[Gluster-users] Fwd: simple AFR setup, one server crashes, entire cluster becomes unusable ?

Stas Oskin stas.oskin at gmail.com
Tue Dec 9 10:47:21 UTC 2008


Hi.

What about using Wackamole and server side AFR?

Wackamole (http://www.backhand.org/wackamole/) allows to set a P2P kind of
fault tolerance, where remaining server would take the IP of the crashed
one. Then the client could continue working with the remaining server.

What do you think about this?

Also, can someone provide more info about server side - I remember I only
seen some config examples, but never any info how it actually works.

Regards.


2008/12/8 Keith Freedman <freedman at freeformit.com>

At 06:17 AM 12/8/2008, Daniel Maher wrote:
>
>> Stas Oskin wrote:
>>
>> > Based on my limited knowledge of GlusterFS, the most reliable and
>> > recommended way (in wiki) is client-side AFR, where the clients aware of
>> > the servers status, and replicate the files accordingly.
>>
>> I've reviewed the AFR-related sections of the documentation on the wiki...
>>
>> http://www.gluster.org/docs/index.php/GlusterFS_Translators_v1.3#Automatic_File_Replication_Translator_.28AFR.29
>> http://www.gluster.org/docs/index.php/Understanding_AFR_Translator
>>
>> Nowhere in those sections is it stated, either directly or implicitly,
>> that client-side AFR is more reliable than server-side AFR.  I'm not
>> saying that the statement is incorrect, but rather that the
>> documentation noted above doesn't seem to suggest that this is the case.
>>
>
> the issue isn't reliability, it's availability.
>
> if a client only talks to one server and that server goes down then the
> client has nothing to 'fail over' to.  however, if the client talks to both
> servers then if one goes down it'll keep talking to the other one.
>
> There are costs and benefits to each approach.
> server side AFR is handy to insure that the filesystems are in sync, so no
> matter which server a client connects to, it'll have the correct data.
> with client side AFR you lend yourself to more configuration problems.
> For example.
> if client 1 only knows about server 1, it will update files happily and no
> AFR takes place
> if client 2 is doing client side AFR between server 1 and server 2, then it
> keeps both servers in sync, and occasionally when it accesses a file that
> client 1 updated on server 1, then client 2 takes the responsibility of
> replicating that file to server 2.
>
> I really think a better approach would be to always have server side AFR,
> and then when a gluster client connects to a server, it's given the AFR
> config, so that it has a 'failover pool' that it can use in case it's
> connection to it's primary server gets interrupted.
>
> Hopefully this will make it into a future version of gluster, because I
> think it will really simplify administration and increase availability.
> There could be an option to make the client responsible for the
> replication, but the control and config should be centralized at the server,
> to eliminate cases where some clients are replicating to certain servers and
> not others.
>
> my .02
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://supercolony.gluster.org/pipermail/gluster-users/attachments/20081209/60e4b856/attachment.html>


More information about the Gluster-users mailing list