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@oss.clusterlabs.org > 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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Pacemaker mailing list: Pacemaker@oss.clusterlabs.org 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