IBM BS029ML Self Help Guide - Page 42

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