Tomcat non-multicast session replication

Question

I plan to use 2 dedicated root servers rented from a hosting provider. these machines will run tomcat 6 in the cluster. if I add additional machines later, it is unlikely that they will be available with multicast because they will be located on different subnets.

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

Or are other alternatives more suitable in this situation?

Answer 1

Without control over the distance between both servers (they can be in two different data centers) and a separate dedicated interserver communication line, I would rather run them through a circular DNS or loadbalancer, which redirects clients to any www1.yourdomain.xxx or www2.yourdomain. xxx and carefully handle the server connection.

If the servers communicate strongly with each other, you can either see how to change your architecture, optimize the hell from the application to "fit" on one server (at least temporarily), or switch to dedicated hosting with control of location, distance and cables your servers. Otherwise, your interserver communication, heart rate, etc. They will use the same channel as the clients who communicate with it (for example, the same network segment), which can slow down everyone.

If you really expect such a heavy load, I suppose there is at least some money, no? Use it wisely and use your tuning skills for problems more complicated than setting up distributed clustering without control or leased lines.

Answer 2

Having seen a comment on a question after answering another question, I am puzzled that your question ... Is this about session replication? Cluster communication? You might be better off indicating your problem instead of a planned solution that has problems.

I will talk about some possible problems along with quick answers:

CPU / RAM Intensity in Your Application

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

Your application has bandwidth

• Using cheapo clustering, which you mentioned in your question, is likely to make it even worse, since the same (hidden) channel is used for inter-server communication, as for client-server communication.
• You may be able to share different types of bandwidth, for example. by dynamic content served from a different server than static content: no cross-server communication is needed here.

Your application is intensively stored in storage

• get a larger server
• go for dedicated hosting and insert as many spinning disks into it as you need.
• see if other models can work (for example, Amazon S3 S3 storage).

Your application is likely to be disabled

• determine which of the above factors (or others) determine the limits of your application, correct it.

Do you just need session replication?

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

Other ideas

• look at more flexible settings, such as EC2 (amazon), offers for googles or other cloud computing settings. Use your own cloud storage and cross-server communications. Be careful not to depend on this infrastructure.

Of course, I forgot something, but this can serve as a starting point. Be more specific about the nature of your main problem in order to get the best answers :)

Answer 3

I am trying to deploy yale central authentication server (CAS) and I would like to group it for redundancy because this is a critical part of the infrastructure. CAS requires that the session be replicated, because after a user logs on to application A and goes to application B, which participates in a domain with a single sign in, application B sends a CAS request to determine if the user has an active “ticket”, since there is no device to indicate to application B to which node it must address itself to validate the ticket, all active tickets in one node must be replicated to all nodes of the cluster. In other words, session stickiness is not the solution here because application B, when checking a ticket in a user cookie, is not aware of the sessionId of the original session in application A during which the user is logged in.

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

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

which seems very useful and easy to deploy (at least on the Linux operating system), but unfortunately it only provides a transition to the session and is not a session replication solution.

Answer 4

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