Hi, Sorry to go slightly off the topic, but I have to express surprise (laugh) at the 99.99% availability bit. Its highly laudable to aim at that, indeed mobile phone operators claim to aim for, or even require, "five 9's", ie 99.999%, which equates to a massive 315 minutes downtime per year (and between you and me I _know_ that mobile operators never even get close). 99.99% gives you a whole 3153 mins per year, or 52 hours, or 1 hour per week of operation per year....And thats not much to play with.
As all of us who have tried it know that trying to make a system highly redundant so that there are no single points of failure necessarily makes the whole thing more complicated and thus if something does go wrong (2 switches die at once or something, followed by a disk array failure, and causing an unexpected knock on effect etc etc), you can suddenly find that your massively complex system has all fallen apart and takes a few hours to put back together.... Speaking from experience of the tomcat session replication issue, we use it and it works well, although in fact we have just 2 tomcat instances at this time. However, problems can occur if a server dies whilst there are a lot of active sessions, after recovery of the failed box trying to bring the server back into the group and thus attempting to copy all those active sessions back can impose surprisingly and dangerous load levels on the "live" server. On a few occasions this did actually grind the live server to a halt and we had to restart the entire system from cold, dumping all the live sessions. I'm still searching for the optimal configuration for this. Still, I wish you well in the 99.99% availability quest. Mark On Tuesday 14 November 2006 12:09, Mirou, Antoine wrote: > Hello, > > Could you please give an example of "really big sites" ? > > How do you organize your cluster (how many members/domains, ...) ? > > Do you use Farm-deployer ? > > Do you use session replication ? > > How do you manage/monitor the cluster ? > > Many questions, sorry, but I'm currently studying the possibility of > setting up a cluster of tomcat 5.5 for a 99.99% available app with lots of > user connexions, and I really don't feel confident of my ease with tomcat > clustering... > > Thanks for your answers. > > Regards, > Antoine > > -----Message d'origine----- > De : Peter Rossbach [mailto:[EMAIL PROTECTED] > Envoyé : mardi 14 novembre 2006 09:31 > À : Tomcat Users List > Objet : Re: session replication/tomcat 5.5 > > Am 13.11.2006 um 20:27 schrieb David O'Dell: > > Is anyone using session replication in production? > > Yes, at really big sites :-) > > > Is there an alternative to using multicasting? > > No, but you can implement you own membership service. > > > In the doc http://tomcat.apache.org/tomcat-5.5-doc/cluster-howto.html > > > > It states "This is an algorithm that is only efficient when the > > clusters are small." > > I have 6 tomcat instances behind a load balancer, is this still > > considered small? > > Yes, but split your cluster into different domains. Use Apache/mod_jk > > >= 1.2.19 with the > > domain attribute. The mod_jk loadbalancer can then route to the right > backup. > > regards > Peter > > > --------------------------------------------------------------------- > > To start a new topic, e-mail: users@tomcat.apache.org > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- > To start a new topic, e-mail: users@tomcat.apache.org > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > > Ce message et toutes les pièces jointes (ci-après le « message ») sont > confidentiels et établis à l'intention exclusive de ses destinataires. > Toute utilisation de ce message non conforme à sa destination, toute > diffusion ou toute publication, totale ou partielle, est interdite, sauf > autorisation expresse. Si vous recevez ce message par erreur, merci de le > détruire sans en conserver de copie et d'en avertir immédiatement > l'expéditeur. Internet ne permettant pas de garantir l'intégrité de ce > message, la Caisse des Dépôts et Consignations décline toute responsabilité > au titre de ce message s'il a été modifié, altéré, déformé ou falsifié. > > This email message and any attachments ("the email") are confidential and > intended only for the recipient(s) indicated. If you are not an intented > recipient, please be advised that any use, dissemination, forwarding or > copying of this email whatsoever is prohibited without Caisse des Depots et > Consignations's prior written consent. If you have received this email in > error, please delete it without saving a copy and notify the sender > immediately. Internet emails are not necessarily secured, and Caisse des > Depots et Consignations declines responsibility for any changes that may > have been made to this email after it was sent. > > > --------------------------------------------------------------------- > To start a new topic, e-mail: users@tomcat.apache.org > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > ________________________________________________________________________ > This email has been scanned for all known viruses by the MessageLabs > SkyScan service. ________________________________________________________________________ This email has been scanned for all known viruses by the MessageLabs SkyScan service. --------------------------------------------------------------------- To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
