IBM BS029ML - WebSphere Portal Server Self Help Manual page 40

Two independent WebSphere Cells (Cell A and Cell B).
Each WebSphere Portal Server cluster consists of at least two physical nodes per cluster
or cell (so that each cluster is in highly available its own right).
The WebSphere Plug-in resident in each HTTP Server only routes requests to the cluster
members for the immediate Portal Cluster.
Two independent WebSphere Network Deployment Manager (Deployment Manager)
instances, one per WebSphere Cell, are collocated on the same physical node.
A separate release database domain (releaseAusr and releaseBusr) exists for each
WebSphere Portal Server cluster or "Lines of Production" (Portal Cluster A and Portal
Cluster B), maintaining indenpendant configuration data for each.
The remaining database domains (communityusr, customizationusr, wmmusr, fdbkusr,
lmdbusr, and jcr) are shared between each WebSphere Portal Server cluster or "Lines of
Production" to maintain a consistent user experience. Note that the JCR Repository exists
in a different database.
The environment also hosts a LDAP directory server (not shown), which is highly
available, for maintaining the registered user base.
It is worth noting that a dual clustered architecture will require twice as much administration
as a single clustered deployment. Furthermore, in order to keep each "Line of Production" in
synchronization, a staging environment plays an important part for preparing build
promotions. Such tools as XMLAccess and Release Builder must be utilized to ensure
consistency between the different "Lines of Production" or clusters.
The geographically deployed architecture
As WebSphere Portal Server has evolved, one requirement that has continually been
requested has been the ability to deploy an architecture in geographically distributed fashion.
With the release of WebSphere Portal Server V6.0.x, this requirement is now a possibility.
Such a requirement, however, raises the question about how best to design an operational
architecture that caters for such a "global deployment".
Not every WebSphere Portal Server deployment with a geographically scattered workforce
requires that the physical servers themselves are geographically dispersed. Indeed, many
internet facing Portals may be country or region specific, but by the very nature of the internet
are accessible worldwide. However, when the demands of an implementation start to include
the very integration points that a Portal brings together, partitioning across geographies
becomes a necessity. Aspects, such as high availability and disaster recovery, are also
influencers for considering a distributed implementation. For example, partitioning a
WebSphere Portal Server deployment between Europe and North America becomes a
prerequisite when each major geography maintains the local services and back-end systems
that are effectively accessed through the Portal. The idea of a geographically deployed
architecture can also be considered in terms of a split between multiple data centers, even
when those data centers exist within close proximity to one another (across the street or
across a city).
With the introduction of database domains in WebSphere Portal Server V6.0.x, greater
flexibility was made possible in terms of the permissible operational architecture. As such, the
distinction between release, community, and user customization data has made it possible to
achieve a truly "global deployment". Readers familiar with previous versions of WebSphere
Portal Server will recall that it was not possible to split the Portal database between multiple
redundant clusters, located potentially in different geographies, and to maintain a consistent
user experience. Indeed, such an architecture when deployed sacrificed the ability for a user
to make any customization or personalization modifications, as the changes simply could not
26
IBM WebSphere Portal V6 Self Help Guide