A sandbox for clusterzation
According to documentation:
This manager only replicates the session data to one backup node, and only to nodes that have the application deployed. Downside of the BackupManager: not quite as battle tested as the delta manager.
Important:
- Sessions have a primary node and a backup node
- Need to use sticky sessions
- Backup node selected on a round-robin basis from all other nodes. So, there is NOT a single backup node
- Every node knows the primary node and backup node for every session
- Network traffic proportional to the number of nodes
- Failover is more complicated
Use case:
Suppose we've got a cluster of 4 nodes: A, B, C, D. And suppose that node D fails. Assume, out user makes new request, and his request comes to one of alive nodes:
-
Sessions will be distribtued to other nodes as soon as node failure is detected
-
There are 2 cases:
- If new node was backup node, it becomes primary, and a new backup node is selected, session is replicated to new backup node.
- If new node wasn't backup it becomes primary, backup node remains the same, session is copied from the backup node.
This solution offers a guaranteed session data replication.
Replication via BackupManager (nginx as a balancer, farm deployer)
Replication via BackupManager (mod_jk as a balancer, farm deployer)
Source: memcached-session-manager
According to this:
The memcached session manager installed in a tomcat holds all sessions locally in the own jvm, just like the StandardManager does it as well.
Additionally, after a request was finished, the session (only if existing) is additionally sent to a memcached node for backup.
When the next request for this session has to be served, the session is locally available and can be used, after this second request is finished the session is updated in the memcached node.
Now imagine the tomcat dies.
The next request will be routed to another tomcat. This tomcat (in more detail the memcached session manager) is asked for a session he does not know. He will now lookup the session in the memcached node (based on an id that was appended to the sessionId when the session was created). He will fetch the session from memcached and store the session locally in its own jvm - he is responsible for that session from now on. After the tomcat served this request of course he also updates the session in the memcached node. You see tomcat failover is handled completely.
Comparing to SimpleTcpCluster
The DeltaManager does an all-to-all replication which limits scalability. The BackupManager (according to the docs not quite as battle tested as the delta manager) does a replication to another tomcat, which requires special configuration in the load balancer to support this.
memcached-session-manager supports non-sticky sessions (not supported by Delta/BackupManager) and provides session locking to handle concurrent requests served by different tomcats.
DeltaManager/BackupManager use java serialization, memcached-session-manager comes with pluggable serialization strategies and e.g. one implementation that is based on kryo.
When a new session is created the memcached-session-manager selects the memcached node randomly.
Replication via MemcachedBackupManager (nginx as a balancer)
According to documentation:
DeltaManager enables all-to-all session deltas replication. By all-to-all we mean that the session gets replicated to all the other nodes in the cluster. This works great for smaller cluster but we don't recommend it for larger clusters(a lot of Tomcat nodes). Also when using the delta manager it will replicate to all nodes, even nodes that don't have the application deployed. To get around this problem, you'll want to use the BackupManager.
This solution offers a guaranteed session data replication.
Replication via DeltaManager (nginx as a balancer, farm deployer, dynamic membership)
Replication via DeltaManager (nginx as a balancer, farm deployer, static membership)
Sticky Session with a persistence manager and a JDBC-based store, which is already built into Tomcat. The idea is to stored session data thus in the event of a failure the session data can be retrieved. Using a shared store all the Tomcat instances has access to the session data. However Tomcat will not guarantee when a sessions data will be persisted to the store, thus you could have a case where a Tomcat instance crashes but the session data was not written to the store.
Session passivation using PersistentManager (nginx as a balancer)
Information about session clustering using Hazelcast can be found here
1. According to documentation:
Parallel deployment is a function of the Context Container. The Context element represents a web application, which in turn specifies the context path to a particular Web Application Archive (WAR) file that is the application logic. Parallel deployment allows you to deploy multiple versions of a web application with the same context path concurrently. When choosing what version of the application for any given request, Tomcat will:
-
Route new requests to the latest version, so new sessions go to the new application.
-
If session information is in the request, check the session manager for a matching version, so existing sessions will go to the original application for the request.
-
If session information is in the request, but the corresponding application is no longer present, it will route to the latest version.
NOTE: It actually means that if one of your nodes fails before new version of your application is deployed to all of instances, there is a chance that this new session being replicated to failover node, will cause crashes and undesirable behaviours.
-
For more information see this. Configuration example can be found here
-
Multicast messaging isn't required for SimpleTcpCluster:
3. Using memcached-session-manager be aware of that it depends on load balancer in sticky-mode. So it is possible to get inconsistent session data.
- Use AJP Connector based load balancer