On Tue, Feb 28, 2012 at 03:51:29PM -0500, William Seligman wrote:
> On 2/28/12 2:09 PM, Lars Ellenberg wrote:
> > You say "fencing resource-only" in drbd.conf.
> > But you did not show the fencing handler used?
> > Did you specify one at all?
>
> It looks like I "over-edited" when I got rid of the comments before I posted
> my
> configuration. The relevant sections are:
>
> disk {
> fencing resource-only;
> }
> handlers {
> pri-on-incon-degr "/usr/lib/drbd/notify-pri-on-incon-degr.sh;
> /usr/lib/drbd/notify-emergency-reboot.sh; echo b > /proc/sysrq-trigger ;
> reboo\
> t -f";
> pri-lost-after-sb "/usr/lib/drbd/notify-pri-lost-after-sb.sh;
> /usr/lib/drbd/notify-emergency-reboot.sh; echo b > /proc/sysrq-trigger ;
> reboo\
> t -f";
> local-io-error "/usr/lib/drbd/notify-io-error.sh;
> /usr/lib/drbd/notify-emergency-shutdown.sh; echo o > /proc/sysrq-trigger ;
> halt -f";
> split-brain "/usr/lib/drbd/notify-split-brain.sh
> [email protected]";
> fence-peer "/usr/lib/drbd/crm-fence-peer.sh";
> after-resync-target "/usr/lib/drbd/crm-unfence-peer.sh";
> }
>
>
> > Besides, for a dual-primary DRBD setup, you must have "fencing
> > resource-and-stonith;", and you should use a DRBD fencing handler
> > that really fences off the peer. It may additionally set constraints.
>
> Do crm-fence-peer.sh or Lon Hohberger's obliterate-peer.sh "really" fence off
> a
> peer? I suspect your answer will be no, since from what I can tell in a
> cman+pacemaker configuration they both wind up calling stonith_admin.
The "obliterate peer" thing does.
So do the stonith_admin_fence_peer.sh and the rhcs_fence from
http://git.drbd.org/gitweb.cgi?p=drbd-8.3.git;a=tree;f=scripts
They do not set constraints, though, so you are relying
on some more DRBD internals here...
The "crm-fence-peer.sh" simply sets a constraint,
and is in itself not sufficient to shoot the peer.
It is suitable for single primary setups.
For dual primary setups, you may combine it
with the obliterate thingy or similar.
Though it should typically cause the losing side to be "demoted",
which will typically fail if it is primary, in use, and blocked
due to "fencing resource-and-stonith".
Causing demote failure, then stop failure, then node-fencing, so it may
still end up being good enough and cause the peer to be shot.
It just takes a few detours on the way.
> > Because of the increased complexity, I strongly recommend against dual
> > primary DRBD, unless you have a very good reason to want it.
> >
> > "Because it can be done" does not count as good reason in that context
>
> <off-topic>
> Sigh. I wish that were the reason.
>
> The reason why I'm doing dual-primary is that I've a got a single-primary
> two-node cluster in production that simply doesn't work. One node runs
> resources; the other sits and twiddles its fingers; fine. But when primary
> goes
> down, secondary has trouble starting up all the resources; when we've actually
> had primary failures (UPS goes haywire, hard drive failure) the secondary
> often
> winds up in a state in which it runs none of the significant resources.
>
> With the dual-primary setup I have now, both machines are running the
> resources
> that typically cause problems in my single-primary configuration. If one box
> goes down, the other doesn't have to failover anything; it's already running
> them. (I needed IPaddr2 cloning to work properly for this to work, which is
> why
> I started that thread... and all the stupider of me for missing that crucial
> page in Clusters From Scratch.)
>
> My only remaining problem with the configuration is restoring a fenced node to
> the cluster. Hence my tests, and the reason why I started this thread.
> </off-topic>
Uhm, I do think that is exactly on topic.
Rather fix your resources to be able to successfully take over,
than add even more complexity.
What resources would that be,
and why are they not taking over?
--
: Lars Ellenberg
: LINBIT | Your Way to High Availability
: DRBD/HA support and consulting http://www.linbit.com
_______________________________________________
Linux-HA mailing list
[email protected]
http://lists.linux-ha.org/mailman/listinfo/linux-ha
See also: http://linux-ha.org/ReportingProblems
