[ClusterLabs] How to cancel a fencing request?

Klaus Wenninger kwenning at redhat.com
Thu Apr 5 03:43:05 EDT 2018


On 04/05/2018 06:45 AM, Andrei Borzenkov wrote:
> 04.04.2018 01:35, Ken Gaillot пишет:
>> On Tue, 2018-04-03 at 21:46 +0200, Klaus Wenninger wrote:
> ...
>>>>> -inf constraints like that should effectively prevent
>>>>> stonith-actions from being executed on that nodes.
>>>> It shouldn't ...
>>>>
>>>> Pacemaker respects target-role=Started/Stopped for controlling
>>>> execution of fence devices, but location (or even whether the
>>>> device is
>>>> "running" at all) only affects monitors, not execution.
>>>>
>>>>> Though there are a few issues with location constraints
>>>>> and stonith-devices.
>>>>>
>>>>> When stonithd brings up the devices from the cib it
>>>>> runs the parts of pengine that fully evaluate these
>>>>> constraints and it would disable the stonith-device
>>>>> if the resource is unrunable on that node.
>>>> That should be true only for target-role, not everything that
>>>> affects
>>>> runnability
>>> cib_device_update bails out via a removal of the device if
>>> - role == stopped
>>> - node not in allowed_nodes-list of stonith-resource
>>> - weight is negative
>>>
>>> Wouldn't that include a -inf rule for a node?
>> Well, I'll be ... I thought I understood what was going on there. :-)
>> You're right.
>>
>> I've frequently seen it recommended to ban fence devices from their
>> target when using one device per target. Perhaps it would be better to
>> give a lower (but positive) score on the target compared to the other
>> node(s), so it can be used when no other nodes are available.
>>
> Oh! So I must have misunderstood comments on this in earlier discussions.
>
> So ability to place stonith resource on node does impact ability to
> perform stonith using this resource, right? OTOH decision which node is
> eligible to use stonith resource for stonith may not match decision
> which node is eligible to start stonith resource? Even more confusing ...

Something like that, yes ... and sorry for the confusion ...
Maybe easier to grab: "Has to be able to run there but doesn't
actually have to be started there right at the moment"

Regards,
Klaus

>>> It is of course clear that no pengine-decision to start
>>> a stonith-resource is required for it to be used for
>>> fencing.
>>>
> This means that there is only subset of usual (co-)locating restrictions
> that is taken into account? Is it all documented somewhere?

iirc there are restrictions mentioned in the documentation.
But what is written there didn't ring the right bells for me-
at least not immediately without having a look to the code ;-)
So we are working on something easier to grab there.
Guess for now the crucial rule is not to use anything that
might alter location-rule results over time (attributes, rules
with time in them, ...).

> _______________________________________________
> Users mailing list: Users at clusterlabs.org
> https://lists.clusterlabs.org/mailman/listinfo/users
>
> Project Home: http://www.clusterlabs.org
> Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
> Bugs: http://bugs.clusterlabs.org




More information about the Users mailing list