Two Sets Of Production Environments - IBM BS029ML - WebSphere Portal Server Self Help Manual

undertaken during a period of scheduled outage, such as during the weekend or overnight,
when the respective users of the solution may be unaffected by any downtime. Alternatively,
in-situ maintenance can be performed by adhering to the IBM documented 24x7 maintenance
procedure. However, while this latter approach represents a distinct improvement over the
24x7 maintenance procedures applicable to previous versions of WebSphere Portal Server,
the complexities of performing such maintenance, and maintaining an uninterrupted level of
service, arguably remain high risk for many organizations. As such, the decision to implement
the 24x7 maintenance procedure in a single clustered WebSphere Portal Server V6.0.x
environment can only rest with the comfort factor required by each particular organization.
The key differentiator between this and the other maintenance methods described in this
section is that the in-situ procedure does not require an additional environment during the
period of maintenance. Full details for this procedure, including the IBM documented 24x7
maintenance proceedure, can be found in the WebSphere Portal Server Version 6.0
Information Center.

2.4.2 Two sets of production environments

This option considers two sets of production environments, each supporting duplicate
WebSphere Portal Server configurations. It is not implied that either environment shares the
same user community, customization, and wmm database domains in a peer-to-peer fashion,
as is now achieveable with WebSphere Portal Server V6.0.x. Instead, it is characterized by
the replication of all data and artifacts between hosting environments prior to undertaking
maintenance.
As such, the deployment of two sets of production environments has long been an
acknowledged approach for maintaining operational continuity and for addressing disaster
recovery. However, unlike the approach detailed in 2.4.3, "The dual cluster with two lines of
production architecture" on page 29, such a deployment does not normally see both sets of
production servers actively handling the load. It is what is commonly referred to as an
active/passive implementation. Furthermore, the passive environment may also serve the
purpose of addressing disaster recovery.
When considering an architecture based on the selection of two sets of production
environments, there are two sub approaches that are most commonly implemented.
The Flip-Flop approach
One approach for maintaining a continuous level of operation in a WebSphere Portal Server
environment has been with the adoption of a Flip-Flop architecture. Such an architecture
utilizes a second WebSphere Portal Server instance identical to the primary instance. Each
environment is normally clustered and highly available in its own right. During scheduled
maintenance, user requests are first gracefully quiesced over to the secondary instance, or
Flip environment, before Fix Packs and updates are applied to primary instance. With the
successful completion of all maintenance activities to the primary instance, the decision can
be made to Flop the users back or to retain the users against the current secondary instance.
If the latter option is selected, the secondary WebSphere Portal Server environment
effectively becomes the primary instance.
Unfortunately, there are several weaknesses associated with the Flip-Flop architecture that
make the approach somewhat less than straight forward to implement. First, it should be fairly
evident that the procedure requires an additional physical environment. Typically, many
organizations address this issue by collocating the secondary instance, or Flip environment,
on the same hardware hosting their staging environment. Secondly, there is the requirement
to transfer all configurational data, including the very Portlets deployed within the Portal, and
the need to carry across any user customization data between Portal instances. With the
28
IBM WebSphere Portal V6 Self Help Guide