Giacomo Bagnoli <g.bagnoli@...> 2009-05-18 12:27:
> Hi all,
> this is my first message here, I did a quick search on google but I did
> not found the answers I'm looking for.
> I'm trying to setup (well, right now I am experimenting :) ) a 2 node
> cluster with drbd-shared storage using 64bit profile on 2 intel xeon
> servers. I've successfully setup drbd 8 in primary-primary using an lvm
> LV as drbd disk with ocfs2 (that's it, drbd over lvm). 
> Now I'm trying to do the opposite, lvm over a drbd device, using drbd1
> as a PV for a lvm VG. If I've understood the problem correctly I need
> clvm to manage active-active configuration to avoid metadata corruption
> when managing LVs. 
> This shared PV is not the system PV I use for the node OS, it's on
> another disk that i plan to share directly via drbd.
> 
> What confuses me is the presence of sys-fs/clvm and sys-fs/lvm2 with
> clvm and cman use flags.
> I've installed sys-fs/lvm2-2.0.45, when trying to install clvm I get
> blockers (device-mapper and lvm2 itself).
> sys-fs/lvm2 clvm and  cman use flags are profile masked on amd64 (but
> not on x86), why?
> Should I need to downgrade lvm2 and install clvm or do it's safe to try
> out unmasking those use flags by overriding the profile (I'm using
> paludis and already have a custom profile that inherit from
> amd64/2008.0/server)? 
> 
> Thanks in advance,
> 	Giacomo 

I remember looking at this a while ago as well and being fairly
confused.  I'm fairly certain that lvm2 with the use flags you mention
is the way to go, so you might have to unmask them in your
/etc/portage/profile/use.mask (add -clvm, -cman).

OCFS2 generally uses it's own different cluster stack than CMAN (which
uses openais).  Since I believe 2.6.26 you can use the other one, but I
haven't found it to be as stable.  It also requires quite a bit of extra
configuration for proper fencing, whereas that's built into the OCFS2
stack.  Since you're doing this with DRBD it sounds like you're trying
to do it on the cheap so proper fencing probably isn't available
anyways.

If you aren't doing anything with LVM that needs to be cluster aware
(eg: just a concatenation of multiple PVs, no striping) then it should
be just fine without CLVM.  The key is that you /must/ take all but one
node offline (umount; vgchange -an) before you do any LVM operations
such as adding more extents, else they'll have an inconsistent view of
the VGs/LVs.  This also isn't technically supported but I've run it
without problems for a year or so now.

Brian