CLVM + DRBD dual primary? (was Re: replicated file system?)

[Alan Johnson]

On Wed, Feb 29, 2012 at 10:32 AM, Mark Komarinski <mkomarinski at wayga.org>wrote:

> As pointed out before, DRBD can do active/active, so long as the
> filesystem on top support it (GFS2 and OCFS2).  The DRBD team even has
> documentation to get you started:
>
> http://www.drbd.org/users-guide/ch-gfs.html
> http://www.drbd.org/users-guide/ch-ocfs2.html
>

The "active/active" terminology just clicked for me.  (brain fart! I was
pretty tired when I was responding before.)  While I am very intrigued by
this dual-primary functionality in DRBD, I expect gluster will work out
bitter-faster-stronger for Kenny in my experience, even if it would not
bring you a bed pan and breakfast as beens seems to have interpreted my
previous comments to include.   ;-p  [Ass-ide: Of course, Ben is right.
Only certain drugs can make "everything trivial", and they don't last.]  =)

That said, does anyone know if CLVM would meet the needs of a dual-primary
DRBD?  I'm having trouble finding good docs on clustering LVM.  Maybe I
just need to look again now that I'm more awake! =)  Still, any hints would
be appreciated.

If it matters, the LVs would only be accessed by one node at a time.  They
would serve as backing block devices for KVM virtual drives enabling live
migration.  This could remove the need for iSCSI and heartbeat from my
current DRBD>LVM>iSCSI>heartbeat setup.

If this works as expected, it would be ideal for a 2 host cloud, but live
migration would not be possible outside those 2 hosts.  Unless... can
DRBD+CLVM be multi-primary?  Of course, this quickly leads to excessive
redundancy... unless... DRBD can do something like RAID5/6/Z/Z2, but I'm
sure I'm asking too much there, especially if I want it to be efficient
over a network.

I can imagine that CLVM across a bunch of iSCSI PVs would be ideal,
allowing mirroring and/or stripping on a per LV basis, but I again, I can't
find good docs on CLVM to back me up.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.gnhlug.org/mailman/private/gnhlug-discuss/attachments/20120229/368c41de/attachment.html