[Pacemaker] Force a Master resource off a node if another resource fails
Eliot Gable
egable at broadvox.net
Mon May 4 09:38:16 EDT 2009
So, is there any way to say "if res-b fails, demote res-a on node1 and promote res-a on node2?" It seems to me that this would be a common requirement. Or am I the only one who has the Master/Slave state of one resource required to be dependent on the Started/Stopped state of another resource?
The dilemma is this:
Res-A must be in slave state before Res-B or Res-C start.
Res-A must be Master on a node where Res-B or Res-C is started and operational.
What is worse is that Res-A is a group of 11 resources.
I may be able to cludge this into a single Master/Slave script with lots of attributes, but it really makes more sense for CRM to handle this natively. Please let me know if I am just being ignorant and missing something here.
Thanks again,
Eliot Gable
Senior Engineer
1228 Euclid Ave, Suite 390
Cleveland, OH 44115
Direct: 216-373-4808
Fax: 216-373-4657
egable at broadvox.net
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.
-----Original Message-----
From: Andrew Beekhof [mailto:andrew at beekhof.net]
Sent: Monday, May 04, 2009 3:39 AM
To: pacemaker at oss.clusterlabs.org
Cc: pacemaker at clusterlabs.org
Subject: Re: [Pacemaker] Force a Master resource off a node if another resource fails
On Fri, May 1, 2009 at 12:42 AM, Eliot Gable <egable at broadvox.net> wrote:
> So, it seems that res-a is actually being promoted to Master _before_ res-b
> or res-c actually finish starting.
This conflicts with "res-a must be started before res-b or res-c start".
Its not possible to configure: A-start -> B-start -> A promote
> 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
> egable at broadvox.net
>
> 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:egable at broadvox.net]
> Sent: Thursday, April 30, 2009 5:58 PM
> To: pacemaker at 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
> egable at broadvox.net
>
> 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.
>
> _______________________________________________
> Pacemaker mailing list
> Pacemaker at oss.clusterlabs.org
> http://oss.clusterlabs.org/mailman/listinfo/pacemaker
>
>
_______________________________________________
Pacemaker mailing list
Pacemaker at oss.clusterlabs.org
http://oss.clusterlabs.org/mailman/listinfo/pacemaker
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.
More information about the Pacemaker
mailing list