Re: dynamic membership modification

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Patrick,

Patrick Hemmer napsal(a):
> *From: *Jan Friesse <jfriesse@xxxxxxxxxx>
> *Sent: * 2013-11-18 11:23:03 E
> *To: *Patrick Hemmer <corosync@xxxxxxxxxxxxxxx>, discuss@xxxxxxxxxxxx
> *Subject: *Re:  dynamic membership modification
> 
>> Patrick,
>>
>> Patrick Hemmer napsal(a):
>>> What is the proper way of adding and removing nodes at runtime?
>>>
>>> There was a commit
>>> (https://github.com/corosync/corosync/commit/a358791d5b5b5eaaedeba7eae4f89b0e03807c44)
>>> a couple years ago which added support for dynamically adding and
>>> removing UDPU members. But it looks like in the current release (2.3.2)
>>> this code is gone.
>> The code is still there. See cmap_keys(8) man page.
> Ah, ok. Yes the functionality still remains, things just got
> renamed/restructured :-)
> 
>>> I've been able to add nodes by simply putting them in the corosync.conf
>>> and calling `corosync-cfgtool -R`, but this does not work for removing.
>>> If I remove a node and issue the reload, corosync-cmapctl and
>>> corosync-quorumtool both still show the node.
>> Yes. The behavior there is little ... weird. The problem is that after
>> removing UDPU node, corosync will not update it's internal totemsrp
>> structures so it's still aware of nodes. Maybe there may be interesting
>> to explore possibility of moving totemsrp to gather state...
> 
> So with the info from cmap_keys(8), instead of looking in
> `runtime.totem.pg.mrp.srp.members` to see whether a node is in the
> group, I look in `nodelist.node` instead. That list is properly updated
> when a node is removed from corosync.conf and corosync is reloaded with
> `corosync-cfgtool -R`.
> 
> Would there be any need for updating the totemsrp state? The project I'm
> working on now is going to have nodes dynamically coming up and shutting
> down, so it's possible the srp list can continue to grow because of this
> activity. Would there ever be a problem with this list getting huge?

It really depends. If you talking about fixed number of nodes where only
part of them are active (let's say 64 nodes but there are always only 4
active), then list will not grow (it will be 64). But if use case is
2^24 nodes (so basically, subnet 255.0.0.0) and only 4 are active, it
may be problem.


> 
> As long as quorum is properly calculated with the target node removed,
> that's really all that matters to me (and from some playing around I
> just did, it appears to work fine).
> 

Cool

>>> The goal here is to add and remove members without having to shut
>>> corosync down and interrupt any services which are using it.
>>>
>> This is perfectly possible. Again see example in cmap_keys(8).
>> corosync-cfgtool -R is perfectly valid, it will just make your life A
>> LOT easier (you don't need to change key on every node, but only you
>> will change corosync.conf on all "to be alive" nodes and issue reload).
>>
>> Regards,
>>   Honza
> 
> Thanks again :-)
> 

Regards,
  Honza

>>
>>> Thanks
>>>
>>>
>>> -Patrick
>>>
>>>
>>>
>>> _______________________________________________
>>> discuss mailing list
>>> discuss@xxxxxxxxxxxx
>>> http://lists.corosync.org/mailman/listinfo/discuss
>>>
> 
> 

_______________________________________________
discuss mailing list
discuss@xxxxxxxxxxxx
http://lists.corosync.org/mailman/listinfo/discuss




[Index of Archives]     [Linux Clusters]     [Corosync Project]     [Linux USB Devel]     [Linux Audio Users]     [Photo]     [Yosemite News]    [Yosemite Photos]    [Linux Kernel]     [Linux SCSI]     [X.Org]

  Powered by Linux