[Pacemaker] ordering cloned resources

Andrew Beekhof andrew at beekhof.net
Mon Mar 10 21:13:56 EDT 2014 

On 9 Mar 2014, at 10:36 pm, Alexandre <alxgomz at gmail.com> wrote:

> So...,
> 
> It appears the problem doesn't come from the primitive but for the
> cloned resource. If I use the primitive instead of the clone in the
> order constraint (thus deleting the clone and the group) , the second
> resource of the constraint startup as expected.
> 
> Any idea why?

Not without logs

> 
> Should I upgrade this pretty old version of pacemaker?

Yes :)

> 
> 2014-03-08 10:36 GMT+01:00 Alexandre <alxgomz at gmail.com>:
>> 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
>>> 
> 
> _______________________________________________
> 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://lists.clusterlabs.org/pipermail/pacemaker/attachments/20140311/b06716d7/attachment-0003.sig>

More information about the Pacemaker mailing list