Popular Posts

Clustering Environment with Tomcat

Configuring Clustering Environment in Tomcat7
What is Clustering: Connecting two or more computers together in such ways that they behave like a single computer. Clustering is used for parallel processing, load balancing and fault tolerance.
Clustering is a popular strategy for implementing parallel processing applications because it enables companies to leverage the investment already made in PCs and workstations. In addition, it's relatively easy to add new CPUs simply by adding a new PC to the network.
There are two types of clustering is possible
1.       Vertical Clustering
2.       Horizontal Clustering
Vertical Clustering: installing multiple Java application servers on a single physical machine

Horizontal Clustering: Horizontal clustering involves running multiple Java application servers that are run on two or more separate physical machines.


Steps to vertical clustering with tomcat7 and apache web server
1.       Download Tomcat7 zip version from here and extract the files into some directive and rename to tomcatA
2.       Similarly create two more tomcat instances as tomcatB and tomcatC as shown below


3.       Download Apache2.2 server from here and install it.
NOTE: use Network Domain and Server Name as localhost while installation
4.       Download suitable mod_jk connector (tomcat-connectors-1.2.37-windows-i386-httpd-2.2.x.zip) from here and copy that connector into the installed apache HTTP server modules folder.
5.       Paste the following commands in conf folder of httpd.conf file under HTTP Server.
LoadModule jk_module modules/mod_jk.so
JkWorkersFile path_to_worker.properties file
JkLogFile "logs/mod_jk.log"
JkLogLevel error
#add all your application which need to handler by load balancer
JkMount / examples myLoadBalancer
JkMount /mywebApp/* myLoadBalancer
JkMount / examples/* myLoadBalancer


The LoadModule directive links in the object file or library filename and adds the module structure named module to the list of active modules. Module is the name of the external variable of type module in the file, and is listed as the Module Identifier in the module documentation.

6.       Create workers.properties file in conf folder of apache and include following lines in this file.
Tomcat worker is a Tomcat instance that is waiting to execute servlets or any other content on behalf of some web server. For example, we can have a web server such as Apache forwarding servlet requests to a Tomcat process (the worker) running behind it.

The scenario described above is a very simple one; in fact one can configure multiple Tomcat workers to serve servlets on behalf of a certain web server. The reasons for such configuration can be:
·         We want different contexts to be served by different Tomcat workers to provide a development environment where all the developers share the same web server but own a Tomcat worker of their own.
·         We want different virtual hosts served by different Tomcat processes to provide a clear separation between sites belonging to different companies.
·         We want to provide load balancing, meaning run multiple Tomcat workers each on a machine of its own and distribute the requests between them.

# Define list of workers that will be used
# for mapping requests
worker.list= myLoadBalancer,status

# Status worker for managing load balancer
worker.status.type=status

worker.tomcatA.port=8109
worker.tomcatA.host=localhost
worker.tomcatA.type=ajp13
worker.tomcatA.lbfactor=1

worker.tomcatB.port=8209
worker.tomcatB.host=localhost
worker.tomcatB.type=ajp13
worker.tomcatB.lbfactor=1

worker.tomcatC.port=8309
worker.tomcatC.host=localhost
worker.tomcatC.type=ajp13
worker.tomcatC.lbfactor=1

7.       Load Balancer into worker properties: A load balancer is a worker that does not directly communicate with Tomcat. Instead it is responsible for the management of several "real" workers, called members or sub workers of the load balancer.
This management includes:
·         Instantiating the workers in the web server.
·         Using the worker's load-balancing factor, perform weighted load balancing (distributing load according to defined strengths of the targets).
·         Keeping requests belonging to the same session executing on the same Tomcat (session stickiness).
·         Identifying failed Tomcat workers, suspending requests to them and instead falling-back on other workers managed by the load balancer.
·         Providing status and load metrics for the load balancer itself and all members via the status worker interface.
·         Allowing to dynamically reconfiguring load-balancing via the status worker interface.
Load Balancer properties
A worker is configured as a load balancer by setting its worker type to lb.
The following table specifies some properties used to configure a load balancer worker:
·         balance_workers:  is a comma separated list of names of the member workers of the load balancer. These workers are typically of type ajp13. The member workers do not need to appear in the worker.list property themselves, adding the load balancer to it suffices.
·         sticky_session:  specifies whether requests with SESSION ID's should be routed back to the same Tomcat instance that created the session. You can set sticky_session to False when Tomcat is using a session manager which can share session data across multiple instances of Tomcat - or if your application is stateless. By default sticky_session is set to True.
·         lbfactor:  can be added to each member worker to configure individual strengths for the members. A higher lbfactor will lead to more requests being balanced to that worker. The factors must be given by integers and the load will be distributed proportional to the factors given. Higher factors lead to more requests.
Add below code into the workers.properties
 worker. myLoadBalancer.type=lb
worker. myLoadBalancer.balance_workers=tomcatA,tomcatB,tomcatC
# for sticky session it is true(1) and session replications make it false(0)
worker. myLoadBalancer.sticky_session=1

NOTE: Session stickiness is not implemented using a tracking table for sessions. Instead each Tomcat instance gets an individual name and adds its name at the end of the session id. When the load balancer sees a session id, it finds the name of the Tomcat instance and sends the request via the correct member worker. For this to work you must set the name of the Tomcat instances as the value of the jvmRoute attribute in the Engine element of each Tomcat's server.xml. The name of the Tomcat needs to be equal to the name of the corresponding load balancer member. In the above example, Tomcat on host "localhost" needs jvmRoute="tomcatA.      
8.       Create mod_jk.log file in log folder of apache
9.       Change the server.xml files of tomcatA and tomcatB and tomcatC with following changes for vertical clustering
Change the ports name as
8105,8081,8109 for Tomcat A
8205,8082,8209 for Tomcat B
8305,8083,8309 for Tomcat C
In the place of 8005,8080,8009 for the following first, second ,third steps
1. <Server port="8005" shutdown="SHUTDOWN">
2. <Connector port="
8080" protocol="HTTP/1.1"
               connectionTimeout="20000"
               redirectPort="8443" />
3. <Connector port="8009" protocol="AJP/1.3" redirectPort="8443" />
4. Add jvmRoute as tomcatA for tomcatA , tomcatB for tomcatB, tomcatC for tomcatC
      <Engine name="Catalina" defaultHost="localhost" jvmRoute="tomcatC">
5. Uncommented clustering tag
<Cluster className="org.apache.catalina.ha.tcp.SimpleTcpCluster"/>


10.   Next step to do add distributed tag in web.xml to switching session among the tomcat clustering instance
1.       TomcatAà webapps/examples/WEB-INF/web.xml
2.       TomcatB à  webapps/examples/WEB-INF/web.xml
3.       TomcatCà webapps/examples/WEB-INF/web.xml
<?xml version="1.0" encoding="ISO-8859-1"?>
<web-app xmlns="http://java.sun.com/xml/ns/javaee"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-  app_2_5.xsd"   version="2.5">
 
 <distributable />
 
 </web-app>
11.   Create the test.jsp in examples folder of tomcatA, tomcatB, tomcatC and include the following lines in this JSP file respectively
  TomcatA Session ID <%= session.getId() %>
  TomcatB Session ID <%= session.getId() %>
  TomcatC Session ID <%= session.getId() %>

12.   Restart the apache HTTP server, tomcatA, tomcatB, tomcatC
13.   Open the following in web browsers
Now you can able to see same session id from all tomcats, thus clustering is achieved.
AJP Connector: When the server is installed, the initial Tomcat configuration contains a connector that receives HTTP requests using Apache Jserv Protocol (AJP). Although Tomcat is capable of receiving HTTP requests directly from the network, this connector allows Tomcat to receive requests from software in a lower tier. For example, Tomcat may receive requests from web servers (like the Apache HTTP Server), proxy servers, and load balancing systems that support the AJP protocols.
Advanced Load Balancer: The load balancer supports complex topologies and failover configurations.
When working with shared sessions, either by using session replication or a persisting session manager (e.g. via a database), one often splits up the Tomcat farm into replication groups. In case of failure of a member, the load balancer needs to know, which other members share the session. This is configured using the domain attribute. All workers with the same domain are assumed to share the sessions.
For maintenance purposes you can tell the load balancer to not allow any new sessions on some members, or even not use them at all. This is controlled by the member attribute activation. This activation attribute will take three values

1.     active: it will allows normal use of members
2.     Disabled: it will not create new sessions on it, but still allow sticky requests. When you add this attribute you have to add redirect attribute to all other tomcat servers.
3.     stopped: will not allow send any request to member
The redirect flag on tomcatA tells the load balancer to redirect the requests to tomcatC in case that tomcatA has a problem. In all other cases tomcatC will not receive any requests, thus acting like a hot standby.
worker.tomcatA.redirect=tomcatC
worker.tomcatB.redirect=tomcatC
worker.tomcatC.activation=disabled

Reference:


2 comments: