|
|
This topology is very similar to using multiple cells, so the considerations stated in 5.3.1, Multiple cells environment also apply for this scenario. For a single cell, multiple clusters topology the isolation of a branch means the isolation of a cluster.
|
Important: This topology has a major drawback and, thus, is not a recommended approach. In order to have the same application running on two clusters in one cell, you actually need two differently deployed instances of the same application. It is very important that your application design or development allows for this. For example, there must be no hardcoded information, such as JNDI references, in the application. Deployment is more difficult for the second instance of the application, several modifications must be made. For example, for the second installation, we need a different context roo and different resource mappings (EJBs, datasources, and so forth). You might also need to use different virtual hosts. Because it is possible to configure multiple cells on only two physical machines, we strongly recommend that you use the multiple cells approach rather than the multiple clusters approach. |
Depending on your topology, you might be able to achieve the isolation of one cluster at the Load Balancer level or at the Web server plug-in level. See Updating a WebSphere application and static content on the HTTP server for more information about how to edit the plugin-cfg.xml file to isolate appservers.
Figure 5-2 shows such a topology.
Figure 5-2 WebSphere topology with a single cell and multiple clusters
The high-level approach for an application update is as follows:
1. Make sure no new requests are sent to the first cluster (for example by setting the appserver's weights to 0). Wait until all active sessions have expired. This is needed because there is no failover from one cluster to the other.
| 2. | Stop the cluster when all requests are finished. |
| 3. | If change static content that is located on the HTTP server: quiesce, then stop one HTTP server at the Load Balancer level. |
| 4. | Update the application on the stopped cluster and update static content on the stopped HTTP server. |
| 5. | Make sure the updated HTTP server only sends requests to the updated cluster (for example by mapping only this HTTP server to the application using the Administrative Console or by changing the plugin-cfg.xml file). |
| 6. | Restart the HTTP server and appserver cluster. |
| 7. | Repeat steps 1 to 6 for the second cluster and HTTP server. |
| 8. | Change the application modules mapping/plug-in file back to its original state so both HTTP servers can send to both clusters again. |
