一直以來，我都在想這樣一個(gè)問題：這些管理接口是否滿足存儲管理員的所有需求?我碰到的及從客戶和同事那聽到的這類問題越多，我對這個(gè)問題的答案就更趨向“No”。
經(jīng)歷了幾十年時(shí)間，網(wǎng)絡(luò)錯(cuò)誤管理框架以及各個(gè)不同堆棧(如ICMP—網(wǎng)絡(luò)控制信息協(xié)議，IP，TCP，SONET—同步光纖網(wǎng)，以太網(wǎng)等)中的錯(cuò)誤功能才得以成熟并滿足各種要求。SNMP 1.0從1991年五月就已經(jīng)問世，并通過RFC(請求注解—Request For Comments)部署—RFC是IETF(互聯(lián)網(wǎng)工程任務(wù)組)的標(biāo)準(zhǔn)部署方式。
那么問題出在哪里呢?我認(rèn)為數(shù)據(jù)通路的錯(cuò)誤管理框架遺漏了以下兩個(gè)重要因素：
● 關(guān)于存儲設(shè)備的詳細(xì)分析
● 關(guān)于每個(gè)連接的信道誤碼率的詳細(xì)信息
存儲設(shè)備錯(cuò)誤細(xì)節(jié)
實(shí)際上，磁盤和磁帶驅(qū)動器的錯(cuò)誤信息的細(xì)節(jié)都得到了跟蹤。如果你有時(shí)間，你可以看看關(guān)于閃存驅(qū)動器的一篇文章來了解磁盤驅(qū)動器上所使用的SMART(自我監(jiān)測、分析和報(bào)告))技術(shù)的背景知識。對于磁帶驅(qū)動器來說，驅(qū)動器的錯(cuò)誤信息得到保存，而且磁帶盒的錯(cuò)誤信息也保存在驅(qū)動器內(nèi)，因此你才有可能跟蹤錯(cuò)誤條件。但是，這兩種情況所引發(fā)的問題實(shí)際上并不像一開始那么簡單。讓我們分別來看看磁帶和磁盤。
磁帶
就像所有其他硬件設(shè)備一樣，所有的磁帶驅(qū)動器都會跟蹤錯(cuò)誤。此外，所有的磁帶都會產(chǎn)生錯(cuò)誤和并且存在一個(gè)使用壽命。隨著你的磁帶越來越接近使用壽命，它很可能會產(chǎn)生越來越多的錯(cuò)誤。這些錯(cuò)誤大部分是軟錯(cuò)誤，最終，它們會變成硬錯(cuò)誤，這也就意味著你無法讀取你的數(shù)據(jù)了。因此如何發(fā)現(xiàn)這些錯(cuò)誤，并在它們變成硬錯(cuò)誤之前就解決這些軟錯(cuò)誤問題呢?
當(dāng)然，說起來容易做起來難。磁帶錯(cuò)誤統(tǒng)計(jì)數(shù)據(jù)是依賴于驅(qū)動器的。你必須做到的就是能夠發(fā)送一個(gè)叫做pass-through的特殊SCSI(小型計(jì)算機(jī)系統(tǒng)接口)命令到驅(qū)動器。這是一個(gè)低層次的驅(qū)動器命令，從而使得驅(qū)動器可以在SCSI pass-through命令下將你所要求的錯(cuò)誤信息報(bào)告給你。當(dāng)搜集信息時(shí)，無論是驅(qū)動器的錯(cuò)誤信息，還是驅(qū)動器磁帶盒的錯(cuò)誤信息都可以被搜集到，因此一個(gè)LTO(線性開放協(xié)議)驅(qū)動器的錯(cuò)誤以及搜集錯(cuò)誤統(tǒng)計(jì)數(shù)據(jù)的命令可能會不同于一個(gè)Sun T10000磁帶驅(qū)動器。
這確實(shí)相當(dāng)復(fù)雜，對于一些磁帶驅(qū)動器和磁帶庫來說，這種情況沒有顯示在文檔上，而有些時(shí)候你必須有一個(gè)保密協(xié)議才能理解其含義并得到磁帶驅(qū)動器和磁帶庫的不同錯(cuò)誤的地址。很顯然，對于軟件產(chǎn)品來說，這是一個(gè)機(jī)遇，而且很多廠商都已經(jīng)推出一些產(chǎn)品來搜集并顯示不同磁帶庫和磁帶機(jī)中的這類數(shù)據(jù)。這些產(chǎn)品各有不同的功能以及顯示方式。其中一些產(chǎn)品在大型環(huán)境下能夠比其他同類產(chǎn)品更好地?cái)U(kuò)展，但是你有很多選擇。這些產(chǎn)品能夠極大地幫助你理解環(huán)境中的軟錯(cuò)誤，而且它們還可以幫助你積極主動地解決磁帶、驅(qū)動器以及磁帶機(jī)中的這些軟錯(cuò)誤，以防止它們變成硬錯(cuò)誤。在大型環(huán)境中使用這些產(chǎn)品是非常重要的。
那么這里會存在什么問題嗎?這些產(chǎn)品是否能夠整合到環(huán)境中其他部分的錯(cuò)誤管理框架中去?和SNMP警告不同，讓數(shù)據(jù)融入單一的管理框架并不是一件簡單的事。
磁盤
在磁盤硬件監(jiān)測上，你也有類似的問題。磁盤存在一個(gè)通用的錯(cuò)誤值集合，這些錯(cuò)誤值由SMART技術(shù)予以定義并加以搜集。如果你有JBOD(簡單磁盤捆綁)或者低端的RAID(獨(dú)立磁盤冗余陣列)，那么你可以購買一個(gè)軟件包來幫助你搜集SMART數(shù)據(jù)。
那么對于我們這些擁有來自大型廠商的大型RAID系統(tǒng)的用戶來說又會怎樣呢?所有這些廠商都會監(jiān)測SMART統(tǒng)計(jì)數(shù)據(jù)，并根據(jù)它們所搜集的來自驅(qū)動器廠商的信息、歷年來所搜集的統(tǒng)計(jì)信息，以及某些情況下的性能要求，來主動地停止驅(qū)動器的運(yùn)作，比如一些廠商會選擇替換驅(qū)動器而不是選擇重試低性能的驅(qū)動器。對于一些使用SATA(串行ATA)驅(qū)動器的廠商來說，尤其如此。所有這些都很好，但是你對此毫無所知，因?yàn)樗羞@些都是由RAID控制器來完成和管理的，你根本就看不到它們。
因此，我還在想，這種情況會不會有什么問題?我覺得是有一些問題和值得擔(dān)憂的地方。
● 就像培根先生所說的那樣，知識就是力量。我想知道RAID控制器里所發(fā)生的事情，決策是如何做出的，以及為什么磁盤控制器會出現(xiàn)故障。
● RAID廠商們在看到一些情況后一般會怎么做呢?在過去的10年中，我看到了很多次故障率非常高的情況，特別是在新驅(qū)動器的早期發(fā)布上。如果我早知道這些統(tǒng)計(jì)數(shù)據(jù)，我就可以更加積極主動地和廠商溝通這些故障(當(dāng)然，他們很可能不想讓我知道)。
● 錯(cuò)誤信息都沒有被整合到環(huán)境中去，而我所能獲得的就是一些SNMP警告，或者如果登錄到RAID控制器本身，我可能會得到更多的細(xì)節(jié)。
因此，基于這些理由，我非常希望RAID廠商能夠提供關(guān)于他們底層所做的事情方面的數(shù)據(jù)，這樣我可以做出更好的決策。問題是你如何讓所有這些信息都進(jìn)入到企業(yè)監(jiān)測框架中去呢?答案是：不容易。
信道誤碼率
光纖通道和一些其他技術(shù)有10E12th比特的信道誤碼率，但是通過錯(cuò)誤糾正代碼，可以獲得更高的正確率。就我所聞而言，光纖通道的誤碼率可以糾正到大約10E21st比特。也就是說，在每10E21st比特的信息中可能會因?yàn)闆]有將一個(gè)誤碼監(jiān)測為誤碼，或者因?yàn)殄e(cuò)誤地糾正一個(gè)誤碼而得到一個(gè)誤碼。
這個(gè)比特?cái)?shù)很高，這是一件好事，但是一直以來我所面臨的問題是：如果信道開始衰減(見《當(dāng)比特變壞》)那么會發(fā)生什么?如果誤碼率為10E12th的信道開始衰減，那么會如何影響10E21st的誤碼糾錯(cuò)率，而信道會何時(shí)開始衰減?如果誤碼率為10E11th或者10E10th時(shí)又如何呢?至少，我還沒有從公開的渠道中獲得任何答案。無論是什么數(shù)字，誤碼糾錯(cuò)率都會以非線性的形式急速下降。在這個(gè)領(lǐng)域中，我還是沒有發(fā)現(xiàn)公開的答案，但我自己估計(jì)，大概會以4到5倍的數(shù)量級下降。這也就是我為什么希望搜集這種類型的錯(cuò)誤信息的原因，因?yàn)檫@樣我就可以對整個(gè)數(shù)據(jù)通路進(jìn)行相關(guān)分析。
實(shí)際上，在整個(gè)數(shù)據(jù)通路上，都可以得到很多的錯(cuò)誤統(tǒng)計(jì)數(shù)據(jù)和信息，問題是沒有一個(gè)統(tǒng)一的管理工具來獲得所有這些信息。我經(jīng)常要利用很多工具和腳本來確定問題所在并進(jìn)行相關(guān)分析。隨著存儲環(huán)境越來越復(fù)雜，將低層次數(shù)據(jù)、所有的數(shù)據(jù)通路錯(cuò)誤以及警告聯(lián)系起來肯定是一件非常好的事情。SNMP警告則僅僅是警告，因?yàn)閹缀跞魏螘r(shí)候，它們都不會提供足夠的信息來告訴你是因?yàn)槭裁丛驅(qū)е铝司妗Ｒ苍S我問得太多了，但是如果這個(gè)問題得到了解決，那么肯定會有很多人從中受益。
