[DRBD-user] DRBD on top of LVM - 50% performace drop

trekker.dk at abclinuxu.cz trekker.dk at abclinuxu.cz
Fri Sep 10 20:12:25 CEST 2010

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

Digimer wrote:
> On 10-09-10 08:06 AM, trekker.dk at abclinuxu.cz wrote:
>> As I mentioned, I tested DRBD in _standalone_ mode - without network
>> connection - so I don't need to take any network-related latencies into
>> account.
>> The only thing added on top of LVM (and all those other layers) here is
>> the DRBD layer, which doesn't need to wait on network and (in my
>> opinion) should be passing requests to lower layers as quickly as possible.
> Dan's comment about Protocol is important. With Protocol C, DRBD will
> not return a successful write to the OS until the data has been written
> to disk on both nodes. Without the other node there, you could be seeing
> slowdown caused by DRBD waiting, and then giving up, for communication
> with the other disconnected node.
> Re-run your tests with Protocol A. Of course, as Dan pointed out, this
> is not normally safe. However, if you're rarely ever going to have the
> other node connected...

Now you got me quite confused. I seriously thought, that when I run DRBD 
in StandAlone mode, there's nowhere to set the protocol. (According to 
man page drbdsetup x disk has no parameter, which could specify the peer 
or protocol or any other network-related stuff.)

I just can't imagine, that DRBD attempts to use network without being 
told to do so. (Where would it try to connect? I didn't told it any IP 

Can't use protocol A/B, because AFAIK hypervisor needs to access 
partitions both on the old and on the new host during migration. That 
means dual primary setup and AFAIK only protocol C is able to do that.

> As an aside, have you considered simply freezing and dd'ing your VM when
> you want to migrate it? It doesn't seem like you really need DRBD if
> you're not concerned about keeping the data sync'ed across two nodes.

Well I wanted live migration without downtime and dd takes a lot of 
time. So I agree, I don't need DRBD most of the time, but I wasn't able 
to come up with any other way to do live migration without it and 
without resorting to having images in files.

Anyway, I just (quite accidentally) found out that only first write onto 
DRBD is slow and subsequent writes are much faster (nearly as fast as 
underlying storage.) My guess is first run is slowed by out-of-sync 
metadata changes.

I never tried to re-run the test without resetting DRBD metadata, 
because I don't usually see problems fixing themselves on their own. ;-) 
My bad.

Thanks for your time.


More information about the drbd-user mailing list