Am 08.06.2011 21:10, schrieb Digimer:
>
> This is why I started with the node about DRBD. I am not familiar enough
> with Pacemaker to make suggestions there, but if/when Pacemaker is
> unable to prevent a split brain for whatever reason, the DRBD-level
> fencing will avoid the split brain.
>
> This works because at the moment a split-brain would have occurred, DRBD
> will instead block IO and call the fence script. Only when that script
> returns success (knowing reliably that the other node is dead), will it
> unblock IO.
>
> On the victim node, it should reboot as part of the fence call and,
> hopefully, recover in a healthier state. If the node still can't contact
> the surviving node, it should wait until the network issue is resolved
> before connecting and going online.
>
> Think of it like a last line of defence to avoid the split brain when
> all else has failed.
>
fencing on resource level is better practice from my point of view,
unless, you have a network dedicated for fencing only that is completely
independent from the other two - including independent switching
infrastructure and PSU you have no way of knowing if fencing was OK, or
even comitting the fencing operation at all.
DRBD provides a fencing script, that needs to be called when the
drbd-link breaks. We are using this setup on about 50 clusters with the
same setup you have, each cluster running heavy loade oracle databases
and some of our own applications. Use two redundant rings, use bonding
with balance-rr for the interlink, if possible, use deadline as
IO-scheduler, use online verification and integrity verification. these
are good practices proven on our systems and also approved by our vendor
Novell, as well as recommended by linbit (deadline, balance-rr) good
luck with your cluster.
Robert
_______________________________________________
Openais mailing list
[email protected]
https://lists.linux-foundation.org/mailman/listinfo/openais
