Overview of Clustering

To enable session replication in Tomcat, three different paths can be followed to achieve the exact same thing:

• Using session persistence, and saving the session to a shared file system (PersistenceManager + FileStore)
• Using session persistence, and saving the session to a shared database (PersistenceManager + JDBCStore)
• Using in-memory-replication, using the SimpleTcpCluster that ships with Tomcat (lib/catalina-tribes.jar + lib/catalina-ha.jar)

In this release of session replication, Tomcat can perform an all-to-all replication of session state using theDeltaManager or perform backup replication to only one node using the BackupManager. The all-to-all replication is an algorithm that is only efficient when the clusters are small. For larger clusters, to use a primary-secondary session replication where the session will only be stored at one backup server simply setup the BackupManager.

Currently you can use the domain worker attribute (mod_jk > 1.2.8) to build cluster partitions with the potential of having a more scalable cluster solution with the DeltaManager(you’ll need to configure the domain interceptor for this). In order to keep the network traffic down in an all-to-all environment, you can split your cluster into smaller groups. This can be easily achieved by using different multicast addresses for the different groups. A very simple setup would look like this:

DNS Round Robin

|

Load Balancer

/           \

Cluster1     Cluster2

/     \       /     \

Tomcat1 Tomcat2 Tomcat3 Tomcat4

What is important to mention here, is that session replication is only the beginning of clustering. Another popular concept used to implement clusters is farming, i.e., you deploy your apps only to one server, and the cluster will distribute the deployments across the entire cluster. This is all capabilities that can go into with the FarmWarDeployer (s. cluster example at server.xml)