[Pacemaker] Order Constraint for: stop rscA only when rscB is running ?

[Andreas Kurz]

On Thursday 09 October 2008 13:58:26 Andrew Beekhof wrote:
> On Oct 9, 2008, at 12:40 PM, Andreas Kurz wrote:
> > On Monday 06 October 2008 15:36:31 Andrew Beekhof wrote:
> >> On Thu, Oct 2, 2008 at 10:23, Andreas Kurz
> >>
> >> <andreas.kurz at linbit.com> wrote:
> >>> Hi,
> >>>
> >>> I have a Heartbeat 2.1.3 two-node cluster and I wonder if there is
> >>> a way
> >>> to create constraints that work like that:
> >>>
> >>> * Two resources (rscA and rscB) of class "heartbeat" that should run
> >>> together on one node .... simple advisory colocation constraint
> >>>
> >>> <rsc_colocation id="rscA-colocated-with-rscB"
> >>>       from="rscA" to="rscB"
> >>>       score="1" symmetrical="true"/>
> >>>
> >>> * When doing maintenance on one node I put the node into standby
> >>> mode and
> >>> want rscA only stop and migrate away if rscB is already up and
> >>> running on
> >>> the other node and vice versa because  there must always run at
> >>> least one
> >>> of these resources in the cluster.
> >>>
> >>> I added two order_constraints and tested it with ptest on an
> >>> adapted live
> >>> cib but they seem to produce a loop:
> >>
> >> This is logical if you draw it out (and remember that Stop X always
> >> precedes Start X)
> >
> > Yes, I expected a loop and I had a slide hope there is some
> > cool "prevent-loops" logic available ;-)
>
> Possible in theory - but there is no way to know where the "right"
> place to break the chain is.

Maybe using the priority of the resources to break the chain?

>
> >> Any reason not to just use the following?
> >>
> >> <rsc_order id="always-start-A-after-B"
> >>       from="service_rscB" action="start"
> >>       type="before"
> >>       to="service_rscA" to_action="start"
> >>       symmetrical="true" score="0"/>
> >
> > The reason is that first rscA then rscB ist stopped ... so they are
> > both down
> > before they are restarted in this order on the other node.
> >
> > The idea is ... in case of a manual switchover of all services from
> > nodeA to
> > nodeB during regular failover tests, rscA should be stopped on nodeA
> > _after_
> > rscB is already _started_ on nodeB.
>
> But in normal operation rscB should start after rscA?

This is not necessary, the should run together on one node in normal 
operation, for a short period of time they can run on different nodes ... the 
only realy demand is: keep at least one of these resources running

Regards,
Andreas

> >
> >>> <rsc_order id="stop-rscA-only-after-rscB-start"
> >>>       from="service_rscA" action="stop"
> >>>       type="after"
> >>>       to="service_rscB" to_action="start"
> >>>       symmetrical="false" score="0"/>
> >>>
> >>> <rsc_order id="stop-rscB-only-after-rscA-start"
> >>>       from="service_rscB" action="stop"
> >>>       type="after"
> >>>       to="service_rscA" to_action="start"
> >>>       symmetrical="false" score="0"/>
> >>>
> >>> Is there a way to get the requested behavior or is a manual resource
> >>> after resource migration the only way to achieve this?
...

-- 
: Andreas Kurz					 
: LINBIT | Your Way to High Availability
: Tel +43-1-8178292-64, Fax +43-1-8178292-82
:
: http://www.linbit.com

DRBD® and LINBIT® are registered trademarks of LINBIT, Austria.

This e-mail is solely for use by the intended recipient(s). Information
contained in this e-mail and its attachments may be confidential,
privileged or copyrighted. If you are not the intended recipient you are
hereby formally notified that any use, copying, disclosure or
distribution of the contents of this e-mail, in whole or in part, is
prohibited. Also please notify immediately the sender by return e-mail
and delete this e-mail from your system. Thank you for your co-operation.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.clusterlabs.org/pipermail/pacemaker/attachments/20081009/efbc1cd1/attachment-0002.sig>