難以決定的重啟操作

四川 賴文書

筆者單位應(yīng)用組的同事反饋公司應(yīng)用后臺(tái)的文件服務(wù)器異常，引發(fā)用戶上傳文件報(bào)錯(cuò)，影響公司業(yè)務(wù)正常辦理運(yùn)作。

公司應(yīng)用系統(tǒng)部署6臺(tái)虛擬機(jī)構(gòu)成的Weblogic 服務(wù)器集群，由單獨(dú)一臺(tái)虛擬機(jī)通過(guò)NFS 服務(wù)提供共享文件服務(wù)。

NFS 服務(wù)器是以iSCSI 掛載H3C 的ONEStor 分布式存儲(chǔ)的塊存儲(chǔ)，虛擬化平臺(tái)與存儲(chǔ)融合部署于CVK 宿主機(jī)拓?fù)淙鐖D1所示，分布式存儲(chǔ)的LUN1 和LUN2 掛載到物理機(jī)用于存放虛擬機(jī)磁盤文件，LUN3 掛載到NFS 服務(wù)器虛機(jī)用于存放應(yīng)用系統(tǒng)的非結(jié)構(gòu)化數(shù)據(jù)文件。

初步診斷

圖1 虛擬化及分布式存儲(chǔ)融合架構(gòu)

由于問(wèn)題的影響面比較大，運(yùn)維組老D 接到反饋后第一時(shí)間對(duì)應(yīng)用集群服務(wù)器和NFS 服務(wù)器進(jìn)行了檢查。

測(cè)試掛載到集群服務(wù)器上的目錄，執(zhí)行touch 命令新建文件發(fā)現(xiàn)無(wú)法寫入，報(bào)錯(cuò)提示“Read-only file system”，檢查目錄的權(quán)限是777 即（rwxrwxrwx），也沒(méi)有異常。

同時(shí)測(cè)試集群中其他服務(wù)器所掛載的目錄均無(wú)法寫入，在集群中的一臺(tái)服務(wù)器執(zhí) 行“mount -o rw,remount/nasapp”重新掛載，仍然無(wú)法寫入。

推測(cè)是NFS 服務(wù)器有問(wèn)題，登入NFS 服務(wù)器上執(zhí)行命 令“service nfs restart”重啟NFS 服務(wù)，在群集服務(wù)器上測(cè)試仍然無(wú)濟(jì)于事。

忙活了這么久竟忘了該對(duì)iSCSI 掛載的塊存儲(chǔ)進(jìn)行測(cè)試，touch 命令依然是無(wú)法新建文件。

排查故障原因從mount掛載方面，轉(zhuǎn)到NFS 服務(wù)是否異常，最后檢測(cè)確認(rèn)到iSCSI掛載的塊存儲(chǔ)異常。由于NFS 服務(wù)器所共享的磁盤是基于Ceph 的塊存儲(chǔ)，前期部署由公司集成部配合廠商完成，具體技術(shù)細(xì)節(jié)運(yùn)維組了解甚少，所以得請(qǐng)求他們緊急支援解決問(wèn)題。

運(yùn)維組通過(guò)郵件具體描述了故障現(xiàn)象以及排查過(guò)程，發(fā)給項(xiàng)目組領(lǐng)導(dǎo)A 請(qǐng)求集成部領(lǐng)導(dǎo)B 溝通協(xié)助排查。同時(shí)運(yùn)維組詢問(wèn)廠商，請(qǐng)求遠(yuǎn)程對(duì)ONEStor 分布式存儲(chǔ)進(jìn)行排查。

由于事關(guān)重大，集成部的技術(shù)大牛胖U 第一時(shí)間響應(yīng)了運(yùn)維組的請(qǐng)求，當(dāng)他了解到NFS 服務(wù)器所在的iSCSI磁盤也無(wú)法寫時(shí)，立即判斷是分布式存儲(chǔ)方面的問(wèn)題，并讓運(yùn)維組聯(lián)系廠商解決。廠商售后工程師通過(guò)遠(yuǎn)程檢查了ONEStor 存儲(chǔ)運(yùn)行狀態(tài)，沒(méi)有發(fā)現(xiàn)任何異常初步判斷是虛擬機(jī)系統(tǒng)層面或者是軟件配置的問(wèn)題。

而近幾天又沒(méi)有進(jìn)行系統(tǒng)或軟件層面的配置修改，就今天早上突然出現(xiàn)了故障，目前應(yīng)用仍然無(wú)法正常運(yùn)行直接影響公司業(yè)務(wù)，項(xiàng)目組領(lǐng)導(dǎo)A 強(qiáng)烈要求廠商和集成的同事到現(xiàn)場(chǎng)協(xié)助解決。

深入排查

