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 address.) 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. Regards J.B