[Gluster-users] thin arbiter vs standard arbiter

Dmitry Melekhov dm at belkam.com
Fri Aug 3 01:27:32 UTC 2018



02.08.2018 18:40, Ashish Pandey пишет:
>
>
> I think it should be rephrased a little bit -
>
> "When one brick is up: Fail FOP with EIO."
> should be
> "When only one brick is up out of 3 bricks: Fail FOP with EIO."
>
> So we have 2 data bricks and one thin arbiter brick. Out of these 3 
> bricks if only one brick is UP then we will fail IO.
>
> ---
> Ashish
>

Hello!

Thank you!

This is what we need :-)

>
> ------------------------------------------------------------------------
> *From: *"Dmitry Melekhov" <dm at belkam.com>
> *To: *gluster-users at gluster.org, atumball at redhat.com
> *Sent: *Thursday, August 2, 2018 4:59:41 PM
> *Subject: *Re: [Gluster-users] thin arbiter vs standard arbiter
>
> 01.08.2018 22:04, Amar Tumballi пишет:
>
>     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
>
>
> Hello!
>
> I have question:
>
> Manual says:
>
>
> "When one brick is up: Fail FOP with EIO."
>
> So, if we have 2 nodes with thin arbiter and only one node is up, i.e. 
> second node is down for some reason, then I/O will be stopped.
> Any reasons to have two nodes then?
>
> Could you tell me is manual right here or it is misprint?
>
> Thank you!
>
>
>
>
>     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
>
>
>
>
>
>     -- 
>     Amar Tumballi (amarts)
>
>
>     _______________________________________________
>     Gluster-users mailing list
>     Gluster-users at gluster.org
>     https://lists.gluster.org/mailman/listinfo/gluster-users
>
>
>
> _______________________________________________
> 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/20180803/d9e52011/attachment.html>


More information about the Gluster-users mailing list