[Gluster-users] Striped replicated volumes in Gluster 3.3.0

[Anand Avati]

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: [Gluster-users] 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://supercolony.gluster.org/pipermail/gluster-users/attachments/20120605/c782958c/attachment.html>