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

[Gao,Yan]

On 2020/3/23 8:00, Ulrich Windl wrote:
>>>> 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).

The fact about priority is, on "calculation", what resources scheduler 
should "consider" first, so that in cases where there are conflicting 
colocation/anti-colocation constraints, lack of utilization capacity, 
the resources with higher priority will get "decided" first.

So does it affect the order of the resources listed from the output of 
crm_mon? Yes. But it doesn't reflect in what order cluster transitions 
actually start the resources. That's what order constraints are for.

Regards,
   Yan

> 
> [...]
> 
> Regards,
> Ulrich
> 
> _______________________________________________
> Manage your subscription:
> https://lists.clusterlabs.org/mailman/listinfo/users
> 
> ClusterLabs home: https://www.clusterlabs.org/
>