George - This is why I hate statistics. You can make them say anything. Wouldn't the better calculation be based on the average number of currently active sessions at one data center, since when it goes down, that is the number of users which will be affected. The calculation should also include probability and length of outage and then weighed against the downside of the end user gettng an error message and having to login again and start over. I'd really only see it as being a problem if there were extremely long-running transactions that would have to be restarted in the event of an outage (or a really poorly designed app). Jeff p.s. I'm with you on this probably being a minor concern causing a larger headache, but we should get the scope of the problem correct to begin with. (said by one who both supports and uses webapps that support large numbers of users)
-----Original Message----- From: George Sexton [mailto:geor...@mhsoftware.com] Sent: Wednesday, August 26, 2009 9:52 AM To: 'Tomcat Users List' Subject: RE: Multiple data centers and redundency? > -----Original Message----- > From: Andre-John Mas [mailto:aj...@sympatico.ca] > Sent: Tuesday, August 25, 2009 6:30 PM > To: Tomcat Users List > Subject: Multiple data centers and redundency? > > Hi, > > I have been asked to look into a solution that would involve a few > different data centres each with their own set of load balanced Tomcat > servers. The requirement is for the users not to lose their session if > one data center goes down. I have never had to work on something this > large and have no idea to what extent this can be achieved with Tomcat. > > My initial thoughts would be for each data center to have a session > pool, which is synced with each other, so if ever a Tomcat server or > data center goes down they can check in the pool to see if it exists > and then reuse that. It would mean extra communication behind the > scene, but I see no other way go about it. > > Any help would be appreciated. > > André-John Has anyone really done any math to determine the risk? Here an example of what I mean. Say you are in a high quality co-location. The probability of an outage is maybe once in 3 years. That's overstating the probability in my mind, but we'll use it. Let's also say that you have a high quality clustering solution in place in each data center that handles failover of any equipment WITHIN the data center. Say the average length of a user/customer session is 2 hours, and your failover system will route any new users to a remaining data center. I think 2 hours is kind of a long session but we'll use it. Say you have two data centers. So, the probability of an average customer being affected by a data center outage is: 1/( (2 hours)/24(Hours day) * 1/(3*365))/2 (Data centers) The probability of an average customer being affected by an outage is conservatively 1 in 26280. Expressed as a percentage, the probability of any individual session being affected is 0.0038%. Is your application really so big and critical that you have to address this very small percentage chance of a session being interrupted? George Sexton MH Software, Inc. http://www.mhsoftware.com/ Voice: 303 438 9585 --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org ******************************* NOTICE ********************************* This message is intended for the use of the individual or entity to which it is addressed and may contain information that is privileged, confidential, and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient or the employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by reply or by telephone (call us collect at 512-343-9100) and immediately delete this message and all its attachments. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
