[Linux-HA] Multi-state resource constraints

[Joseph Lamoree]

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"
score="INFINITY"/>
<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
working properly.

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.

-- 
Joseph Lamoree
-------------- next part --------------
A non-text attachment was scrubbed...
Name: crazy-master-slave.xml.gz
Type: application/x-gzip
Size: 3877 bytes
Desc: not available
Url : http://lists.community.tummy.com/pipermail/linux-ha/attachments/20070921/52084b26/crazy-master-slave.xml.bin