Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Linux-HA: Pacemaker

Re: [solved] stopping resource stops others in colocation / order sets

 

 

Linux-HA pacemaker RSS feed   Index | Next | Previous | View Threaded


phil at macprofessionals

Jun 15, 2012, 9:19 AM

Post #1 of 2 (259 views)
Permalink
Re: [solved] stopping resource stops others in colocation / order sets

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
>> and
> 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 constraints.

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


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
http://oss.clusterlabs.org/mailman/listinfo/pacemaker

Project Home: http://www.clusterlabs.org
Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
Bugs: http://bugs.clusterlabs.org


andreas at hastexo

Jun 18, 2012, 8:05 AM

Post #2 of 2 (235 views)
Permalink
Re: [solved] stopping resource stops others in colocation / order sets [In reply to]

On 06/15/2012 06:19 PM, Phil Frost wrote:
> 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
>>> and
>> 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
>> constraints.
>
> 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.

Regards,
Andreas

--
Need help with Pacemaker?
http://www.hastexo.com/now

>
>
> 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
> http://oss.clusterlabs.org/mailman/listinfo/pacemaker
>
> Project Home: http://www.clusterlabs.org
> Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
> Bugs: http://bugs.clusterlabs.org
Attachments: signature.asc (0.22 KB)

Linux-HA pacemaker RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.