[ClusterLabs] Pacemaker ordering constraints and resource failures

Andrei Borzenkov arvidjaar at gmail.com
Wed Aug 8 00:37:28 EDT 2018


08.08.2018 07:36, Andrei Borzenkov пишет:
> 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

s/can/can not/

Sorry :)

> (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