[one-users] Storage subsystem: which one?

[Carlos Martín Sánchez]

Hi,

On Thu, Oct 13, 2011 at 5:54 PM, Fabian Wenk <fabian at wenks.ch> wrote:

I hope this helps and my information are correct, if not, could somebody
> from OpenNebula please correct me.
>

Thank you for your great contributions to the list!

I'd like to add that we tried to summarize the implications of the shared
[1] and non-shared [2] approaches in the documentation, let us know if there
are any big gaps we forgot about.

Regards.

[1]
http://opennebula.org/documentation:rel3.0:sfs#considerations_limitations
[2]
http://opennebula.org/documentation:rel3.0:nsfs#considerations_limitations
--
Carlos Martín, MSc
Project Engineer
OpenNebula - The Open Source Toolkit for Cloud Computing
www.OpenNebula.org <http://www.opennebula.org/> | cmartin at opennebula.org


On Thu, Oct 13, 2011 at 5:54 PM, Fabian Wenk <fabian at wenks.ch> wrote:

> Hello Humberto
>
>
> On 13.10.2011 11:03, Humberto N. Castejon Martinez wrote:
>
>> Reading the Opennebula documentation, I believe there are two things I
>> have
>> to deal with:
>>
>> 1) The image repository, and whether it is shared or not between the
>> front-end and the workers
>>
>
> I have some persistent Images which are used for "persistent" VMs. I have
> the images folder shared with NFS and I use tm_nfs. When starting a VM with
> a persistent images, it creates only a soft link in VM_DIR which points to
> the image in the images folder. If you want to have copied the persistent
> image into the VM_DIR on the cluster node, you would need tm_ssh. But then
> on startup the whole image will be copied to the cluster node into VM_DIR
> and on shutdown it will be copied back to the images folder.
>
>
>  2) The<VM_DIR>, that contains deployment files, etc for the VMs running on
>> a worker. This directory may or not be shared between the front-end and
>> the
>> workers, but it should always be shared between the workers if we want
>> live
>> migration, right?
>>
>
> If you use tm_ssh you do not need to share this, if you use tm_nfs, you
> need to have it shared. The same with the images folder. For live migration
> you need a shared images folder and VM_DIR.
>
>
>  Some of the questions I have are these (sorry if some of them seem stupid
>> :-)):
>>
>
> They are not stupid, It took me some time to try out and see through how
> this things works, and so I had to change my setup a few times until
> OpenNebula an I were happy.
>
>
>  - What are the implications of sharing or not the image repository
>>  between
>> the front-end and the workers (apart from the need to transfer images to
>> the
>> worker nodes in the latter case)?
>>
>
> See above.
>
>
>  - What are the implications of sharing or not the<VM_DIR>  between the
>> front-end and the workers?
>>
>
> Also above.
>
>
>  - Can I use ZFS or MooseFs and still be able to live migrate VMs?
>>
>
> MooseFS [1] is a fault tolerant, network distributed file system (eg. over
> several servers). I do not know if ZFS can do this. MooseFS is similar like
> NFS, only that the data are distributed over several servers (including your
> local server). I guess live migration should work.
>
>  [1] http://www.moosefs.org/
>
>
>  - Will the<VM_DIR>  always hold a (copy of a) VM image for every VM
>> running
>> on a worker? Must the<VM-DIR>  be in the local hard drive of a worker or
>> may
>> it reside on an external shared storage?
>>
>
> See above, if used with tm_nfs, it is on a external shared storage (NFS
> server). When used with tm_ssh, it is on the local disk and all images
> (public or persistent) will be copied in full through ssh.
>
>
>  I guess two factors i should also consider when choosing a solution are
>> the
>> following, right?
>>
>> - The speed of transferring VM images
>> - The speed of cloning VM images
>>
>
> Yes. Access to a persistent image through NFS only transfers the data
> needed, cloning always creates a full copy. When you use tm_ssh, the image
> will always be copied in full through ssh (which also gives some CPU
> overhead on the front end and cluster node).
>
> I hope this helps and my information are correct, if not, could somebody
> from OpenNebula please correct me.
>
>
> bye
> Fabian
> ______________________________**_________________
> Users mailing list
> Users at lists.opennebula.org
> http://lists.opennebula.org/**listinfo.cgi/users-opennebula.**org<http://lists.opennebula.org/listinfo.cgi/users-opennebula.org>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opennebula.org/pipermail/users-opennebula.org/attachments/20111017/13d0ca46/attachment-0003.htm>