It is essential to see the ratio of: No of active VMs / No of servers. If it is >= 1 (which is usually the case) then you already aren't getting the theoretical claims of striping (apart from the configuration overheads and complexity).<div>
<br></div><div>Avati<br><br><div class="gmail_quote">On Tue, Jun 5, 2012 at 8:58 AM, Fernando Frediani (Qube) <span dir="ltr"><<a href="mailto:fernando.frediani@qubenet.net" target="_blank">fernando.frediani@qubenet.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
<div style="direction:ltr;font-size:10pt;font-family:Tahoma">I think the main limitation of using other than strip+repl type is that first the maximum size of a file is the size of a brick and sometimes Virtual Machines tend to be really
big, second is that the performance of a single image file (say .VMDK for example) will be limited to a a single's brick performance, while if you could strip that big file accross multiple nodes it would spread the IOPS as well through several RAID controllers
and caching systems.<br>
But I've tried that type of volume and it didn't work at all to run Virtual Machines.<br>
<br>
Fernando<br>
<br>
<div style="font-size:16px;font-family:Times New Roman">
<hr>
<div style="direction:ltr"><font color="#000000" face="Tahoma"><b>From:</b> <a href="mailto:gluster-users-bounces@gluster.org" target="_blank">gluster-users-bounces@gluster.org</a> [<a href="mailto:gluster-users-bounces@gluster.org" target="_blank">gluster-users-bounces@gluster.org</a>] on behalf of Anand Avati [<a href="mailto:anand.avati@gmail.com" target="_blank">anand.avati@gmail.com</a>]<br>
<b>Sent:</b> 05 June 2012 16:41<br>
<b>To:</b> Whit Blauvelt<br>
<b>Cc:</b> <a href="mailto:gluster-users@gluster.org" target="_blank">gluster-users@gluster.org</a><div class="im"><br>
<b>Subject:</b> Re: [Gluster-users] Striped replicated volumes in Gluster 3.3.0<br>
</div></font><br>
</div>
<div></div>
<div><br><div><div class="h5">
<br>
<div class="gmail_quote">On Tue, Jun 5, 2012 at 8:29 AM, Whit Blauvelt <span dir="ltr">
<<a href="mailto:whit.gluster@transpect.com" target="_blank">whit.gluster@transpect.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>On Tue, Jun 05, 2012 at 08:13:37AM -0700, Anand Avati wrote:<br>
<br>
> Whit,<br>
> There has been no drop in goal. There are many parts to "supporting a VM<br>
> workload". The goals listed for 3.3 are definitely met - to make VMs work good<br>
> enough (fix self-heal locking issues, some FUSE upstream work for supporting<br>
> O_DIRECT etc.) However, for 3.4 we have bigger goals of supporting VM image use<br>
> case in a much better way - libglusterfsclient integration for QEMU etc. This<br>
> was what Amar was referring to. I hope I clarified your doubt, and apologies<br>
> for the confusion.<br>
<br>
</div>
Thanks for the clarification, Avanti. So if "VMs work good enough" now, the<br>
recommendation is that in general Gluster is ready for production work with<br>
VMs? Performance should be acceptable, if not always spectacular? Or should<br>
VM use be considered more in the beta area still, until 3.3.1 or whatever?<br>
<br>
I know there's no substitute for testing it in a particular environment.<br>
Just trying to get the general overview before committing to that.<br>
<br>
</blockquote>
<div><br>
</div>
<div>You are definitely expected and encouraged to test out VMs in a test environment. This is the first public release with the announced VM support and there is only so much what internal QA can cover. While there are no known issues, we are actively awaiting
feedback from all your beta testing. About performance - FUSE is something which will be a fundamental limit to how much performance you get expect for a VM image. Whether that is good enough for you or not is something only you can decide. We have heard many
users say they are very satisfied. Some might not be. The libglusterfsclient based QEMU integration is for this very purpose of avoiding context switches you get with a FUSE filesystem. That would however be an add-on, and FUSE mount based VM image will still
work.</div>
<div><br>
</div>
<div>Avati</div>
<div><br>
</div>
</div>
</div></div></div>
</div>
</div>
</div>
</blockquote></div><br></div>