Minimizing downtime during deployment

Your WebSphere Commerce site is an integral part of your company's revenue flow, so disruptions and any downtime should be minimized. Moreover, taking down a site for long periods of time or frequently, reflects on the store's credibility and impacts the customer's shopping experience with and potential return visits to the site.

WAS provides the clustering functionality that allows you to:

Typically when deploying changes to the application, the application needs to be restarted. For example, if you change a class file, it must be reloaded and the only way to do this is to restart the application. You must ensure that changes like this can be made without impacting the end users of the application.

WAS 6.0 introduces a mechanism that works in combination with the clustering feature to allow you to do application updates while still ensuring that the application is available. This feature is called roll out updates.

Consider the following environment: You have a WebSphere cluster with three nodes; each node is running a single application server process. These servers comprise your cluster; that is, they are all running the same application and the workload is distributed amongst them. If one of the servers is stopped, the others will pick up the workload so that it appears as though nothing is down. Roll out updates uses this failover feature to ensure continuous availability of the application while you are updating it.

The overall procedure can be described in stages: packaging your changes, performing database updates, deploy Web server assets, and deploy WAS assets.

 

Stage 1: Prepare your deployment packages

Firstly, prepare your deployment packages for your custom Enterprise Application (EAR) file using one of the three packaging options.

 

Stage 2: Perform database updates

Perform any database updates that are required. It is imperative that these are done before deployment of the Application Server assets. You could be deploying new EJB files that will be accessing new tables. If the tables and data are not present, the end users will see unexpected behavior. You will complete these database changes while the application is running, so be mindful of the changes you are making and the impact they have to the application. Consider if your database changes are so significant that you do not want to take the risk of doing a live deployment and stop the application instead.

 

Stage 3: Deploy Web server assets

Deploy any new Web server assets. Again it is imperative that these are deployed first. Your application server assets can refer to new static content (such as a new image file or cascading style sheet). You need these in place before any application server assets that refer to them are deployed. Similar to database assets, the new Web server assets must be compatible with both the current version and the new version of application server assets.

 

Stage 4: Deploy WAS assets

In Deploy custom J2EE assets, the synchronization process (Sync) was outlined. To do the roll out update, WAS controls the synchronization process carefully to ensure that only one node goes down at a time so that it can be updated with the new assets. Here is the general procedure:

  1. Update the J2EE application with your new assets. If you have multiple deployment packages, ensure that you update the application with all of them before your save the new configuration.

  2. Disable automatic synchronization for the nodes that are part of the cluster running the application.

  3. For each node:

    1. Stop all servers on that node

    2. Synchronize the node

    3. Start all servers on that node

    4. Wait for application expansion

    5. Move to the next node

    6. Reset the automatic synchronization to the original configuration

During this process, each node is brought down, the code is updated on that node and then the application is restarted. This type of deployment will take longer due to the orchestration of the updates on the nodes, but for the end user of the application it will look as if the application was never down.

A key aspect to these updates is that while an update is in progress, there are different versions of the application running and customers could get switched between them. You must be aware of this and ensure that the types of changes you are making do not cause problems for the customer as they get switched between servers. For example, you introduce a new controller command and a JSP file that refers to it. The customer is on the server with the new JSP file, and submits a form that sends a request to this new controller command but is directed to a server that does not yet have the new code yet. The customer will see an error page.

If you are making a significant change to your site, it is better to perform the deployment at off-peak hours to ensure that the changes can be made with minimal impact to the users. This means that you have to take some downtime.

WebSphere application server provides a simple task that performs rolling updates for you. Here is a sample JACL script that can be used to do a rolling update:

$AdminApp update WC_prod partialapp {-contents /deployments/2007-01-01a/partialApp.zip}

$AdminConfig save

$AdminTask updateAppOnCluster {-ApplicationNames WC_demo}

For information on the updateAppOnCluster task see Commands for the AdminTask object.

Related tasks

Stages of deploying customized assets