[DRBD-user] Best practice: DRBD + Heartbeat
lars.ellenberg at linbit.com
Fri Feb 15 17:35:24 CET 2008
On Fri, Feb 15, 2008 at 01:21:35PM +0100, Wolfram Schlich wrote:
> Dear Linbit staff,
> first, thanks for DRBD!
> Second, what is your personal recommendation for a rock-solid
> 2-node active/passive HA cluster setup?
> If possible, please choose any combination from:
> - DRBD
> - 0.7
> - 8.0
> - Heartbeat
> - 1.x
> - drbddisk LSB RA
> - 2.x with 1.x features (without CRM)
> - drbddisk LSB RA
> - 2.x with 2.x features (with CRM)
> - drbddisk LSB RA
> - drbd OCF RA
my drbd recommendation is "use latest 8.2",
well, if you want you can stay with 8.0 of course.
and, due to the, uhm, frequent release cycle lately, you are probably
better off waiting for a release to be out for a couple of weeks without
being superseeded, aparently, before upgrading production setups.
heartbeat: 2.1.3 (or newer).
if you are new to the field, the haresources thing (1.x, no CRM)
is much more easy to grasp. it is much less flexible and less powerful
as well, though.
if you want the power of PaceMaker (aka CRM), take a day aside, and play
with it, understand what all the parameters to, what constraints are
for, what resource stickiness is, what containers are for, how to do
resource migration without leaving unwanted constrains behind, how to
avoid spurious resource migrations etc. and how to do all the magic
from the commandline without breaking it completely.
once you get used to CRM/PaceMaker, you won't go back.
so my recommendation is: [*] use CRM.
[*] (book a training for drbd+heartbeat, look at my sig :->, then)
if you want too keep it very simple, use the "legacy 1.x no crm" mode.
> Can you also explain in what case I should (not) be using:
> - /usr/lib/heartbeat/dopd + /usr/lib/heartbeat/drbd-peer-outdater
you should always have as many _independend_ heartbeat links as
possible. then, to avoid stale data from going online, use dopd.
> - fencing "resource-only" vs. "resource-and-stonith" (when I have
> configured Heartbeat with STONITH)
the question is already the answer.
for some more about dopd, see the post in our blog, last October,
iirc, google for drbd dopd blog.
> It seems like Linbit has not yet fallen in love with the
> features of Heartbeat 2.x and the drbd OCF RA :)
> I was talking to lmb about this and he said it was primarily a
> lack of time that there wasn't yet a 100% solid solution for
> the combination of DRBD-8 and the drbd OCF RA.
> Can we do something about that?
> Could you guys have a look at the drbd OCF RA?
we do, every now and then.
I believe the concept to let heartbeat load/configure/unload the drbd
module in the resource agent to be broken by design. and I still don't
really buy the "multi state multi clone master slave" resource thing.
so I don't think it is only the lack of time there,
but at least also a design problem.
yeah, I know, eventually there will be "floating peers" in two
distant data centers, floating around some N node cluster each,
connected to several SANs each blablah.
the typical setup for drbd is still two nodes, with direct attached
storage. which is also the very much recommended setup, for various
reasons, one being performance.
there is absolutely no point in handing over
the drbd configuration to heartbeat.
if anything, there may be some OCF resource agent that does what
currently "drbddisk" does, namely switching secondary/primary.
probably time will prove me wrong, though, and the design of the
OCF multi whatever drbd RA will win, that drbd RA will be fixed
and everyone will be happy.
meanwhile, you can use drbddisk with CRM style heartbeat just fine.
that is what we recommend to do right now.
: Lars Ellenberg http://www.linbit.com :
: DRBD/HA support and consulting sales at linbit.com :
: LINBIT Information Technologies GmbH Tel +43-1-8178292-0 :
: Vivenotgasse 48, A-1120 Vienna/Europe Fax +43-1-8178292-82 :
please use the "List-Reply" function of your email client.
More information about the drbd-user