[Pacemaker] [RFC] [Patch] DC node preferences (dc-priority)

[Florian Haas]

On Fri, May 25, 2012 at 11:38 AM, Lars Ellenberg
<lars.ellenberg at linbit.com> wrote:
> On Fri, May 25, 2012 at 11:15:32AM +0200, Florian Haas wrote:
>> On Fri, May 25, 2012 at 10:45 AM, Lars Ellenberg
>> <lars.ellenberg at linbit.com> wrote:
>> > Sorry, sent to early.
>> >
>> > That would not catch the case of cluster partitions joining,
>> > only the pacemaker startup with fully connected cluster communication
>> > already up.
>> >
>> > I thought about a dc-priority default of 100,
>> > and only triggering a re-election if I am DC,
>> > my dc-priority is < 50, and I see a node joining.
>>
>> Hardcoded arbitrary defaults aren't that much fun. "You can use any
>> number, but 100 is the magic threshold" is something I wouldn't want
>> to explain to people over and over again.
>
> Then don't ;-)
>
> Not helping, and irrelevant to this case.
>
> Besides that was an example.
> Easily possible: move the "I want to lose" vs "I want to win"
> magic number to be 0, and allow both positive and negative priorities.
> You get to decide whether positive or negative is the "I'd rather lose"
> side. Want to make that configurable as well? Right.

Nope, 0 is used as a threshold value in Pacemaker all over the place.
So allowing both positive and negative priorities and making 0 the
default sounds perfectly sane to me.

> I don't think this can be made part of the cib configuration,
> DC election takes place before cibs are resynced, so if you have
> diverging cibs, you possibly end up with a never ending election?
>
> Then maybe the election is stable enough,
> even after this change to the algorithm.

Andrew?

> But you'd need to add an other trigger on "dc-priority in configuration
> changed", complicating this stuff for no reason.
>
>> We actually discussed node defaults a while back. Those would be
>> similar to resource and op defaults which Pacemaker already has, and
>> set defaults for node attributes for newly joined nodes. At the time
>> the idea was to support putting new joiners in standby mode by
>> default, so when you added a node in a symmetric cluster, you wouldn't
>> need to be afraid that Pacemaker would shuffle resources around.[1]
>> This dc-priority would be another possibly useful use case for this.
>
> Not so sure about that.
>
>> [1] Yes, semi-doable with putting the cluster into maintenance mode
>> before firing up the new node, setting that node into standby, and
>> then unsetting maintenance mode. But that's just an additional step
>> that users can easily forget about.
>
> Why not simply add the node to the cib, and set it to standby,
> before it even joins for the first time.

Haha, good one.

Wait, you weren't joking?

Florian

-- 
Need help with High Availability?
http://www.hastexo.com/now