IBM BS029ML Self Help Guide - Page 36

There are several approaches for clustering a WebSphere Portal Server Version 6.0.1 implementation. The following section outlines each in detail. The single clustered architecture In a standard WebSphere Portal Server V6.0.x clustered architecture, two or more separate WebSphere Portal Server nodes are clustered together to form a single WebSphere Portal Server instance. In turn, each node is capable of supporting multiple vertical cluster members to better leverage the available system resources and to achieve the demands of scaleability. High Availability is thus accomplished not only through the vertical clustering of WebSphere Portal Server, but also by way of horizontal clustering of WebSphere Portal Server to safeguard against the outage of an actual physical node, and the replication of the database and LDAP directory servers, respectively. As such an architecture utilizes the same user customization, community, and release data throughout an environment, any user customization made against one Portal cluster member by a user would then be available to the same user, as and when that user accesses any of the other cluster members participating in the same Portal cluster. It is acknowledged that under normal conditions, session affinity is maintained against the same Portal cluster member until such time that a user terminates his or her session, or the Portal cluster member becomes unavailable, either through a deliberate or an unscheduled outage. In isolation, this architecture should be considered the de facto WebSphere Portal Server V6.0.x architecture of choice. However, maintaining continuous operation during periods of scheduled or unscheduled maintenance requires careful consideration. As this implementation does not typically include any redundant hardware, either in the form of a fully redundant production environment or a "double duty" staging environment, maintenance requiring an uninterrupted level of service (also referred to as 24x7 availability) must be performed as a multi-step process. As such, this involves disabling the automatic file synchronization service from the WebSphere Deployment Manager administrative admin console and then stopping the node agent on each of the nodes participating in the cluster. Maintenance is then performed on each node in turn, starting with the primary node, by first gracefully quiescing user requests from each node by modifying the WebSphere Web server plug-in load balancing weighting (when multiple cluster members exist on the same node, all must be stopped at the same time) while the remaining node or nodes in the cluster continue to honor user requests. The final step is to synchronize and restart all of the nodes one at a time, not forgetting to re-enable the automatic file synchronization service. While this approach represents a distinct improvement over the 24x7 maintenance procedures applicable to previous versions of WebSphere Portal Server, the complexities of performing maintenance and maintaining an uninterrupted level of service arguably remain high risk for many organizations. As such, the decision to implement this approach rests with the comfort factor of each particular organization. Figure 2-2 on page 23 illustrates the system topology needed for a WebSphere Portal Server V6.0.x single clustered architecture. 22 IBM WebSphere Portal V6 Self Help Guide