Server side or client side AFR

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi, I think that to use the server side AFR is more correct put in front
of a server gluster an LVS Machine (Linux Virtual Server) to balance the
client load, or use, on all AFR server, a protocol like carp (UCARP)
that expose a single IP address for gluster all servers, so the client
will always be connected to the server online.

Best Regards
Roberto Freguia


Il 23/04/2011 07:34, Liam Slusser ha scritto:
> Problem with server side AFR is you loose your redundancy in the event
> that one of your server goes down because the client is only
> connecting to one of the two servers.  So if your client is connected
> to the server that went down, you're SOL.
>
> liam
>
> On Fri, Apr 22, 2011 at 4:05 PM, Nobodys Home <n1shome at yahoo.com> wrote:
>> Hello all,
>> I prefer server side AFR for my topology and I think it makes overall sense
>> for most configurations.  However, I don't think the
>> 3.1 documentation regarding the creation of a replicated distributed volume
>> is server side after a bit of testing.  It seems like I'm in a bit of a
>> pickle:
>>
>> 1.  Can I "only" expand volumes on the fly if I use the gluster cli to
>> initially define my volumes?
>>
>> 2. Most of the examples regarding server side AFR "do not show" how to add
>> bricks to a predifined server.vol configuration on the fly.  If there is a
>> way to do this can I get help on this?
>>
>> Best Regards,
>> Nobodys Home
>> _______________________________________________
>> Gluster-users mailing list
>> Gluster-users at gluster.org
>> http://gluster.org/cgi-bin/mailman/listinfo/gluster-users
>>
>>
> _______________________________________________
> Gluster-users mailing list
> Gluster-users at gluster.org
> http://gluster.org/cgi-bin/mailman/listinfo/gluster-users
>
>


[Index of Archives]     [Gluster Development]     [Linux Filesytems Development]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux