[Pacemaker] Force a Master resource off a node if another resource fails

[Andrew Beekhof]

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
>
>