Configuring the tomcat cluster for mid tier

Clustering is a function of the application server and not of the web application. However, not all java web applications can be deployed in a clustered environment. The requirement for a java web application to be deployable in a clustered environment is that the HTTP session object is serializable. The mid tier is has this requirement as of version 7.06.04.

In this topic, we cover only the essentials of clustering the Apache Tomcat and deploying the AR mid tier in a clustered environment. For other web/application servers, consult your vendor documentation for server clustering and deployment of a clusterable web application.

A cluster is a set of members or nodes acting collectively as a single unit. A web cluster is a cluster of web/application servers.

Since we focus only on the Apache Tomcat, a Tomcat cluster is a collection of deployed Tomcat instances configured to act as a cluster. In practical terms, this means every user session of a member node is duplicated and synchronized to all other member nodes so that if a node fails, the web user's requests can be seamlessly bound to another node by the load-balancer without the user's intervention. In most cases, this means the web user does not need to re-login or re-perform an action. The exception to this behavior is when an HTTP request is already in-flight to a failed node, but before the failure was detected so that the routing transition to an available node has yet begun.

A java web application is clusterable or distributable if the HTTPSession class implements the java Serializable interface. This is so that each user session object is transportable to be duplicated on every node of a configured web cluster.

Requiring the Serializable implementation of a web application is generally insufficient to be distributable because in practice, the JVM CPU/heap cost of duplicating and synchronizing the user session objects across all nodes can be significant, especially when a cluster has 4 or more nodes. (Note that all user sessions of a cluster exist on every node.) A web application optimized for clustering must minimize the changes to the session object (so that the Tomcat cluster need not duplicate and synchronize the user session object frequently across all nodes) and minimize the size of the session object (so that the cost of duplication is also minimized across all nodes).

The AR mid tier web application is clusterable since version 7.6.04; however, the clustering optimization is implemented in version 9.0 and higher.

To deploy the mid tier in a Tomcat cluster, you need to configure:

1. A Tomcat cluster
2. The deployment of the mid tier to be distributable, and 
3. The load-balancer to change routing on detection of a node failure.

Tomcat cluster configuration

For the detailed steps and recommendations, see  Configuring a cluster .

Mid Tier distributable deployment configuration

There are 2 methods to mark a web application as distributable for each Tomcat instance of the cluster:

The first method and the easiest to maintain is to add the XML attribute/value distributable="true" to the deployment descriptor of the web application: For the AR mid tier, open the <tomcat dir>/conf/Catalina/localhost/arsys.xml file and add the XML attribute/value distributable="true".

The second method and the less maintainable is to add the XML tag <distributable />  as a child tag of the XML tag <web-app> in the file <mid tier dir>/WEB-INF/web.xml 

Save the edited file and restart Tomcat.

Load balancer routing upon node failure

Once you have a Tomcat cluster running with the mid tier web app deployed as distributable, we need to configure the load-balancer to distribute the user load across the cluster nodes. See Fine tuning the web infrastructure for the Mid Tier for configuration of the load-balancing scheme. We also need to configure the load-balancer to monitor the health of each node of the cluster and redistribute the HTTP requests on an unavailable node to an available node. Consult your load-balancer vendor documentation for the health monitoring.

In the BMC Performance Lab, the monitoring heartbeat is set at 15 seconds interval with 2 retries on a failure. This introduces a roughly 20 seconds indeterminate window, the interval whence an HTTP request might be routed to a failed node. You can configure the heartbeat at a higher rate depending on your requirement. However, note that more frequent heartbeats introduces extra overhead.