[Pacemaker] ordering cloned resources
Alexandre
alxgomz at gmail.com
Sat Mar 8 09:36:49 UTC 2014
Hi Andrew,
I have tried to stop and start the first resource of the ordering
constraint (cln_san), hoping it would trigger a start attemps of the
second resource of the ordering constraint (cln_mailstore).
I tailed the syslog logs on the node where I was expecting the second
resource to start but really nothing appeared in those logs (I grepped
'pengine as per your suggestion).
I have done another test, where I changed the first resource of the
ordering constraint with a very simple primitive (lsb resource), and
it worked in this case.
I am wondering if the issue doesn't come from the rather complicated
first resource. It is a cloned group which contains a primitive
conditional instance attributes...
Are you aware of any specific issue in pacemaker 1.1.7 with this kind
of ressources?
I will try to simplify the resources by getting rid of the conditional
instance attribute and try again. In the mean time I'd be delighted to
hear about what you guys think about that.
Regards, Alex.
2014-03-07 4:21 GMT+01:00 Andrew Beekhof <andrew at beekhof.net>:
>
> On 3 Mar 2014, at 3:56 am, Alexandre <alxgomz at gmail.com> wrote:
>
>> Hi,
>>
>> I am setting up a cluster on debian wheezy.
>> I have installed pacemaker using the debian provided packages (so am
>> runing 1.1.7-ee0730e13d124c3d58f00016c3376a1de5323cff).
>>
>> I have roughly 10 nodes, among which some nodes are acting as SAN
>> (exporting block devices using AoE protocol) and others nodes acting
>> as initiators (they are actually mail servers, storing emails on the
>> exported devices).
>> Bellow are the defined resources for those nodes:
>>
>> xml <primitive class="ocf" id="pri_aoe1" provider="heartbeat"
>> type="AoEtarget"> \
>> <instance_attributes id="pri_aoe1.1-instance_attributes"> \
>> <rule id="node-sanaoe01" score="1"> \
>> <expression attribute="#uname"
>> id="expr-node-sanaoe01" operation="eq" value="sanaoe01"/> \
>> </rule> \
>> <nvpair id="pri_aoe1.1-instance_attributes-device"
>> name="device" value="/dev/xvdb"/> \
>> <nvpair id="pri_aoe1.1-instance_attributes-nic"
>> name="nic" value="eth0"/> \
>> <nvpair id="pri_aoe1.1-instance_attributes-shelf"
>> name="shelf" value="1"/> \
>> <nvpair id="pri_aoe1.1-instance_attributes-slot"
>> name="slot" value="1"/> \
>> </instance_attributes> \
>> <instance_attributes id="pri_aoe2.1-instance_attributes"> \
>> <rule id="node-sanaoe02" score="2"> \
>> <expression attribute="#uname"
>> id="expr-node-sanaoe2" operation="eq" value="sanaoe02"/> \
>> </rule> \
>> <nvpair id="pri_aoe2.1-instance_attributes-device"
>> name="device" value="/dev/xvdb"/> \
>> <nvpair id="pri_aoe2.1-instance_attributes-nic"
>> name="nic" value="eth1"/> \
>> <nvpair id="pri_aoe2.1-instance_attributes-shelf"
>> name="shelf" value="2"/> \
>> <nvpair id="pri_aoe2.1-instance_attributes-slot"
>> name="slot" value="1"/> \
>> </instance_attributes> \
>> </primitive>
>> primitive pri_dovecot lsb:dovecot \
>> op start interval="0" timeout="20" \
>> op stop interval="0" timeout="30" \
>> op monitor interval="5" timeout="10"
>> primitive pri_spamassassin lsb:spamassassin \
>> op start interval="0" timeout="50" \
>> op stop interval="0" timeout="60" \
>> op monitor interval="5" timeout="20"
>> group grp_aoe pri_aoe1
>> group grp_mailstore pri_dlm pri_clvmd pri_spamassassin pri_dovecot
>> clone cln_mailstore grp_mailstore \
>> meta ordered="false" interleave="true" clone-max="2"
>> clone cln_san grp_aoe \
>> meta ordered="true" interleave="true" clone-max="2"
>>
>> As I am in an "opt-in cluster" mode (symmetric-cluster="false"), I
>> have the location constraints bellow for those hosts:
>>
>> location LOC_AOE_ETHERD_1 cln_san inf: sanaoe01
>> location LOC_AOE_ETHERD_2 cln_san inf: sanaoe02
>> location LOC_MAIL_STORE_1 cln_mailstore inf: ms01
>> location LOC_MAIL_STORE_2 cln_mailstore inf: ms02
>>
>> So far so good. I want to make sure the initiators won't try to search
>> for exported devices before the targets actually exported them. To do
>> so, I though I could use the following ordering constraint:
>>
>> order ORD_SAN_MAILSTORE inf: cln_san cln_mailstore
>>
>> Unfortunately if I add this constraint the clone Set "cln_mailstore"
>> never starts (or even stops if started when I add the constraint).
>>
>> Is there something wrong with this ordering rule?
>> Where can i find informations on what's going on?
>
> No errors in the logs?
> If you grep for 'pengine' does it want to start them or just leave them stopped?
>
>>
>> _______________________________________________
>> Pacemaker mailing list: Pacemaker at 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
>
>
> _______________________________________________
> Pacemaker mailing list: Pacemaker at 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
>
More information about the Pacemaker
mailing list