That proposal came in the context of federated zookeeper, and the motivation at the time was to use multiple overlapping clusters to enable increasing write throughput as we increase the number of servers. To my knowledge, we haven't made any progress on the implementation of such a feature.

I'd be curious to understand what scenario Vishal envision for such a 2-node cluster feature. If it is not federated, then we would have trouble with ZooKeeper because we rely upon one single leader to generate state updates. In the federated case, there is one leader (perhaps multiple during non-overlapping periods of time) for each     

There is this wiki page I have written a while back:

Hope it helps.


On Oct 25, 2010, at 11:24 PM, Vishal K wrote:

Hi Mahadev,

It lets one run multiple 2-node clusters. Suppose I have an application that
does a simple 2-way mirroring of my data and uses ZK for clustering. If I
need to support many 2-node clusters, where will I find the spare machines
to run the third instance for each cluster?


On Mon, Oct 25, 2010 at 5:14 PM, Mahadev Konar <>wrote:

Hi Vishal,
This idea  (2.) had been kicked around intially by Flavio. I think heĀ¹ll
probably chip in on the discussion. I am just curious on the whats the idea
behind your proposal? Is this to provide some kind of failure gaurantees
between a 2 node and 3 node cluster?


On 10/25/10 1:05 PM, "Vishal K" <> wrote:

Hi All,

I am thinking about the choices one would have to support multiple 2-node
clusters. Assume that for some reason one needs to support multiple
This would mean they will have to figure out a way to run a third
of ZK server for each cluster somewhere to ensure that a ZK cluster is
available after a failure.

This works well if we have to run one or two 2-node clusters. However,
if we have to run many 2-node clusters?

I have following options:
1. Find m machines to run the third instance of each cluster. Run n/m
instances of ZK on each machine.
2. Modify ZooKeeper server to participate in multiple clusters. This will
allow us to run y instances of third node where each instance will be
of n/y clusters.
3. Run the third instance of ZK server required for the ith cluster on
of the server on (i+1)%n cluster. Essentially, distribute the third
across the other clusters.

The pros and cons of each approach are fairly obvious. While I prefer the
third approach, I would like to check what everyone thinks about the


research scientist
direct +34 93-183-8828
avinguda diagonal 177, 8th floor, barcelona, 08018, es
phone (408) 349 3300    fax (408) 349 3301

Reply via email to