Global clusters will affect writes greatly, and may also affect you client reads in an indirect manner.
Writes, having to traverse from one region to another for purposes of voting, will be slowed down considerably by the ping time between regions.
If you did a three node deployment in the manner you mentioned, your clients may also suffer. Usually you would want to have a list of all available cluster members for your client to connect to, so if one is down or goes down the client can fail over to a running node. However, given that your client will have regional affinity for at most one of your servers, if you use the standard zk client connection logic your client either may be connected to a far region (slowing down all responses due to latency) or the client would have no failover node available should their close region node fail. If you choose to have clients able to connect to any node you may also have wan traffic considerations.
Some of the client side issues may be alleviated by using observers.
I've got deployments across regions to handle data center failure, but in all cases the off-region member is not available for client connections, and is kept from acting as leader to prevent slowness on writes.
----- Original Message -----
From: Oliver Wulff <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Sent: Wed May 04 12:37:43 2011
Subject: Importance of latency in a global deployment
I'm quite new to the zookeeper project and got a question regarding
robustness of the failover functionality in a global deployment.
Are there any pre-conditions how close the zookeeper servers must be to each
other from a geographical distance point of view?
The reason is that the servers have to monitor and sync with each other in
realtime and the latency might play an important role if for instance one
server is in the US, one in Europe and one in China.