WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-users

Re: [Xen-users] Re: Xen + SAN



Viele Grüße.
Christian

Am 23.06.2011 um 23:41 schrieb Javier Guerra Giraldez <javier@xxxxxxxxxxx>:

On Thu, Jun 23, 2011 at 4:04 PM, Shaun Reitan
<mailinglists@xxxxxxxxxxxxxxxx> wrote:
I don't know about AOE but with ISCSI the problem I'm seeing is that if i
create a volume group on the SAN there is no way to export that volume
group.  I could export the device that the volume group was created on but
then the host doesn't see that VG. I'm assuming i would need to use
clustered LVM for that which i have been told to stay far away from. Another
option was to carve out the LV's on the SAN and to export each LV to the
initiators but still the problem is that the host assigns these luns to
/dev/sd devices and there's no simple nice way to map them to who owns what
disk.  Least not that I've found yet.  I'm fairly new to ISCSI though so
maybe there's something I'm missing.


your problem has two parts:

A: the sharing/splitting. iSCSI shares block devices, and (as you've
found) a VG is not a block device.  you have to either export PVs or
LVs
Fibre channel is also easy to use.
there are three (main) ways to do it:

1: don't worry about partitions/LVM on the target. Export disks (or
rather, arrays).  On the initator(s) set those as PVs to create a VG
and then LVs.  typically you do it on only one initiator and then
vgscan on all the others (like John Madden).

pros: simple, manageable.  cons: no lock protection, resizing LVs can
be dangerous without suspending initiators.


2: do as 1, but use cLVM.  any LVM management done on any initiator is
automatically and atomically seen by all of them.

pros: safer.  cons: the lock manager itself is a big pain to manage.

CLVM is not a pain. You only need cLVM if you follow some rules. IO fencing, pacemaker and all this complicated stuff is not really needed. Only cLVM compiled with openais. You can even make snapshots in a cluster environment with the latest version of LVM2. I use this since 3 years now and never lost a machine.

3: do all the LVM management on the target(s), export each LV as an
iSCSI LUN.  Most commercial iSCSI appliances include management on par
with LVM, at the very least.
This is a pain, when you have more then 100 machines, as I have.

pros: much safer, easier to handle, no need of shared locks.   cons:
you can't have a LV spanning two targets.


B:  the Linux iSCSI initiator exposes each LUN as a full drive:
/dev/sdd, /dev/sde, etc., not as a 'partition' /dev/sdX1, /dev/sdX2,
etc.   That's because they're exactly the same as SCSI disks.  but,
just like SCSI disks, those LUNs are partitionable with any tool.
just do `parted /dev/sdX` and create a full-size /dev/sdX1 partition.

(BTW, wasn't there an iSCSI-specific 'phy:' driver? something like
'phy:iscsi:<lun name>'.... or am i mixing faint memories?)

--
Javier

_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
<Prev in Thread] Current Thread [Next in Thread>