伺服器硬體問題整理的一點總結

之前寫過一篇通過shell來監控磁碟壞塊的文章 http://blog.itpub.net/23718752/viewspace-1872978/
從使用情況來看，也確實發現了一些壞塊很多的問題，這也給我們的工作帶來一些清晰的指導。不過感覺對於硬體的監控還在隔靴搔癢，還有很多的監控不夠到位。或者太細感覺有些雞肋，或者太粗有感覺有些籠統。而且還有些問題還是說不清道不明。
比如前段時間碰到一個問題，白天剛做過磁碟巡檢，沒有發現任何壞塊，結果到晚上伺服器就崩了。也沒有任何的前兆，收到一條ICMP的報警之後，伺服器就徹底失去連線了。對於這種問題，我們可以肯定的是磁碟沒有壞塊，所以資料肯定是沒有丟，不過後續又做了確認，這個庫已經沒有業務在上面了，所以也算是僥倖逃過了一個忙碌而又糾結的恢復過程。之後我也在感慨，如果沒有備庫就是在耍流氓，而且感覺心裡真是不踏實，如果你知道了哪些問題，可能老得擔心，直到解決了才會心裡踏實一些。
而且我們也一起討論，發現一個比較奇怪的現象就是，很多伺服器奔潰的情況都出現在半夜的時候，剛好是我們睡得真香的時候，它這麼一折騰，我們一天都會沒精打采。恢復的好，恢復的快，還能再多睡一會，系統忙，系統非常重要，估計連帶的就是一大撥人了。如果細想，這個還是有一定的原因，可能還是在半夜的時候會有大量的備份和報表查詢，批處理之類的任務可能對系統資源也會使用率比較高，也會直接間接導致一些潛在的問題。
可能還有一些原因就是我們沒有發現針對性的硬體問題前兆，可能有些問題已經發生了很久，硬體監控的時候不一定能夠及時捕捉到，有些可能是硬體的某一部分出現了一些警告，可能也很容易被忽略。
為此，我覺得得負責看看環境，不能讓這種事情概率性的發生，至少應該能夠提前預防好，過年的時候也能心安理得一些。
因為手頭有一大撥機器的資源，於是就通過ILO的方式來檢視歷史的硬體情況。我就硬著頭皮整理了一下，雖然枯燥，但是整理完再來看看，發現還是有些感悟。
比如像下面的這個問題，
這臺伺服器是一臺MySQL的備庫伺服器，也是最近才移交到我手上，檢視歷史發現竟然已經開始有了主機板的警告了，那麼這臺備庫的伺服器看來還是很有可能出現問題。那麼如果在備庫上每天進行大批量的備份和查詢請求，那麼這臺伺服器還是比較脆弱的。

再來看一臺，可以發現這臺似乎最近都是正常的，很久以前看報錯細細，應該是電源壞了，然後近期raid卡電池看起來有一些警告資訊，至於以前的資訊是無法去求證了。但是所幸的是有電源恢復的記錄。

當然我發現了這麼一個警告。從告警來看，應該是硬碟直接壞掉了，但是從我之前的磁碟壞塊監控來看，是沒有發現存在磁碟壞塊的。

可見這個部分就是一個遺漏的地方。
原本是通過下面的命令來監控磁碟壞塊的。
/opt/MegaRAID/MegaCli/MegaCli64 -CfgDsply -a0|grep Error
但是如果通過下面的命令去查磁碟的狀態就會發現有一塊磁碟確實已經壞了。
#  /opt/MegaRAID/MegaCli/MegaCli64 -PDList -aALL|grep Firmware
Firmware state: Online, Spun Up
Device Firmware Level: DA07
Firmware state: Online, Spun Up
Device Firmware Level: DA07
Firmware state: Online, Spun Up
Device Firmware Level: DA07
Firmware state: Online, Spun Up
Device Firmware Level: DA07
Firmware state: Unconfigured(bad)
Device Firmware Level: DA07
Firmware state: Online, Spun Up
Device Firmware Level: DA07
Firmware state: Online, Spun Up
Device Firmware Level: DA07
Firmware state: Online, Spun Up
Device Firmware Level: DA07
多麼痛的領悟。帶著這種思路去檢視，發現我手頭還有幾個庫有著類似的問題，所以監控中也得把握好這個度，逐步完善吧。
當然磁碟的問題是一個，也發現了另外的一些其它的硬體問題，知道了這麼多的問題，趕緊得去好好搞搞災備了。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/23718752/viewspace-1972890/，如需轉載，請註明出處，否則將追究法律責任。