14.5.6 Rolling out application updates to a cluster

The new Rollout Update feature allows you to roll out a new version of an application, or part of an application using the techniques described previously, to a cluster. The Rollout Update feature takes care of stopping the cluster members, distributing the new application, synchronizing the configuration, and restarting the cluster members. The operation is done sequentially over all cluster members in order to keep the application continuously available.

When stopping and starting the cluster members, the Rollout Update feature works on node level, so all cluster members on a node are stopped, updated, and then restarted, before the process continues to the next node.

Because the Web server plug-in module is not able to detect that an individual application on an appserver is unavailable, the Rollout Update feature always restarts the whole appserver hosting the application. Because of this, if HTTP session data is critical to your application, it should either be persisted to database or replicated to other cluster members using the memory-to-memory replication feature.

The order in which the nodes are processed and the cluster members are restarted is the order in which they are read from the cell configuration repository. There is no way to tell the Rollout Update feature to process the nodes and cluster members in any particular order.

Assume we have an environment with two nodes, amsterdamNode1 and amsterdamNode2, and a cluster called HelloCluster, which has one cluster member on each node (HelloServer1 on amsterdamNode1 and HelloServer2 on amsterdamNode2). Assume we have an application called HelloApp deployed and running on the cluster. To update this application using the Rollout Update feature we would do the following:

1.	Select Applications  | Enterprise Applications. Select the application to update and click the Update button.

2.	On the Preparing for the application installation window, select the appropriate action depending on the type of update. In this example, we will update the entire application EAR to a new version, so we select the Replace the entire application option.

3.	Select either the Local file system or Remote file system option and click the Browse button to select the updated EAR file. Click Next.

4.	Proceed through the remaining windows and make any changes necessary. For information about the windows, see Deploying the application. On the Summary window, click Finish.

5.	When the application has been updated in the master repository, the status window shown in Figure 14-11 is displayed.

Figure 14-11 Preparing for application rollout

You then have two options to start the rollout action:

Click the Rollout Update link.

Click the Manage Applications link and on the Enterprise Applications window, select the application and click the Rollout Update button.

Do not click the Save to Master Configuration link or otherwise save the configuration yourself. The Rollout Update will do that for you. If you save the configuration yourself, the rollout update action will be canceled and it will be handled as a normal application update.

During the rollout, the window in Figure 14-12 is displayed in the status window.

Figure 14-12 Rolling out an application

For each node, the cluster members are stopped, the application is distributed, and they are restarted. When the rollout has completed (the last message says "The application rollout succeeded", click Continue.

6.	If the application update changes the set of URLs handled by the application (servlet mappings added, removed, or modified), make sure the Web server plug-in is regenerated and propagated to the Web server.

The automatic file synchronization of the node agent is temporarily disabled during the rollout process and then re-enabled afterwards, if it was previously enabled. The Rollout Update feature works regardless of the automatic file synchronization setting. However, in production systems, the automatic synchronization is often disabled anyway to give the administrator greater control over exactly when changes made to the cell configuration are distributed to the nodes.

Although the Rollout Update feature makes it very easy to roll out an application to a cluster while keeping the application continuously available, make sure that your application can handle the roll out.

For example, assume you have version 1.0 of an application running in a cluster consisting of two appservers, server1 and server2, and that HTTP session data is persisted to a database. When you roll out version 2.0 of the application and server1 is stopped, the Web server plug-in redirects the users on server1 to server2. Then, when server1 is started again, bringing up version 2.0 of the application, the plug-in will start distributing requests to server1 again. Now, if the application update incurred a change in the interface of any class stored in the HTTP session, when server1 tries to get these session objects from the database, it might run into a deserialization or class cast exception, preventing the application from working properly.

Another situation to consider is when the database structure changes between application versions, as when tables or column names change name or content. In that case, the whole application might need to be stopped and the database migrated before the new version can be deployed. The Rollout Update feature would not be suitable in that kind of scenario.

So it is very important to understand the changes made to your application before rolling it out.