PC伺服器硬碟故障處理

1. 寫在前頭

2. 簡介

3. 硬碟故障處理流程

3.1 故障定位及分析

3.1.1 名詞解釋

3.1.2 收集日志及陣列穿孔

3.1.3 檢視實體磁盤資訊

3.1.4 實體磁盤故障分析

3.1.5 檢視磁盤陣列資訊

3.1.6 磁盤陣列故障分析

3.2 業務定位

3.3 裝置定位

3.4 故障處理

标簽：PC伺服器, 硬碟故障

一直以來都想寫一些關于伺服器硬碟維護的文檔，但是由于各種原因，就一直擱置了。而且還有一個原因，我這國文不及格呢，語言該怎麼組織？還想着找度娘學習借鑒一下高人寫的文檔，可惜都沒找到我想要的，好吧不多扯，進入正題吧

大資料時代，如何保證資料安全性，顯得更加重要。從簡單的定期備份，到備份系統、到災備解決方案等等，都是為了確定資料安全。而不論何種方案，都必須将資料存放在底層的實體裝置（硬碟、錄音帶等），今天我們主要講伺服器硬碟故障時該如何維護。

一直以來都在一線處理各類裝置故障，我把硬碟的故障流程整理成如下五個步驟，四個都缺一不可。

故障定位及分析

業務定位

裝置定位

故障處理

<code>- DSA ：IBM日志收集工具</code>

<code>- DSET ：DELL日志收集工具</code>

<code>- TTY ：硬碟日志收集工具</code>

<code>- Slot Number ：伺服器硬碟槽位号，dell/IBM伺服器槽位号從O開始</code>

<code>- Media Error Count：硬碟實體錯誤數</code>

<code>- Other Error Count：硬碟邏輯錯誤數</code>

<code>- Predictive Failure Count：預告警數</code>

<code>- Raw Size：磁盤容量</code>

<code>- PD Type: 磁盤類型（SAS,STAT)</code>

<code>- Firmware state:硬碟狀态</code>

<code>- RAID Level ：陣列等級</code>

<code>- State ：陣列狀态</code>

不僅僅是硬碟故障的時候需要收集日志，在伺服器診斷中，線索往往是撲所迷離的，憑借經驗或者猜測，無法正确地判斷裝置故障原因，排除故障，收集日志送出給售後工程師，可以快速和有效的縮小問題範圍，精準定位故障點。

伺服器出現故障後，必須一步步檢測解決，走捷徑可能會付出巨大的代價！收集日志可以大大減少資料丢失風險，避免多次上門維修，反複溝通造成的時間和精力浪費。

好吧估計名眼人一看就知道，上面的這兩段文字不是我自己寫的，因為我國文不及格嘛，其實是從DELL的微信公衆号（公衆号：戴爾服務解碼）文章中抄來的，目的僅僅是為了讓大家知道收集日志的重要性！當然過保的機器，就需要我們自己學會檢視日志檔案了。

DSA日志

<code>DSA日志是IBM機器保修時候，必要的日志，他可以收集所有的硬體健康狀态日志，這裡不多做介紹，隻要一個檔案在系統裡執行完成後可以順利收到日志</code>

DSET日志

<code>DSET日志是DELL機器保修時候，必要的日志，功能如同DSA日志，DSET日志可以收集所有硬體健康狀态日志，還可以收集到硬體的部件号，售後可以根據部件号來确認故障配件是否屬于本機原配，若不是原配配件，則需要另外提供采購的配件訂單号。</code>

TTY日志

接到伺服器硬碟告警後要怎麼做呢？（至于，如何做硬碟監控，以後有機會再講），當然是直接上伺服器确認故障啦，使用MegaCli64工具就可以了(SAS 5/i，SAS 6/i陣列卡使用lsiutil工具，這裡不做介紹咯）

MegaCli64工具安裝

<code>#rpm -i Lib_Utils-1.00-09.noarch.rpm</code>

<code>#rpm -i MegaCli-8.02.21-1.noarch.rpm</code>

如下為MegaCli64工具檢視實體磁盤資訊的輸出結果

Media Error Count&gt;10

<code>這裡為什麼定位數字10呢,因為IBM的機器中，Media Error Count&gt;10就當做是硬碟故障啦，可以直接收集DSA日志，找IBM售後處理了</code>

Other Error Count&gt;0

<code>這個Other Error Count就是真的沒啥用處了，因為不論是DELL還是IBM都不認這個東東，數值再大，沒其他的告警出現，都不會當回事的，但是在IBM的機器上，這個坑爹的東東有時候就會莫名其妙的突然暴漲，解決辦法隻有一個，就是自己更新陣列卡微碼和硬碟微碼後重新開機，至于怎麼更新微碼，這裡就不多贅述咯</code>

Predictive Failure Count&gt;0

<code>這個預告警就要重點關注了，因為不論是DELL還是IBM，隻要出現這個告警，肯定是硬碟已經出現故障了，這個時候各自收集日志保修吧</code>

Firmware state 

固件狀态，這裡講幾種固件狀态，需要特别關注Failed， Unconfigured(bad)

使用MegaCli64工具檢視磁盤陣列資訊

當你根據實體磁盤故障分析，确認目前伺服器上已經存在硬碟故障了，那還需要确認磁盤陣列才能夠确認是否能夠進行實體硬碟的更換

State: Optimal狀态下

<code>并不是Optimal狀态下，就說明該機器上就沒有磁盤故障了，因為有的機器有熱備盤，硬碟故障後，熱備盤會直接進入rebulid狀态（重建狀态中，陣列等級是Degraded），rebulid完成後，陣列狀态恢複正常，但是實體磁盤還會有故障提示，此時就要處理實體磁盤</code>

State: Degraded

陣列進入降級狀态，就能直接處理硬碟了嗎？當然不是咯，還需要配合陣列等級的哦，當陣列進入降級狀态，不同的陣列等級下我們都改如何處置

<code>RAID 10： 在raid10中，最多允許N/2塊硬碟故障，但是前提是這N/2塊故障盤必須是分布在不同的raid1上的</code>

<code>RAID 5 :  在raid5中，最多允許1塊硬碟故障，當然如果你的機器中有熱備盤的話，最多可以允許熱背叛數量+1塊盤故障</code>

<code>RAID 0 ： 在raid0中，你的硬碟挂了，那就死翹翹咯，換盤就以為這這塊硬碟裡的資料會丢失，祈禱你有做資料備份吧（當然也有冒險的辦法，這裡不講咯）</code>

根據故障定位分析，你還是不能直接更換故障硬碟，因為換硬碟都會存在風險的，是以，在做所有的故障硬碟更換之前，都必須确認好業務，特别是在RAID0的時候！RAID0的硬碟出現故障，隻要資料有備份，業務确認可以更換，那就可以直接處理

裝置定位，其實就是确認裝置的實體位置，機房、機櫃、機架位、故障硬碟槽位

當經過上述的故障分析、定位，業務定位，裝置定位後，就可以直接現場更換故障硬碟了，當然可能還有其他的細節問題，比如IDC機房人員進出權限問題（IDC機房需要工單才能正常進出），故障硬碟型号問題（尺寸、容量、轉速等）……