[DRBD-user] DRBD performance on a budget

Christopher Chen muffaleta at gmail.com
Tue Sep 15 01:34:09 CEST 2009

Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.

>From my understanding the internal metadata write penalty in your case
is caused by seeks between the data and metadata parts of your disk.

You may experiment with metadata on a different spindle, as this will
allow you to dispatch data and metadata io in parallel.

Most people run their DRBD backing store on top of raid--in this case,
either a SAS or SATA (I'm running on FC disks). A simple 3 ware should
have BBU, which should allow you to enable write-back caching.

Good luck!


On Mon, Sep 14, 2009 at 3:48 PM, Christian Iversen
<chrivers at iversen-net.dk> wrote:
> Hey DRBD-list
> I'm trying to build a reasonably performant DRBD-minicluster (2 machines
> with heartbeat). I've got the basic setup working fine, with 2 largely
> identical servers each running a Seagate 7200.ES 500GB disk.
> This is exported as a HA-NFS on top of the 500GB DRBD volume with internal
> metadata. It's used in our production system, and we're generally very happy
> with the result (failover, etc), except the performance leaves a bit to be
> desired.
> I have a few questions:
> 1) It really seems internal metadata is a bad idea, since it eats 2 extra
> seeks per write. Is this always true, or can DRBD sometimes buffer these
> metadata-writes to minimize impact?
> 2) Suppose write latency (related to question #1) is our biggest concern. We
> are currently using protocol C. Will protocol A or B be vastly different? I
> know there's no substitute for a proper benchmarking, but we are a little
> wary of "just testing something" on our production system. Does anybody have
> experience with this they would like to share?
> 3) Suppose the write latency really is the biggest problem we're facing
> (we're still investigating the situation). As far as I can tell, a
> battery-backed storage controller is the way to go, since this will allow
> persistent stores to complete right away. However, this is for a normal
> server, not DRBD. How does DRBD affect this situation? Will such a
> controller even be useful at all?
> 4) If it will be useful, can anybody recommend a good SATA battery backed
> controller?
> I look forward to hearing any comments you might have.
> P.S: I should note that we are not willing to sacrifice data integrity for
> performance. If it seems that way from my comments about protocol A/B/C, let
> me assure you that we simply want to learn about the various bottlenecks in
> the system.
> --
> Med venlig hilsen
> Christian Iversen
> _______________________________________________
> drbd-user mailing list
> drbd-user at lists.linbit.com
> http://lists.linbit.com/mailman/listinfo/drbd-user

Chris Chen <muffaleta at gmail.com>
"The fact that yours is better than anyone else's
is not a guarantee that it's any good."
-- Seen on a wall

More information about the drbd-user mailing list