How to achieve near to zero downtime deployment for WCS in ND mode

Today I will walk through as to how we can achieve a near-to-zero downtime deployment of Websphere Commerce application on production environment with deployment manager (a.k.a node manager).

In my previous posts, I mentioned that the deployment manager holds the master copy of the websphere commerce EAR artefacts.  The deployment manager is responsible for keeping all the nodes, configured with it, synchronized. Any deployments to be done on the production should be done to the deployment manager itself (using the script deploy.sh usually a script that calls an ant task).

Note: Never deploy directly on the node as this may corrupt the EAR.

To achieve a near-to-zero downtime deployment, follow the steps below. The purpose is to make the site available most of the time to the end-users with minimal interruption. For the purpose of simplicity I am assuming here that there are two nodes namely “Node A” for “Server A” and “Node B” for “Server B” and a deployment manager in my environment. Also, I am assuming two webservers “Web 1” and “Web 2” which use round robin method to redirect requests to application server.

1. Build the websphere commerce zip/ear file using the websphere commerce build and deploy (WCBD) instance.

2. Before starting the deployment, ensure that webservers are configured to route the requests always to one of the servers, in this case “Server B”.

3. Stop the node agent on “Node B” so that the deployment manager does not have the status availability for this node. To stop à login to the server (Node B) and issue stopNode.sh / stopNode.bat command. This will not stop the request processing coming through from the web server because the server is still running.

4. Now use the deployment script to deploy websphere commerce. This script will first deploy on to the deployment manager and then propagate the changes to “Node A” (Node agent on Node B is currently inactive). When the changes are being propagated, the WC application on the server restarts.

5. Ensure that the propagation is complete. This can be done by looking at the server and application status on the node manager console and also by monitoring the EAR size on the application server. Stop and start the application server A.

6. Once deployment to “Node A” is complete, configure webservers to redirect all requests to Server A.

7. Now start the node agent on “Node B”. This can be done using startNode.sh / startNode.bat. Once the node is started, the deployment manager synchronizes “Node B” with the new deployed EAR.

8. Once the deployment is complete on “Node B”, then configure the webservers to route requests to both application servers in a round-robin way (or whatever is the load balancing algorithm)

Note that the webservers need to be restarted 3 times for the configuration to take effect in step 2, 6 and 8. But this is much faster than restarting the application servers.