On 23/07/2013 18:11, Charles Lyons - ConnetU wrote:
If we snapshot the LV itself, presumably we'll get a copy not only of
the VM's volume block data but also of DRBD metadata on the LV (which I
understand is stored in the end/final segment(s) of the LV).
Yes, assuming you are using internal metadata. I'm doing exactly this too.
(1) Is there any danger of this process not giving a DRBD-consistent
snapshot? Is there anything within DRBD which needs to be flushed/synced
prior to starting the snapshot (as is the practice with SQL)?
I've found it to be 100% reliable, it worked absolutely fine when I
really needed it.
(2) How is best to restore an image file of the LV, assuming the VM is
offline and, if necessary, the DRBD resource can be
detached/disconnected on each/both side(s)?
I treat it more or less like a new resource. I do the below, this works
but is perhaps OTT:
# Shutdown the VM
drbdadm secondary <resource> # on the primary node
drbdadm down <resource> # on both nodes
# Restore the LV image to the LV on one node
drbdadm create-md <resource> # on both nodes
drbdadm up <resource> # on both nodes
drbdadm -- -o primary <resource> # on the node I restored
# Start the VM
Because you have new metadata on both nodes, there will be a full resync
doing the above.
I suppose, but have not tried and proven, that this could be simplified
by just doing:
# Shutdown the VM
# Restore the LV image to the DRBD resource in primary role.
# Start the VM
The LV image will of course be longer than the DRBD resource but the
extra is the metadata at the end of the volume which we're not
interested in anyway. Because you write to the DRBD resource rather than
the underlying LV, the sync to the secondary is already happening during
your restore.
(3) Presumably it doesn't matter if the snapshot is taken on the primary
or secondary?
With protocol C, it doesn't matter.
Second related topic: if we've got an existing snapshot, can we use this
as the basis for creating a totally new DRBD resource... i.e. creating a
new LV of identical size, dd the image to the LV and then create a new
DRBD resource on top. Is there anything in the metadata (like global
UUIDs) which could be duplicated and confuse DRBD? If so, is there a
recommended way to "reset" the metadata prior to attaching so it will
appear as a totally new pre-seeded volume?
Yes, using the method I described above (drbdadm create-md <resource>)
you'll have fresh metadata on both sides. You'll be prompted before it
overwrites the existing metadata.
HTH,
Simon
_______________________________________________
drbd-user mailing list
[email protected]
http://lists.linbit.com/mailman/listinfo/drbd-user