HomeDocumentation > User's guide > Clustering > Tomcat Native Clustering

The Tomcat Web container provides a native clustering solution that can be configured through Geronimo using gbean definitions within config.xml or your deployment descriptors . This document will go through the available GBeans and how to configure them for clustering in a Geronimo server with a tomcat web container.
A cluster configuration should be considered when you want to improve the scalability and availability of your Web application. The following sections provide detailed instructions on how to set up your cluster nodes and how to deploy your applications with tomcat clustering enabled.

Setting up a clustering environment

Generally, to set up a small cluster you will need at least 2 nodes and 1 HTTP server. The HTTP server is used to serve requests from clients and ensure well-balanced traffic load among different nodes. Similarly, each node is configured to use the same logical Tomcat engine and enable session affinity.

Planning your cluster

The Tomcat cluster replicates HTTP session data via memory to memory multicast communication.

Every node transmits its session data to every node in the cluster. This algorithm is only efficient when the clusters are small. If the clusters grow too large, the overhead in storage utilization and network traffic becomes excessive. To avoid excessive overhead, consider dividing your nodes into several smaller clusters.

HTTP session data is replicated among the nodes in the cluster using a multicast broadcast. All nodes in the cluster must be on the same physical subnet and multicast broadcast must be supported by that subnet.

Preparing your Web application

To participate in a cluster configuration, your Web application must be implemented correctly.

  • Ensure that every object placed in the HTTP session implements java.io.Serializable. The clustering feature serializes the objects when it distributes them to the other nodes in the cluster.
  • The deployment descriptor for your Web application, that is the web.xml file in the Web archive, must indicate that your Web application is distributable. To do this, insert the distributable element in the deployment descriptor.
    Excerpt from web.xml
  • Do not use stateful session Enterprise JavaBeans (EJBs). The clustering feature does not replicate stateful EJBs among the nodes in the cluster.
  • If your Web application uses a database, make sure the database can be accessed from every node in the cluster. Ensure that the proper JDBC drivers are installed on every node and that the datasource objects are defined correctly on every node.
  • Do not depend on dynamic updates to the Java Naming and Directory Interface (JNDI). You will need to configure all the JNDI names used by your application in every node of the cluster. The clustering feature does not replicate JNDI changes among the nodes in the cluster.

Enable Session Affinity

Support for session affinity, also known as sticky session support, allows a load balancing service to route an HTTP request back to the same node that created the HTTP session associated with that request until that node fails. You must use session affinity if you configure an asynchronous type of session replication. With asynchronous replication, the reply is returned before the HTTP session is replicated so there is always a chance that the next request using that session arrives before the replication is complete. In this case, the only way to ensure that the request is processed using the correct session data is to route the request to the node that sent the reply to the last request and originated the replication.

For every node in the cluster, update config.xml as follows after the server is stopped

Excerpt from config.xml

Engaging load balancing and failover

Initially, the server configuration includes an AJP connector suitable for exchanging messages with a load balancing service. See Configuring a remote Apache HTTP server for more information about the HTTP server configuration.

Deploying your application to a cluster

To deploy your application to a cluster and make sure HTTP sessions are replicated successfully, cluster configuration elements of Tomcat Web containers must be configured using GBean definitions within deployment plans.

If you want to deploy your Web application to a cluster, install your WAR files to the appropriate cluster member, assuring that you use the correct deployment plan for each member. Here is the template for your Web application deployment plan

  • Sample geronimo-web.xml for geronimo 2.1.4 and below
    geronimo-web.xml
  • Sample geronimo-web.xml for geronimo versions above 2.1.4. This does not include g 2.2
    After applying fix to 2.1 through GERONIMO-4187 there are some modifications which needs to picked up by your configuration through geronimo-web.xml
geronimo-web.xml

where

  • web-cluster-server1 should match the WAR file name. It can be different for each node in the cluster.

On each node, deploy your Web application, either via admin console or deploy command, following this syntax:

deploy --user name --password word deploy archive plan

where

  • name is replaced with a user name authorized to manage the server. If you omit this option, you will be prompted to enter a user name.
  • word is replaced with the password used to authenticate the user. If you omit this option, you will be prompted to enter a password.
  • archive is replaced with a file specification to your Web application WAR file.
  • plan is replaced with a file specification to your deployment plan.

Note: After server installation, the default user name is initially system, and the default password is manager.

Sample Tomcat clustering with unicast configuration

Static members in a cluster are defined using org.apache.geronimo.tomcat.cluster.StaticMemberGBean in the deployment plan. You have to specify all static members within the deployment plan to make sure the application is clustered successfully. Refer to the sample code below for an application-scoped unicast clustering configuration on one node. The sample assumes there are only two static members in a cluster environment.

A few notes for better understanding of the sample deployment plan:

  • Use ReceiverGBean to specify the information of the current node and port number used for communication.
  • Use ChannelInterceptorGBeans to disable the multicast cluster configurations, and specify how the static member are chained together as you can see the configurations of StaticMember1Interceptor and StaticMember2Interceptor.
  • Use StaticMemberGBean to specify the information of the second static member and port number used for communication.
  • Use TcpPingInterceptor to send a ping to another member periodically. You can manage ping interval by setting the interval attibute for TcpPingInterceptor. It is a good practice to set interval to 240.

To convert this example to a multicast configuration, the DisableMCastInterceptor, StaticMemberInterceptor, and StaticMember definitions should be removed. Also, the value for the address attribute for the ReceiverGBean definition should be changed to auto.

excerpt from geronimo-web.xml

Where

  • IPAddress1 is the IP address or host name of current static member.
  • TCP_port1 is the TCP port on the current node to listen for session replication data from other static members.
  • IPAddress2 is the IP address or host name of the second static member.
  • TCP_port2 is the TCP port on the second static member to listen for session replication data from other static members.

Configuration of unicast clustering with more than two nodes

To set up an application-scoped unicast clustering with more than two nodes, make sure you have defined all the static members in the deployment plan for each server node.

Interceptors can perform actions when a message is sent or received. Use a reference NextInterceptor in interceptor configurations to chain interceptors together. You can control how the client requests are processed by arranging the order of the interceptor chain. In the following sample code, when the TcpFailureDetector intercepter catches errors, it calls the next interceptor StaticMember1Interceptor. The static member referenced inside StaticMember1Interceptor, static member 2 in this example, will immediately take over the work of the first static member.

excerpt of interceptor chain

All the static members involved should be defined in the deployment plan as well as the relationship between these static members. Use a reference NextStaticMember in the definition of each static member, except for the last one, to chain static members together. When static member 2 in this example fails to take over the work, static member 3 will immediately take over the work. It is the same for longer static member chain. When a static member fails to take over the work of the previous static member, it calls the next static member in the chain. The request is passed along until a static member can handle the work or it gets to the end.

excerpt of static member chain

See the following deployment plan snippet as a complete example of setting up application-scoped unicast clustering with more than two nodes.

excerpt from geronimo-web.xml

Where

  • IPAddress1 is the IP address or host name of current static member.
  • TCP_port1 is the TCP port on the current node to listen for session replication data from other static members.
  • IPAddress2 is the IP address or host name of the second static member.
  • TCP_port2 is the TCP port on the second static member to listen for session replication data from other static members.
  • IPAddress3 is the IP address or host name of the third static member.
  • TCP_port3 is the TCP port on the third static member to listen for session replication data from other static members.