IBM BS029ML Self Help Guide - Page 41
Portal deployment considerations, 2.4.1 In-situ maintenance procedures
![]() |
View all IBM BS029ML manuals
Add to My Manuals
Save this manual to your list of manuals |
Page 41 highlights
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). 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. 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 Chapter 2. Architecture and planning 27
![](/manual_guide/products/ibm-bs029ml-self-help-guide-6d3dd71/41.png)