難以決定的重啟操作

四川 賴文書

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

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

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

初步診斷

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

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

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

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

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

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

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

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

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

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

深入排查

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

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

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

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

雖然初步檢查到了基本的故障原因，但是問題并沒有解決。經(jīng)工程師Y 與二線工程師討論決定，需要對NFS 服務(wù)器系統(tǒng)進(jìn)行重啟以測試確認(rèn)故障點(diǎn)，為防止所掛載的iSCSI 磁盤的文件系統(tǒng)發(fā)生異常，導(dǎo)致所存放的文件有問題，重啟前建議對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)開始備份大概要到第二天上午才能完成。

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

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

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

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

專家會診

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

總結(jié)

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

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

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

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

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