[Gluster-users] GlusterFS 3.3 not yet quiet ready for Virtual Machines storage

[Fernando Frediani (Qube)]

Well Brian, first of all I think it's a bit of a waste to make a RAID10 on a Gluster enviroment given that the data is already replicated across other nodes. It would limit from begining the usable space to 1/4 of the Raw which is quiet a lot. Consider not only the price of the Disk, but alto to maintain it and the extra power each consumes, besides extra CPU and Memory.
I would much rather have multiple nodes made of either RAID 5 or 6 and spread the IOPS across them as if each brick was a disk in a large RAID10 enviroment (that's what was my point about spread IOPS acrross the whole cluster).
Yes some VMs could mount things directly from the Gluster volume(and using Gluster client if a Linux machine which is even better), but that is not always an option specially in if you are a Service Provider and you can not give that access to customers, so they must store they data on the local vdisks of their VMs

Fernando
________________________________________
From: Brian Candler [B.Candler at pobox.com]
Sent: 05 June 2012 17:28
To: Fernando Frediani (Qube)
Cc: 'gluster-users at gluster.org'
Subject: Re: [Gluster-users] GlusterFS 3.3 not yet quiet ready for Virtual Machines storage

On Mon, Jun 04, 2012 at 10:28:50PM +0000, Fernando Frediani (Qube) wrote:
>    I have been reading and trying to test(without much success) Gluster
>    3.3 for Virtual Machines storage and from what I could see it isn’t yet
>    quiet ready for running virtual machines.
>
>    One great improvement about the granular locking which was essential
>    for these types of environments was achieved, but the other one is
>    still not, which is the ability to use
>    striped+(distributed)+replicated.

I think you would have to have a very specialised requirement for this to be
"essential".

Suppose you have a host with 12 disks in a RAID10, and you make a replicated
volume with another similar host for resilience.  That gives you a pretty
huge I/O ops for a VM to use, and also a pretty huge VM size (depending on
how big the disks are, of course).

Also: if you are handling terabytes of data, the natural approach in many
cases would be to have a relatively small VM image, and store the data in
glusterfs, mounting it from within the VM.  This means that the same dataset
can be shared by multiple VMs, and is easier to backup and replicate.