前一段时间GlusterFS分布式存储系统进行迁移后，经常出现掉线、时断时续的现象，折腾了很长时间无法正常使用。观察发现其中一个节点总是不断地重启，进一步发现四个节点的复制型存储只剩下一个节点还活着，另外两个节点虽然还在运行，但相应目录都是空的，而且gluster volume status显示没有联机。下面将修复GlusterFS分布式存储系统的过程记录下来。
1、查看状态
得到GlusterFS的 volume 状态和信息：
#获得状态，是运行时的结果。
sudo gluster volume status gvzr00
#获得信息，是预先定义的结果。
sudo gluster volume info gvzr00
定义的结果和运行时结果的差异就是问题所在。
获得联机节点（peer）的信息：
sudo gluster peer status 发现其中一个节点已经是disconnetced，重启了多次、更新系统软件失败后，决定将该节点暂时移除。
2、移除节点
使用下面命令移除节点：
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 force3、恢复节点
如果节点修复后可用（或者换个新的节点），可以重新添加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
基本存储服务恢复正常。
4、恢复JupyterHub服务
为了在Kubernetes中使用，进一步：
首先需要在Kubernetes创建pv和pvc。参考：
然后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的服务，恢复正常。
