有许多来自厂商和开放源代码社区的软件包能够解决SNMP（简单网络管理协议）数据搜集问题，这些数据可以来自所有的数据通路，包括从HBA（主机总线适配器）到存储设备。如今，有许多存储设备支持SMI-S，即存储网络行业协会（SNIA）所发展的存储管理计划规范。

　　长期以来，我一直有一个问题，即这些管理计划能否满足存储管理者所有的需求。我越是看我所面临的问题和我所听到的来自客户和同事的案例，我越是觉得答案是“不”。

　　人们花了几十年时间才让网络错误管理结构以及不同栈（ICMP——网络控制信息协议，IP，TCP，SONET——同步光纤网，以太网等）中的错误功能得以成熟并满足各种要求。SNMP 1.0从1991年五月就面世了，并通过RFC（请求注解）部署——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警告则仅仅是警告——它们几乎任何时候都不提供足够的信息来告诉你是因为什么原因导致了警告。也许我问得太多了，但是这个问题如果解决肯定能帮助许多人。

本文作者Henry Newman是国外专业存储网站的撰稿人，在高性能计算和存储行业从事了28年的顾问工作。