廠商一線工程師Y 趕到現(xiàn)場(chǎng)，運(yùn)維組老D 給他演示了故障現(xiàn)象，并解釋了遠(yuǎn)程檢查的結(jié)果，即ONEStor 存儲(chǔ)沒(méi)有問(wèn)題，還是讓我們從軟件配置方面檢查，是不是哪里對(duì)磁盤容量有限制的策略。

該建議對(duì)于運(yùn)維組來(lái)說(shuō)沒(méi)有可操作性，畢竟系統(tǒng)部署是廠商完成的，還個(gè)方向的檢查還得請(qǐng)廠商工程師完成。工程師Y 在虛擬平臺(tái)的管理頁(yè)面沒(méi)發(fā)現(xiàn)任何可疑項(xiàng)。為了推動(dòng)問(wèn)題的解決，運(yùn)維組同事建議先從NFS 服務(wù)器的系統(tǒng)日志進(jìn)行排查。在系統(tǒng)日志文件message 里凌晨5點(diǎn)26 分發(fā)現(xiàn)數(shù)十條的I/O 報(bào)錯(cuò)：

大概意思是文件系統(tǒng)由于I/O 錯(cuò)誤無(wú)法寫入邏輯磁盤塊，自動(dòng)以只讀模式重新掛載。

根據(jù)此日志，工程師Y解釋文件系統(tǒng)變?yōu)橹蛔x，原因?yàn)槲募到y(tǒng)遭到破壞，與ONEStor 塊存儲(chǔ)是否故障無(wú)直接關(guān)系，更堅(jiān)決認(rèn)定故障原因在虛機(jī)服務(wù)器操作系統(tǒng)層面，用手機(jī)對(duì)錯(cuò)誤日志拍了兩張照片報(bào)告其公司的二線工程師。

雖然初步檢查到了基本的故障原因，但是問(wèn)題并沒(méi)有解決。經(jīng)工程師Y 與二線工程師討論決定，需要對(duì)NFS 服務(wù)器系統(tǒng)進(jìn)行重啟以測(cè)試確認(rèn)故障點(diǎn)，為防止所掛載的iSCSI 磁盤的文件系統(tǒng)發(fā)生異常，導(dǎo)致所存放的文件有問(wèn)題，重啟前建議對(duì)iSCSI 磁盤進(jìn)行備份。

運(yùn)維組和負(fù)責(zé)NBU 備份的同事聯(lián)系確認(rèn)，還有大概7TB 的可用空間，再經(jīng)咨詢NBU 售后工程師確認(rèn)，其備份需要在NFS 服務(wù)器上安裝NBU 客戶端并新建備份任務(wù)，4TB 的數(shù)據(jù)文件從目前16 點(diǎn)開(kāi)始備份大概要到第二天上午才能完成。

同時(shí)集成部大牛胖U 還擔(dān)心NBU 的恢復(fù)驗(yàn)證問(wèn)題，推薦直接COPY 方式復(fù)制到空閑的SAN 存儲(chǔ)，由于是巨量的小文件也會(huì)非常耗時(shí)。

經(jīng)過(guò)討論，針對(duì)眼前緊急狀況，這些備份措施均無(wú)法滿足要求。廠商工程師Y 就一直等著運(yùn)維組拿出備份解決方案，進(jìn)展也卡在這里1個(gè)多小時(shí)。

在這期間，運(yùn)維組技術(shù)骨干建議將iSCSI 塊存儲(chǔ)LUN3重新掛載到其它虛擬服務(wù)器，以確認(rèn)其文件系統(tǒng)是否正常，還是被工程師Y 否定，稱在沒(méi)有備份前對(duì)其操作存在很大風(fēng)險(xiǎn)，可能導(dǎo)致部分?jǐn)?shù)據(jù)損壞或丟失。

廠商工程師的意見(jiàn)把大家都震住了，備份不能很快完成，不備份直接重啟帶來(lái)的風(fēng)險(xiǎn)責(zé)任誰(shuí)也無(wú)法承擔(dān)，真不知如何是好啊。

專家會(huì)診

時(shí)間一分一秒不停地在流逝，可處理故障的進(jìn)展陷入了停止?fàn)顟B(tài)。

公司應(yīng)用系統(tǒng)雖然還在運(yùn)行，但是部分功能確實(shí)無(wú)法使用，給業(yè)務(wù)帶來(lái)的影響非常大。集成部領(lǐng)導(dǎo)B 也打來(lái)電話關(guān)心處理進(jìn)度，并指責(zé)運(yùn)維組為什么之前沒(méi)有備份，還強(qiáng)硬地要求派人去IDC 數(shù)據(jù)中心拿移動(dòng)硬盤拷貝完成備份。

