Re: [Xen-users] Storage Question

[Ramon Moreno <rammor1@xxxxxxxxx>]

> Fajar,
>
> Thanks for the info.
>
> I think option 2 sounds most attractive. I would like to get rid of
> the gfs filesystem. So going nfs with it is a great idea.
>
> As far as the clustering goes, I use the software mainly for the
> following reasons:
>
> * A global view for the redistribution of resources.
> * Automated failover.
>
> Since I have 20 nodes per cluster I am looking at, I need a more
> global view of how things look, and if I become resource constrained,
> I would like the clustering software to make the failover decision
> based on available resources. Only thing I oversubscribe is cpu by
> 50%, so if a host becomes unusable, I would like to failover vms to
> another node based on policy decisions.
>
> Any thoughts on this would also be much appreciated... Thanks for your
> reply. nfs is an excellent idea.
>
> On Sat, Jan 31, 2009 at 5:12 PM, Fajar A. Nugraha <fajar@xxxxxxxxx> wrote:
>> On Sun, Feb 1, 2009 at 5:08 AM, Ramon Moreno <rammor1@xxxxxxxxx> wrote:
>>> Option 1:
>>> I present a single iscsi lun to my systems in the cluster. I then
>>> carve it up using lvm for the vms. The problem with this solution is
>>> that if I clone a vm, it takes mass network bandwidth.
>>
>> True. But for most iscsi servers cloning will take mass amount of
>> resources anyway (whether it's network, disk I/O, or both). Using
>> ionice during cloning process might help by giving cloning process
>> lowest priority.
>>
>>> Option 2:
>>> I present multiple iscsi luns to the systems in the cluster. I still
>>> add to lvm so I dont have to about labeling and such.
>>> Adding to lvm
>>> ensures things dont change with the lun on reboot.
>>
>> I think you can also use /dev/disk/by-path and by-id for that purpose
>>
>>> With this option I
>>> can use the storage layer (using a netapp like solution) to clone luns
>>> and such.
>>
>> If you clone LUNs on storage/target side, then you can't use LVM on
>> the initiator. The cloning process will copy any LVM label on it
>> making the cloned LUN a duplicate PV, which can't be used on the same
>> host.
>>
>>> This eliminates the possibility of saturating the network
>>> interfaces when cloning vms.
>>
>> How does your iscsi server (netapp or whatever) clone a LUN? If it
>> copies data, then you'd still be I/O bound.
>>
>> An exception is if you use zfs-backed iscsi server (like opensolaris)
>> where cloning process requires near-zero I/O with zfs clone.
>>
>> Note that with option 2 you can also avoid using clustering altogether
>> (by putting config files on NFS or synchronizing them manually), which
>> eliminates the need of fencing. This would greatly reduce complexity.
>>
>> Regards,
>>
>> Fajar
>>
>

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