thin arbiter vs standard arbiter

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Gluster Development]     [Linux Filesytems Development]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux