雲主機檔案系統readonly處理案例
本文由作者朱益軍授權網易雲社群釋出。
背景
維護巡檢雲主機時，發現有一臺執行redis的雲主機狀態顯示維護中，登入該例項檢視，系統盤變成readonly。本文簡單分析該問題出現原因，併為運維人員提供常見處理方法及建議。
故障分析
檢視雲主機dmesg資訊發現，系統執行過程中python程序發生segfault，隨後vda（雲主機配置virtio-blk，故碟符顯示為vda）系統盤I/O error。
[8349644.226151] Clock: inserting leap second 23:59:60 UTC
[8744049.152007] The scan_unevictable_pages sysctl/node-interface has been disabled for lack of a legitimate use case. If you have one, please send an email to[email protected]
[30940223.794815] python[28313]: segfault at 58 ip 00000000004aa8c7 sp 00007f2b44a2f560 error 4 in python2.7[400000+257000]
[42731185.176179] end_request: I/O error, dev vda, sector 12590864
[42731185.468491] EXT4-fs error (device vda1): __ext4_get_inode_loc:3697: inode #403168: block 1573613: comm updatedb.mlocat: unable to read itable block
[42731185.471307] Aborting journal on device vda1-8.
[42731185.472359] journal commit I/O error
[42731185.473183] EXT4-fs error (device vda1): ext4_journal_start_sb:327: Detected aborted journal
[42731185.474761] EXT4-fs (vda1): Remounting filesystem read-only
[42731185.588205] EXT4-fs (vda1): Remounting filesystem read-only
[42731185.750067] end_request: I/O error, dev vda, sector 12590872
[42731185.751578] EXT4-fs error (device vda1): __ext4_get_inode_loc:3697: inode #403173: block 1573614: comm updatedb.mlocat: unable to read itable block
[42817852.384073] EXT4-fs (vda1): error count since last fsck: 4
[42817852.384077] EXT4-fs (vda1): initial error at time 1517610339: __ext4_get_inode_loc:3697: inode 403168: block 1573613
[42817852.384081] EXT4-fs (vda1): last error at time 1517610340: __ext4_get_inode_loc:3697: inode 403173: block 1573614
[42904359.904061] EXT4-fs (vda1): error count since last fsck: 4
[42904359.904065] EXT4-fs (vda1): initial error at time 1517610339: __ext4_get_inode_loc:3697: inode 403168: block 1573613
[42904359.904069] EXT4-fs (vda1): last error at time 1517610340: __ext4_get_inode_loc:3697: inode 403173: block 1573614
[42990867.424056] EXT4-fs (vda1): error count since last fsck: 4
[42990867.424060] EXT4-fs (vda1): initial error at time 1517610339: __ext4_get_inode_loc:3697: inode 403168: block 1573613
[42990867.424064] EXT4-fs (vda1): last error at time 1517610340: __ext4_get_inode_loc:3697: inode 403173: block 1573614
基本可確定是業務把系統盤寫壞了。通常發生該問題的場景有二：
一、雲主機和宿主機IO繁忙，雲主機的IO請求得不到及時的響應，從而產生磁碟IO錯誤，為了保護磁碟資料會remount分割槽為只讀；
二、雲主機被強制關機，導致磁碟出現檔案系統錯誤故障。
故障處理
通常的解決方法是重啟系統以root使用者進入單使用者模式，執行fsck.ext3 –y /dev/vda（如果是ext4使用fsck.ext4修復），/dev/vda是系統/根分割槽。修復完reboot進入系統。以debian系統為例：
1、重啟系統，grub選單會出現正常啟動和修復模式（
2、進入修復模式，執行fsck工具修復；
3、重啟進入正常模式啟動。
注意：
1、運維人員在重啟雲主機之前儘量先收集一些關鍵的日誌，如/var/log下面的一些日誌、dmesg等，有條件也要收集宿主機的日誌；
2、fsck是Linux核心自帶工具，它不僅可以對檔案系統進行掃描，還能修正檔案系統的一些問題。fsck掃描檔案系統時一定要在單使用者模式、修復模式或把裝置umount後進行。建議在單使用者模式下執行。如果掃描正常執行中的系統，會造成系統檔案損壞,需要root許可權執行。
建議與思考
1、當前開發要定位問題，需要申請宿主機許可權等流程，無法及時上去定位；
2、當前雲主機的日誌收集功能尚不完善，呈現的日誌比較雜、亂、實用性不高，需要適當進行修改調整。另外，運維人員也不知道要收集哪些日誌可支撐開發定位；
開發正在考慮開發一個一鍵式日誌收集工具，整合到版本中，定期採集系統資料並歸檔，或者在發生故障時，由運維先收集分析，再交給開發定位，這樣效率會高一些。
更多網易技術、產品、運營經驗分享請訪問網易雲社群。
相關文章：
【推薦】 MongoDB複製集與Raft協議異同點分析