解决存储错误管理的困境

瓶客

很多来自厂商和开放源代码社区的软件包都能够解决SNMP(简单网络管理协议)数域集问题，这些数据可以来自所有的数据通路，包括从HBA(主机总线适配器)到存储设备。如今，很多存储设备都支持由存储网络工业协会(SNIA)开发的存储管理接口标准(SMI-S)。

　　一直以来，我都在想这样一个问题：这些管理接口是否满足存储管理员的所有需求?我碰到的及从客户和同事那听到的这类问题越多，我对这个问题的答案就更趋向“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警告则仅仅是警告，因为几乎任何时候，它们都不会提供足够的信息来告诉你是因为什么原因导致了警告。也许我问得太多了，但是如果这个问题得到了解决，那么肯定会有很多人从中受益。