zookeeper-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ted Dunning <ted.dunn...@gmail.com>
Subject Re: split ZK cluster across DCs?
Date Fri, 28 Sep 2012 17:25:38 GMT
I am not sure of any substantial advantage to the monitor and restart trick
over observers.  As far as I can tell, it mostly just makes the majority
more delicate.  The minority still has to send updates through to the other
data center.

On Fri, Sep 28, 2012 at 10:57 AM, Camille Fournier <camille@apache.org>wrote:

> If these nodes in the remote DC just need to read, you can do this via
> observers in the remote DC. If they need to write as well, you're in a
> tough spot. If most of the clients will be in one data center, I would
> favor keeping a majority of nodes in that datacenter and forcing the master
> to be there (via monitoring and restarting as necessary), so that you can
> get votes locally and have mostly faster writes. Otherwise you're just
> going to have a slower cluster than is optimal but that's the tradeoff for
> supporting two datacenters.
> C
> On Fri, Sep 28, 2012 at 12:13 AM, Ishaaq Chandy <ishaaq@gmail.com> wrote:
> > Hi all,
> > We're in the process of understanding the implications of splitting some
> of
> > the nodes of our system into a different DC. The DC will be situated in a
> > different continent to be geographically closer to some of our clients -
> > for network latency reasons.
> >
> > Anyway, we're trying to work out how work with our ZK cluster in this
> > scenario. The way I see it we have 2 options:
> >
> > 1. Leave our existing ZK cluster as is on our primary DC, make the nodes
> on
> > the new DC make the hop to do comms with it
> > 2. Add a couple of new local ZK nodes to the new DC and let all them sort
> > out the comms between them and the rest of the ZK cluster back in the
> > primary DC
> >
> > I am leaning towards the latter option but was wondering if any of you
> have
> > any insights/experiences in this area that might help us make an informed
> > decision.
> >
> > Thanks,
> > Ishaaq
> >

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message