抢修GlusterFS分布式存储系统

前一段时间GlusterFS分布式存储系统进行迁移后，常常出现掉线、时断时续的现象，折腾了很长时间没法正常使用。观察发现其中一个节点老是不断地重启，进一步发现四个节点的复制型存储只剩下一个节点还活着，另外两个节点虽然还在运行，但相应目录都是空的，并且gluster volume status显示没有联机。下面将修复GlusterFS分布式存储系统的过程记录下来。

一、查看状态

获得GlusterFS的 volume 状态和信息：

#得到状态，是运行时的结果。
sudo gluster volume status gvzr00

#得到信息，是预先定义的结果。
sudo gluster volume info gvzr00

定义的结果和运行时结果的差别就是问题所在。

得到联机节点（peer）的信息：

sudo gluster peer status

发现其中一个节点已是disconnetced，重启了屡次、更新系统软件失败后，决定将该节点暂时移除。

二、移除节点

使用下面命令移除节点：

sudo gluster peer detach 

可是，执行失败。

• 提示有brick在此节点上链接，须要先移除全部volume上位于该节点的brick。

首先使用volume info查看相应的bricks，而后强制移除bricks：

#移除复制卷gvzr00上的brick，须要指定replica参数。
sudo gluster volume remove-brick gvzr00 replica 2 10.1.1.193:/zpool/gvzr00 force

#移除条带卷gvz00上的brick（注意：可能会引发数据丢失）。
sudo gluster volume remove-brick gvz00 10.1.1.193:/zpool/gvz00 force

而后强制移除peer（由于已离线，必须使用force参数）：

sudo gluster peer detach 10.1.1.193 force

三、恢复节点

若是节点修复后可用（或者换个新的节点），能够从新添加peer：

sudo gluster peer probe 10.1.1.193

获取peer的状态：

sudo gluster peer status

从新添加brick：

sudo gluster volume add-brick gvzr00 replica 2 10.1.1.193:/zpool/gvzr00

获取volume的状态：

sudo gluster volume info gvzr00

sudo gluster volume status gvzr00

输出以下：

sudo gluster volume status gvzr00
Status of volume: gvzr00
Gluster process                             TCP Port  RDMA Port  Online  Pid
------------------------------------------------------------------------------
Brick 10.1.1.205:/zpool/gvzr00              49153     0          Y       30347
Brick 10.1.1.193:/zpool/gvzr00              49152     0          Y       15144
Brick 10.1.1.150:/zpool/gvzr00              49152     0          Y       11586
NFS Server on localhost                     2049      0          Y       16425
Self-heal Daemon on localhost               N/A       N/A        Y       16499
NFS Server on 10.1.1.150                    N/A       N/A        N       N/A  
Self-heal Daemon on 10.1.1.150              N/A       N/A        Y       11661
NFS Server on 10.1.1.205                    N/A       N/A        N       N/A  
Self-heal Daemon on 10.1.1.205              N/A       N/A        Y       5848 
NFS Server on 10.1.1.203                    2049      0          Y       27732
Self-heal Daemon on 10.1.1.203              N/A       N/A        Y       27770
NFS Server on 10.1.1.167                    2049      0          Y       24585
Self-heal Daemon on 10.1.1.167              N/A       N/A        Y       24619
NFS Server on 10.1.1.202                    2049      0          Y       28924
Self-heal Daemon on 10.1.1.202              N/A       N/A        Y       28941
NFS Server on 10.1.1.234                    2049      0          Y       26891
Self-heal Daemon on 10.1.1.234              N/A       N/A        Y       26917
NFS Server on 10.1.1.193                    2049      0          Y       15689
Self-heal Daemon on 10.1.1.193              N/A       N/A        Y       15724
 
Task Status of Volume gvzr00
------------------------------------------------------------------------------
There are no active volume tasks

基本存储服务恢复正常。

四、恢复JupyterHub服务

为了在Kubernetes中使用，进一步：

• 使用kubeadm部署高可用Kubernetes 1.17.0
• Kubernetes 1.17.0管理界面Dashboard 2
• 快速设置JupyterHub for K8s

首先须要在Kubernetes建立pv和pvc。参考：

• Kubernetes中挂载GlusterFS的volume
• JupyterHub on Kubernetes-容器存储

而后JupyterHub运行时出现错误，Notebook Server没法启动，进pod日志发现提示信息"NoneType"，采用下面的方法修复：

kubectl patch deploy -n jupyter hub --type json \
--patch '[{"op": "replace", "path": "/spec/template/spec/containers/0/command", "value": ["bash", "-c", "\nmkdir -p ~/hotfix\ncp \
-r /usr/local/lib/python3.6/dist-packages/kubespawner ~/hotfix\nls -R ~/hotfix\npatch ~/hotfix/kubespawner/spawner.py \
<< EOT\n72c72\n<             key=lambda x: x.last_timestamp,\n---\n>             key=lambda x: x.last_timestamp and x.last_timestamp.timestamp() or 0.,\nEOT\n\nPYTHONPATH=$HOME/hotfix \
jupyterhub --config /srv/jupyterhub_config.py --upgrade-db\n"]}]'

再去访问JupyterHub的服务，恢复正常。

五、更多参考

• http://www.javashuo.com/article/p-zhratsiw-gc.html
• GlusterFS强制删除节点
• ZFS存储池zpool丢失恢复及Gluster卷自愈
• JupyterHub on Kubernetes--部署指南