Minimize downtime during deployment
Your WebSphere Commerce site is an integral part of the 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.
WebSphere Application Server provides the clustering functionality that allows you to:
- Balance the workload of the application across several systems. This gives you the ability to scale the application as you grow.
- Failover support. If one of the servers go down, since there are other servers running the application, the end user will see no disruption of the application functionality.
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.
WebSphere Application Server 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 the 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 the changes, performing database updates, deploy Web server assets, and deploy WebSphere Application Server assets.
Stage 1: Prepare the deployment packages
Firstly, prepare the deployment packages for the custom Enterprise Application (EAR) file using one of the three packaging options.
Stage 2: Execute database updates
Execute any database updates 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 the 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 see new static content (such as a new image file or cascading style sheet). You need these in place before any application server assets that see 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 WebSphere Application Server assets
In Deploy custom J2EE assets, the synchronization process (Sync) was outlined. To do the roll out update, WebSphere Application Server 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:
- Update the J2EE application with the new assets. If you have multiple deployment packages, ensure that you update the application with all of them before the save the new configuration.
- Disable automatic synchronization for the nodes that are part of the cluster running the application.
- For each node:
- Stop all servers on that node
- Synchronize the node
- Start all servers on that node
- Wait for application expansion
- Move to the next node
- 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 the 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, see Commands for the AdminTask object.
Related tasks