curator-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jordan Zimmerman <jor...@jordanzimmerman.com>
Subject Re: N+1 redundancy with Curator
Date Thu, 11 Jul 2013 16:43:24 GMT
InterProcessSemaphoreV2.getParticipantNodes() would have ordinal numbers on each node - it's
part of the recipe. But, use whichever method works best for you.

-Jordan

On Jul 11, 2013, at 8:26 AM, Ignasi Rius <iriusvsn@gmail.com> wrote:

> Hi Jordan, Eric, thanks for your advices.
> 
> InterProcessSemaphoreV2.getParticipantNodes() is fine, but as Jordan
> says, I would like that each participant knows who it is ordinally.
> The reason is that I would like to use this number as an identifier
> for the "role" I want that node to fulfill.
> 
> Eric's suggestion will do the job and looks  pretty easy to implement
> and mantain. I will store a "list of roles" somewhere, and once a node
> acquires de semaphore, it will try to create each "role node" until it
> succeeds. That's it.
> 
> Thanks!
> 
> 2013/7/10 Eric Tschetter <echeddar@gmail.com>:
>> 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> 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