Thursday, 26 August 2010

Deploy to Tomcat with no Downtime

Java web applications hosted in tomcat, can have a considerable startup time, particularly when libraries such as hibernate are used. Unless you have a large scale web site with multiple web servers, this means that deploying a new version of the application means a restart of the tomcat server, and this means downtime for the application.

It is however possible to eliminate this downtime by making use of tomcat's clustering capabilities.

The idea is that we define 2 tomcat instances in a cluster, fronted by the Apache web server. In normal operation1 only one of these tomcat instances is running. When we are ready to deploy a new release to the server, we deploy the war file to the tomcat instance that is not currently running. We start up this instance which then joins the cluster and has all the session information from the existing instance replicated to it. We can now test our application by connecting directly to the tomcat http connector ports.

Once we are happy that the application has deployed successfully, we switch the apache configuration to send all requests to the updated instance. As this has the session information replicated to it, users do not experience any downtime. Once the original instance has finished processing all of it's requests, it can be shutdown.

Should there turn out to be a problem with the release we have just performed, it is a simple matter to startup the old instance and change the apache configuration to switch back to the old instance.

With some clever scripting it is possible to manage deployments of different web applications within the cluster using the same techniques.

We can now perform deployments to our live servers without fear of downtime or unexpected errors. This can have a profound effect. No longer do we try and roll a number of features up into a single release, but can release more frequently increasing the rate at which we deliver useful features to our clients.

I will post another article on the details of the cluster configuration we have used detailing how to disable multicast (which does not work on Amazon EC2)

No comments: