tomcat session replication without multicast

Question

i am planning to use 2 dedicated root servers rented at a hosting provider. those machines will run tomcat 6 in a cluster. if i will add additional machines later on - it is unlikely that they will be accessible with multicast, because they will be located in different subnets.

is it possible to run tomcat without multicast? all tutorials for tomcat 6 clustering include multicast heartbeat. are there any alternatives to SimpleTcpCluster?

or are other alternatives more appropriate in this situation?

Answer 1

With no control over the distance between both servers (they might be in two different datacenters) and no dedicated inter-server-communication line, I'd rather run them via round-robin DNS or a loadbalancer that redirects clients to either www1.yourdomain.xxx or www2.yourdomain.xxx and handle server-communication carefully.

If the servers are heavily communicating with each other you might either look to change your architecture, optimize the hell out of your application to "fit" on one server (at least for a while) or go for dedicated hosting with control over the location, distance and cabling of your servers. Otherwise your inter-server-communication, heartbeat etc. would use the same channel as the clients that are communicating with it (eg the same network segment) which might slow everyone down.

If you are really expecting that much load I suppose there's at least some money involved, no? Use it wisely and use your setup skills for problems harder than setting up distributed clustering with no control or dedicated lines.

Answer 2

Seeing the comment to the question after having given my other answer I'm puzzled about what your question is... Is it about session replication? Cluster communication? It might be better to state your problem instead of your planned solution that has problems itself.

I'll state some possible problems together with quick answers:

Your application is CPU/RAM intensive

• Profile it, optimize it, try again
• Buy a bigger/better server

Your application is bandwidth intensive

• using the cheapo clustering you mentioned in your question will most likely make it worse, as the same (cloaked) channel is used for inter-server-communication as for client-server communication
• You might be able to separate different kinds of bandwidth eg by having dynamic content served from a different server than static content: No need for inter-server-communication here

Your application is storage intensive

• get a bigger server
• go for dedicated hosting and fit in as many spinning disks as you need
• see if other models (like amazons S3 storage) might work for you)

Your application is likely to be slashdotted

• determine which of the above factors (or others) are determining the limits of your application, fix that.

You just need session replication?

• Tomcats SessionManager interface is small and can easily be implemented/extended yourself. Use it for any session replication you like. See the StandardManager documentation and implementation for more information

More ideas

• look at more flexible setups like EC2 (amazon), googles offerings or other cloud computing setups. Make use of their own cloud-storage and inter-server-communication-facilities. Be careful to not depend too much on this infrastructure.

I certainly have forgotten something, but this might provide some starting point. Be more concrete about the nature of your underlying problem to get better answers :)

Answer 3

I am attempting to deploy the yale Central Authentication Server (CAS) and I would like to cluster it for redundancy, because this is a critical piece of infrastructure. CAS requires that the session be replicated, because after a user logs in application A and navigates to application B that partakes in the single-sign-on domain, application B sends a request to CAS to determine whether the user has an active 'ticket'. Since there is no device to indicate to application B to which node it should address itself to validate the ticket, all the active tickets in one node must be replicated to all nodes in the cluster. In other words, session stickiness is not a solution here, because application B, when validating the ticket in the user's cookie, is not aware of the sessionId of the original session in application A during which the user logged in.

Thus, CAS requires that the session be replicated across all nodes. The requirement that the network support multicasting adds a non-trivial amount of overhead, and makes this approach a bit heavier to deploy. I tested this project at google code:

http://code.google.com/p/memcached-session-manager

which seems very useful and simple to deploy (at least on a linux OS), but unfortunately only provides for session failover, and is not a session replication solution.

Answer 4

Just use http://code.google.com/p/memcached-session-manager/ . It works great. We are using it for years for this setup with 20 Tomcat servers sharing sessions. You can have one or two memcached servers to handle the session replication.