Not sure customer will accept to deploy an infrastructure service to EC2 (or any other hosting service), but it's worth mentioning it. Still there will be questions about realibility, response times, firewalls, etc.... Anyway, thx for the quick answers on this mailing list. As soon as we have relased our product I will add it to the PoweredBy page in the wiki.
Zsolt Am 02.03.2011 um 23:57 schrieb Ted Dunning: A variant is to keep the tie-breaker in EC2. That can be made fairly secure, especially if all you are hosting is status information. On Wed, Mar 2, 2011 at 2:51 PM, Zsolt Beothy-Elo <[email protected]<mailto:[email protected]>> wrote: Am 02.03.2011 um 18:56 schrieb Jesse Kempf: > Hi Zsolt, > > If the customer has a computer room at their headquarters, you could keep two > ZKs in each datacenter and a fifth ZK at their HQ. In that case you could > lose a datacenter and still have quorum. Running such an infrastructure service outside one of the data centers of course violates almost every policy (security, backup,...) that is in place at the customer. But we also had the idea :) And as Ritesh states computer at headquarter would likely become the bottleneck. Connection between centers is fast and reliable under almost all circumstances. Zsolt > > Cheers, > -Jesse > > On Mar 2, 2011, at 2:57 PM, Zsolt Beothy-Elo wrote: > >> Hi all, >> in our product we currently implement to use ZooKeeper in conjunction with >> CXF to dynamically manage available services and endpoints. Unfortunately >> one of our customers is not very happy of having to run a minimum of three >> ZooKeeper server instances to ensure fail over. The customer has two data >> centers in different locations where data and applications are replicated >> and some big-ip appliance in front of the data centers. If one data center >> fails everything must still be operable. So he would prefer to only have two >> instances one in each data center. I would be grateful for some advise how >> to best cope with these contradicting requirements. >> >> Cheers, >> Zsolt Beothy-Elo >
