On Oct 9, 2008, at 3:55 PM, Andreas Kurz wrote:
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
<[EMAIL PROTECTED]> 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?
Still wont help you, since every link in the chain is "required".
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
<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"/>
Then just this constraint should work should it not?
If A and B are both restarting, then A will always wait for B to be
active.
If only A is restarting, then B will still be active.
If only B is restarting, then A will still be active.
If A and B are stopping, the constraint is ignored.
If A is stopping, and B remains (in)active, the constraint is ignored.
If B is stopping, and A remains (in)active, the constraint is ignored.
Did I miss something?
<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.
_______________________________________________
Pacemaker mailing list
[email protected]
http://list.clusterlabs.org/mailman/listinfo/pacemaker
_______________________________________________
Pacemaker mailing list
[email protected]
http://list.clusterlabs.org/mailman/listinfo/pacemaker
