[Linux-HA] Multi-state resource constraints
jlamoree at gmail.com
Fri Sep 21 22:56:42 MDT 2007
I have a two-node cluster that has two multi-state resources, each of
which contain a DRBD primitive. These two resources must be promoted
to master on the same node, but that's not always the case --
especially after one or the other nodes go to standby and back online.
Currently constraints exist like so:
<rsc_colocation from="drbd1" to="drbd0" to_role="master" score="INFINITY"/>
<rsc_order from="nfs1_fs_nfsmd" action="start" to="drbd0" to_action="promote"/>
<rsc_order from="nfs1_fs_ss" action="start" to="drbd1" to_action="promote"/>
<rsc_colocation from="nfs1_fs_nfsmd" to="drbd0" to_role="master"
<rsc_colocation from="nfs1_fs_ss" to="drbd1" to_role="master" score="INFINITY"/>
The meaning that I intended is this:
Always have drbd0 and drbd1 run as master on the same node.
Start drbd0 and drbd1 before mounting their filesystems
Always make drbd0 and drbd1 master before mounting their filesystems
However, in reading through the information on multi state clone
resources, I believe it may be better to assert the negative
conditions. I'm sure this is a common requirement for systems with two
DRBD resources that need to be masters on the same node. I would
appreciate guidance from users that have this type of configuration
I don't know if this is by design, but when a node comes back from
standby, the other node will stop all its resources and then restart
them -- even though the resources should stay in place on the node
acting as master. I increased the default resource stickiness in an
effort to prevent this, but it didn't make a difference. In the
process, the second DRBD gets all confused:
Master/Slave Set: drbd0
drbd0_nfsmd:0 (heartbeat::ocf:drbd): Master teri
drbd0_nfsmd:1 (heartbeat::ocf:drbd): Started eve
Master/Slave Set: drbd1
drbd1_ss:0 (heartbeat::ocf:drbd): Slave teri (unmanaged) FAILED
drbd1_ss:1 (heartbeat::ocf:drbd): Started eve
In this state, I thought I could use drbdadm up ss && drbdadm primary
ss, then crm_resource -R, but that doesn't fix it up. I've attached
the CIB when in this state, if it'll help.
I know that's a whole lot. Thanks for your patience.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 3877 bytes
Desc: not available
Url : http://lists.community.tummy.com/pipermail/linux-ha/attachments/20070921/52084b26/crazy-master-slave.xml.bin
More information about the Linux-HA