大家對(duì)于領(lǐng)導(dǎo)B 面對(duì)故障的心情是可以理解的，只是他的指揮意見(jiàn)在此時(shí)此刻沒(méi)有操作可行性。項(xiàng)目組領(lǐng)導(dǎo)A 沉著冷靜地在一邊思考，然后電話與廠商的商務(wù)負(fù)責(zé)人溝通故障排查情況及影響程度，因?yàn)楣镜膽?yīng)用是部署在廠商的虛擬化和分布式存儲(chǔ)之上的，出現(xiàn)的存儲(chǔ)問(wèn)題需要廠商大力配合盡快處理，要求工程師Y 聯(lián)系他們二線工程師進(jìn)一步分析故障及有效的解決方案。

在商務(wù)負(fù)責(zé)人的推動(dòng)下，廠商很快建立了專項(xiàng)故障診斷微信群，使用向日葵遠(yuǎn)程控制軟件分享遠(yuǎn)程桌面。

二線工程師X 主導(dǎo)診斷分析，工程師Y 按指導(dǎo)意見(jiàn)進(jìn)行操作。

首先針對(duì)我們需要備份的問(wèn)題，工程師X 查看ONEStor 分布式存儲(chǔ)磁盤使用率才40%多，決定再劃分5TB 塊存儲(chǔ)以iSCSI 掛載到NFS 服務(wù)器上進(jìn)行備份。

這樣即解決了備份空間的問(wèn)題，又避免了通過(guò)其他網(wǎng)絡(luò)備份的性能瓶頸問(wèn)題，此操作果然高明，真是行家一出手便知有沒(méi)有啊。

工程師Y 操作過(guò)程中，在NFS 服務(wù)器上以“fdisk”命令對(duì)新的5TB 塊存儲(chǔ)進(jìn)行磁盤分區(qū)，操作了多遍都只能分區(qū)到2TB 的空間，百思不得其解。后來(lái)猛然間才發(fā)現(xiàn)fdisk只能創(chuàng)建2TB 的分區(qū)，改用“parted”命令并以GPT（GUID分區(qū)表）完成磁盤分區(qū)操作。

經(jīng)過(guò)格式化后，工程師Y編寫了個(gè)shell 腳本對(duì)NFS原塊存儲(chǔ)的文件進(jìn)行備份，運(yùn)行時(shí)發(fā)現(xiàn)很多報(bào)錯(cuò)，大概意思是無(wú)法復(fù)制文件夾。

圖2 查看系統(tǒng)日志sysIog

為了驗(yàn)證是否是腳本問(wèn)題，手動(dòng)執(zhí)行腳本里的復(fù)制命令仍然報(bào)錯(cuò)，再以cat 命令輸出NASAPP 目錄下的幾個(gè)文件竟然無(wú)法讀取，這樣就確認(rèn)到此時(shí)原來(lái)iSCSI 塊存儲(chǔ)不僅無(wú)法寫也不能讀了，備份工作就無(wú)法正常進(jìn)行。

在這種情況下，二線工程師X 遠(yuǎn)程詳細(xì)檢查NFS 服務(wù)器虛機(jī)所在宿主機(jī)CVK5，查看系統(tǒng)日志syslog。如圖2所示。

查看kernel日志文件kern.log 發(fā)現(xiàn)內(nèi)核報(bào)檢測(cè)到通訊錯(cuò)誤，拒絕I/O 到離線的設(shè)備。

在路徑/var/log/libvirt/qemu/的對(duì)應(yīng)NFS 服務(wù)器虛機(jī)日志，發(fā)現(xiàn)了50條如下錯(cuò)誤日志，持續(xù)時(shí)間2 秒鐘：

最后嘗試命令“umount”卸載nasapp 目錄，但仍然報(bào)錯(cuò)，使用“l(fā)sof/nasapp/”和“fuser/nasapp/”命令查看占用情況，并使用“fuser -k/nasapp”殺掉占用該文件夾的進(jìn)程，再umount 正常卸載，編輯/etc/fstab 注釋掉nasapp 防止系統(tǒng)啟動(dòng)時(shí)自動(dòng)掛載，避免ext4 文件系統(tǒng)自檢導(dǎo)致異常。

現(xiàn)場(chǎng)工程師Y 再次電話溝通，確認(rèn)重啟系統(tǒng)是否對(duì)iSCSI 磁盤數(shù)據(jù)有影響，二線工程師X 根據(jù)檢查情況和經(jīng)驗(yàn)確認(rèn)不會(huì)影響，reboot 重啟NFS 服務(wù)器。重啟后取消fstab 文件剛才的注釋項(xiàng)，使用“mount -a”命令將/etc/fstab 的所有內(nèi)容重新加載，進(jìn)入/nasapp 目錄創(chuàng)建文件正常確認(rèn)可讀寫，同時(shí)檢查了各節(jié)點(diǎn)訪問(wèn)nfs 共享目錄讀寫也都正常。

