|
|
This is the most simple topology to administer and ideal for an environment that accepts downtime while updating an application. The downtime is related to the fact that there is no option to isolate a branch for the update.
If the cluster members are on different nodes (horizontal scaling), then this topology also allows for an application rollout update which means that the different nodes are updated one after the other while having the application up and running on the other node or nodes. However, the rollout update is not always the right solution, for example, when it comes to a major release update with changes to the back-end data or if your new application version cannot handle changes to the persistence layer gracefully. See 5.4.2, Rollout update (new feature of WebSphere V6) for more information about this function.
Changes to the cluster configuration or application must always be handled with care, but this is especially true when having only one cluster available because there is no other cluster and thus application version available in case something goes wrong.
Figure 5-3 shows the single cell, single cluster topology.
Figure 5-3 WebSphere topology with a single cell and single cluster
