Hi this is my fourth part of the Tomcat Clustering Series. In this post we are going to discuss the 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]
Its continuation of the last post (session replication using Delta Manager). In delta manager each tomcat instance need to replicate the session information to all other tomcat instances. Its take more time and replication if our cluster size is increased. so there is alternative manager is there. Its Backup Manager.
Backup Manager is replicate the copy of session data to exactly one other tomcat instances. This big difference between both managers. here which tomcat creates that is primary copy of the session. and another tomcat whose hold the replicate session is backup copy. If any one of the tomcat is down. back up tomcat serve the session. Its achieve the fail over capability.
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 rquest 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 run 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 replicate to tomcat3.
now tomcat1 is crashed/shutdown for some reason
so in either case our session is replicate and maintained by backup manager. Its good for large cluster.
check the video below
check my configuration in my github repo or get as ZIP file
Load balancer also faces single point failure. to resolve this we need to put another load balancer with public address and update the new IP to DNS server with same URL. so our URL like example.com query resolves the 2 IP address for 2 load balancer.
How its work:-
-> If browser want to access http://example.com then it first ask DNS server.
-> DNS server gives 2 IP address to browser
-> Browser take the first IP address and try to connect.
-> If in the case that server is failed to respond then browser side make timeout
-> then browser contact second IP address, now second load balancer is works fine.
This kind of adding more load balancer makes to our website more scalable and reliable in case of tragedy.
check in ur terminal
> nslookup google.com
Another thing this DNS servers not return same order of IP list to browser. each an every time its rotate(round robin) the IP list. so in 2 different machine ask google.com get different order of IP list. so these 2 differnt machine connect different google load balancer. so here DNS server also play little role for distribute the requests(loads).
to verify use same command twice. and verify the IP order.
Its continuation of the last post (session replication using Delta Manager). In delta manager each tomcat instance need to replicate the session information to all other tomcat instances. Its take more time and replication if our cluster size is increased. so there is alternative manager is there. Its Backup Manager.
Backup Manager is replicate the copy of session data to exactly one other tomcat instances. This big difference between both managers. here which tomcat creates that is primary copy of the session. and another tomcat whose hold the replicate session is backup copy. If any one of the tomcat is down. back up tomcat serve the session. Its achieve the fail over capability.
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 rquest 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 run 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 replicate to tomcat3.
now tomcat1 is crashed/shutdown for some reason
now same user try to access the page. this time load balancer try to redirect to tomcat1. but tomcat1 is down. so load-balancer pick one tomcat from the remaining tomcats. here interestingly 2 case are there.
Case 1:
Suppose Load balancer pick the tomcat3 then tomcat3 receive the request and tomcat3 itself hold the backup copy of the session. so tomcat3 make that session as primary copy and tomcat3 pick any one tomcat as backup copy. so here remaining only one tomcat is there. so tomcat3 replicate the session to tomcat2. so now tomcat3 hold primary copy and tomcat2 hold the backup copy. now tomcat3 give the response to user. all further request is handled by tomcat3 (sticky session).case 2:
Suppose Load balancer pick the tomcat2 then tomcat2 receive the request and tomcat2 don't have the session. so tomcat2 session manager (Backup Manager) ask to all other tomcat manager "hi anybody hold the session for this user (based on session id [cookie])". Actually tomcat3 have the backup session. so tomcat3 inform to tomcat2. and replicate the session to tomcat2. now tomcat2 make 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 replicate and maintained by backup manager. Its good for large cluster.
check the video below
check my configuration in my github repo or get as ZIP file
Note:
Load balancer also faces single point failure. to resolve this we need to put another load balancer with public address and update the new IP to DNS server with same URL. so our URL like example.com query resolves the 2 IP address for 2 load balancer.
How its work:-
-> If browser want to access http://example.com then it first ask DNS server.
-> DNS server gives 2 IP address to browser
-> Browser take the first IP address and try to connect.
-> If in the case that server is failed to respond then browser side make timeout
-> then browser contact second IP address, now second load balancer is works fine.
This kind of adding more load balancer makes to our website more scalable and reliable in case of tragedy.
check in ur terminal
> nslookup google.com
its gives 11 IP address. these all are google load balancer's located in various geographic locations
Another thing this DNS servers not return same order of IP list to browser. each an every time its rotate(round robin) the IP list. so in 2 different machine ask google.com get different order of IP list. so these 2 differnt machine connect different google load balancer. so here DNS server also play little role for distribute the requests(loads).
to verify use same command twice. and verify the IP order.