IBM BS029ML - WebSphere Portal Server Self Help Manual 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.
de facto
In isolation, this architecture should be considered the 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