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