IBM BS029ML - WebSphere Portal Server, Self Help Manual

Page: 41 / 242

Chapter 2. Architecture and planning
27
be propagated between clusters. This in part was attributed to the fact that the internal object
IDs associated with the various elements of a deployment could not be guaranteed to be
unique. Any attempt, therefore, to deploy a bi-directional database replication technique was
further hindered. To overcome this constraint, it was mandatory that all Portal cluster
members, participating in the same Portal instance, accessed the same centralized database.
However, the performance considerations of accessing a centralized database across the
WAN from geographically dispersed Portal servers made this approach impractical in many
environments.
In addition to the separation of Portal data into distinct database domains with WebSphere
Portal Server V6.0.x, which represents an acknowledged product improvement, it should also
be recognized that Portal data can now be shared between different Portal clusters and the
very cluster members that exist within them. Such database domains can now be deployed in
a peer-to-peer manner using techniques like queue replication or 2-way SQL replication in
order to provide a global deployment capability, where user personalization is automatically
made available to all Portal clusters in all geographies. In this manner, WebSphere Portal
Server V6.0.x also allows users to experience portability should they temporarily access the
Portal solution from another geo (branch or office location).
The WebSphere XD deployment architecture
The latest WebSphere Portal Server V6.0.1 deployment option includes support for
WebSphere Extended Deployment V6.0.2, or WebSphere XD for short. Such an architecture
makes it possible to dynamically start and stop additional WebSphere Portal Server cluster
members, or dynamic clusters in the WebSphere XD sense, as and when workload demands.
In addition, the On-demand Router (ODR) component of WebSphere XD can be utilized to
route requests based on priority and user rules.
For more information about WebSphere Extended Deployment refer to:
򐂰 WebSphere Extended Deployment (XD) 6.0.2 support for WebSphere Portal Server, found
at:
http://www.ibm.com/support/docview.wss?uid=swg21264596
򐂰 WebSphere Extended Deployment (XD) 6.0.x Information Center, found at:
http://www.ibm.com/software/webservers/appserv/extend/library/library60x.html
2.4 Portal deployment considerations
Three principle methods exist for implementing maintenance in a WebSphere Portal Server
V6.0.x production environment.
2.4.1 In-situ maintenance procedures
As the name suggests, in-situ maintenance describes the process of undertaking
maintenance in a target environment without the inclusion of an additional environment for
providing operational continuity. For the most part, such maintenance may simply be
Important: The implementation of a multi-clustered WebSphere Portal Server V6.0.x
architecture that sees the deployment of individual clusters in each geography to support a
truly "global deployment" mandates the use of the same LDAP directory server in all
geographies. The LDAP directory server may, however, be replicated for redundancy
purposes. This requirement is necessary to maintain uniqueness between Portal users.