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). Avati On Tue, Jun 5, 2012 at 8:58 AM, Fernando Frediani (Qube) < fernando.frediani at qubenet.net> wrote: > 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. > But I've tried that type of volume and it didn't work at all to run > Virtual Machines. > > Fernando > > ------------------------------ > *From:* gluster-users-bounces at gluster.org [ > gluster-users-bounces at gluster.org] on behalf of Anand Avati [ > anand.avati at gmail.com] > *Sent:* 05 June 2012 16:41 > *To:* Whit Blauvelt > *Cc:* gluster-users at gluster.org > > *Subject:* Re: Striped replicated volumes in Gluster 3.3.0 > > > > On Tue, Jun 5, 2012 at 8:29 AM, Whit Blauvelt <whit.gluster at transpect.com>wrote: > >> On Tue, Jun 05, 2012 at 08:13:37AM -0700, Anand Avati wrote: >> >> > Whit, >> > There has been no drop in goal. There are many parts to "supporting a >> VM >> > workload". The goals listed for 3.3 are definitely met - to make VMs >> work good >> > enough (fix self-heal locking issues, some FUSE upstream work for >> supporting >> > O_DIRECT etc.) However, for 3.4 we have bigger goals of supporting VM >> image use >> > case in a much better way - libglusterfsclient integration for QEMU >> etc. This >> > was what Amar was referring to. I hope I clarified your doubt, and >> apologies >> > for the confusion. >> >> Thanks for the clarification, Avanti. So if "VMs work good enough" now, >> the >> recommendation is that in general Gluster is ready for production work >> with >> VMs? Performance should be acceptable, if not always spectacular? Or >> should >> VM use be considered more in the beta area still, until 3.3.1 or whatever? >> >> I know there's no substitute for testing it in a particular environment. >> Just trying to get the general overview before committing to that. >> >> > 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. > > Avati > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://gluster.org/pipermail/gluster-users/attachments/20120605/c782958c/attachment.htm>
