[ClusterLabs] Pacemaker ordering constraints and resource failures

Andrei Borzenkov arvidjaar at gmail.com
Wed Aug 8 04:36:49 UTC 2018


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 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_Scratch.pdf
> Bugs: http://bugs.clusterlabs.org
> 



More information about the Users mailing list