[ClusterLabs] Question about ping nodes

[Walker, Chris]

I see the same behavior as Andrei.  On a two-node test cluster (symmetric-cluster=true, resource-stickiness=100) I configure a simple Dummy resource and add the rule

      <rsc_location id="dummy_loc" rsc="dummy">
        <rule score="-10000" id="dummy_loc-rule-0">
          <expression attribute="mgmt" operation="lt" value="1" type="number" id="dummy_loc-rule-0-expression"/>
        </rule>
      </rsc_location>

If I then change the value of ‘mgmt’ to zero for both nodes, the resource stops.  We have code much like Andrei outlined to work around this behavior.

Thanks,
Chris

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:
> > > Hi,
> > >
> > > Hope some guru will advise here ;)
> > >
> > > I've got two nodes cluster with some resource placement dependent
> > > on ping
> > > node visibility (
> > > https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/high_availability_add-on_reference/s1-moving_resources_due_to_connectivity_changes-haar
> > > ).
> > >
> > > Is it possible to do nothing with these resources when both nodes
> > > do not
> > > have access to the ping node?
> > >
> > > Currently, when the ping node is unavailable (node itself becomes
> > > unavailable) both nodes stop the resources.
> > >
> >
> > Just use any negative score higher than -INFINITY in location
> > constraint.
> >
>
> No, it does not work. I was mislead by documentation (5.2.1 location
> properties):

Actually your initial interpretation was correct. Using a non-infinite
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.

>
> score:
>
> Negative values indicate the resource(s) should avoid this node (a
> value
> of -INFINITY changes "should" to "must").
>
> I interpreted "should" as "pacemaker will normally avoid this node
> but
> 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 still
> 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 for
> individual nodes and makes it available. Logical place is
> ocf:pacemaker:ping resource agent itself.
--
Ken Gaillot <kgaillot at redhat.com>

_______________________________________________
Manage your subscription:
https://lists.clusterlabs.org/mailman/listinfo/users<https://lists.clusterlabs.org/mailman/listinfo/users>

ClusterLabs home: https://www.clusterlabs.org/<https://www.clusterlabs.org/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clusterlabs.org/pipermail/users/attachments/20210419/3cdaf309/attachment-0001.htm>