Re: thin arbiter vs standard arbiter

W Kern <wkmail@xxxxxxxxx> · Wed, 1 Aug 2018 17:56:28 -0700



      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@xxxxxxxxx>
              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@xxxxxxxxxxx

                https://lists.gluster.org/mailman/listinfo/gluster-users

                
            -- 

            
                    Amar Tumballi (amarts)

                    
_______________________________________________
Gluster-users mailing list
Gluster-users@xxxxxxxxxxx
https://lists.gluster.org/mailman/listinfo/gluster-users