Hi, this is my fourth part of the Tomcat Clustering Series. In this post we are going to discuss how to setup session replication using Backup Manager in tomcat clustering environment. Session replication makes High availability and full fail-over capability to our clustering environment.
[Check the video below for better understanding]
This post is a continuation of my last post (Session replication using Delta Manager). In delta manager each tomcat instance needs to replicate the session information to all other tomcat instances. It takes more time and replication if our cluster size is increased, so, an alternative manager is there, the Backup Manager.
Backup Manager replicates the copy of session data to exactly one other tomcat instance in the cluster. This is the main difference between Delta and Backup managers. Here one tomcat instance maintains what is the primary copy of the session whereas another tomcat instance holds the replicated session data acting as the backup one. If any one of the tomcat instances fails the other one serves the session. That way fail over capability is achieved.
The setup process of backup manager is same as Delta manager. Except we need to mention the Manager as BacupManager (org.apache.catalina.ha.session.DeltaManager) inside <Cluster> element.
Suppose we have 3 tomcat instances like previous post, and i configured into backup manager.
Now user try access the page. User request comes to load balancer, and load balancer redirect the request to suppose tomcat1. Now tomcat one create the session, now tomcat1 is responsible to replicate exactly one copy to any one of the tomcat. So tomcat1 picks any tomcat which is part of the cluster (multicast). Here tomcat1 picks tomcat3 as a backup. So tomcat3 hold the backup copy of the session.
We are running the load balancer in sticky session mode so all further request from that particular user is redirect to tomcat1 only. All modification in tomcat1 is replicated to tomcat3.
Now tomcat1 is crashed/shutdown for some reason
Now same user try to access the page. This time load balancer tries to redirect to tomcat1 but tomcat1 is down, so load-balancer picks one tomcat from the remaining tomcats. Here interestingly 2 cases are there.
Case 1: Suppose Load balancer picks the tomcat3, then tomcat3 receives the request and tomcat3 itself holds the backup copy of the session. So tomcat3 makes that session as primary copy and tomcat3 picks any one tomcat as backup copy. So here remaining only one tomcat is there. So tomcat3 replicates the session to tomcat2. Now tomcat3 holds primary copy and tomcat2 holds the backup copy. Now tomcat3 gives the response to user. All further request is handled by tomcat3 (sticky session).
case 2: Suppose Load balancer picks the tomcat2 then tomcat2 receives the request and tomcat2 don’t have the session. So tomcat2 session manager (Backup Manager) asks all other tomcat managers: ‘hi anybody hold the session for this user (based on session id [cookie])’. Actually tomcat3 has the backup session. So tomcat3 informs to tomcat2 and replicate the session to tomcat2. Now tomcat2 makes that session as primary copy and tomcat3 whose already have copy of session as remains as a backup copy of that session, so now tomcat2 hold primary copy and tomcat3 hold the backup copy. Now tomcat2 give the response to user. All further request is handled by tomcat2 (sticky session).
So in either case our session is replicated and maintained by backup manager. This is good for large cluster.
Check the video below
Check my configuration in my github repo or get as ZIP file
Screen Cast:
Reference: Tomcat Clustering Series Part 4 : Session Replication using Backup Manager from our JCG partner Rama Krishnan at the Ramki Java Blog blog.
Have a quick question about backup session manager in tomcat. Take a scenario where i have 10 nodes in cluster, now question here is does a backup node also serve request other than behaving as backup or it just dedicated for backup purpose only. if this is the case it means if i hv 10 nodes in cluster then only 5 will serve the traffic and rest 5 will be backup ? if this is not the case and backup nodes also serve their own traffic which means each node is working as a primary and backup both, then hardware… Read more »
yes. backup nodes also serve their own traffic. its get overload, but compare to delta manager (each node have all node session), back node is less resource hungry.
Session stickness necessary for BackupManager, I’ve 6 Nodes in backend