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 On Wed, Aug 1, 2018 at 11:09 PM, wkmail <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 > https://lists.gluster.org/mailman/listinfo/gluster-users > > >-- Amar Tumballi (amarts) -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.gluster.org/pipermail/gluster-users/attachments/20180801/a403daf7/attachment.html>
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. -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)-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.gluster.org/pipermail/gluster-users/attachments/20180801/70700973/attachment.html>
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. > > -AmarHello! 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 > <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/dbcbbfb9/attachment.html>