Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
Zookeeper >> mail # user >> split ZK cluster across DCs?


Copy link to this message
-
Re: split ZK cluster across DCs?
Good point. The monitor and restart trick is if you need the second DC to
be voting for BCP purposes (over 3 datacenters), but otherwise an Observer
is the way to go.

C

On Fri, Sep 28, 2012 at 1:25 PM, Ted Dunning <[EMAIL PROTECTED]> wrote:

> 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 <[EMAIL PROTECTED]
> >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 <[EMAIL PROTECTED]>
> 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
> > >
> >
>