IBM BS029ML - WebSphere Portal Server Self Help Manual page 38

The multiple clustered architecture
New to WebSphere Portal Server Version 6.0.1 is the ability to architect multiple Portal
clusters within the same WebSphere cell. Indeed, the WebSphere Portal Server Version 6.0
Information Center describes just such an architecture and the necessary configuration tasks
needed to implement such a deployment.
It is, however, important to understand that such an architecture is subject to a number of
inherent limitations. Most important, despite the fact that the Information Center states that it
is possible to federate multiple, independently configured Portals into the same WebSphere
cell and that it is possible to manage such clusters from the same cell, it must be recognized
that only a single J2EE enterprise application, of a unique name, can be deployed into a given
WebSphere cell at any one time. Furthermore, all J2EE enterprise applications are
cell-scoped. This limitation makes it impossible to deploy different versions of the same
enterprise application against the different Portal clusters within the same cell, as the case
might be during periods of 24x7 maintenance. This extends to WebSphere Portal Server
itself, which consists of a number of enterprise applications that make up the effective runtime
and also to the very Portlet applications deployed within the solution.
In other words, enterprise applications are shared across the WebSphere cell, regardless of
the presence of multiple Portal clusters or not. As a consequence, it is not possible to upgrade
one Portal cluster in isolation from another, as the underlying enterprise applications and
supporting class libraries are common to both. Attempting to do so runs the risk that
incompatibilities will result, potentially bringing down the complete environment.
It is plausible that such a WebSphere Portal Server architecture is practical for the purposes
of providing different applications and services between Portal clusters, which might be the
case with each Portal cluster supporting a different line of business.
The dual cluster with two lines of production architecture
Deploying either a single clustered instance or a multiple clustered instance within the same
WebSphere Cell of WebSphere Portal Server V6.0.x would at first glance appear to be the
most logical architectural choice for most implementations.
However, when 24x7 availability is considered as a non-functional requirement, both
architectures fall short of the mark. This is not to say that both architectures are not capable
of maintaining a continuous level of operation during periods of either scheduled or
unscheduled maintenance. Indeed, WebSphere Portal Server V6.0.x has introduced
considerable improvements over previous versions in this very respect. Rather, the
considerations are associated with the comfort factor demanded by the very organizations
that typically manage such implementations. For those organizations that do not mandate
24x7 availability, which should not be confused with high availability, deploying a single
clustered instance of WebSphere Portal Server remains an acceptable choice.
The deployment, therefore, of a WebSphere Portal Server V6.0.x dual clustered architecture
represents a significant architectural enhancement for the majority of organizations looking to
meet the needs of continuous operation with a 24x7 availability requirement. Indeed, such an
architecture represents the new WebSphere Portal Server V6.0.x Gold Availability Standard.
The primary enabling feature of this capability is the presence of two distinct WebSphere
Portal Server clusters, each deployed within separate WebSphere cells. This makes it
possible to perform maintenance on one Portal cluster, while the other continues to service
user requests. The benefits of adopting such an architecture are that there are effectively two
"Lines of Production". This allows for continuous operation during periods of maintenance,
albeit at reduced capacity, without the need for a dedicated failover environment. One "Line of
Production" can effectively be taken off line, as and when required, without impacting the
remaining "Line of Production". Critically, the ability to share user customization and
24
IBM WebSphere Portal V6 Self Help Guide