[ClusterLabs] Pacemaker ordering constraints and resource failures
Ken Gaillot
kgaillot at redhat.com
Wed Aug 8 09:59:29 EDT 2018
On Wed, 2018-08-08 at 07:36 +0300, Andrei Borzenkov wrote:
> 06.08.2018 20:07, Devin A. Bougie пишет:
> > What is the best way to make sure pacemaker doesn’t attempt to
> > recover or restart a resource if a resource it depends on is not
> > started?
> >
> > For example, we have two dummy resources that simply sleep -
> > master_sleep and slave_sleep. We then have a non-symmetrical
> > ordering constraint that ensures master_sleep is started before
> > slave_sleep:
> > start master_sleep then start slave_sleep (kind:Mandatory) (non-
> > symmetrical)
This constraint tells the cluster to behave in the way you described.
The "non-symmetrical" parts means that *only* starts are ordered:
slave_sleep cannot start until master_sleep has been started, but it
can then run independently, regardless of whether master_sleep stops or
fails.
If you want slave_sleep to also stop whenever master_sleep is stopped,
then simply leave off the non-symmetrical -- the default behavior is
what you want. When symmetrical, slave_sleep will be stopped before
stopping master_sleep (including if master_sleep fails).
> >
> > This works as expected when both resources are disabled. If we
> > enable slave_sleep first, it won’t actually start until after
> > master_sleep if enabled and started.
> >
> > However, if slave_sleep dies when master_sleep is disabled and
> > stopped, pacemaker recovers and restarts slave_sleep. For example:
> > - enable master_sleep, and wait for it to start
> > - enable slave_sleep, and wait for it to start
> > - disable master_sleep, and wait for it to stop
>
> While I can answer your question (although gut feeling is that
> behavior
> is expected) - what is your final goal? If I interpret documentation
> correctly, the configuration with master target state "stop" and
> slave
> target state "start" makes it impossible to start slave at all. So
> while
> it may be interesting exercise, what are you trying to achieve at the
> end?
>
> > - kill the slave_sleep process (or, “pcs resource debug-stop
> > slave_sleep”)
> > - pacemaker recovers and restarts slave_sleep, even though
> > master_sleep is disabled and stopped.
> >
>
> Actually my first reaction was "why slave was left started when
> master
> was stopped" :) If you do not question *this*, I'd say this behavior
> is
> logically correct - pacemaker tries to maintain status quo, and
> target
> state is "slave running" so it just tries to keep it running.
>
> Whether slave should have been stopped when master had been stopped
> is
> interesting question; documentation is not exactly clear on semantic
> of
> Mandatory ordering constraints.
>
> > Is this the expected behavior, and is there any way to change
> > it? I’m happy to provide logs if that would help.
> >
> > Many thanks,
> > Devin
> >
> >
> >
> > _______________________________________________
> > 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_Scratc
> > h.pdf
> > Bugs: http://bugs.clusterlabs.org
> >
>
> _______________________________________________
> 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
--
Ken Gaillot <kgaillot at redhat.com>
More information about the Users
mailing list