Hello, On 11/02/2011 06:07 PM, King, Christopher wrote: > Hi all, > > > > We have a 2-node cluster running on the SLES 11 HAE SP1, plus the latest > supported patches. (So Pacemaker version 1.1.5, etc). In the cluster, > we have a clone resource and a stateful resource that have an > mandatoryordering constraint between the two, such that the stateful > resource will start after the clone. > > > > From the output of “crm configure show”. We reproduced the problem with > the stock “Dummy” and “Stateful” RAs. > > > > primitive testStateful ocf:heartbeat:Stateful \ > > op start interval="0" timeout="1800s" \ > > op stop interval="0" timeout="45s" \ > > op monitor interval="10s" > > > > primitive testDummy ocf:heartbeat:Dummy \ > > op monitor interval="20" timeout="10" > > > > ms testStateful-ms testStateful \ > > meta target-role="Started" master-max="1" master-node-max="1" > clone-max="2" clone-node-max="1" notify="true" ordered="false" > globally-unique="false" is-managed="true" > > > > clone testDummy-clone testDummy \ > > meta target-role="Started" > > > > order testDummy-testStateful-order inf: testDummy-clone > testStateful-ms:start > > > > I then perform some experiments: > > 1) If the testDummy instance on the same node as the > testStateful:slave instance fails, both the testStateful:slave and > testStateful:master instances are stopped, and restarted when the > testDummy instance is restarted. > > 2) If the testDummy instance on the same node as the > testStateful:master instance fails, both the testStateful:slave and > testStateful:master instances are stopped, and restarted when the > testDummy instance is restarted. > > The desired behaviour is for the instance of testStateful on the same > node as the failed instance of the testDummy to be stopped, and > restarted when the testDummy instance is restarted. In other words, we > want to be able to order an instance of a clone/stateful resource on the > instance of a clone/stateful resource on the same node. For our > purposes, it is actually very harmful if the dependent resource depends > on BOTH instances of the clone, as my experiments show that it does. > > > > So questions: > > 1) Is it possible to express with a valid configuration a “nodal” > ordering constaint between instances of different clone resources? > I.e., an ordering constraint in which the instance of the stateful > resource depends on the instance of the clone on the same node, but not > the instance of the clone on the other node. I’ve read the on-line > documentation which highly discourages referencing a clone’s child in an > ordering constraint (and by “clone’s child”, I am assuming you mean the > clone’s primitive, not a specific instance of the primitive) so I don’t > want to do that. But, if I manually edit the cluster configuration to > reference the primitives in the ordering constraint between testDummy > and testStateful, we seem to get the desired behaviour, but the cluster > configuration is technically invalid. (“crm configure verify” returns > errors.) So we don’t want to do that, but is there a valid way of > configuring for the desired behaviour? > > 2) Again, looking at the online documentation, I found a reference > to a meta attribute of clones called “interleave”. The description is a > little open to interpretation; does it refer to changing the behaviour > of ordering constraints between the instances of a clone, or between two > different cloned resources? We think the former interpretation is most > likely, but if I add a “interleave=”true” attribute to the > testDummy-clone and testStateful-ms configurations above, I get the > desired behaviour. Is that what you would expect, or is this a > side-effect that may not deterministically occur?
it refers to order constraints between different clone/multi-state resources ... so you want to add "interleave=true" to your multi-state resource. No side-effect ... it's a feature ;-) Regards, Andreas -- Need help with Pacemaker? http://www.hastexo.com/now > > > > Thanks very much. > > Chris > > > > > > _______________________________________________ > 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://developerbugs.linux-foundation.org/enter_bug.cgi?product=Pacemaker
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://developerbugs.linux-foundation.org/enter_bug.cgi?product=Pacemaker
