[ClusterLabs] Question about ping nodes
arvidjaar at gmail.com
Mon Apr 19 13:20:30 EDT 2021
On 19.04.2021 19:15, Ken Gaillot wrote:
> Well, this is a new one to me. I've confirmed that this is the
> intentional behavior, and the documentation is an oversimplification.
> The documentation is partly correct: a -INFINITY score means the node
> is *never* eligible to run the resource, and a nonnegative score means
> the node *may* be eligible to run the resource under certain
> What it omits is what those circumstances are: when some other positive
> factor outweighs the negative score. For example, another constraint,
> or stickiness.
> That does give an interesting configuration possibility: with a
> stickiness able to outweigh the location constraint, any node running a
> resource when connectivity is lost would be able to continue running
> the resource, but once the resource stopped, it couldn't be started
This is missing "all nodes"; resource will stay on a node even if other
node has better connectivity.
> Anyway, a workaround to achieve the desired effect would be to give
> positive location constraints for the resource on all nodes, equal in
> dimension to the negative constraint score. Because the positive scores
> are all equal, they shouldn't affect which node is chosen, but any node
> that loses connectivity will have it score drop to 0 rather than
> negative, allowing it to run resources, while still preferring any node
> with connectivity.
This is clever. It is one of those things that is obvious after you have
seen it :)
Although I guess the same can be achieved by using positive score.
Instead of banning node without connectivity just prefer node with
connectivity. It sounds more simple.
> I've filed a bug to update either the documentation or the behavior
> (I'm not sure which would be better at this point):
>> From: Users <users-bounces at clusterlabs.org>
>> Date: Monday, April 19, 2021 at 10:28 AM
>> To: Cluster Labs - All topics related to open-source clustering
>> welcomed <users at clusterlabs.org>
>> Subject: Re: [ClusterLabs] Question about ping nodes
>> On Sun, 2021-04-18 at 17:31 +0300, Andrei Borzenkov wrote:
>>> On 18.04.2021 08:41, Andrei Borzenkov wrote:
>>>> On 17.04.2021 22:41, Piotr Kandziora wrote:
>>>>> Hope some guru will advise here ;)
>>>>> I've got two nodes cluster with some resource placement
>>>>> on ping
>>>>> node visibility (
>>>>> Is it possible to do nothing with these resources when both
>>>>> do not
>>>>> have access to the ping node?
>>>>> Currently, when the ping node is unavailable (node itself
>>>>> unavailable) both nodes stop the resources.
>>>> Just use any negative score higher than -INFINITY in location
>>> No, it does not work. I was mislead by documentation (5.2.1
>> Actually your initial interpretation was correct. Using a non-
>> negative score for the location constraint should work as expected --
>> the resource can still run there if there's no better place.
>> I'm not sure why you didn't see that in your test, maybe some other
>> factor prevented it from running?
>> BTW another solution to the initial problem would be to use multiple
>> IPs in the ping agent. It would be less likely for all of them to be
>> down at the same time without a network issue.
>>> Negative values indicate the resource(s) should avoid this node (a
>>> of -INFINITY changes "should" to "must").
>>> I interpreted "should" as "pacemaker will normally avoid this node
>>> still may chose it if nothing better is possible". It is not what
>>> happens. Apparently negative score completely prevents assigning
>>> resource to this node, and "should" here probably means "it is
>>> possible that final score may become positive".
>>> As it is not possible to refer to attributes of multiple nodes in a
>>> rule, you would need something that combines current pingd status
>>> individual nodes and makes it available. Logical place is
>>> ocf:pacemaker:ping resource agent itself.
>> Manage your subscription:
>> ClusterLabs home: https://www.clusterlabs.org/
More information about the Users