andreas at hastexo
Jun 18, 2012, 8:05 AM
Post #2 of 2
On 06/15/2012 06:19 PM, Phil Frost wrote:
Re: [solved] stopping resource stops others in colocation / order sets
[In reply to]
> On 06/15/2012 11:55 AM, David Vossel wrote:
>>> If resC is stopped
>>> resource stop resC
>>> then drbd_nfsexports is demoted, and resB and resC will stop. Why is
>>> that? I'd expect that resC, being listed last in both the colocation
>> It is the order constraint.
>> Order constraints are symmetrical. If you say to do these things in
>> this order
>> 1. promote drbd
>> 2. start resB
>> 3. start rscC
>> Then the opposite is also true. If you want to demote drbd it the
>> following has to happen first.
>> 1. stop rscC
>> 2. stop resB
>> 3. demote drbd
>> You can get around this by using the symmetrical option for your order
> True, but I wasn't demoting DRBD; I was stopping resource C (mostly to
> see what would happen if for whatever reason, it couldn't run anywhere).
> The order constraint alone doesn't explain the behavior I saw. However,
> I think I've pieced together what was actually happening. This constraint:
> colocation colo inf: drbd_nfsexports_ms:Master resB resC
Yes, unfortunately this is quite confusing in the crm shell syntax.
Because a resource-set can only have one specific role, crm shell
creates in this example two resource-sets. One for the drbd resource and
one for the two simple resources.
So you have two sets. Within the "simple" resource-set resB is more
significant then resC (like in a group).
Between the two resource-sets, drbd depends on the "simple" resource-set
(needs to be Master on the same host) and will be demoted as soon as (at
least) resC is stopped or not runable.
Need help with Pacemaker?
> means, very confusingly, that to be a master, resB and resC must be
> active. Also, for resC to be active, resB must be active. In other words
> (with some transitive reduction applied):
> drbd -> resC -> resB
> It doesn't make any sense, and the documentation is wrong (or at least
> self-conflicting). But that's what it really does mean. What was really
> confusing is that were it not for the :Master modifier, then crm would
> make only one resource set, and it would mean something else. So when I
> was testing with dummy resources, I was only more confused. I made
> another post explaining it more.
> So, DRBD can't be master unless resC and resB are active. And as you
> explained, the order constraint will stop resC and resB if DRBD is
> demoted. Combined, that means either all these things run, or none:
> - resC is stopped, or can't run anywhere
> - (by colocation constraint) DRBD may not be master. Demote it.
> - (by order constraint) stop resC (actually a no-op: it's already stopped)
> - (by order constraint) stop resB
> Pacemaker mailing list: Pacemaker [at] oss
> Project Home: http://www.clusterlabs.org
> Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
> Bugs: http://bugs.clusterlabs.org