Re: [Xen-users] live migration iscsi and lvm

[Stephan Seitz <s.seitz@xxxxxxxxxxx>]

Am Samstag, den 30.06.2012, 19:13 +0700 schrieb Fajar A. Nugraha:
> On Sat, Jun 30, 2012 at 7:06 PM, John McMonagle <johnm@xxxxxxxxxxx> wrote:
> 
> > I have been trying to get clvm working but it's dependent on cman and have 
> > not
> > had  much luck figuring out cluster.conf.
> >
> > I see the new version in testing has no dependency on cman so I think I'll 
> > try
> > that one.
> > Looks like will have to upgrade lvm2 also.
> >
> > I have seen references saying that you can not do snapshots.
> > And others saying the the snapshot  and snapshotted volume have to be on one
> > node.  That I can live with. Is that the case?
> 
> Since you're using an iscsi target anyway, why not just setup a
> separate LUN for each VM? That you don't have to worry about LVM on
> the dom0 nodes.
> 

I've tried that, but was never able to figure out how a smoothly working
multipath setup could be done for direct LUN/VM mapping. After some
xm/xl create and migrate either dm-multipath or open-iscsi always had
issues with locked devices which in most cases couldn't be freed. I
assume better scripting skills for my xen/scripts/block-* attach/detach
scripts could've mitigate that.
Additionally, using a fixed set of LUNs connected via fixed amount of
paths over fixed dedicated links and combined as PVs together to VGs
gave me the chance of setting any tcp and iscsi (target as well as
initiator) value to ideally fit to latency and bandwidth. Having
different kind of Disks and Raid behind the LUNs gives me the
possibility of offering different service tiers with guaranteed
throughput and predictable
latency to each dom0.
For future setups clvm will be my first choice again, only the lack of
snapshots for clustered VGs is a pain. Having 1:1 LUN/VM as you suggest,
it's up to your storages if (and how) snapshots can be triggered, so
if snapshots are required, one can't use clvm. At least one could get
rid of the "c" and use lvm without any locking mechanism, but when it
comes to lvresize, lvcreate -s etc. reloading the lvm layout on every
dom0 becomes mandatory. I wouldn't recommend lvm without clustering, as
it's extremely easy to get out of layout sync which include potential
data loss (requires grande cojones...)
By now, I'm running different test scenarios with plain ocfs2 and
tap:aio backends. Performance is not too bad, but I recently managed
to i/o deadlock my dom0s on high domU i/o demands. Tracking that down,
kept me from trying lvm+ocfs2 combination and other weird scenarios ;)

My advice to John would be: learn the very basics of cman and friends
(RHEL6 and derivates offers very nice tutorials, as a starting point:
look for luci and ricci) and try gfs, ocfs2 and or clvm.

cheers,

Stephan



_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxx
http://lists.xen.org/xen-users