Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
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. but. 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.