User: Password:
Subscribe / Log in / New account

Sounds like fun :-)

Sounds like fun :-)

Posted Apr 23, 2009 15:44 UTC (Thu) by felixfix (subscriber, #242)
Parent article: DRBD: a distributed block device

Aside from sounding like it might actually be practical, it also sounds like fun. What if the remote node (or the local node, if it is allowed) is an NFS volume, which is itself under DRBD control? The devil in me wonders about a chain of these beasties, especially if you can see or hear drive activity, activating one after the other, fractions of a second apart.

How much delay is there from node protocol? If you had an infinitely fast network, how much difference is there among the various Protocols and compared to a standard local filesystem not under DRBD control?

Is it possible to choose whether a disk is under DRBD control? COuld you run benchmarks both ways with just a simple umount / mount between?

(Log in to post comments)

Sounds like fun :-)

Posted Apr 23, 2009 18:57 UTC (Thu) by bronson (subscriber, #4806) [Link]

DRBD has a steeper learning curve than you'd expect but, yea, it is pretty fun.

You'd need a filesystem between DRBD and NFS. If you want a primary-primary DRBD (data locally accessible on both nodes), that filesystem must be distributed, which restricts you to GFS, OCFS2, etc, which don't play well with NFS. If you set up a primary-secondary DRBD, you can use ext3 in the middle, which works great with NFS, but then the only benefit DRBD brings is hot failover. And there are MUCH easier ways to set up HA NFS. So... Probably not the best way to go.

Yes, you can stack DRBD: But, unless you're just asynchronously mirroring a volume for hot backup, which works great, stacking tends to be pretty cranky. Definitely don't think, "hey, I can create a 7 layer stack and distribute a single block device to all my satellite offices!" You won't be happy.

The delay is entirely dependent on your network; DRBD itself is pretty light. But remember that block devices tend to use TONS of bandwidth. DRBD includes a userspace proxy that will do compression to make things more tolerable over wan links but it makes things more complex... Only use it if you need to.

The node protocol just specifies how long the primary needs to wait for an ack. It allows you to trade a small risk of data loss for a large improvement in write latencies. The remote can ack immediately (A), keeping less data in flight, but there's a slightly higher risk of data loss. Or the remote can delay the ack until the data is actually in the oxide (C), reducing your potential data loss to pretty much nil, but then writes to the primary will take a lot longer and there will be a lot more data in flight at any one time.

So, with an infinitely fast network, there's basically no downside to going with C. Over a WAN, C would probably be intolerable.

> Is it possible to choose whether a disk is under DRBD control?

What do you mean? You can put pretty much any block device under DRBD control. Right now my stack is SATA > LVM > DRBD > OCFS2. Putting DRBD on top of LVM means that I can grow DRBD+OCFS2 just by attaching more storage anywhere on the system. It's pretty nice. But you could just as easily go SATA > DRBD > LVM > OCFS2 (if you will be snapshotting a lot), or SATA > LVM > DRBD > LVM > etc...

Sounds like fun :-)

Posted Apr 23, 2009 19:35 UTC (Thu) by felixfix (subscriber, #242) [Link]

You've answered all my questions and more. As for what I meant by whether a disk is under DRBD control or not, I was thinking of LVM. You can't choose at mount time whether a disk is under LVM control or not -- it is built one way or the other. I realize now I meant file system, not disk ... the B stands for Block, so a little thought and a little more clarity in my question would have answered it right from the start.


DRBD learning curve

Posted Apr 26, 2009 22:25 UTC (Sun) by giraffedata (subscriber, #1954) [Link]

DRBD has a steeper learning curve than you'd expect

From context, I'm sure you mean shallower. A steep learning curve (the graph of productivity vs time) indicates that you learn everything there is to know quickly.

DRBD learning curve

Posted Apr 27, 2009 1:45 UTC (Mon) by mgb (guest, #3226) [Link]

The familiar expression "steep learning curve" may refer alternately to rapid learning that is easy, or especially hard, or to steady progress that is increasingly difficult. Which is referred to needs to be clarified by context. The difference is specifically whether one is referring to the rate of learning or the rate of investment needed to learn.


DRBD learning curve

Posted Apr 27, 2009 3:03 UTC (Mon) by giraffedata (subscriber, #1954) [Link]

Yes, "steep learning curve" is frequently (usually, I think) used to mean it's hard to learn or there's lots to learn. So one has to know that when reading the term. But that doesn't change the fact that it's wrong and it would be better if people didn't write the term that way.

The learning curve is a well known name for a useful concept with a clear history. It was invented by industrial engineers to describe the effect of introducing a new process or machine and is always a graph of productivity vs time. It slopes upward because learning takes place.

One could imagine a graph which shows, as Wikipedia suggests, a rate of learning or of investment, but you won't find anyone drawing such graphs anywhere, unlike true learning curves. One could imagine a graph in which steepness reflects something that is hard to learn too, but no one ever uses those either (and if someone does, I'm sure he would give it a name that isn't already taken for something else).

DRBD learning curve

Posted Apr 27, 2009 3:09 UTC (Mon) by bronson (subscriber, #4806) [Link]

Time/effort required to learn is on the Y axis. It takes some studying to wrap your head around DRBD, thus the curve rises fast. Was this unclear?

Some reading material:"steep+learning+curve"

DRBD learning curve

Posted Apr 27, 2009 15:26 UTC (Mon) by giraffedata (subscriber, #1954) [Link]

Was this unclear?

It was not unclear. You'll note I didn't ask for a clarification.

Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds