[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