curator-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eric Tschetter <eched...@gmail.com>
Subject Re: N+1 redundancy with Curator
Date Wed, 10 Jul 2013 16:31:23 GMT
The other option is to have a specific znode for each "role" that you want
fulfilled.  On startup, you have each process race to claim one of those
znodes by creating an ephemeral node.  If it manages to create its
ephemeral node, then it acts as that role.  If it gets a
NodeExistsException, then it tries another role.

This is similar to electing a leader for each role.  It does cause some
stampeding when a node goes down, though.  There also is no recipe for this
currently.

--Eric

On Wednesday, July 10, 2013, Jordan Zimmerman wrote:

> I would use InterProcessSemaphoreV2. Does each node need to know which
> participant it is ordinally? If so, I'm curious why. In any event, you can
> use setNodeData() to set an identifier for each participant. Just like
> LeaderLatch InterProcessSemaphoreV2 has a getParticipantNodes() method.
>
> -Jordan
>
> On Jul 10, 2013, at 3:18 AM, Ignasi Rius <iriusvsn@gmail.com<javascript:;>>
> wrote:
>
> > Hi all,
> >
> > I am a newbie to Zookeeper and Curator. After a couple of weeks
> > reading, testing and playing with it, I am quite convinced that it is
> > a great solution for our cluster management needs.
> >
> > I would like to ask you some advice on how could I implement the
> > following behaviour based on Curator recipes:
> >
> > We provide a service which is split/distributed among N nodes, and we
> > would like to implement a N+1 redundancy strategy. That is N active
> > nodes plus 1 spare node which can "behave" as any of the others.
> >
> > Indeed, when each node starts, it should take the following role:
> > - a) Behave like a Spare Node: iif there are already "N" nodes working.
> > - b) Behave like node (M+1): if  (M < N) (assuming M is the number of
> > current workers).
> >
> > Then, in case that any of the N working nodes dies, the Spare one
> > should behave like the one that died.
> >
> >
> > Summarizing, as an exemple with  3 hosts (1,2 and 3) this is a
> > possible sequence of events:
> >
> > - Host 1 starts and acts as Node 1.
> > - Host 2 starts and acts as Node 2.
> > - Host 3 starts and acts as a Spare Node.
> > - Host 2 dies.
> > - Host 3 takes over and acts as Node 2.
> >
> >
> > My question is about what do you guys think would be the best
> > "practice" for implementing such scenario?
> >
> > I thought that the simplest thing to do was using an
> > InterProcessSemaphoreV2 (N), so if a node can acquire the semaphore,
> > it means that it is not the "Spare" one. However, I don't see a way in
> > Curator to find out "which node I am" in case I can acquire de
> > semaphore.
> >
> > On the contrary, LeaderLatch seems to handle participant IDs, etc...
> > but there is only "one leader" at a time (obviusly).
> >
> > Thanks for your time. Any ideas are welcome.
> >
> > Best,
> > Ignasi
>
>

Mime
View raw message