[Gluster-users] thin arbiter vs standard arbiter

Ravishankar N ravishankar at redhat.com
Thu Aug 2 02:52:31 UTC 2018



On 08/02/2018 06:26 AM, W Kern wrote:
>
>
> On 8/1/18 11:04 AM, Amar Tumballi wrote:
>> This recently added document talks about some of the technicalities 
>> of the feature:
>>
>> https://docs.gluster.org/en/latest/Administrator%20Guide/Thin-Arbiter-Volumes/
>>
>> Please go through and see if it answers your questions.
>>
>> -Amar
>>
>
>
> Well yes that does answer some. By skipping a lot more of the arbiter 
> traffic, there may be some noticeable performance benefits especially 
> in an older 1G network.
> At least until you have to deal with a failure situation.
>
> Though the "would you use it on a VM, either now or when the code is 
> more seasoned?" question is still there.
>
> I'm willing to try it out on some non-critical VMs (cloud-native 
> stuff, where I always spawn from a golden image), but if it is not 
> ready for production, then I don't want to bother with it at the moment.
Hi WK,

There are a few patches [1]  that are still undergoing review .  It 
would be good to wait for some more time until trying it out. If you are 
interested in testing, I'll be happy to inform you once they get merged.

[1] https://review.gluster.org/#/c/20095/, 
https://review.gluster.org/#/c/20103/, https://review.gluster.org/#/c/20577/

Regards,
Ravi


>
> -wk
>
>>
>> On Wed, Aug 1, 2018 at 11:09 PM, wkmail <wkmail at bneit.com 
>> <mailto:wkmail at bneit.com>> wrote:
>>
>>     I see mentions of thin arbiter in the 4.x notes and I am intrigued.
>>
>>     As I understand it, the thin arbiter volume is
>>
>>     a) receives its data on an async basis (thus it can be on a
>>     slower link). Thus gluster isn't waiting around to verify if it
>>     actually got the data.
>>
>>     b) is only consulted in situations where Gluster needs that third
>>     vote, otherwise it is not consulted.
>>
>>     c) Performance should therefore be better because Gluster is only
>>     seriously talking to 2 nodes instead of 3 nodes (as in normal
>>     arbiter or rep 3)
>>
>>     Am I correct?
>>
>>     If so, is thin arbiter ready for production or at least use on
>>     non-critical workloads?
>>
>>     How safe is it for VMs images (and/or VMs with sharding)?
>>
>>     How much faster is thin arbiter setup over a normal arbiter given
>>     that the normal data only really sees the metadata?
>>
>>     In a degraded situation (i.e. loss of one real node), would
>>     having a thin arbiter on a slow link be problematic until
>>     everything is healed and returned to normal?
>>
>>     Sincerely,
>>
>>     -wk
>>
>>     _______________________________________________
>>     Gluster-users mailing list
>>     Gluster-users at gluster.org <mailto:Gluster-users at gluster.org>
>>     https://lists.gluster.org/mailman/listinfo/gluster-users
>>     <https://lists.gluster.org/mailman/listinfo/gluster-users>
>>
>>
>>
>>
>>
>> -- 
>> Amar Tumballi (amarts)
>
>
>
>
> _______________________________________________
> Gluster-users mailing list
> Gluster-users at gluster.org
> https://lists.gluster.org/mailman/listinfo/gluster-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gluster.org/pipermail/gluster-users/attachments/20180802/f808351c/attachment.html>


More information about the Gluster-users mailing list