Saturday, September 21, 2013

Session replication / clustering / failover with Tomcat (Part 1 - Overview)

This is my first post of a series about Tomcat and clustering.
In this post i will explain some different replication mechanism.


NOTE: A common drawback of replication, like it's defined in the specs, is that only HttpSession#setAttribute(...) triggers replication.
This means that if you store a container object in the session and if you change a variable inside the object, you must HttpSession#setAttribute(...) again to replicate the modified object again.
Many frameworks implements a simple workaround for it - i will write about it another post.


All to all replication / DeltaManager 


With this mode, Tomcat just replicates the session to all registered nodes.



Pro:
  • No single point of failure at software level
  • Every node holds all sessions
  • In theory, all other nodes can be turned off
  • No extra software is needed
  • Synchronous or Asynchronous replication
  • Open Source
  • Enterprise-Support available
Contra:
  • High memory usage and network traffic because all nodes holds all sessions
  • Objects which are stored in the session must be triggered manually to replicate again if a property has been changed
  • Slower session serialization



Primary/Secondary Replication (Buddy Replication) / BackupManager


The sessions will be replicated to the next neighbor. If one Tomcat is not available anymore, the neighbor still holds the sessions.



 Pro:
  • No single point of failure at software level
  • Lower memory usage and network traffic because the session is not stored on all nodes
  • No extra software is needed
  • Synchronous or Asynchronous replication
  • Open Source
  • Enterprise-Support available
 Contra:
  • Not quite as battle tested as the All-to-all replication (see Tomcat documentation)
  • Objects which are stored in the session must be triggered manually to replicate again if a property has been change
  • Slower session serialization



Memcached-session-manager


Each Tomcat replicates all sessions to N (multiple) Memcached nodes.
If a session is not available on the local Tomcat, the memcached-session-manager tries to lookup the session from the Memcached nodes.



 Pro:
  • No single point of failure at software level
  • More scalability
  • Session will be replicated to N “Memcached” nodes – The sessions are still available if all webservers are down
  • Automatically handles “Memcached” nodes failover
  • Sticky mode: Lower memory usage because every node holds only the current used sessions
  • Non-Sticky mode: Lowest memory usage because Tomcat does not hold the sessions anymore. Session will be received from memcached for each request
  • MSM will automatically trigger replication if a property in a session stored object has been changed
  • Faster session serialization – Changeable mechanism
  • Synchronous or Asynchronous replication
  • Open Source
  • Enterprise-Support available for Tomcat
 Contra:
  • Extra software needed (“Memcached” plugin and nodes)
  • Cannot switch to another Java Webserver which does not automatically check changed values in the session - but only if the used framework has no implemented workaround
  • AFAIK no Enterprise-Support available for the Memcached plugin but Martin Grotzke is very active on the mailing list

3 comments:

  1. This comment has been removed by the author.

    ReplyDelete
  2. This comment has been removed by a blog administrator.

    ReplyDelete