[ClusterLabs] Antw: [EXT] Re: Coming in Pacemaker 2.0.4: fencing delay based on what resources are where

[Ulrich Windl]

>>> Andrei Borzenkov <arvidjaar at gmail.com> schrieb am 21.03.2020 um 18:22 in
Nachricht
<14318_1584811393_5E764D80_14318_174_1_6ab730d7-8cf0-2c7d-7ae5-8d0ea8402758 at gmai
.com>:
> 21.03.2020 20:07, Ken Gaillot пишет:
>> Hi all,
>> 
>> I am happy to announce a feature that was discussed on this list a
>> while back. It will be in Pacemaker 2.0.4 (the first release candidate
>> is expected in about three weeks).
>> 
>> A longstanding concern in two-node clusters is that in a split brain,
>> one side must get a fencing delay to avoid simultaneous fencing of both
>> nodes, but there is no perfect way to determine which node gets the
>> delay.
>> 
>> The most common approach is to configure a static delay on one node.
>> This is particularly useful in an active/passive setup where one
>> particular node is normally assigned the active role.
>> 
>> Another approach is to use the relatively new fence_heuristics_ping
>> agent in a topology with your real fencing agent. A node that can ping
>> a configured IP will be more likely to survive.
>> 
>> In addition, we now have a new cluster-wide property, priority-fencing-
>> delay, that bases the delay on what resources were known to be active
>> where just before the split. If you set the new property, and configure
>> priorities for your resources, the node with the highest combined
>> priority of all resources running on it will be more likely to survive.
>> 
>> As an example, if you set a default priority of 1 for all resources,
>> and set priority-fencing-delay to 15s, then the node running the most
>> resources will be more likely to survive because the other node will
>> wait 15 seconds before initiating fencing. If a particular resource is
>> more important than the rest, you can give it a higher priority.
>> 
> 
> That sounds good except one consideration. "priority" also affects
> resource placement, and changing it may have rather unexpected results,
> especially in cases when scores are carefully selected to achieve
> resource distribution.

I've always seen pririties as "super odering" constraints: Try to run the
important resources first (what ever their dependencies or scores are).

[...]

Regards,
Ulrich