So, it seems that res-a is actually being promoted to Master _before_ res-b or res-c actually finish starting. The start operation is issued for both of them, but the promotion should not occur until they actually finish starting.
Also, this is accepted by the validation system:
<rsc_colocation id="res-a-not-master-on-node1-if-res-b-stopped"
score="-INFINITY">
<resource_set id="res-a-not-master-on-node1-set-1" role="Master">
<resource_ref id="res-a"/>
</resource_set>
<resource_set id="res-a-not-master-on-node1-set-2" role="Stopped">
<resource_ref id="res-b"/>
</resource_set>
</rsc_colocation>
However, it does not actually work the way I would expect. It simply prevents
res-a from starting on node1 at all. Coupled with the previous discovery, this
seems to indicate that the role="Started" and role="Stopped" are both
completely ignored. I cannot find anything in the documentation that says it is
supported, but it parses properly.
It would be really nice to support this.
Eliot Gable
Senior Engineer
1228 Euclid Ave, Suite 390
Cleveland, OH 44115
Direct: 216-373-4808
Fax: 216-373-4657
ega...@broadvox.net<mailto:ega...@broadvox.net>
[cid:image001.gif@01C9C9C3.1154B6E0]
CONFIDENTIAL COMMUNICATION. This e-mail and any files transmitted with it are
confidential and are intended solely for the use of the individual or entity to
whom it is addressed. If you are not the intended recipient, please call me
immediately. BROADVOX is a registered trademark of Broadvox, LLC.
From: Eliot Gable [mailto:ega...@broadvox.net]
Sent: Thursday, April 30, 2009 5:58 PM
To: pacema...@clusterlabs.org
Subject: [Pacemaker] Force a Master resource off a node if another resource
fails
Let's say I have these requirements:
- a master/slave resource called res-a
- a normal resource called res-b that runs on node1 only
- a normal resource called res-c that runs on node2 only
- res-b and res-c both do the same thing, but they are configured as
separate resources so I can refer to each individually
- res-a must be started before res-b or res-c start
- res-a can only be promoted to Master on node1 if res-b is running
- res-a can only be promoted to Master on node2 if res-c is running
- res-a prefers node1 to be Master
- If res-a is Master on node1 and res-b fails, res-a should move to
node2 if res-c is running
- If res-a is Master on node2 and res-c fails, res-a should move to
node1 if res-b is running
How would I set up the constraints?
This should make res-a prefer node1 over node2, but allow res-a to fail over to
node2:
<rsc_location id="res-a-location" rsc="res-a">
<rule id="res-a-location-rule-1" score="500">
<expression id="res-a-location-rule-1-exp" attribute="#uname"
operation="eq" value="node1"/>
</rule>
<rule id="res-a-location-rule-2" score="0">
<expression id="res-a-location-rule-2-exp" attribute="#uname"
operation="eq" value="node2"/>
</rule>
</rsc_location>
This should make res-b run only on node1:
<rsc_location id="res-b-location" rsc="res-b">
<rule id="res-b-location-rule-1" score="INFINITY">
<expression id="res-b-location-rule-1-exp" attribute="#uname"
operation="eq" value="node1"/>
</rule>
<rule id="res-b-location-rule-2" score="-INFINITY">
<expression id="res-b-location-rule-2-exp" attribute="#uname"
operation="eq" value="node2"/>
</rule>
</rsc_location>
This should make res-c run only on node2:
<rsc_location id="res-c-location" rsc="res-c">
<rule id="res-c-location-rule-1" score="-INFINITY">
<expression id="res-c-location-rule-1-exp" attribute="#uname"
operation="eq" value="node1"/>
</rule>
<rule id="res-c-location-rule-2" score="INFINITY">
<expression id="res-c-location-rule-2-exp" attribute="#uname"
operation="eq" value="node2"/>
</rule>
</rsc_location>
This should make res-a start before res-b starts:
<rsc_order id="order-res-a-first-then-b">
<resource_set id="res-a-set-1" sequential="true">
<resource_ref id="res-a"/>
</resource_set>
<resource_set id="res-b-set" sequential="false">
<resource_ref id="res-b"/>
</resource_set>
</rsc_order>
This should make res-a start before res-c starts:
<rsc_order id="order-res-a-first-then-c">
<resource_set id="res-a-set-2" sequential="true">
<resource_ref id="res-a"/>
</resource_set>
<resource_set id="res-c-set" sequential="false">
<resource_ref id="res-c"/>
</resource_set>
</rsc_order>
This should make res-a only run as Master on node1 if res-b is started and make
it prefer node1:
<rsc_colocation id="res-a-prefers-node1" score="500">
<resource_set id="res-a-prefers-node1-set-1" role="Master">
<resource_ref id="res-a"/>
</resource_set>
<resource_set id="res-a-prefers-node1-set-2" role="Started">
<resource_ref id="res-b"/>
</resource_set>
</rsc_colocation>
This should make res-a only run as Master on node1 if res-c is started and make
it not prefer node2:
<rsc_colocation id="res-a-not-prefer-node2" score="250">
<resource_set id="res-a-not-prefer-node2-set-1" role="Master">
<resource_ref id="res-a"/>
</resource_set>
<resource_set id="res-a-not-prefer-node2-set-2" role="Started">
<resource_ref id="res-c"/>
</resource_set>
</rsc_colocation>
I do see res-a starting before b and c, and I do see it being promoted to
master on node1. I also see res-b starting on node1 only and res-c on node2
only.
However, based on these constraints, I would expect that if I forced res-b to
fail when res-a is Master on node1, then res-a should switch to Master on
node2. Once that is done, then I would expect res-b to restart on node1 and
res-a to stay Master on node2 (because of stickiness).
Instead, if I cause res-b to fail, it simply restarts res-b. Is there something
I am missing in this logic? Do I need another constraint to force it over to
node2 if res-b fails? Do I need another constraint to force it to node1 if
res-c fails on node2?
Thanks for any assistance you can provide.
Eliot Gable
Senior Engineer
1228 Euclid Ave, Suite 390
Cleveland, OH 44115
Direct: 216-373-4808
Fax: 216-373-4657
ega...@broadvox.net<mailto:ega...@broadvox.net>
[cid:image001.gif@01C9C9C3.1154B6E0]
CONFIDENTIAL COMMUNICATION. This e-mail and any files transmitted with it are
confidential and are intended solely for the use of the individual or entity to
whom it is addressed. If you are not the intended recipient, please call me
immediately. BROADVOX is a registered trademark of Broadvox, LLC.
________________________________
CONFIDENTIAL. This e-mail and any attached files are confidential and should be
destroyed and/or returned if you are not the intended and proper recipient.
________________________________
CONFIDENTIAL. This e-mail and any attached files are confidential and should be
destroyed and/or returned if you are not the intended and proper recipient.
<<inline: image001.gif>>
_______________________________________________ Pacemaker mailing list Pacemaker@oss.clusterlabs.org http://oss.clusterlabs.org/mailman/listinfo/pacemaker
