[Pacemaker] resources not migrating when some are not runnable on one node, maybe because of groups or master/slave clones?
Phil Frost
phil at macprofessionals.com
Mon Jun 18 14:33:06 UTC 2012
On 06/18/2012 10:14 AM, Vladislav Bogdanov wrote:
> Sets (constraints with more then two members) are evaluated in the
> different order.
> Try
> colocation colo_drbd_master inf: ( drbd_nfsexports_ms:Master ) (
> vg_nfsexports ) ( test )
I'm sure that's the wrong order. I've put the parens on each resource to
force crm to create three sets of one resource each. Otherwise, it would
make two sets, one with DRBD, and one with vg_nfsexports and test. To
maintain the correct order (that is, vg_nfsexports requires the DRBD
master, and test requires vg_nfsexports), I'd have to write this:
colocation colo_drbd_master inf: vg_nfsexports test
drbd_nfsexports_ms:Master [1]
As you've proposed, if "test" can't run, then nothing can. If
"vg_nfsexports" can't run, then test can run but drbd_nfsexports_ms can
not. If drbd_nfsexports_ms can not run, then vg_nfsexports and test are
not affected. That's the opposite of what I think makes sense. I only
know this because I hashed exactly this out just last week. The
documentation is wrong, and crm's syntax is arcane and misleading. See
here: http://oss.clusterlabs.org/pipermail/pacemaker/2012-June/014420.html
Even so, I think in a situation where some node could run all the
resources, the intended behavior is that Pacemaker will use that
resource placement, regardless of the ordering of the colocation
constraint. The ordering only should come in to play when there's no
node that can run all the resources, or when there are multiple
solutions that run all resources and it must decide which is "best". I
think. If I'm wrong on that point please correct me.
[1] yes, really.
More information about the Pacemaker
mailing list