AWS deployment options - Part 2 - mod_jk with autoscaling

Part 1 gave the overall deployment picture.

 

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 http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/using-features.managing.elb.html

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/mod_jk-1.2.30-httpd-2.2.X.so JkWorkersFile conf/workers.properties 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 “worker.properties” will also need to be modified as indicated below.

worker.list=lb,jkstatus   #node 1 worker.node1.type=ajp13 worker.node1.port=8009 worker.node1.host=172.23.0.36 worker.node1.lbfactor=1 worker.node1.cachesize=10   #node 2 worker.node2.type=ajp13 worker.node2.port=8009 worker.node2.host=172.23.0.38 worker.node2.lbfactor=1 worker.node2.cachesize=10   #node 3 worker.node3.type=ajp13 worker.node3.port=8009 worker.node3.host=172.23.1.36 worker.node3.lbfactor=1 worker.node3.cachesize=10

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 This maps to the Tomcat server.xml for each JVM

 

 

§Pros:

–Has very good support for failure detection and switchover to alternate Tomcat server.

–Use ELB for health checks and not for load balancing

§Cons:

–The session stickyness is using cookies like this jsessionid=AB327CD87667461357C95742BB9974B1.node1 which is maintained via configuration in Apache workers.properties. 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 “jvmRoute” as 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