接下來(lái)由應(yīng)用同事檢查nasapp 非結(jié)構(gòu)化文件的完整性，確認(rèn)系統(tǒng)訪問(wèn)情況正常，整個(gè)緊急處理過(guò)程算是告一段落。

項(xiàng)目經(jīng)理A 再次向廠商工程師了解故障的根本原因，二線工程師根據(jù)檢查結(jié)果初步判斷為網(wǎng)絡(luò)波動(dòng)所致。但是從網(wǎng)絡(luò)監(jiān)測(cè)和日志中并未發(fā)現(xiàn)這種問(wèn)題，況且分布式存儲(chǔ)的LUN1 和LUN2 運(yùn)行正常，運(yùn)維部門對(duì)此故障原因深表懷疑。

為了更進(jìn)一步排查深層故障原因，最后廠商工程師全面收集了虛擬化平臺(tái)和ONEStor 分布式存儲(chǔ)的日志，故障虛擬機(jī)及所在宿主機(jī)的日志，待廠商的研發(fā)部門深入分析根本原因。

最后收到的故障分析報(bào)告，還是證實(shí)了集成部技術(shù)大牛最初的判斷，問(wèn)題確實(shí)出在存儲(chǔ)方面。

ONEStor 高可用工作節(jié)點(diǎn)CVK2 的tgt（iscsi Target存儲(chǔ)服務(wù)端）進(jìn)程由于已知Bug 引發(fā)自動(dòng)終止，導(dǎo)致主機(jī)檢測(cè)到iscsi 連接異常，隨后存儲(chǔ)的保護(hù)機(jī)制高可用(keepalive)檢查到該故障，觸發(fā)工作節(jié)點(diǎn)切換到CVK4 節(jié)點(diǎn)，此時(shí)存儲(chǔ)高可用切換完成，大致耗時(shí)15s。

隨后主機(jī)在05:26:41 完成在CVK4 節(jié)點(diǎn)建立iscsi 連接，此時(shí)主機(jī)IO 完全恢復(fù)正常，存儲(chǔ)高可用業(yè)務(wù)切換加主機(jī)重新建立iscsi 連接共計(jì)耗時(shí)約24s。

而在虛擬化集群系統(tǒng)中，為了保證多路徑可以及時(shí)切換，所以把CVK 設(shè)置iscsid session 恢復(fù)時(shí)限為20s，導(dǎo)致存儲(chǔ)在高可用切換過(guò)程中，主機(jī)認(rèn)為20s 超時(shí)將塊存儲(chǔ)置于離線，并且返回業(yè)務(wù)上層IO error，觸發(fā)ext4文件系統(tǒng)錯(cuò)誤處理機(jī)制導(dǎo)致Remounting filesystem read-only。

最終建議對(duì)ONEStor 版本進(jìn)行升級(jí)修復(fù)此類故障。

總結(jié)

雖然最終是小小的重啟排除了故障，使公司的應(yīng)用系統(tǒng)恢復(fù)了正常運(yùn)行，但其過(guò)程是相當(dāng)艱難和漫長(zhǎng)的，耗時(shí)近10個(gè)小時(shí)。

造成如此局面大概有兩方面的因素：

首先技術(shù)方面在初步診斷時(shí)僅從Linux 系統(tǒng)服務(wù)的表面去檢查，未能第一時(shí)間從內(nèi)核和系統(tǒng)日志去檢查；運(yùn)維組、集成部和一線工程師均無(wú)法確認(rèn)重啟是否影響存儲(chǔ)上的數(shù)據(jù)。

其次是工作邊界引起的操作責(zé)任方面的問(wèn)題，集成部直接判定為存儲(chǔ)問(wèn)題，而廠商工程師一直認(rèn)為是軟件或者系統(tǒng)層面的原因，重啟操作前需要備份又將責(zé)任轉(zhuǎn)移到運(yùn)維組。有效推動(dòng)此次故障解決的，除了項(xiàng)目經(jīng)理A 正確把握故障處理方向和高效溝通協(xié)調(diào)外，二線工程師X 深厚技術(shù)功底和經(jīng)驗(yàn)起了決定性作用。

通過(guò)這次故障經(jīng)歷認(rèn)識(shí)到，只有技術(shù)過(guò)硬才能在緊急處理中有擔(dān)當(dāng)，如果我們都能擁有像廠商二線工程師X 的技術(shù)實(shí)力，也就能在最短時(shí)間內(nèi)解決問(wèn)題，避免跨部門及廠商協(xié)作中的責(zé)任劃分帶來(lái)的效率問(wèn)題。