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

[Gao,Yan]

On 2020/3/23 14:04, Gao,Yan wrote:
> 
> 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, 

I mean conflicting situations in regard of colocation/anti-colocation 
constraints.

Regards,
   Yan


> 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/
>>