seligman at nevis
Feb 27, 2012, 2:23 PM
Post #14 of 19
On 2/27/12 4:10 PM, Lars Ellenberg wrote:
Re: Understanding the behavior of IPaddr2 clone
[In reply to]
> On Mon, Feb 27, 2012 at 03:39:04PM -0500, William Seligman wrote:
>> On 2/24/12 3:36 PM, William Seligman wrote:
>>> On 2/17/12 7:30 AM, Dejan Muhamedagic wrote:
>>>> OK, I guess that'd also be doable by checking the following
>>>> OCF_RESKEY_CRM_meta_notify_inactive_resource (set of
>>>> currently inactive instances)
>>>> OCF_RESKEY_CRM_meta_notify_stop_resource (set of
>>>> instances which were just stopped)
>>>> Any volunteers for a patch? :)
>>> a) I have a test cluster that I can bring up and down at will;
>>> b) I'm a glutton for punishment.
>>> So I'll volunteer, since I offered to try to do something in the first place. I
>>> think I've got a handle on what to look for; e.g., one has to look for
>>> notify_type="pre" and notify_operation="stop" in the 'node_down' test.
>> Here's my patch, in my usual overly-commented style.
> Sorry, I may be missing something obvious, but...
> is this not *the* use case of globally-unique=true?
I did not know about globally-unique. I just tested it, replacing (with name
clone ipaddr2_clone ipaddr2_resource meta notify="true"
clone ipaddr2_clone ipaddr2_resource meta globally-unique="true"
This fell back to the old behavior I described in the first message in this
thread: iptables did not update when I took down one of my nodes.
I expected this, since according to "Pacemaker Explained",
globally-unique="true" is the default. If this had worked, I never would have
reported the problem in the first place.
Is there something else that could suppress the behavior you described for
> Which makes it possible to set clone-node-max = clone-max = number of nodes?
> Or even 7 times (or whatever) number of nodes.
> And all the iptables magic is in the start operation.
> If one of the nodes fails, it's bucket(s) will be re-allocated
> to the surviving nodes.
> And that is all fully implemented already
> (at least that's how I read the script).
> What is not implemented is chaning the number of buckets aka clone-max,
> without restarting clones.
> No need for fancy stuff in *pre* notifications,
> which are only statements of intent; the actual action
> may still fail, and all will be different than you "anticipated".
>> - To make this work, you need to turn on notify in the clone resources; e.g.,
>> clone ipaddr2_clone ipaddr2_resource meta notify="true"
>> None of the clone examples I saw in the documentation (Clusters From Scratch,
>> Pacemaker Explained) show the notify option; only the ms examples do. You may
>> want to revise the documentation with an IPaddr2 example.
>> - I tested this with my two-node cluster, and it works. I wrote it for a
>> multi-node cluster, but I can't be sure it will work for more than two nodes.
>> Would some nice person test this?
>> - I wrote my code assuming that the clone number assigned to a node would remain
>> constant. If the clone numbers were to change by deleting/adding a node to the
>> cluster, I don't know what would happen.
> For "anonymous clones", it can be relabeled.
> In fact, there are plans to remove the clone number from anonymous
> clones completely.
> However, for globally unique clones,
> the clone number is part of its "identifier".
Bill Seligman | Phone: (914) 591-2823
Nevis Labs, Columbia Univ | mailto://seligman [at] nevis
PO Box 137 |
Irvington NY 10533 USA | http://www.nevis.columbia.edu/~seligman/