glusterfs：Server-quorum和Client Quorum

overview

这两个参数在容错场景中发挥着巨大的作用。用户借助这两个参数 既可以手动控制存在多少个活着的节点表示集群健康，也可以把这个控制权交给集群。

Server-quorum

由两个参数组成

• cluster.server-quorum-type: none | server
  如果设置为server表示启动了server-quornum
• cluster.server-quorum-ratio: 0-100
  这是个百分比，表示百分多少的节点存活时，集群才是健康的

Server-quorum是node级别的控制，也就是说是cluster级别的参数。强调一下，这是node级别的！！！所有volume共享这个参数。

这个参数有个漏洞：

比如三个节点集群（N1、N2、N3），构建了两副本的volume。cluster.server-quorum-type设置为server，cluster.server-quorum-ratio设置为60%：

• N1挂了,N2、N3活着。正常写入。
• N2挂了，N1活了，N3仍然活着。正常写入。
• N3挂了，N1仍然活着，N2活了。完了，副本不一致，脑裂了。

可以看出上面，每个时刻，存活的节点数的百分比都是大于60%的。但是还是发生脑裂了。
如果集群中存在二副本，又想防止脑裂的时候，server quorum是做不到的。

当server quorum不被满足的时候，glusterfs就会kill掉brick的进程，让所有的volume不可用。

Client Quorum

同样由两个参数组成：

• cluster.quorum-type: none|auto|fixed。
• cluster.quorum-count: 整数数字

cluster.quorum-type = none: 应该是不启动Client Quorum，这个官网没有给出说明
cluster.quorum-type=fixed，此时cluster.quorum-count应该设置一个数字，表示volume的存活brick必须大于或者等于这个数字，该volume才能被写入
cluster.quorum-type=auto,此时cluster.quorum-coun无效。 也就是半数原则，如果volume的存活brick必须大于等于 volume总brick数/2。还没完，如果volume的brick总数是偶数，并且volume存活的brick等于 volume总brick数/2，那么第一个brick必须或者。

Client Quorum的逻辑是由AFR执行的，AFR是在客户端，所以不会kill掉brick。

Announcements（注意事项）：

glusterfs-3.13 以前的版本，brick的数量不达标的时候，volume是只读的。以后的版本volume会是不可用，返回ENOTCONN 错误。

两副本场景

如果是fixed模式，那么quorum-count必须是2了，也就相当于没有高可用能力。
如果是auto模式，那么第一个brick必须活着，也就相当于没有高可用能力。