[DRBD-user] LCMC display (and other tools) says "up to date" but DRBD is not

Adam Goryachev mailinglists at websitemanagers.com.au
Thu Oct 25 15:55:44 CEST 2012

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


On 26/10/12 00:38, Whit Blauvelt wrote:
> I love ASCII art! Really, any diagram is good. Helps disperse the opacity.
>
> In the interest of understanding how an average administrator can get
> confused here: DRBD on setup offers to duplicate the data on the primary to
> the secondary. That works. So it would seem (to the naive) like it sees the
> data at that point, and has every opportunity to insert itself under the
> data, per your 3rd diagram. In the case where that data was a normal
> filesystem, that's what DRBD does, right? That's the point of the offer to
> duplicate the existing data from primary to secondary? So with a normal
> filesystem, you can have a filesystem with data, add DRBD, and DRBD slips
> itself under the filesystem. With a VM written raw to a logical volume, DRBD
> can see things well enough to handle the initial duplication, but fails to
> slip itself under the VM.

To me, it is a bit like having a filesystem on /dev/sda1, then telling
mdadm to build a RAID1 array from that as /dev/md0 along with /dev/sdb1.
mdadm is smart enough to copy the bits from /dev/sda1 to /dev/sdb1.
However, if you still do a mount /dev/sda1 /mnt, change lots of bits,
and then umount, then mount /dev/md0 /mnt, you will get a confusing, and
inconsistent mess.

It shouldn't be surprising to learn the unix allows you to shoot
yourself in the foot, or the arm, or even the head, and you can do it in
exceptionally interesting and exciting ways if you choose.

In your case, it sounds like you used LVM (block devices) instead of
/dev/sda1, and that you used DRBD instead of mdadm, and you used kvm
instead of mount... but at the end of the day, you told kvm to slip
under DRBD, which is allowed, but it hurts.....

I would suggest that at the least, you will need to
1) Stop one VM (at a time)
2) Start the VM on top of DRBD instead of LVM
3) Instruct DRBD to throw away the secondary
4) do a full sync from the primary to the secondary

Repeat for each VM
Internal or External metadata is irrelevant, as long as the VM's are
reading/writing to DRBD and not LVM.

You might have chosen to do it this way:
sda1 -> DRBD -> LVM -> VM

instead of
sda1 -> LVM -> DRBD -> VM


Regards,
Adam

-- 
Adam Goryachev
Website Managers
www.websitemanagers.com.au




More information about the drbd-user mailing list