All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lars Ellenberg <lars.ellenberg@linbit.com>
To: drbd-dev@lists.linbit.com
Subject: Re: [Drbd-dev] changing the fencing policy on the fly
Date: Mon, 30 Nov 2009 20:10:58 +0100	[thread overview]
Message-ID: <20091130191058.GC12030@racke> (raw)
In-Reply-To: <BC2F8964429F14468EA0E6D6CF00E8C90ADFA2@EXHQ.corp.stratus.com>

On Mon, Nov 30, 2009 at 01:51:02PM -0500, Petrakis, Peter wrote:
> 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.

IPv6 is supposed to work.

> 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.

modinfo drbd
usermode_helper:string
	(default: /sbin/drbdadm)
	also available via /sys/modules/drbd/parameters/usermode_helper

You can add your own wrapper around drbdadm as "hanlder" helper.

But feel free to write a patch to replace the DRBD config interface
(currently netlink/connector resp. genetlink based) to
a sysfs based one, and we might consider it ;)

Use a "DRBD" bus, each sub dir being a single drbd,
expose all parameters we currently have,
see that you don't step on each others toes when configuring those.
you probably need a "live" and a "pending" config set,
so you can change paramters when configuring in sequence,
then "commit" them in one go.

Post on drbd-dev and possibly on lkml.

Converting single parameters to sysfs in some ad-hoc fashion,
just because you feel _this_ one should be there,
is not useful und unmaintainable.

Thanks,

	Lars


  reply	other threads:[~2009-11-30 19:09 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-30 18:51 [Drbd-dev] changing the fencing policy on the fly Petrakis, Peter
2009-11-30 19:10 ` Lars Ellenberg [this message]
  -- strict thread matches above, loose matches on Subject: below --
2009-12-01 20:50 Petrakis, Peter
2009-12-03 16:23 Petrakis, Peter

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20091130191058.GC12030@racke \
    --to=lars.ellenberg@linbit.com \
    --cc=drbd-dev@lists.linbit.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.