一、问题重现

我们已有9台部署有glusterfs3.7.2的服务器(qserver0, qserver1, … qserver8)，现在想新加入3台服务器(qserver9, qserver0, qserver11)。11台机器的ip分别是：192.168.0.130, 192.168.0.131, …, 192.168.0.141。我们一直都通过以下方式来安装glusterfs:

step1：将以下内容新建到文件/etc/yum.repos.d/glusterfs-epel.repo中

Place this file in your /etc/yum.repos.d/ directory
[glusterfs-epel]
name=GlusterFS is a clustered file-system capable of scaling to several petabytes.
baseurl=http://download.gluster.org/pub/gluster/glusterfs/3.7/LATEST/EPEL.repo/epel- $releasever/$ basearch/
enabled=1
skip_if_unavailable=1
gpgcheck=1
gpgkey=http://download.gluster.org/pub/gluster/glusterfs/3.7/LATEST/rsa.pub
[glusterfs-noarch-epel]
name=GlusterFS is a clustered file-system capable of scaling to several petabytes.
baseurl=http://download.gluster.org/pub/gluster/glusterfs/3.7/LATEST/EPEL.repo/epel-$releasever/noarch
enabled=1
skip_if_unavailable=1
gpgcheck=1
gpgkey=http://download.gluster.org/pub/gluster/glusterfs/3.7/LATEST/rsa.pub
[glusterfs-source-epel]
name=GlusterFS is a clustered file-system capable of scaling to several petabytes. - Source
baseurl=http://download.gluster.org/pub/gluster/glusterfs/3.7/LATEST/EPEL.repo/epel-$releasever/SRPMS
enabled=0
skip_if_unavailable=1
gpgcheck=1
gpgkey=http://download.gluster.org/pub/gluster/glusterfs/3.7/LATEST/rsa.pub
step2:用以下命令安装glusterfs

sudo yum install glusterfs-server

但此时的LATEST版本已经是glusterfs3.7.18了。
为保持一致性，我们直接将旧的9台机器update到gluster3.7.18。然后再从qserver8中添加qserver11节点：

sudo gluster peer probe 192.168.0.141

此时查看peer状态

sudo gluster peer status

qserver8机器上如下：

qserver11机器上如下：
[当时没有截图，汗。。。]也是State: Peer Rejected (Connected)的状态

二、问题探索

发现1：

通过对比qserver0~qserver8和qserver11中的/var/lib/glusterfs中的内容，我们发现qserver0~qserer8中的/var/lib/glusterfs/vols/{vol_name}/cksum的值都相同，但qserver11中的cksum值和他们不同。
怀疑1：cksum的不同是问题的根源，考虑手动修改cksum

发现2：

我在qserver11上手动将cksum修改为和qserver8一致，再重新启动glusterd：

sudo systemctl restart glusterd

发现重启服务失败，/var/log/glusterfs/etc-glusterfs-glusterd.vol.log中记录错误如下：
log
初步发现此时只能将/var/lib/glusterfs整个文件夹删除再重新启动

结论1：一旦通过qserver8将qserver11 porbe之后，qserver11上的glusterd就无法重启了。所以不能手动修改qserver11的cksum，考虑曲线救国，修改qserver0~qserver8上的cksum

发现3：

先对qserver8进行尝试

修改qserver8的cksum和qserver11上的一致，再重启qserver8上的glusterd，发现qserver8上的cksum又恢复了原来的值。由此可知，glusterd在重启时会计算并重写cksum。
进一步阅读glusterfs-3.7.18源码，发现cksum是对/var/lib/glusterfs/vols/{vol_name}/info的内容进行计算。
对比qserver8和qserver11的/var/lib/glusterfs/vols/{vol_name}/info内容，发现qserver11中缺少一行quota-version=0

怀疑2：glusterfs-3.7.2的info内容会存在quota-version=0,但glusterfs-3.7.18的info内容并不会存在quota-version=0。而glusterfs在从3.7.2升级到3.7.18时，并不会更新已存在的info的内容，从而导致了这种不一致。

发现4：

将qserver8中的info中的quota-version=0全部删去，再重新probe qserver11。发现
qserver8和qserver11正常连接：Status: Peer in Cluster(Connected)
qserver8和qserver0~qserver7连接异常： State: Peer Rejected (Connected)
结论2：由此我们可以印证，确实是因为info不一致导致cksum不一致，再导致rejected(connected)

发现5：

就在我考虑将qserver0~qserver7也都像qserver8那样修改时，发现一个问题：

sudo gluster volume status {vol_name}

qserver8上的volume信息出错了，也就是说qserver8其实是脱离了qserver0~qserver7了。如果将qserver0~qserver7也都修改了，虽然qserver0~qserver8和qserver11互相peer in cluster了，但他们原来的volume都异常了
结论3：我们只能再次回归到qserver11上，看看为什么怀疑1中发现的qserver11就无法重启了。只要解决了qserver11重启，问题也就解决了

发现6：

通过修改glusterfs的日志打印级别至DEBUG

sudo vim /usr/lib/systemd/system/glusterd.service

对照/var/log/glusterfs/etc-glusterfs-glusterd.vol.log和glustetfs-3.7.18的源代码，log中提示是因为无法找到qserver2。找到glusterfs-3.7.18中对应的源码，知道glusterd在启动的时候，会将/var/lib/glusterd/vols/{vol_name}/中的brick信息的hostname，用peers来解析。
因为peers中只有probe失败之后的qserver8信息，自然无法解析qserver2
结论4：只要补全qserver11中/var/lib/glusterd/peers中的信息即可

三、问题解决

step1：

qserver8:

sudo gluster peer probe 192.168.0.141

step2:

qserver11:
根据qserver8上的内容将qserver8上的 /var/lib/glusterd/peers信息补全

step3:

qserver11:
将/var/lib/glusterd/vols/{vol_name}/info中的quota-version=0去掉

step4:

qserver11:

sudo systemctl restart glusterd

Gluster升级遇到的问题