[DRBD-user] Persistent Device Names
mail at tedyoung.me
Wed Jan 25 01:52:47 CET 2012
Thank you again, Arnold. You have given me something to think hard about.
Yes, I was planning on just having a single master with failover. Also, my
plan was to use whatever was included in Debian, which turns out to be 8.3
(on 2.6.32). This rules out the use of volumes. So, if I wanted to
continue my original strategy I would have to set each hard drive up as a
separate resource. But, I am continuing to digest your recommendations and
From: drbd-user-bounces at lists.linbit.com
[mailto:drbd-user-bounces at lists.linbit.com] On Behalf Of Arnold Krille
Sent: Tuesday, January 24, 2012 6:05 PM
To: drbd-user at lists.linbit.com
Subject: Re: [DRBD-user] Persistent Device Names
On Tuesday 24 January 2012 16:50:09 Ted Young wrote:
> > Additionally when you mirror disks directly with drbd, your
> > drbd-resources
> are fixed to the size of the disk-pairs. When you mirror lvm volumes,
> they can have the size they need to have to fulfill their > task. You
> can have drbd-resources of only some MB but also resources of the size
> of two or three of your disks toghether.
> Thank you Arnold for your reply. I think you may have hit the
> impedance mismatch on the head! You are recommending putting DRBD on
> top of a large LVM volume. In fact, I was planning on putting LVM on
> top of a bunch of mirrored (DRBD) physical drives. When one puts DRBD
> on top of LVM one risks losing the entire logical volume if a single
> drive fails. In such a case, DRBD would have to re-sync the entire
> logical volume. By putting LVM on top of DRBD, DRBD would only have to
re-sync the failed hard drive.
> That being said, I just discovered today that DRBD volumes are a
> relatively new feature. Prior to version 8.4 one would have to create
> a separate DRBD resource for every synchronized block device.
> Obviously, this would be really annoying and so using DRBD on top of
> LVM makes sense. However, I was planning on defining each physical
> hard drive as a DRBD volume within one resource then using LVM to
> stripe/aggregate them. So perhaps the reason I have found little on
> the subject is that most people have traditionally put DRBD on top of LVM
instead of the other way around.
I see your reasoning. You are planning on providing just a few "services" in
With smaller drbd resources, you could provide atomic disks for the services
and balance the load so that normally not all services run on one node just
because its all one drbd resource that is master on that node.
If you just have one big drbd resource (regardless of how many drbd-volumes
are in there), all the services need to run on that node where the resource
is in primary state. Possible but the second node will then just waste
electricity and produce heat. And the first node also might produce a lot of
heat when its reaching its capacity.
But when you have two or more drbd-resources, one can be primary on node1
with the connected services running there while the second drbd is primary
on node2 and has its services there. When all is well, the load is ~evenly
balanced, processing is low enough to use some power-savings and energy (and
bill) will be saved. Of course the systems would still have to be powerfull
enough to take over all services on a single system in case the other node
dies or is shut down. But as that shouldn't be the normal state of
operation, the load-balancing-by-distributing-services allows for a certain
over- commitment that only affects performance for the short (un-)planned
downtimes of one of the nodes.
I am not yet convinced of 8.4.X, if you plan to put this system into
production in the next weeks, it might be better to stay with latest 8.3.X.
My advocating towards drbd-on-lvm doesn't speak against lvm-on-drbd. At our
work I did several drbd-on-lvm, some of these drbd-resources are used for
gfs2, some are used for new volume groups, some are used as disks for
virtual machines and got a partition-table with pv on top.
The fact that drbd results "just" in a block device makes it very versatile.
More information about the drbd-user