We are setting our infrastructure to run tomcat servers with stateful two-tier Web UI applications (WEB Tier (Tomcat) --jdbc--> Database). Broadly speaking the infrastructure has to satisfy 99.9% of up time as far as HA is concerned. As far as applications are concerned, in case a server fails it is OK to fail the in-flight-request, however the user's session should be preserved. Another requirement is of course performance / scalability. Even though it has not been explicitly specified (i.e. in terms of number of concurrent users/requests and maximum allowed response times) it is expected that when the response times start getting poor this would be resolved by putting additional nodes in the infrastructure. I realize addressing scalability does not end in the web tier and that in large portion it depends on the scalability of the data tier, but for the sake of this discussion please abstract data tier out and assume that scalability is entirely constrained by the web tier.
The architecture we were thinking of implementing would have two nodes (for starters) each running a Tomcat server. Tomcats would be configured to run within one cluster (referring to Tomcat's clustering capabilities here - not clustering software like Veritas etc.). The cluster would be fronted by a pair of LocalDirectors (Cisco load-balancing appliance) that would implement load balancing over the servers. Pretty much all applications would run over https where SSL sessions would terminate on tomcat servers, not on the load balancers. Note that this means that request's payload would not be available to balancers so to be able to implement request stickiness based on JSESSIONID nor any other piece of content within the request. So all of that means that an https request would be forwarded to a tomcat instance, and in the course of processing it any change in session state would be broadcast to all cluster members. Since the session is now in the "collective memory" of the cluster any subsequent request is free to be routed to any available tomcat instance not just the initial one that created the session. When the load increases to the point that responses start becoming too slow, we just add another tomcat node. Sounds too simple to be true so I am wondering if I am missing something, and is a setup like this supposed to work? 1) First of all I have found many posts where almost every load balancing setup with Tomcat mentions implementing sticky session where load balancers (usually apache httpd with tomcat's mod_jk module) would forward requests to the instance that created the session in the first place and it would only be ever routed to a different instance in case the original one is not available to process it (e.g. crashes). Is stickiness required and why? If the session is replicated across the cluster should it not be irrelevant where a request gets processed? Or it is recommended because session replication can not be 100% guaranteed especially under heavy load (and having an incomplete and out-dated session is better then no session at all in failure scenarios)? 2) How to ensure session uniqueness across the cluster? Is Tomcat smart enough not to generate an ID that was already created by another instance in the cluster or one has to ensure uniqueness through configuration using jvmRoute attribute of Tomcat's /server/service/engine element (inside server.xml configuration file)? The problem I am seeing with using jvmRoute in the setup we are considering is that JSESSIONID changes every time a request gets routed to a different instance. Even though that does not seem to affect session state (which seems preserved) it worries me that this is not a right thing to do... Please let me know your thoughts on this, any problems you see with such a setup, and if there are better solutions. Thanks Nash -- View this message in context: http://www.nabble.com/Getting-the-Right-High-Availability-Architecture-for-Tomcat-tp23452018p23452018.html Sent from the Tomcat - User mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
