[Linux-cluster] [clvm] Volume group for uuid not found

[Gordan Bobic]

Abraham Alawi wrote:
> On 2/02/2010, at 11:31 AM, Gordan Bobic wrote:
> 
>> Abraham Alawi wrote:
>>> On 2/02/2010, at 5:21 AM, Gordan Bobic wrote:
>>>> AlannY wrote:
>>>>> On Mon, Feb 01, 2010 at 03:34:18PM +0000, Christine Caulfield wrote:
>>>>>> Is it really two different devices ? If so then clvmd will not work.
>>>>>> It needs the same view of storage on all systems. Not necessarily
>>>>>> the same names, but definitely the same actual storage.
>>>>> So, should I use DRBD with clvm for data mirroring on both nodes?
>>>> You could, indeed, use DRBD. Or you could cross-export the block devices with iSCSI (or ATAoE) and have them connected to all the nodes that way. I guess it depends on whether you prefer to use DRBD or CLVM. My preference is for DRBD, but don't let that bias your decision. :)
>>>>
>>>> Gordan
>>>>
>>> I reckon GNBD will be a better solution in your case, DRBD is more
>>> suitable for non-cluster file systems (e.g. ext3, xfs .. ) in case
>>> of active-passive
>> DRBD is specifically designed to also work in active-active mode. I've been running shared root GFS clusters on DRBD for years. DRBD is singularly _THE_ best solution for network RAID1, _especially_ in active-active mode with a clustered file system on top. It also handles resyncing after outages much more gracefully and transparently than other similar solutions.
>>
>> Gordan
>>
> 
> Yes, it does work in active-active but DRBD people themselves don't
> recommend running it in production active-active under cluster file
> system, I quote from their website:
> "DRBD's primary-primary mode with a shared disk file system (GFS,
> OCFS2). These systems are very sensitive to failures of the
> replication network. Currently we cannot generally recommend this
> for production use."
> http://www.drbd.org/home/mirroring/

That surprises me - it could just be an out of date page. I've used it 
in active-active mode with GFS on top in all sorts of harsh and abusive 
edge-case ways and never saw it skip a beat.

> In terms of production solution I reckon GNBD is designed more
> specifically for that purpose.

Not really. GNBD is really paper thin and quite dumb. It doesn't 
actually have any feature overlap with DRBD. It's more akin to iSCSI, in 
the sense that it is for exporting a block device, not mirroring a block 
device. In other words it's a 1->many export feature. It won't provide 
mirroring on it's own. Features like mirroring and post-outage resync 
have to be taken higher by "some else". And these alternatives handle 
failures nowhere nearly as gracefully as DRBD. For example, if a DRBD 
mirror fails (failed disk), all access will get transparently redirected 
to the surviving mirror. If a node disconnects, upon reconnection it 
will sync on the blocks that changed since it was last connected, and do 
so transparently, as you would expect.

Gordan