IBM BS029ML Self Help Guide - Page 43

caveat that WebSphere Portal Server prior to V6.0.x did not support database domains, the possibility that such data could be readily shared between Portal instances was not feasible; the only option was the one-way transfer of such data between environments. Finally, the need to undertake any so-called backend plumping, to those systems and services being integration through Portal, warranted significant time and effort to ensure a satisfactory outcome. Environments with multiple personalities This implementation deploys both a production and a staging environment. The staging environment, however, has multiple personalities and pulls "double duty". It is primarily the staging environment but also acts as a standby pseudo-production environment for times of scheduled maintenance to the production environment. There is obviously some planning required to ensure that the environment is up to date with configurational data from the production environment, prior to being put into service. The same limitations regarding the replication of data between environments, as described under the Flip-Flop approach, also hold true. Furthermore, this approach is really only viable if the staging environment mimics the production environment in terms of overall system resources and capacity. It is also vitally important to recognize that it is not the actual staging instance of WebSphere Portal Server, as such, that handles the temporary production load. Rather, such an implementation necessitates the installation of a secondary instance of WebSphere Portal Server alongside that of the staging instance. Without such a configuration, production and staging data would merge and impact the underlying integrity of the entire solution. 2.4.3 The dual cluster with two lines of production architecture The deployment of a dual clustered WebSphere Portal Server V6.0.x architecture with "Two Lines of Production" brings about distinct advantages when maintenance and operational continuity are concerned. Indeed, the architecture sets the new Gold Standard for Availability with WebSphere Portal Server V6.0.x. The approach makes full use of the WebSphere Portal Server V6.0.x product enhancements that introduce the concept of database domains. As such, one "Line of Production" can be effectively taken off line, as and when required, without impacting the remaining "Line of Production". Furthermore, as each "Line of Production" has its own release database domain, while the user community and customization database domains are shared, this makes it possible to have two different releases in production. The deployment of a dual clustered WebSphere Portal Server V6.0.x based architecture usually consists of a minimum of four physical nodes. The nodes are split into two halves (each half will consist of two physical nodes and will host what will effectively be a separate but identical Portal cluster). Customization and community data is shared between each peer cluster permitting user customization updates made in one cluster to be available to the peer. However, release data is maintained on a per cluster basis. Further details can be found in "The dual cluster with two lines of production architecture" on page 24. Attention: It is important to recognize that the deployment of a dual clustered WebSphere Portal Server V6.0.x architecture with "Two Lines of Production" introduces special considerations in terms of code deployment and release management. Such a requirement is needed to ensure that each "Line of Production" remains consistent and identical in terms of overall user experience. This is achieved by assembling a build, or release, first in a staging environment and then by promoting the build, or release, to each Line of Production. Chapter 2. Architecture and planning 29