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 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
|
§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
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
