[Linux-HA] Understanding the behavior of IPaddr2 clone
seligman at nevis.columbia.edu
Mon Feb 27 16:05:20 MST 2012
On 2/27/12 5:49 PM, Lars Ellenberg wrote:
> On Mon, Feb 27, 2012 at 05:41:09PM -0500, William Seligman wrote:
>>>>> 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
>>> You need clone-node-max == clone-max.
>>> It defaults to 1.
>>> Which obviously prevents nodes already running one
>>> instance from taking over an other...
>> I tried it, and it works. So there's no need for my patch. The magic invocation
>> for a highly-available IPaddr2 resource is:
>> ip_clone ip_resource meta clone-max=2 clone-node-max=2
> Note that, if you have more than two nodes, to get more evenly
> distributed buckets in the case of failover, you can also specify larger
> numbers than you have nodes. In which case by default, all nodes would
> run several. And in case of failover, each remaining node should
> takeover it's share.
>> Could this please be documented more clearly somewhere?
> Clusters from Scratch not good enought?
Drat and darnit, somehow I missed that page! Mea maxima culpa.
> But yes, I'll add a note to the IPaddr2 meta data
> where the long desc talks about cluster IP usage...
Bill Seligman | Phone: (914) 591-2823
Nevis Labs, Columbia Univ | mailto://firstname.lastname@example.org
PO Box 137 |
Irvington NY 10533 USA | http://www.nevis.columbia.edu/~seligman/
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 4497 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.linux-ha.org/pipermail/linux-ha/attachments/20120227/eec7566e/attachment.bin
More information about the Linux-HA