Enterprise Apache Tomcat 7 Clustering - Designing an Efficient, Reliable and Productive Application

This is the third and final part of my Apache Clustering blog series. In part one, An In-Depth Look at Tomcat's Clustering Mechanisms, we discussed what a cluster is and why your enterprise should cluster. Part two, An Enterprise Tomcat Clustering Guide, was a little more hands-on and it covered the different cluster setups. It also covered how to choose the best setup for your organization. Part three, Designing an Efficient, Reliable and Productive Application Server Cluster, is going to teach you how to create a simple cluster. This blog is not a step-by-step tutorial on cluster creation, but we will provide you with the tools you can use to implement a cluster rapidly and effectively.

Hopefully, by the time you finish reading this blog you should be able to create your own cluster. Whether you have created many clusters in the past or this is your first attempt, we hope that you will be able to learn something, whether it be basic or advanced, from this blog. To limit the liability of your attempt at creating a cluster, you can set up a machine, virtual or physical, just for this task.  

*Note - You can run multiple tomcat instances on a single virtual/physical machine by tweaking a just few settings, mainly port numbers so the instances don't interfere with each other. The configuration of these tomcat instances is well outside the scope of this document, although it is not difficult to accomplish. Settings for the connectors in your server configuration files can be found at the Apache Tomcat 7 website. I have created two server configuration files that you can use to run a simple cluster, just start with two instances of Tomcat 7 and replace the corresponding server.xml file with the ones I have provided here, example 1 and example 2.

No matter what happens, from your configuration being a little out of whack to your entire enterprise cluster crashing, OpenLogic will be there to support you. Based on your ability, we can consult with your company if need be, to create and configure your cluster, in addition to providing for all of your clustering support needs.

 

The fastest way to create a cluster

Tomcat clustering is very simple to setup.  However, if you wish to leverage clustering in your enterprise environment, the default configuration is not going to be the best route for you.  To turn on clustering in your tomcat server all you have to do is add one line of code to your server.xml.

 

<Cluster className="org.apache.catalina.ha.tcp.SimpleTcpCluster"/>

 

Adding this line to your configuration enables clustering with all of the default settings. This would be great if you were not in an enterprise setting.  

You have created a clustered Tomcat instance, but you only have one instance, so it is not a very big cluster. Before we create the next instance we should install the application we want to test on this cluster.

 

Making your web application distributable

With your cluster running, placing a normal application on one server will not trigger propagation to other servers. The idea behind propagation is:  an application is placed on one "node" in the cluster, it is migrated (copied) automatically to other nodes in the cluster. To achieve this we add the following code to the web.xml:

 

<distributable/>

 

This tells tomcat that this application is designed to run on multiple nodes in this cluster.

 

Default Settings of note

All to all session replication: Any session data created on a server will be duplicated to all other servers in the cluster. If you application creates session data for a user, and you have a heterogeneous cluster, the session data will still be replicated across the other nodes. If you recall from last month's blog, a heterogeneous configuration is one that does not have all of the same applications on every node. Therefore, if application A stores session data for a user, and application A is running on server A, but not server B, session data will replicate to server B, even though there is no use for it there.

Default Multicast Setup: The cluster is discovered and maintained via multicast heartbeats. The server will be set up with a default multicast ip address of 228.0.0.4 and a multicast port of 45564. This means, any other nodes that are using the same multicast address and port will see this cluster / node.

 

Determining what is best for your organization

There are certain questions you need to ask when setting up the cluster for your organization. How many users do I have?  How many simultaneous requests do I need to be able to serve?  How many applications am I running? What resources are available on our servers for these applications? The list goes on and on. Only you can figure out what kind of cluster configuration you need.

If you need a large cluster, either because you have memory and processor intensive applications that need multiple servers, or because you serve millions of requests a day, you need to set it up differently than you would a small cluster.

If you need a small cluster, of about one to six nodes, it will be configured differently. The main difference will be the method of session replication.

Whether you are creating a large cluster or a small cluster, the basics are the same.

 

The Basics

The first step is configuring your tomcat instances. You need all of the instances, whether there is 2 or 500, to run properly without being in a cluster. Once your nodes are running, you know they will function in a cluster, and if they don't then something is wrong with your clustering configuration.  

After creating the "Cluster" object and making your web applications distributable, both shown previously in this blog, we need to move on to configuring other settings.

 

The Manager Object

The Manager object controls session replication.  

 

<Manager
 className="org.apache.catalina.ha.session.DeltaManager".../>

 

The "DeltaManager" replicates all changed session data to all nodes of the cluster. The "BackupManager" backs up session data to a specific "backup" node. For large clusters the BackupManager is the option to go with, for smaller clusters it is common to just use the default Delta Manager.

In Tomcat 5 you could not choose the specific session manager for your application. In Tomcat 7 you can define a manager in the cluster configuration, as you could in earlier versions, but you can also define a manager in a web application's context.  

Defining the Manager in your clustering configuration provides a default setting for applications that do not provide their own Manager configuration. For instance, the following code will set all applications in your cluster to use the BackupManager for session replication.

 

<Manager
  className="org.apache.catalina.ha.session.BackupManager".../>

 

 

Channel Send Options

After setting the Manager, you might need to apply a non-default channel send options value. Channel send options is a setting specified on the

Cluster object. For ex.:

 

<Cluster
 className="org.apache.catalina.ha.tcp.SimpleTcpCluster"
                channelSendOptions="6">

 

Channel send options controls how messages are sent between cluster nodes. Are these message sent synchronously, or , in layman's terms, does the thread that sends the message have to wait until the message has sent before continuing to work, in turn, potentially making the users request wait on this message to be sent? Sending the messages asynchronously is when the thread generates and sends the message, but does not stop and wait for this to happen. It does this by spawning a worker thread.

As you can see, this is just one aspect of the channel send options, and it is a lot of information.  To go over channel send options in detail will require a whole default channel send mode is asynchronous.

 

Conclusion

This discussion barely scratches the surface of clustering. What we have provided is a starting point for your cluster. With the infomration provided here you can start a cluster containing two or one thousand nodes. Please remember, OpenLogic can optimize your cluster for you. I will look for comments on this article, please provide your own customized ideas for Tomcat clustering.

If your organization needs assistance with it's cluster, or you are having problems with nodes disappearing, nodes not joining cluster, session information being lost, random node crashes, or anything cluster or tomcat related, just contact your OpenLogic Sales representative and we will provide you with an easy to implement solution.

References: Apache Tomcat Clustering Guide: http://tomcat.apache.org/tomcat-7.0-doc/cluster-howto.html