[ClusterLabs] Antw: [EXT] Re: Coming in Pacemaker 2.0.4: fencing delay based on what resources are where
ygao at suse.com
Mon Mar 23 09:10:35 EDT 2020
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
>> <14318_1584811393_5E764D80_14318_174_1_6ab730d7-8cf0-2c7d-7ae5-8d0ea8402758 at gmai
>>> 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
>>>> 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
> 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.
>> Manage your subscription:
>> ClusterLabs home: https://www.clusterlabs.org/
More information about the Users