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. The blog posted is very interesting from all aspects and it will surely benefit the readers by all means.
    Prestashop Theme Developer

    ReplyDelete
  2. This comment has been removed by the author.

    ReplyDelete