1. 常見 MON 故障處理
Monitor 維護(hù)著 Ceph 集群的信息，如果 Monitor 無(wú)法正常提供服務(wù)，那整個(gè) Ceph 集群就不可訪問(wèn)。一般來(lái)說(shuō)，在實(shí)際運(yùn)行中，Ceph Monitor的個(gè)數(shù)是 2n + 1 ( n >= 0) 個(gè)，在線上至少3個(gè)，只要正常的節(jié)點(diǎn)數(shù) >= n+1，Ceph 的 Paxos 算法就能保證系統(tǒng)的正常運(yùn)行。所以，當(dāng) Monitor 出現(xiàn)故障的時(shí)候，不要驚慌，冷靜下來(lái)，一步一步地處理。
1.1 開始排障
在遭遇 Monitor 故障時(shí)，首先回答下列幾個(gè)問(wèn)題：
Mon 進(jìn)程在運(yùn)行嗎？
我們首先要確保 Mon 進(jìn)程是在正常運(yùn)行的。很多人往往忽略了這一點(diǎn)。
是否可以連接 Mon Server？
有時(shí)候我們開啟了防火墻，導(dǎo)致無(wú)法與 Monitor 的 IP 或端口進(jìn)行通信。嘗試使用 ssh 連接服務(wù)器，如果成功，再嘗試用其他工具（如 telnet ， nc 等）連接 monitor 的端口。
ceph -s 命令是否能運(yùn)行并收到集群回復(fù)？
如果答案是肯定的，那么你的集群已啟動(dòng)并運(yùn)行著。你可以認(rèn)為如果已經(jīng)形成法定人數(shù)，monitors 就只會(huì)響應(yīng) status 請(qǐng)求。
如果 ceph -s 阻塞了，并沒(méi)有收到集群的響應(yīng)且輸出了很多 fault 信息，很可能此時(shí)你的 monitors 全部都 down 掉了或只有部分在運(yùn)行（但數(shù)量不足以形成法定人數(shù)）。
ceph -s 沒(méi)完成是什么情況？
如果你到目前為止沒(méi)有完成前述的幾步，請(qǐng)返回去完成。然后你需要 ssh 登錄到服務(wù)器上并使用 monitor 的管理套接字。
1.2 使用 Mon 的管理套接字
通過(guò)管理套接字，你可以用 Unix 套接字文件直接與指定守護(hù)進(jìn)程交互。這個(gè)文件位于你 Mon 節(jié)點(diǎn)的 run 目錄下，默認(rèn)配置它位于 /var/run/ceph/ceph-mon.ID.asok，但要是改過(guò)配置就不一定在那里了。如果你在那里沒(méi)找到它，請(qǐng)檢查 ceph.conf 里是否配置了其它路徑，或者用下面的命令獲?。?/p>
ceph-conf --name mon.ID --show-config-value admin_socket
請(qǐng)牢記，只有在 Mon 運(yùn)行時(shí)管理套接字才可用。Mon 正常關(guān)閉時(shí)，管理套接字會(huì)被刪除；如果 Mon 不運(yùn)行了、但管理套接字還存在，就說(shuō)明 Mon 不是正常關(guān)閉的。不管怎樣，Mon 沒(méi)在運(yùn)行，你就不能使用管理套接字， ceph 命令會(huì)返回類似 Error 111: Connection Refused 的錯(cuò)誤消息。
訪問(wèn)管理套接字很簡(jiǎn)單，就是讓 ceph 工具使用 asok 文件。對(duì)于 Dumpling 之前的版本，命令是這樣的：
ceph --admin-daemon /var/run/ceph/ceph-mon.<id>.asok <command>
對(duì)于 Dumpling 及后續(xù)版本，你可以用另一個(gè)（推薦的）命令：
ceph daemon mon.<id> <command>
ceph 工具的 help 命令會(huì)顯示管理套接字支持的其它命令。請(qǐng)仔細(xì)了解一下 config get 、 config show 、 mon_status 和 quorum_status 命令，在排除 Mon 故障時(shí)它們會(huì)很有用。
1.3 理解 MON_STATUS
當(dāng)集群形成法定人數(shù)后，或在沒(méi)有形成法定人數(shù)時(shí)通過(guò)管理套接字， 用 ceph 工具可以獲得 mon_status 信息。命令會(huì)輸出關(guān)于 monitor 的大多數(shù)信息，包括部分 quorum_status 命令的輸出內(nèi)容。
下面是 mon_status 的輸出樣例：
{
"name": "c",
"rank": 2,
"state": "peon",
"election_epoch": 38,
"quorum": [
1,
2
],
"outside_quorum": [],
"extra_probe_peers": [],
"sync_provider": [],
"monmap": {
"epoch": 3,
"fsid": "5c4e9d53-e2e1-478a-8061-f543f8be4cf8",
"modified": "2013-10-30 04:12:01.945629",
"created": "2013-10-29 14:14:41.914786",
"mons": [
{
"rank": 0,
"name": "a",
"addr": "127.0.0.1:6789\/0"
},
{
"rank": 1,
"name": "b",
"addr": "127.0.0.1:6790\/0"
},
{
"rank": 2,
"name": "c",
"addr": "127.0.0.1:6795\/0"
}
]
}
}
從上面的信息可以看出， monmap 中包含 3 個(gè)monitor （ a，b 和 c），只有 2 個(gè) monitor 形成了法定人數(shù)， c 是法定人數(shù)中的 peon 角色（非 leader 角色）。
還可以看出， a 并不在法定人數(shù)之中。請(qǐng)看 quorum 集合。在集合中只有 1 和 2 。這不是 monitor 的名字，而是它們加入當(dāng)前 monmap 后確定的等級(jí)。丟失了等級(jí) 0 的 monitor，根據(jù) monmap ，這個(gè) monitor 就是 mon.a 。
那么，monitor 的等級(jí)是如何確定的？
當(dāng)加入或刪除 monitor 時(shí)，會(huì)（重新）計(jì)算等級(jí)。計(jì)算時(shí)遵循一個(gè)簡(jiǎn)單的規(guī)則： IP:PORT 的組合值越大， 等級(jí)越低（等級(jí)數(shù)字越大，級(jí)別越低）。因此在上例中， 127.0.0.1:6789 比其他 IP:PORT 的組合值都小，所以 mon.a 的等級(jí)是 0 。
1.4 最常見的 Mon 問(wèn)題
達(dá)到了法定人數(shù)但是有至少一個(gè) Monitor 處于 Down 狀態(tài)
當(dāng)此種情況發(fā)生時(shí)，根據(jù)你運(yùn)行的 Ceph 版本，可能看到類似下面的輸出：
root@OPS-ceph1:~# ceph health detail
HEALTH_WARN 1 mons down, quorum 1,2 b,c
mon.a (rank 0) addr 127.0.0.1:6789/0 is down (out of quorum)
如何解決？
首先，確認(rèn) mon.a 進(jìn)程是否運(yùn)行。
其次，確定可以從其他 monitor 節(jié)點(diǎn)連到 mon.a 所在節(jié)點(diǎn)。同時(shí)檢查下端口。如果開了防火墻，還需要檢查下所有 monitor 節(jié)點(diǎn)的 iptables ，以確定沒(méi)有丟棄/拒絕連接。
如果前兩步?jīng)]有解決問(wèn)題，請(qǐng)繼續(xù)往下走。
首先，通過(guò)管理套接字檢查問(wèn)題 monitor 的 mon_status 。考慮到該 monitor 并不在法定人數(shù)中，它的狀態(tài)應(yīng)該是 probing ， electing 或 synchronizing 中的一種。如果它恰巧是 leader 或 peon 角色，它會(huì)認(rèn)為自己在法定人數(shù)中，但集群中其他 monitor 并不這樣認(rèn)為。或者在我們處理故障的過(guò)程中它加入了法定人數(shù)，所以再次使用 ceph -s 確認(rèn)下集群狀態(tài)。如果該 monitor 還沒(méi)加入法定人數(shù)，繼續(xù)。
probing 狀態(tài)是什么情況？
這意味著該 monitor 還在搜尋其他 monitors 。每次你啟動(dòng)一個(gè) monitor，它會(huì)去搜尋 monmap 中的其他 monitors ，所以會(huì)有一段時(shí)間處于該狀態(tài)。此段時(shí)間的長(zhǎng)短不一。例如，單節(jié)點(diǎn) monitor 環(huán)境， monitor 幾乎會(huì)立即通過(guò)該階段。在多 monitor 環(huán)境中，monitors 在找到足夠的節(jié)點(diǎn)形成法定人數(shù)之前，都會(huì)處于該狀態(tài)，這意味著如果 3 個(gè) monitor 中的 2 個(gè) down 了，剩下的 1 個(gè)會(huì)一直處于該狀態(tài)，直到你再啟動(dòng)一個(gè) monitor 。
如果你的環(huán)境已經(jīng)形成法定人數(shù)，只要 monitor 之間可以互通，新 monitor 應(yīng)該可以很快搜尋到其他 monitors 。如果卡在 probing 狀態(tài)，并且排除了連接的問(wèn)題，那很有可能是該 monitor 在嘗試連接一個(gè)錯(cuò)誤的 monitor 地址?？梢愿鶕?jù) mon_status 命令輸出中的 monmap 內(nèi)容，檢查其他 monitor 的地址是否和實(shí)際相符。如果不相符，請(qǐng)?zhí)?strong>恢復(fù) Monitor 損壞的 monmap。如果相符，這些 monitor 節(jié)點(diǎn)間可能存在嚴(yán)重的時(shí)鐘偏移問(wèn)題，請(qǐng)首先參考時(shí)鐘偏移，如果沒(méi)有解決問(wèn)題，可以搜集相關(guān)的日志并向社區(qū)求助。
electing 狀態(tài)是什么情況？
這意味著該 monitor 處于選舉過(guò)程中。選舉應(yīng)該很快就可以完成，但偶爾也會(huì)卡住，這往往是 monitors 節(jié)點(diǎn)時(shí)鐘偏移的一個(gè)標(biāo)志，跳轉(zhuǎn)至時(shí)鐘偏移獲取更多信息。如果時(shí)鐘是正確同步的，可以搜集相關(guān)日志并向社區(qū)求助。此種情況除非是一些（非常）古老的 bug ，往往都是由時(shí)鐘不同步引起的。
synchronizing 狀態(tài)是什么情況？
這意味著該 monitor 正在和集群中的其他 monitor 進(jìn)行同步以便加入法定人數(shù)。Monitor 的數(shù)據(jù)庫(kù)越小，同步過(guò)程的耗時(shí)就越短。
然而，如果你注意到 monitor 的狀態(tài)從 synchronizing 變?yōu)?electing 后又變回 synchronizing ，那么就有問(wèn)題了：集群的狀態(tài)更新的太快（即產(chǎn)生新的 maps ），同步過(guò)程已經(jīng)無(wú)法追趕上了。這種情況在早期版本中可以見到，但現(xiàn)在經(jīng)過(guò)代碼重構(gòu)和增強(qiáng)，在較新版本中已經(jīng)基本見不到了。
leader 或 peon 狀態(tài)是什么情況？
這種情況不應(yīng)該發(fā)生，但還是有一定概率會(huì)發(fā)生，這常和時(shí)鐘偏移有關(guān)。如果你并沒(méi)有時(shí)鐘偏移的問(wèn)題，請(qǐng)搜集相關(guān)的日志并向社區(qū)求助。
恢復(fù) Monitor 損壞的 monmap
monmap 通?？雌饋?lái)是下面的樣子，這取決于 monitor 的個(gè)數(shù)：
epoch 3
fsid 5c4e9d53-e2e1-478a-8061-f543f8be4cf8
last_changed 2013-10-30 04:12:01.945629
created 2013-10-29 14:14:41.914786
0: 127.0.0.1:6789/0 mon.a
1: 127.0.0.1:6790/0 mon.b
2: 127.0.0.1:6795/0 mon.c
不過(guò)也不一定就是這樣的內(nèi)容。比如，在早期版本的 Ceph 中，有一個(gè)嚴(yán)重 bug 會(huì)導(dǎo)致 monmap 的內(nèi)容全為 0 。這意味著即使用 monmaptool 也不能讀取它，因?yàn)槿?0 的內(nèi)容沒(méi)有任何意義。另外一些情況，某個(gè) monitor 所持有的 monmap 已嚴(yán)重過(guò)期，以至于無(wú)法搜尋到集群中的其他 monitors 。在這些狀況下，你有兩種可行的解決方法：
銷毀 monitor 然后新建
只有在你確定不會(huì)丟失保存在該 monitor 上的數(shù)據(jù)時(shí)，你才能夠采用這個(gè)方法。也就是說(shuō)，集群中還有其他運(yùn)行正常的 monitors，以便新 monitor 可以和其他 monitors 達(dá)到同步。請(qǐng)謹(jǐn)記，銷毀一個(gè) monitor 時(shí)，如果沒(méi)有其上數(shù)據(jù)的備份，可能會(huì)丟失數(shù)據(jù)。
給 monitor 手動(dòng)注入 monmap
通常是最安全的做法。你應(yīng)該從剩余的 monitor 中抓取 monmap，然后手動(dòng)注入 monmap 有問(wèn)題的 monitor 節(jié)點(diǎn)。
下面是基本步驟：
1、是否已形成法定人數(shù)？如果是，從法定人數(shù)中抓取 monmap ：
ceph mon getmap -o /tmp/monmap
2、沒(méi)有形成法定人數(shù)？直接從其他 monitor 節(jié)點(diǎn)上抓取 monmap （這里假定你抓取 monmap 的 monitor 的 id 是 ID-FOO 并且守護(hù)進(jìn)程已經(jīng)停止運(yùn)行）：
ceph-mon -i ID-FOO --extract-monmap /tmp/monmap
3、停止你想要往其中注入 monmap 的 monitor。
4、注入 monmap 。
ceph-mon -i ID --inject-monmap /tmp/monmap
5、啟動(dòng) monitor 。
請(qǐng)記住，能夠注入 monmap 是一個(gè)很強(qiáng)大的特性，如果濫用可能會(huì)對(duì) monitor 造成大破壞，因?yàn)檫@樣做會(huì)覆蓋 monitor 持有的最新 monmap 。
時(shí)鐘偏移
Monitor 節(jié)點(diǎn)間明顯的時(shí)鐘偏移會(huì)對(duì) monitor 造成嚴(yán)重的影響。這通常會(huì)導(dǎo)致一些奇怪的問(wèn)題。為了避免這些問(wèn)題，在 monitor 節(jié)點(diǎn)上應(yīng)該運(yùn)行時(shí)間同步工具。
允許的最大時(shí)鐘偏移量是多少？
默認(rèn)最大允許的時(shí)鐘偏移量是 0.05 秒。
如何增加最大時(shí)鐘偏移量？
通過(guò) mon-clock-drift-allowed 選項(xiàng)來(lái)配置。盡管你 可以 修改但不代表你 應(yīng)該 修改。時(shí)鐘偏移機(jī)制之所以是合理的，是因?yàn)橛袝r(shí)鐘偏移的 monitor 可能會(huì)表現(xiàn)不正常。未經(jīng)測(cè)試而修改該值，盡管沒(méi)有丟失數(shù)據(jù)的風(fēng)險(xiǎn)，但仍可能會(huì)對(duì) monitors 的穩(wěn)定性和集群的健康造成不可預(yù)知的影響。
如何知道是否存在時(shí)鐘偏移？
Monitor 會(huì)用 HEALTH_WARN 的方式警告你。 ceph health detail 應(yīng)該輸出如下格式的信息：
mon.c addr 10.10.0.1:6789/0 clock skew 0.08235s > max 0.05s (latency 0.0045s)
這表示 mon.c 已被標(biāo)記出正在遭受時(shí)鐘偏移。
如果存在時(shí)鐘偏移該怎么處理？
同步各 monitor 節(jié)點(diǎn)的時(shí)鐘。運(yùn)行 NTP 客戶端會(huì)有幫助。如果你已經(jīng)啟動(dòng)了 NTP 服務(wù)，但仍遭遇此問(wèn)題，檢查一下使用的 NTP 服務(wù)器是否離你的網(wǎng)絡(luò)太過(guò)遙遠(yuǎn)，然后可以考慮在你的網(wǎng)絡(luò)環(huán)境中運(yùn)行自己的 NTP 服務(wù)器。最后這種選擇可趨于減少 monitor 時(shí)鐘偏移帶來(lái)的問(wèn)題。
客戶端無(wú)法連接或掛載
檢查 IP 過(guò)濾表。某些操作系統(tǒng)安裝工具會(huì)給 iptables 增加一條 REJECT 規(guī)則。這條規(guī)則會(huì)拒絕所有嘗試連接該主機(jī)的客戶端（除了 ssh ）。如果你的 monitor 主機(jī)設(shè)置了這條防火墻 REJECT 規(guī)則，客戶端從其他節(jié)點(diǎn)連接過(guò)來(lái)時(shí)就會(huì)超時(shí)失敗。你需要定位出拒絕客戶端連接 Ceph 守護(hù)進(jìn)程的那條 iptables 規(guī)則。比如，你需要對(duì)類似于下面的這條規(guī)則進(jìn)行適當(dāng)處理：
REJECT all -- anywhere anywhere reject-with icmp-host-prohibited
你還需要給 Ceph 主機(jī)的 IP 過(guò)濾表增加規(guī)則，以確?？蛻舳丝梢栽L問(wèn) Ceph monitor （默認(rèn)端口 6789 ）和 Ceph OSD （默認(rèn) 6800 ~ 7300 ）的相關(guān)端口。
iptables -A INPUT -m multiport -p tcp -s {ip-address}/{netmask} --dports 6789,6800:7300 -j ACCEPT
或者，如果你的環(huán)境允許，也可以直接關(guān)閉主機(jī)的防火墻。
1.5 Monitor 數(shù)據(jù)庫(kù)失敗
數(shù)據(jù)庫(kù)崩潰的表現(xiàn)
Ceph monitor 把集群的各種 map 信息存放在 key/value 數(shù)據(jù)庫(kù)中，如 LevelDB 。如果 monitor 是因?yàn)閿?shù)據(jù)庫(kù)崩潰而失敗，在 monitor 的 log 日志中應(yīng)該會(huì)有如下錯(cuò)誤信息：
Corruption: error in middle of record
或：
Corruption: 1 missing files; e.g.: /var/lib/ceph/mon/mon.0/store.db/1234567.ldb
通過(guò)健康的 Monitor(s) 恢復(fù)
如果還有幸存的 monitor，我們通常可以用新的數(shù)據(jù)庫(kù)替換崩潰的數(shù)據(jù)庫(kù)。并且在啟動(dòng)后，新加入的成員會(huì)和其他健康的伙伴進(jìn)行同步，一旦同步完成，它就可以為客戶端提供服務(wù)了。
通過(guò) OSDs 恢復(fù)
但是萬(wàn)一所有的 monitors 都同時(shí)失敗了該怎么辦？由于建議用戶在部署集群時(shí)至少安裝 3 個(gè) monitors，同時(shí)失效的可能性較小。但是數(shù)據(jù)中心意外的斷電，再加上磁盤/文件系統(tǒng)配置不當(dāng)，可能會(huì)引起底層文件系統(tǒng)失敗，從而殺掉所有的 monitors 。這種情況下，我們可以通過(guò)存放在 OSDs 上的信息來(lái)恢復(fù) monitor 的數(shù)據(jù)庫(kù)：
ms=/tmp/mon-store
mkdir $ms
# collect the cluster map from OSDs
for host in $hosts; do
rsync -avz $ms user@host:$ms
rm -rf $ms
ssh user@host <<EOF
for osd in /var/lib/osd/osd-*; do
ceph-objectstore-tool --data-path $osd --op update-mon-db --mon-store-path $ms
done
EOF
rsync -avz user@host:$ms $ms
done
# rebuild the monitor store from the collected map, if the cluster does not
# use cephx authentication, we can skip the following steps to update the
# keyring with the caps, and there is no need to pass the "--keyring" option.
# i.e. just use "ceph-monstore-tool /tmp/mon-store rebuild" instead
ceph-authtool /path/to/admin.keyring -n mon. \
--cap mon allow 'allow *'
ceph-authtool /path/to/admin.keyring -n client.admin \
--cap mon allow 'allow *' --cap osd 'allow *' --cap mds 'allow *'
ceph-monstore-tool /tmp/mon-store rebuild -- --keyring /path/to/admin.keyring
# backup corrupted store.db just in case
mv /var/lib/ceph/mon/mon.0/store.db /var/lib/ceph/mon/mon.0/store.db.corrupted
mv /tmp/mon-store/store.db /var/lib/ceph/mon/mon.0/store.db
上面的這些步驟：
- 從所有的 OSD 主機(jī)上收集 map 信息。
- 重建數(shù)據(jù)庫(kù)。
- 用恢復(fù)副本替換 mon.0 上崩潰的數(shù)據(jù)庫(kù)。
已知的限制
下面這些信息無(wú)法通過(guò)上述步驟恢復(fù)：
-
一些新增的 keyring ： 通過(guò)
ceph auth add命令增加的所有 OSD keyrings 都可以恢復(fù)。用ceph-monstore-tool可以導(dǎo)入client.admin的 keyring 。但是 MDS 和其他 keyrings 在被恢復(fù)的那個(gè) monitor 數(shù)據(jù)庫(kù)中就會(huì)丟失。你可能需要手動(dòng)重新添加一下。 -
pg 的設(shè)置：通過(guò)
ceph pg set_full_ratio和ceph pg set_nearfull_ratio命令設(shè)置的full ratio和nearfull ratio值會(huì)丟失。 - MDS Maps：MDS maps 會(huì)丟失。
磁盤空間不足導(dǎo)致 MON DOWN
當(dāng) monitor 進(jìn)程檢測(cè)到本地可用磁盤空間不足時(shí)，會(huì)停止 monitor 服務(wù)。Monitor 的日志中應(yīng)該會(huì)有類似如下信息的輸出：
2016-09-01 16:45:54.994488 7fb1cac09700 0 mon.jyceph01@0(leader).data_health(62) update_stats avail 5% total 297 GB, used 264 GB, avail 18107 MB
2016-09-01 16:45:54.994747 7fb1cac09700 -1 mon.jyceph01@0(leader).data_health(62) reached critical levels of available space on local monitor storage -- shutdown!
清理本地磁盤，增大可用空間，重啟 monitor 進(jìn)程，即可恢復(fù)正常。
通過(guò) Mon 數(shù)據(jù)庫(kù)的備份恢復(fù)
具體請(qǐng)參考本手冊(cè)第三部分 2. Monitor 的備份和恢復(fù) 。
