? ? ? ? 剛進(jìn)公司的第三天，接到一個(gè)關(guān)于ceph穩(wěn)定性的攻關(guān)任務(wù)。公司內(nèi)部集群采用k8s的部署模式，用ceph來(lái)做存儲(chǔ)模塊。ceph是5node、3monitor的集群。

? ? ? ? ?同事描述了幾個(gè)現(xiàn)象，1、mysql訪問(wèn)偶現(xiàn)夯住，服務(wù)端直接報(bào)錯(cuò)，由于涉及線上業(yè)務(wù)已切換至虛擬機(jī)部署的mysql，問(wèn)題消失? 2、部署在k8s的efk集群也是采用ceph的rbd塊作為后端存儲(chǔ)，基于rbd的IOPS會(huì)突降為0，efk不可用，過(guò)幾分鐘服務(wù)恢復(fù) 3、ceph-mds.log偶爾會(huì)報(bào)slow request的日志

? ? ? ? ? 由于之前沒(méi)有使用ceph，當(dāng)時(shí)的我一臉懵逼，但是問(wèn)題排查思路還是通用的，我決定一邊查看ceph的文檔一邊復(fù)現(xiàn)問(wèn)題。slow request由于出現(xiàn)頻率較低，也沒(méi)有復(fù)現(xiàn)方案，暫時(shí)擱置。先復(fù)現(xiàn)mysql和efk的問(wèn)題。

? ? ? ? ? ?Mysql這邊，由于只有pod集群的監(jiān)控，沒(méi)有rbd的監(jiān)控，在查看了grafana發(fā)現(xiàn)，出現(xiàn)mysql不穩(wěn)定的時(shí)候，mysql和mysqlexporter(mysql的promethues采集器)的流量均變成0，前后的負(fù)載均沒(méi)有大的波動(dòng)。參照這個(gè)現(xiàn)象，我決定用mysqlslap先對(duì)數(shù)據(jù)庫(kù)做單獨(dú)的壓測(cè)，嘗試復(fù)現(xiàn)問(wèn)題，但是在壓了兩天之后沒(méi)有復(fù)現(xiàn)，于是拉開(kāi)發(fā)進(jìn)行服務(wù)端的壓測(cè)，同時(shí)接入rbd的監(jiān)控，很遺憾的是問(wèn)題還是沒(méi)有復(fù)現(xiàn)。

? ? ? ? ? ?正當(dāng)一籌莫展的時(shí)候，efk集群的IOPS問(wèn)題倒是每天都出現(xiàn)，不妨換個(gè)思路先定位這個(gè)問(wèn)題。這邊問(wèn)題是每天出現(xiàn)，但是日志太少了, 只有mds的日志里有偶爾的slow request日志，和問(wèn)題出現(xiàn)并不是強(qiáng)相關(guān)。所以第一步想辦法打印更多的日志。參照官方文檔?http://docs.ceph.org.cn/rados/troubleshooting/log-and-debug/?把debug_osd的日志等級(jí)打印到了5/5，并把所有的ceph收集到了efk集群方便查看。當(dāng)問(wèn)題再次出現(xiàn)的時(shí)候，我查看的5臺(tái)機(jī)器的負(fù)載和io，都是比較低的水平，由于出現(xiàn)問(wèn)題的時(shí)候沒(méi)法使用efk，osd的日志又很分散沒(méi)法查看，所以只能查看主機(jī)上有沒(méi)有異常，我又查看了主機(jī)的dmesg信息和系統(tǒng)日志，果然在/var/log/messages下面有所發(fā)現(xiàn)，我發(fā)有兩臺(tái)機(jī)器在瘋狂的打以下日志:

Nov 10 03:53:13 db-16-2-hzxs ceph-osd: 2019-11-10 03:53:13.599 7f49b2c9f700 -1 osd.35 4443 get_health_metrics reporting 1 slow ops, oldest is osd_op(client.67215.0:60910421 7.c 7:306feb75:::rbd_data.fea92572485c.000000000001db2a:head [zero 0~40960] snapc 149=[149,138,128,118,108,f8,e9,da,cb,bc,ad,9e,8f,80,71,62,53] ondisk+write+known_if_redirected e4443)

我翻閱了之前出現(xiàn)問(wèn)題的時(shí)間段，都有類似的日志，只是osd編號(hào)和最后的e4443會(huì)有所變化，等efk恢復(fù)查詢之后，我在efk查詢了get_health_metrics關(guān)鍵，果然在兩個(gè)節(jié)點(diǎn)發(fā)現(xiàn)大量的相同日志，那rbd的不可用很可能是這兩個(gè)節(jié)點(diǎn)導(dǎo)致的，但是為什么就這兩個(gè)節(jié)點(diǎn)報(bào)錯(cuò)呢。我問(wèn)了部署ceph集群的同學(xué)節(jié)點(diǎn)之間有什么差異，果然這兩個(gè)節(jié)點(diǎn)的內(nèi)核版本和ceph版本和其他三個(gè)節(jié)點(diǎn)都不一樣，這是一個(gè)重大的信息點(diǎn)。接下來(lái)就能用排除法去解決問(wèn)題了。首先升級(jí)了一個(gè)正常節(jié)點(diǎn)的ceph至14.2.4，和異常節(jié)點(diǎn)的ceph保持一致，但是問(wèn)題再次出現(xiàn)依然是原來(lái)的兩個(gè)節(jié)點(diǎn)報(bào)錯(cuò)。然后我們降級(jí)了一個(gè)異常節(jié)點(diǎn)的內(nèi)核版本，從3.10.0-957.27.2.el7降到了3.10.0-957.12.1.el7，和正常節(jié)點(diǎn)保持一致，重啟機(jī)器，問(wèn)題消失。

? ? ? ? ? ?降級(jí)內(nèi)核后到發(fā)稿時(shí)efk尚未出現(xiàn)問(wèn)題，mysql也沒(méi)有出現(xiàn)問(wèn)題，至于為什么還有一個(gè)節(jié)點(diǎn)沒(méi)有升級(jí)但是依然不報(bào)錯(cuò)，我猜可能是OSD寫(xiě)入的時(shí)候需要2個(gè)osd同時(shí)寫(xiě)入失敗才會(huì)失敗，后面等ceph功力再深一層次再去探究。整個(gè)排查過(guò)程差不多持續(xù)了一周，主要查閱的文檔是官方文檔?http://docs.ceph.org.cn/start/intro/?和這篇博文 https://lihaijing.gitbooks.io/ceph-handbook/content/Troubleshooting/troubleshooting_osd.html?。當(dāng)然這可能還不是最后的結(jié)論，我也把日志發(fā)送給了社區(qū)，希望他們給我答疑 ，但是從接觸問(wèn)題到升級(jí)內(nèi)核解決的過(guò)程還是想記錄和分享給大家 : )? ?最后大家部署開(kāi)源軟件的時(shí)候還是建議部署在官方推薦的硬件和軟件版本上，以免踩不必要的坑。