Re: thin arbiter vs standard arbiter

Ravishankar N <ravishankar@xxxxxxxxxx> · Thu, 2 Aug 2018 08:22:31 +0530



    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@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
    
    
_______________________________________________
Gluster-users mailing list
Gluster-users@xxxxxxxxxxx
https://lists.gluster.org/mailman/listinfo/gluster-users