搶修GlusterFS分佈式存儲系統

時間 2020-01-31

原文原文鏈接

前一段時間GlusterFS分佈式存儲系統進行遷移後，常常出現掉線、時斷時續的現象，折騰了很長時間沒法正常使用。觀察發現其中一個節點老是不斷地重啓，進一步發現四個節點的複製型存儲只剩下一個節點還活着，另外兩個節點雖然還在運行，但相應目錄都是空的，並且gluster volume status顯示沒有聯機。下面將修復GlusterFS分佈式存儲系統的過程記錄下來。python

一、查看狀態

獲得GlusterFS的 volume 狀態和信息：json

#得到狀態，是運行時的結果。
sudo gluster volume status gvzr00

#得到信息，是預先定義的結果。
sudo gluster volume info gvzr00

定義的結果和運行時結果的差別就是問題所在。bash

得到聯機節點（peer）的信息：分佈式

sudo gluster peer status

發現其中一個節點已是disconnetced，重啓了屢次、更新系統軟件失敗後，決定將該節點暫時移除。spa

二、移除節點

使用下面命令移除節點：.net

sudo gluster peer detach

可是，執行失敗。日誌

提示有brick在此節點上鍊接，須要先移除全部volume上位於該節點的brick。

首先使用volume info查看相應的bricks，而後強制移除bricks：code

#移除複製卷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參數）：blog

sudo gluster peer detach 10.1.1.193 force

三、恢復節點

若是節點修復後可用（或者換個新的節點），能夠從新添加peer：rem

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中使用，進一步：

首先須要在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的服務，恢復正常。