Friday, 23 May 2014

AWS deployment options - Part 2 - mod_jk with autoscaling

If the application requires session stickiness at the Tomcat tier, i.e. if some user details are stored in the HTTP Session and you don't enable session replication across Tomcats. The solution is that the Elastic Load Balancer (ELB) maintains the sticky session using it’s own cookie called AWSELB. For ELB sticky session configuration see
In case there is an external ELB (Apache tier) with cookies stickiness set, it will over-ride the internal ELB (Tomcat tier). The stickiness cookie is always named AWSELB, hence the external ELB will overwrite the cookie from the internal ELB. One option here is to set the Tomcat tier ELB with "Application Generated Cookie Stickiness" with value JSESSIONID so it will follow the Application cookie and maintain sticky sessions.

In case sticky session is not enabled on the application tier, and the user is forwarded to a Tomcat server where the session is not present, the user’s session information will be lost

There are various approaches available to maintain session stickiness, and these have been discussed below.
Option 1: Use mod_jk to get Apache to direct to the correct Tomcat

Option 2: Use mod_proxy

Option 3: No session stickiness, keep it stateless (which is what Amazon recommends)

The mod_jk implementation looks like this
The Apache web server can maintain session stickiness along with load balancing i.e. The requests from the Apache server to the Tomcat server are load balanced along with maintaining session stickiness, by Apache server itself .(The application ELB is bypassed).
In this approach the Apache server needs to know the list of all possible Tomcat IPs.
When we set up autoscaling, Tomcat can start up new instances on any IP within the subnet. That's the way AWS works.
Hence this is not feasible as when we restart the AWS servers the IPs might change.

 Mod JK Configuration

The file “httpd.conf” at the location “/www/Apache/conf” needs to have the following entries. These entries indicate that the files from folders “img”, “images”, ”css” and “media” will be served locally where as rest of the requests will be forwarded to the load balancer “lb”.

LoadModule jk_module modules/
JkWorkersFile conf/
JkLogFile logs/mod_jk.log
JkLogLevel error
JkShmFile logs/mod_jk.shm
JKMount /status jkstatus
JkAutoAlias /apps/Tomcat/apache-tomcat-7.0.42/webapps
JkMount  /* lb
JkUnMount /img/* lb
JkUnMount /images/* lb
JkUnMount /css/* lb
JkUnMount /media/* lb


Also the file “” will also need to be modified as indicated below.

#node 1
#node 2
#node 3


 This maps to the Tomcat server.xml for each JVM

Has very good support for failure detection and switchover to alternate Tomcat server.
Use ELB for health checks and not for load balancing
The session stickyness is using cookies like this jsessionid=AB327CD87667461357C95742BB9974B1.node1 which is maintained via configuration in Apache In this all Tomcat IP addresses and ports must be mentioned along with a logical name for each Tomcat (node1 in this case)
That logical name
must be the same as entered in each individual Tomcat server.xml as it’s “jvmRouteas well. Thus we will have Tomcat node1, node2 .. nodeN
This affects autoscaling because Tomcats will be a new instance autoscaled on any available IP (from a set of IPs) and it’s not possible to hardcode a “nodeX” in Tomcat when it is launched via autoscaling
For this reason we next take a look at mod_proxy


No comments:

Post a Comment