[Linux-HA] Multi-state resource constraints

Joseph Lamoree jlamoree at gmail.com
Mon Sep 24 17:43:53 MDT 2007

> i'm not very familiar with drbd, is this some sort of requirement it has?

This isn't really specific to DRBD. The privative resources could be
anything. The actual function of these two resources is to provide a
highly available NFS server. My plan is to put the NFS runtime data
from /var/lib/nfs on a shared block device (drbd:nfsmd). The other
shared block device contains a filesystem to be shared (drbd:ss). When
the NFS service moves from one cluster node to the other, all the
connection state information will be retained (in theory). I'm not an
NFS guru, but I have done a good amount of testing in my lab. My plan
it so have several DRBD resources containing files to be shared for a
group of web servers.

> > However, in reading through the information on multi state clone
> > resources, I believe it may be better to assert the negative
> > conditions.
> shouldn't be required.  where did you read that?


I thought the proper way might be to express the rules as eliminating
all undesired states. The current configuration works fine when
heartbeat is brought up on both nodes. The issues occur when one goes
to standby; when it comes back, heartbeat tries to shuffle the
resources around, and that seems to cause the problem with the second
DRBD resource getting out of sync.

> > 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.
> what version do you have?  some older versions had trouble with this.


> > 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.
> try -C instead

Using crm_resource -P actually seems to help, although it might be a

> can you attach the logs too?  i'd like to see how we got into this state.

Hopefully the attached data helps.

Joseph Lamoree

More information about the Linux-HA mailing list