[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-users] High availability and live migration with just LVMand hardware fencing


  • To: xen-users@xxxxxxxxxxxxxxxxxxx
  • From: Frank S Fejes III <frank@xxxxxxxxx>
  • Date: Tue, 25 May 2010 09:17:17 -0500
  • Delivery-date: Tue, 25 May 2010 07:19:46 -0700
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:content-type :content-transfer-encoding; b=PG58V5AsS45YUdi5DlAy5DMIaweIfvufp3RCz5SUkVrF8vTGGLGOUUlm6G0FQwcR2r /J2AU3lsKT6BHRjQ0hOnW5b1KcEu12xP8rWNpnnStZaI1wyKoEq1Cc9JC/svmFjWE4J6 LNuDOws7lBEe8AYorzoosNY1Z42uZX9lqlcKs=
  • List-id: Xen user discussion <xen-users.lists.xensource.com>

On Mon, May 24, 2010 at 1:00 PM, Bart Coninckx <bart.coninckx@xxxxxxxxxx> wrote:
> On Monday 24 May 2010 19:29:35 John Madden wrote:
>> > John, I'm interested as to why you feel this is unsafe and what bad
>> > experiences you may have had doing shared lvm in a manual (ie,
>> > non-clvm) fashion.  In clusters of up to six Xen hosts per iscsi
>> > target I've been using a combination of scripted lvchange/lvscan
>> > commands in lvm wrappers and have never yet run into corruption.  As
>> > far as I'm aware, there's nothing magical that clvm is doing under the
>> > covers besides locking and if all lvm commands are run via the
>> > "clustered" wrappers then the metadata should not be changing
>> > unexpectedly.
>>
>> If you carefully coordinate changes to the metadata and, for example,
>> reload the data on all cluster members on every change, I think you
>> would be ok.  CLVM takes care of all this for you and uses locking to
>> ensure changes on one node can't clash with other nodes.

> Quite interesting point of view, since it is so different from the one of
> authors commenting before ...
> This is somewhat difficult in regards to taking decisions on setups: one party
> says "don't", the other says "do".

Well, please don't read my post as a recommendation to "do".  I'm only
writing to say that I've done it and that I do not yet have a
technical reason for why it *shouldn't* work.  As others have pointed
out, the process to enabling clvm is long and problematic which is why
I originally set out for a way to avoid it altogether.  I think I've
done that and I've been using it with success so far.

That said, I've never been completely satisfied with this solution for
a number of reasons.  For one, it's completely undocumented and who's
to say that a future update to lvm won't start doing things to the
metadata that breaks my assumptions?  For another, it would seem that
very few other people are doing it which is partly why I posted in the
first place.  I'd love to see if other people such as John are doing
this and what their experiences have been.

What I'd *really* love to see is clvm decoupled from the rhel
clustering beast and packaged as a barebones easy-to-configure and
deploy option to the base lvm package.

--frank

_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.