Digimer wrote:
On 10-09-10 08:06 AM, [email protected] 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
_______________________________________________
drbd-user mailing list
[email protected]
http://lists.linbit.com/mailman/listinfo/drbd-user
