四川 賴文書

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

公司應用系統部署6臺虛擬機構成的Weblogic 服務器集群，由單獨一臺虛擬機通過NFS 服務提供共享文件服務。

NFS 服務器是以iSCSI 掛載H3C 的ONEStor 分布式存儲的塊存儲，虛擬化平臺與存儲融合部署于CVK 宿主機拓撲如圖1所示，分布式存儲的LUN1 和LUN2 掛載到物理機用于存放虛擬機磁盤文件，LUN3 掛載到NFS 服務器虛機用于存放應用系統的非結構化數據文件。

初步診斷

圖1 虛擬化及分布式存儲融合架構

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

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

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

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

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

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

運維組通過郵件具體描述了故障現象以及排查過程，發(fā)給項目組領導A 請求集成部領導B 溝通協助排查。同時運維組詢問廠商，請求遠程對ONEStor 分布式存儲進行排查。

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

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

深入排查

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

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

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

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

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

運維組和負責NBU 備份的同事聯系確認，還有大概7TB 的可用空間，再經咨詢NBU 售后工程師確認，其備份需要在NFS 服務器上安裝NBU 客戶端并新建備份任務，4TB 的數據文件從目前16 點開始備份大概要到第二天上午才能完成。

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

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

在這期間，運維組技術骨干建議將iSCSI 塊存儲LUN3重新掛載到其它虛擬服務器，以確認其文件系統是否正常，還是被工程師Y 否定，稱在沒有備份前對其操作存在很大風險，可能導致部分數據損壞或丟失。

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

專家會診

時間一分一秒不停地在流逝，可處理故障的進展陷入了停止狀態(tài)。

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

大家對于領導B 面對故障的心情是可以理解的，只是他的指揮意見在此時此刻沒有操作可行性。項目組領導A 沉著冷靜地在一邊思考，然后電話與廠商的商務負責人溝通故障排查情況及影響程度，因為公司的應用是部署在廠商的虛擬化和分布式存儲之上的，出現的存儲問題需要廠商大力配合盡快處理，要求工程師Y 聯系他們二線工程師進一步分析故障及有效的解決方案。

在商務負責人的推動下，廠商很快建立了專項故障診斷微信群，使用向日葵遠程控制軟件分享遠程桌面。

二線工程師X 主導診斷分析，工程師Y 按指導意見進行操作。

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

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

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

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

圖2 查看系統日志sysIog

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

在這種情況下，二線工程師X 遠程詳細檢查NFS 服務器虛機所在宿主機CVK5，查看系統日志syslog。如圖2所示。

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

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

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

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

接下來由應用同事檢查nasapp 非結構化文件的完整性，確認系統訪問情況正常，整個緊急處理過程算是告一段落。

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

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

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

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

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

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

最終建議對ONEStor 版本進行升級修復此類故障。

總結

雖然最終是小小的重啟排除了故障，使公司的應用系統恢復了正常運行，但其過程是相當艱難和漫長的，耗時近10個小時。

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

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

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

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