[Gluster-users] GlusterFS 3.3 not yet quiet ready for Virtual Machines storage
jaw171 at pitt.edu
Tue Jun 5 14:56:05 UTC 2012
On 06/04/2012 06:28 PM, 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.
> As it stands now the natural choice would be Distributed + Replicated
> but when storing a Virtual Machines image it would reside in a single
> brick(replicated of course), so the maximum amount of IOPS for write
> would be the equivalent of a single brick’s RAID controller and its
> disks underneath, while if striped+(distributed)+replicated was
> available it would spread the IOPS across all bricks containing the
> large Virtual Machine image and therefore multiple bricks and RAID
> Also, if I understand correctly, the maximum size for a file wouldn’t
> be the size of a brick as ,again, the file would be spread across
> multiple bricks.
> This type of volume is said to be available on version 3.3 but as the
> documentation says it is only to run MapReduce workloads.
> What is everybody’s opinion about this and has this been thought or
> considered ?
I also heard it was only for MapReduce workloads but in theory can't you
just create and use it for whatever you want? Is there something that
limits it to only letting you use MapReduce?
Also, I was under the impression repl+stripe was so you can have files
larger than your brick size, not for speed improvements. I'm not sure
you would see any major speed improvements with repl+stripe vs
repl+distr unless you have lots of storage servers and lots of bricks.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Gluster-users