Instructions for specific types of compatible upgrades | Maintenance Web page for site downtimes


Incompatible upgrades


+

Search Tips   |   Advanced Search

There are certain types of upgrades at the Web and application server tier that make it impossible to update the Web servers (or the application servers) one by one.

If a new application version with major differences from the current application is to be deployed, old static content might not be compatible to the new JSPs, and vice versa. Further, it might not be possible to switch between updated and not yet updated Web servers (by Load Balancer), or between updated and not yet updated application servers (by the IBM HTTP Server Plug-in on the Web server) within one user session. (Switching might lead to application flow and GUI inconsistencies, depending on the nature of the upgrades.)

If this is the case, it might still be okay to use the old version of the application (for example, old static content, old application) and the new version (for example, new static content, new application) in parallel in different user sessions. For example, one user could see the old application while another user already sees the new application.

If this is okay, an upgrade may be performed as follows:

  1. Configure Load Balancer server affinity and Web server to application server affinity such that a client always connects to the same Web server (within a certain sticky time) and the application servers are divided into two separate groups, as shown in Figure 27-5.

    Refer to 19.3, Server affinity, for details on how to set up server affinity in Load Balancer. For performance reasons, server affinity should be enabled here all the time.

    Binding Web servers to certain application servers can be done by editing the plug-in configuration:

    • First disable automatic plug-in propagation for your Web servers in the Network Deployment Manager administrative console for each Web server by navigating to...

      Servers | Web servers | WebServer_Name | Plug-in properties

      ...and deactivating...

      Automatically propagate plugin propagation

      See Figure 10-3. When you are done with all Web servers, save your changes to the master configuration.

    • On each Web server, one -by-one, use the process for compatible upgrades described above (see 27.2.2, Compatible upgrades). Back up and then edit the plug-in configuration file (WC_Install_Dir/instances/Instance_Name/httpconf/plugin-cfg.xml) as the non-root_user. Find the definition for your application server cluster and comment out (using <!-- and -->) the server elements belonging to the other group. Example 27-4 shows our plug-in configuration with one of the two servers in the cluster commented out. 
      ...
<ServerCluster Name="Cluster_Name" ...>
 <Server CloneID="11tf0t8ul" Name="Node1_Name_Cluster_Member1" ...>
 xxxx<Transport Protocol="http" .../>
 xxxx<Transport Protocol="https" ...> ... </Transport>
 </Server>
<!--  <Server CloneID="11trs2mtc" Name="Node2_Name_Cluster_Member2" ...>
 xxxx<Transport Protocol="http" .../>
 xxxx<Transport Protocol="https" ...> ... </Transport>
 </Server> -->
 <PrimaryServers>
 xxxx<Server Name="WC_demo_node_WC_demo_01_goro"/>
<!-- xxxx<Server Name="goro2Node01_WC_demo_01_goro2"/> -->
 </PrimaryServers>
</ServerCluster>
...

    • Save the file and restart your Web server.

      HTTP sessions and dynamic cache objects should also only be replicated within the two groups of application servers, and not between members of different groups, in case sticky time is exceeded at the Load Balancer, but the HTTP session is still valid. If sticky time is expired and a client is diverted from a not-yet-updated Web server to an updated Web server, a new session should be started (or a notice should be displayed informing the user about an expired session).

      Refer to "HTTP session management" and "Configure distributed session management" in WebSphere Application Server V6 Scalability and Performance Handbook, SG24-6392, for details on setting up session replication and to "Cache replication" in WebSphere Application Server V6 Scalability and Performance Handbook, SG24-6392, for details on setting up cache replication. Essentially, you need to do this:

      • Set up an additional replication domain (one was created when setting up the cluster). (Go to the administrative console and select Environment Æ Replication domains.)

      • On each application server, configure one of the two replication domains for session and cache replication, such that there are two equally sized groups of servers that match the groups configured for Web server to application server affinity above. (Go to the administrative console and select Servers Æ Application servers Æ AppServer_Name Æ Web Container Settings Æ Session management Æ Distributed environment settings Æ Memory-to-memory replication Æ Replication domain and Servers Æ Application servers Æ AppServer_Name Æ Container Services Æ Dynamic cache service Æ Consistency settings Æ Full group replication domain.) Save your changes and synchronize with all nodes.

      • One by one, restart your application servers.

    • Now quiesce the first group of Web servers, one by one, as described in 27.2.1, Quiescing a Web server.

    • Upgrade the first group of Web servers and application servers.

    Typically, the application tier upgrade is performed as EAR deployment or update on the Network Deployment Manager. To prevent the upgrade from being distributed to the nodes of the second group of application servers, there are two options:

    • Do not check Synchronize changes with nodes when saving the changes to the master configuration, then manually synchronize the nodes of the first group in the System administration Æ Nodes view. (Select the nodes and click Synchronize.)

    • Stop the nodeagents in the servers of the second group before performing the upgrade. As non-root_user, execute the following command:

      WAS_Install_Dir/profiles/Profile_Name/bin/stopNode.sh

  2. Restart the first group of application servers and Web servers.

  3. Unquiesce the first group of Web servers (see 27.2.1, Quiescing a Web server). New users will now be able to see the new application.

  4. Quiesce the second group of Web servers. All users will now see the new application.

  5. Upgrade the second group of Web servers and application servers.

    The EAR deployment or update has already been performed on the Network Deployment Manager. (See step 3.) Now the nodes of the second group of application servers need to be synchronized. Depending on which option you chose in step 3, do one of the following:

    • Go to System administration | Nodes and synchronize all nodes (select the nodes and click Synchronize) in the second group, so the EAR update is copied to each of the servers.

    • Restart the nodeagents on the servers in the second group by executing the following command as non-root_user:

      WAS_Install_Dir/profiles/Profile_Name/bin/startNode.sh

    The changes should be automatically synchronized after starting the nodeagents.

  6. group of application servers and Web servers.

  7. Unquiesce the second group of Web servers.

  8. Unconfigure Web server to application server affinity by undoing the changes made in step 1:

    • One by one, undo the changes to plugin-cfg.xml on each Web server and restart the Web server.

    • Using the Network Deployment Manager administrative console, change session and cache replication back to just one replication domain. Save your changes and synchronize with all nodes.

    • One bye one, restart your application servers.