故障現(xiàn)象

近些天，機(jī)房的設(shè)備接二連三遭遇些不順，不是被人把服務(wù)器供電搞斷，就是碰到存儲故障導(dǎo)致存儲連接丟失，一波接一波的虛機(jī)不斷被傷害，有的虛機(jī)重啟后一切正常，有的虛機(jī)變成了只讀文件系統(tǒng)，有的則干脆在磁盤檢查報未預(yù)期的不一致錯誤，幾番折騰下來，一直對存儲不太重視的我，對存儲的“情感”更進(jìn)了一步。

首先是變?yōu)橹蛔x文件系統(tǒng)的一類，即操作系統(tǒng)正常運(yùn)行中，突然與存儲失去了聯(lián)系，Windows與Linux容忍的時間是不一樣的，超出了最大容忍時間，操作系統(tǒng)就會將磁盤變?yōu)橹蛔x文件系統(tǒng)，確保數(shù)據(jù)無法寫入，否則引發(fā)異常。此時，無論Windows還是Linux在表面上看都正常運(yùn)行著，網(wǎng)絡(luò)也通暢，讀多寫少的業(yè)務(wù)可能都察覺不到有異常，寫入較多的業(yè)務(wù)則會較為敏感，會在各個操作界面拋出異常。

解決這類問題，最簡單易行的辦法就是重啟虛機(jī)。重啟后有兩種可能，其一是一切正常；其二則是出現(xiàn)磁盤自檢并且需要人工干預(yù)，這是因?yàn)榕c存儲失聯(lián)的容忍時間內(nèi)還有未寫入磁盤的數(shù)據(jù)，造成元數(shù)據(jù)信息不一致。當(dāng)然，也有更高要求的環(huán)境需要不重啟進(jìn)行重新掛載，這不僅要求更高超的技術(shù)水平，同時也依賴底層硬件支持在線刷新連接狀態(tài)方可。本例所遇到的環(huán)境并沒那么嚴(yán)謹(jǐn)，直接采用重啟這一“粗暴”途徑。

重新啟動后，Linux系統(tǒng)直接拋出UNEXPECTED INCONSISTENCY錯誤，也就是文件系統(tǒng)自檢發(fā)現(xiàn)不一致。

故障解決

在操作系統(tǒng)中，為了增加系統(tǒng)性能而采用的Cache機(jī)制，分為write-through和write-back兩 種。Writethrough也叫直寫模式，在數(shù)據(jù)保存時，同時寫入緩存Cache和后端存儲。此模式缺點(diǎn)在于數(shù)據(jù)寫入磁盤的IO速度較慢，必須等待寫入磁盤成功才算完畢。

Write-back也叫回寫模式，在數(shù)據(jù)保存時只寫入緩存Cache，只在數(shù)據(jù)被替換出緩存時，被修改的緩存數(shù)據(jù)才會被寫到后端存儲。此模式的優(yōu)點(diǎn)是數(shù)據(jù)寫入Cache速度快，不需要等存儲反饋落盤成功就算完畢，缺點(diǎn)是數(shù)據(jù)未被寫入存儲時出現(xiàn)系統(tǒng)掉電或死機(jī)等情況，就會導(dǎo)致這一現(xiàn)象（如圖1）。

圖1 文件系統(tǒng)待修復(fù)界面及操作

遇到這一問題不用太擔(dān)心，只要輸入正確的根用戶密碼，執(zhí)行fsck-y /dev/VolGroup00/LogVol01即可完成磁盤修復(fù)，再次重啟就能正常進(jìn)入操作系統(tǒng)了。在這一命令中，fsck是檢查文件系統(tǒng)并修復(fù)錯誤的命令，-y對提出的所有問題假定一個“yes”的響應(yīng)，若不使用該選項(xiàng)，則每檢查到一個錯誤的文件都需要人工響應(yīng)是否修復(fù)，/dev/VolGroup00/LogVol01即待檢測修復(fù)的目標(biāo)文件系統(tǒng)。

然而，接下來處理的另一個虛機(jī)遇到的問題又有些棘手——根用戶密碼始終不正確。詢問了相關(guān)同事，所有可能的密碼都驗(yàn)證失敗，必須另想辦法。

第一個想到的是單用戶模式重置密碼，在GRUB啟動菜單里移動光標(biāo)至kernel項(xiàng)一行，按e編輯kernel菜單項(xiàng)，在行末尾輸入single，更改后按回車返回Linux啟動菜單項(xiàng)界面，然后按b即通過剛修改的行引導(dǎo)Linux從而進(jìn)入單用戶模式?？墒?，相同的磁盤修復(fù)提示導(dǎo)致無法進(jìn)入單用戶模式，即不能重置密碼，也不能修復(fù)磁盤。

第二個想到的是Linux救援模式，通過引導(dǎo)光盤進(jìn)入救援模式環(huán)境，選擇不自動掛載掃描到的文件系統(tǒng)，救援模式下能夠找到本地磁盤的分區(qū)，可嘗試了好多種路徑都無法進(jìn)行修復(fù)。重啟進(jìn)入救援模式，選擇自動掛載本地文件系統(tǒng)，居然成功掛載，并且chroot /mnt/sysimages也能進(jìn)入文件系統(tǒng)目錄，然而執(zhí)行修復(fù)操作，依然無法成功。

轉(zhuǎn)念一想，既然能夠chroot進(jìn)入到損壞的文件系統(tǒng)，是否能夠修改密碼呢？立即嘗試很快有了答案——可以重置root密碼。重啟系統(tǒng)，待提示輸入根用戶密碼進(jìn)入修復(fù)操作界面，終于不再報密碼錯誤了，從而順利完成了磁盤修復(fù)。

故障分析

從修復(fù)文件系統(tǒng)操作忽然變成了特定情況下的重置密碼，密碼的錯誤本身就是蹊蹺的，因?yàn)樵诔霈F(xiàn)問題前同事都成功登錄過，懷疑是因?yàn)槲募到y(tǒng)損壞而導(dǎo)致無法驗(yàn)證密碼，錯誤的密碼又影響文件系統(tǒng)的修復(fù)操作，相互的制約使虛機(jī)承載的業(yè)務(wù)遲遲得不到恢復(fù)。救援模式從獨(dú)立的內(nèi)存環(huán)境中掛載文件系統(tǒng)，遺憾未能找到恰當(dāng)?shù)男迯?fù)文件系統(tǒng)的辦法，但密碼的重置也使問題的破解有了可操作性。

回顧整個問題，重置密碼和修復(fù)文件系統(tǒng)都還是問題的表象，存儲系統(tǒng)的重要性不言而喻，每個虛機(jī)根據(jù)業(yè)務(wù)屬性的不同，合理選擇writethrough和write-back兩種Cache寫機(jī)制，以期盡可能避免問題復(fù)雜度的提升。