數(shù)據(jù)庫(kù)和存儲(chǔ)是密切相關(guān)的兩個(gè)IT組件，很多數(shù)據(jù)庫(kù)的問題有可能和存儲(chǔ)的問題相關(guān)。不過在IT運(yùn)維中，數(shù)據(jù)庫(kù)和存儲(chǔ)的運(yùn)維管理一般屬于兩個(gè)互相獨(dú)立的部門，因此二者的配合總是無(wú)法達(dá)到十分默契的程度。

數(shù)據(jù)庫(kù)出現(xiàn)IO問題的時(shí)候，DBA總是希望能把問題推諉給存儲(chǔ)，說是存儲(chǔ)的IO能力不行。而存儲(chǔ)專業(yè)后面已經(jīng)沒有背鍋俠了，所以沒辦法再往后推，只能選擇反擊，自證自己沒問題，問題一定出在數(shù)據(jù)庫(kù)本身或者前面的應(yīng)用。

存儲(chǔ)管理員一般會(huì)用一份DBA看的云山霧罩的報(bào)告來證明存儲(chǔ)本身沒有問題。DBA也因?yàn)閷I(yè)知識(shí)不夠豐富而往往只能接受這個(gè)問題，集中精力去找前端應(yīng)用的麻煩。這樣的例子在實(shí)際生活中比比皆是，不過這種情況存在，對(duì)于企業(yè)的IT運(yùn)維來說并不是一件好事情，很多這樣的隱患都被這種退位埋藏下來，等到爆發(fā)的那一天一定是一件大事。

幾年前遇到一個(gè)案例，客戶的系統(tǒng)中的5套數(shù)據(jù)庫(kù)突然依次宕機(jī)，后來重啟后系統(tǒng)恢復(fù)正常。從D-SMART的歷史數(shù)據(jù)看，存在大量的寫IO的延時(shí)異常問題。

從健康模型上看，這個(gè)問題實(shí)際上在宕機(jī)前就已經(jīng)比較嚴(yán)重了。IO存在十分嚴(yán)重的問題。通過工具進(jìn)行了一下IO診斷。

診斷工具分析后端存儲(chǔ)的IO性能存在問題。根據(jù)這種情況，我們認(rèn)為存儲(chǔ)的鏈路可能存在問題，報(bào)給客戶后，客戶也找存儲(chǔ)廠商過來檢查了一番。因?yàn)檫@件事發(fā)生在早上業(yè)務(wù)高峰，對(duì)企業(yè)的一個(gè)核心外網(wǎng)APP造成了嚴(yán)重的影響，因此大家都在推諉。存儲(chǔ)廠商堅(jiān)稱存儲(chǔ)絕對(duì)沒有問題，因?yàn)閿?shù)據(jù)重啟后系統(tǒng)都很正常。我們通過D-SMART觀察發(fā)現(xiàn)，數(shù)據(jù)看重啟后，寫IO的性能依然不是很正常，不過存儲(chǔ)廠家堅(jiān)稱沒問題。于是客戶也就只能找了幾條寫的不好的SQL，讓開發(fā)商整改了事了。

事后我和負(fù)責(zé)系統(tǒng)運(yùn)維的主管溝通了了一下，提醒他注意一下存儲(chǔ)的問題，我還是懷疑存儲(chǔ)的硬件或者SAN網(wǎng)絡(luò)的鏈路存在問題。不過那個(gè)哥們也沒太把我的話當(dāng)回事。一個(gè)多月后，同樣的問題在此發(fā)生。上面大領(lǐng)導(dǎo)震怒，于是開展了排查工作，最終發(fā)現(xiàn)了存儲(chǔ)中一條鏈路不穩(wěn)定的隱患。

正是因?yàn)榇鎯?chǔ)對(duì)于數(shù)據(jù)看來說十分重要，因此很多企業(yè)希望能夠打通這一壁壘，讓DBA也能十分直觀的看到存儲(chǔ)的情況。那么現(xiàn)在問題就來了，作為DBA，你想怎么去看存儲(chǔ)系統(tǒng)呢?

這是D-SMART的存儲(chǔ)的健康模型，作為一個(gè)從數(shù)據(jù)庫(kù)監(jiān)控發(fā)展起來的運(yùn)維工具，雖然現(xiàn)在D-SMART已經(jīng)支持了大量的非數(shù)據(jù)庫(kù)組件，不過這個(gè)系統(tǒng)的核心開發(fā)者是一群DBA，這種視角來看存儲(chǔ)絕對(duì)是和大多數(shù)存儲(chǔ)管理員不同的。硬件健康十分明確，任何軟硬件一體化的IT基礎(chǔ)設(shè)施的硬件健康是必須去監(jiān)控的。

這套存儲(chǔ)的硬件總體健康度還可以，不過有四個(gè)備電源出廠時(shí)間已經(jīng)超過5年，存在老化的隱患，如果這是一套十分重要的存儲(chǔ)系統(tǒng)，需要及時(shí)更換老化的備點(diǎn)，從而避免系統(tǒng)出問題。

當(dāng)然磁盤的健康狀態(tài)也是我們所關(guān)注的?，F(xiàn)在的中高端存儲(chǔ)系統(tǒng)的底層軟件做的很好，某塊磁盤故障雖然不會(huì)引起應(yīng)用的問題，不過磁盤故障后的磁盤組的REBUILD還是會(huì)引起一些IO性能問題的。如果業(yè)務(wù)高峰期的IO十分大，這種磁盤引起的故障很可能會(huì)引發(fā)應(yīng)用的性能問題。

在磁盤方面我們選取了一些經(jīng)過評(píng)估的指標(biāo)，磁盤健康分是對(duì)磁盤的SMART數(shù)據(jù)進(jìn)行綜合評(píng)估后的結(jié)果，有些高端存儲(chǔ)中也自帶評(píng)估值。另外容量、性能、負(fù)載等也是我們關(guān)注的磁盤的指標(biāo)。除了這些指標(biāo)之外，我們還需要根據(jù)以往DBA的經(jīng)驗(yàn)來構(gòu)建一些存儲(chǔ)的故障告警的模型，因?yàn)榇鎯?chǔ)系統(tǒng)十分復(fù)雜，某些硬件健康可能會(huì)帶來哪些后果，哪些可能會(huì)影響數(shù)據(jù)庫(kù)的健康，這些問題作為DBA實(shí)際上并不清楚。

基于上述原因，DBA監(jiān)控存儲(chǔ)系統(tǒng)，需要總結(jié)一系列的經(jīng)驗(yàn)，通過這些經(jīng)驗(yàn)來幫助我們發(fā)現(xiàn)存儲(chǔ)中存在的問題，否則DBA就會(huì)像一個(gè)土老帽一樣，在存儲(chǔ)工程師的厚厚的報(bào)告中敗下陣來。實(shí)際上，在絕大多數(shù)的IT運(yùn)維甩鍋行動(dòng)中，DBA很少能夠戰(zhàn)勝存儲(chǔ)管理員。

比如說，“如果控制器IO延時(shí)正常，某個(gè)主機(jī)延時(shí)異常，那么可能說明問題是在鏈路上”，這一點(diǎn)仔細(xì)想一想，任何一個(gè)DBA都能想清楚吧。實(shí)際上，存儲(chǔ)管理員很清楚這一點(diǎn)，不過他們不會(huì)告訴DBA，而是很可能會(huì)找個(gè)時(shí)間，偷偷的把有問題的鏈路找出來，然后換掉。另外如果出現(xiàn)“IO負(fù)載不高，但是存在大量轉(zhuǎn)速過高的風(fēng)扇”，那是不是意味著存儲(chǔ)存在隱患呢?

實(shí)際上，我們需要大量的積累類似的運(yùn)維經(jīng)驗(yàn)，從而可以從一些很可能存儲(chǔ)管理員都沒有意識(shí)到的現(xiàn)象中看出存儲(chǔ)可能存在的問題。如果DBA能夠掌握這些主動(dòng)，在這場(chǎng)運(yùn)維甩鍋大賽中，會(huì)占據(jù)主動(dòng)。

當(dāng)然，今天講的背鍋俠的事情大多數(shù)都是玩笑話，一個(gè)IT團(tuán)隊(duì)中，DBA和存儲(chǔ)管理員是協(xié)作最多的，他們緊密的配合才能讓我們的數(shù)據(jù)庫(kù)系統(tǒng)變得更為穩(wěn)定。而在一個(gè)企業(yè)中，能夠用DBA比較容易看懂的方式來監(jiān)控存儲(chǔ)系統(tǒng)，絕對(duì)是十分必要的。希望今天我分享的這些內(nèi)容會(huì)給大家?guī)硪恍﹩l(fā)。