[Drbd-dev] changing the fencing policy on the fly

Petrakis, Peter Peter.Petrakis at stratus.com
Mon Nov 30 19:51:02 CET 2009

Hi All,
I have a challenge with the use of fencing and the state of flux in our
cluster. The system 
will setup drbd devices in advance and use them independent of it's
peer, which will mirror
it's config once it joins the cluster. Since the fencing helper makes
use of drbdadm and thus
the config file we have a problem. If fencing were to be triggered, it
would immediately fail
with a bad exit status because the config file is inconsistent. We use a
naming convention
for the disks in our cluster so the only piece of information I don't
know at this time is my
peers ip address.

To work around this bug I set the fencing policy to 'dont-care' and then
once the resource
is connected and uptodate, detach the backing store and then reattach it
with the desired
fencing policy. This leaves us vulnerable however, should the link go
down for any reason we're
in big trouble.

I'm trying to eliminate this hole without detaching the backing store. I
can't play tricks with
aliasing the eth interface to some address because I'm not physically in
control of the box and don't
want to ruin someone's network in case they hook up the wires
incorrectly. DRBD doesn't seem to support
IPV6 link local addressing which would help in this case because the
nodes are directly attached.

What I'd like to do is to change the fencing policy on demand and the
mechanism I wish to use is sysfs.
Do you guys see any pitfalls with this approach, locking especially? The
reason I want to use sysfs is two
fold. I want to get away from using drbdadm for the userspace helper and
it'll make writing software to
manage drbd more straight forward. Thanks in advance.


More information about the drbd-dev mailing list