Geronimo Clustering Example - Tomcat web tier clustering

Part 1 - Installing/Running the Clustering Example

Example Overview
This example demonstrates how to use context level clustering with the Tomcat web container in Geronimo. It contains the necessary attachments for setting up cluster members on two separate physical machines. The cluster configuration will allow the two cluster members to replicate httpsession data via memory to memory multicast communication. Also, a load balancer can be used to spray the incoming requests to the available cluster members. In this example, we recommend Apache HTTP server and Apache mod_jk.

Installing the Example
This example contains 4 attachments:

• servlets-examples-cluster-node1.war - web application for Cluster Member 1
• servlets-examples-cluster-node2.war - web application for Cluster Member 2
• servlets-examples-tomcat-cluster-plan-node1.xml - Geronimo deployment plan for node 1
• servlets-examples-tomcat-cluster-plan-node2.xml- Geronimo deployment plan for node 2

Each geronimo cluster member must have a unique jvmRoute designation for both load balancing and session replication.
In the near future, the jvmRoute attribute will be configurable via the var/config/config.xml file. Unfortunately, the only current way to setup the jvmRoute is by rebuilding the geronimo server for each cluster member. The jvmRoute should be configured with a unique value for each cluster member as shown below:

Update filename: geronimo/configs/tomcat/src/plan/plan.xml as follows

<gbean name="TomcatEngine" class="org.apache.geronimo.tomcat.EngineGBean">
<attribute name="className">org.apache.geronimo.tomcat.TomcatEngine</attribute>
<attribute name="initParams">
name=Geronimo
+ jvmRoute=nodex
</attribute>

Rebuild geronimo and uncompress the resulting image for the cluster member. Repeat the procedure for the next cluster member while assuring that a different jvmRoute value is used. Instructions for rebuilding geronimo is beyond the scope of this article. These instructions are available on the Geronimo Wiki.

Now that the jvmRoute is set correctly for each cluster member. You must deploy the example on each of the cluster members. For this example, the applications are slightly different for each cluster member. The difference is merely to output the current Server number (e.g. Server 1, Server 2) in the output of the application. This will be useful when trying to determine which cluster member is servicing the http request from the browser.

Start the geronimo server on each cluster member and then install the attached applications to the appropriate cluster member assuring that you use the correct deployment plan for each. Note that the deployment plan must be updated with the hostname (or IP address) for each machine. The appropriate spots are identified in the plans with xx.yy.zz.aa.

Tip: Memory to memory replication currently requires that all cluster members must reside on the same physical subnet since multicast broadcast is used.

Once you get the applications installed on each cluster member, you can test httpsession replication by hitting the application with your favorite browser. Probably something like: http://localhost:8080/servlets-examples-cluster/servlet/SessionExample . Note that the output page contains the ID of the server that is servicing the request. Fill in the input fields in your browser and hit the submit button. The console dialogue (the prompt where you started geronimo) should show that the httpsession data is being transmitted and received between the cluster members.

Load Balancing and failover
Now you are ready to setup the Load Balancer. We recommend using Apache HTTP server and mod_jk for this example.

Install Apache HTTP server - instructions and downloads available at http://httpd.apache.org/
Install Apache mod_jk - See http://tomcat.apache.org/tomcat-5.5-doc/balancer-howto.html

Configuration tips for mod_jk:
worker.list=loadbalancer,status
worker.node1.port=8009
worker.node1.host=your.first.cluster.member.host.name
worker.node1.type=ajp13
worker.node1.lbfactor=1

worker.node2.port=8009
worker.node2.host=your.second.cluster.member.host.name
worker.node2.type=ajp13
worker.node2.lbfactor=1

worker.loadbalancer.type=lb
worker.loadbalancer.balance_workers=node1,node2
worker.loadbalancer.sticky_session=1
worker.status.type=status

/servlets-examples-cluster=loadbalancer
/servlets-examples-cluster/*=loadbalancer

Testing Load Balancing and Failover

Once you get Apache HTPP Server and mod_jk setup correctly.. You can test load balancing and failover by requesting the following urls on port 80 (Apache HTTP Server default port).

http://youhost/servlets-examples-cluster - HttpSession not used, hence no sticky session http://youhost/servlets-examples-cluster/servlet/SessionExample - HttpSession used, hence sticky session used

Sticky Session refers to the load balancer sending all requests for the same httpsession (indicated by a cookie or encodedUrl) to the same cluster member.

You can test failover by stopping the geronimo server that owns the sticky session and seeing that the next http request will failover into the remaining cluster member. The httpsession data from the previous requets should be recovered and displayed in the refreshed browser window.

Tips
When testing using a web browser, make sure that you erase cookies and cached pages between test cases. Browser caching causes confusion.
Make sure your application has the distributable attribute defined in web.xml
Make sure all cluster members are on the same physical subnet and that multicast broadcast is supported on the subnet.
Also, see http://tomcat.apache.org/tomcat-5.0-doc/cluster-howto.html for more information on tomcat clustering.

Special Acknowledgement to Jeff Genender for developing the Tomcat clustering GBeans for Geronimo.

Back Button Sample applications