Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
* Lars Ellenberg <lars.ellenberg at linbit.com> [2008-02-15 17:36]: > 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? > > 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. So, if I start "from scratch" right now, 8.2 is your recommendation? > 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) Hehe :) I have already learned the basics of the CRM/CIB stuff and now have a almost 100% working setup (at least that's what I think). Indeed I might consider such a training, thanks for the headsup :o) > if you want too keep it very simple, use the "legacy 1.x no crm" mode. Of course, I'd lose the monitoring functionality inside Heartbeat (provided by the OCF resource agents). I'd have to externally monitor the cluster resources with -- say -- mon, right? > > 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. Ok, I currently have a crossover ethernet and a serial cable, so I will probably be using dopd. What about two nodes only interconnected by a single network link, for example because they are like 50m away from each other, in the same building but in two different fire protection areas? It doesn't make any sense to use dopd in this case, does it? Heartbeat itself will only be using the same communication channel as DRBD... > > - 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. Yeah, I've already read that... ok, I guess I will stay with "resource-and-stonith" then 8) > > 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. Well, from my understanding, the drbd OCF RA does not much more than combining the functionality of /etc/init.d/drbd + /etc/ha.d/resource.d/drbddisk, or am I wrong?! I mean, to Heartbeat/CRM, DRBD is just a resource like any other. As none of the other resources may be started/initialized outside of Heartbeat/CRM, I don't see what shall be so bad to do the same with DRBD... it's the only consistent approach to resource management, I believe. > 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. Do you know of any cases in which the drbd OCF RA broke DRBD-8? It's said to work fine with DRBD-0.7... > meanwhile, you can use drbddisk with CRM style heartbeat just fine. > that is what we recommend to do right now. Lars, thanks a lot for sharing your view on that topic! It will clearly help me and others to assess the different choices. Maybe I will just patch the drbddisk LSB RA functionality to be OCF compliant and name it drbd-simple or something. Might be less confusing for new users like me. Currently it looks like the drbd OCF RA is "new style" and therefore the better choice... Have a nice weekend! -- Regards, Wolfram Schlich <wschlich at gentoo.org> Gentoo Linux * http://dev.gentoo.org/~wschlich/