抢修GlusterFS分布式存储系统

原创
01/06 11:09
阅读数 289

前一段时间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 force

3、恢复节点

如果节点修复后可用(或者换个新的节点),可以重新添加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的服务,恢复正常。

5、更多参考

展开阅读全文
打赏
0
0 收藏
分享
加载中
更多评论
打赏
0 评论
0 收藏
0
分享
OSCHINA
登录后可查看更多优质内容
返回顶部
顶部