走出存储错误管理的困境 让工作生活更轻松

现在厂商和开源社区推出了很多可以从数据路径的各个方面解决SNMP数据集的产品套件，从HBA到存储设备。

而且目前许多存储设备都支持由存储网络行业协会（Storage Networking Industry Association，SNIA）制订的存储管理技术规格（Storage Management Initiative ifition，SMI-S）

我一直有一个疑问，是否这些管理技术可以满足有所存储管理者的需求？随着我遇到的存储难题越来越多，加上与用户和合作伙伴之间的交流，我发现这个问题的答案完全是否定的。

网络错误管理架构和错误功能性在不同规格下（例如ICMP、IP、TCP、SONET以及以太网等等）发展到成熟阶段以满足更多需求经历了数十年的时间。SNMP 1.0自1991年5月就已经推出了，它是由RFC执行的——一项标准TF执行方法。

那么缺少了什么？就我个人来看，我认为数据路径的错误管理架构缺失了两大重要因素：

·对存储设备内部情况的全面了解

·对从每个连接的渠道错误率的详细信息

存储设备错误的详细信息

对磁盘和磁带驱动器的错误信息细节实际上是可以追踪到的。对于磁带驱动器来说，针对驱动器的错误信息被保留下来，这样实际上我们是可以追踪到错误条件信息的。不过这两种情况并非表面看上去那么简单，那么就让我们来看一看磁带和磁盘的这两种情况。

磁带

所有磁带驱动器都有磁道错误，就像任何一种硬件设备一样。除此之外，所有磁带都有错误和生命期限（life span）。当你使用的磁带接近生命期限快要结束的时候，你可能就会遇到更多的错误。这些错误起初大多是“软错误”，然后逐渐演变成“硬错误”，也就是说，最终你甚至无法读取数据。那么你如何找到这些错误，并在“软错误”转变成“硬错误”之前将其化解？

当然，这做起来要比说起来难得多。磁带错误数据是由驱动器决定的。你需要做的就是将一种被称为通过指令的特殊SCSI指令发送到驱动器，这是一种低层级驱动器指令，驱动器可以在SCSI通过指令的请求下报告错误信息。当数据被收集的时候，错误信息也可以被驱动器和驱动器中的磁带盒收集起来，所以这些错误以及用于收集LTO驱动器错误数据的指令要不同于 T10000磁带驱动器上的错误和指令的。

这是非常复杂的，而且对于一些磁带驱动器和磁带库来说，这是没有证明文件的，所以有时候你需要一项未公布的协议来获取磁带驱动器和磁带库的信息和不同错误的位置。这对于软件产品来说实际上是一个机会，不少厂商都有可以为不同类型磁带驱动器设备收集和提供这些数据信息的产品。这些产品具有不同的功能特性以及显示数据的方式。有些产品在大型环境下比其他产品具有更好的可扩展性，但是你可以有多种选择。你检查环境中的“软错误”过程中，这些产品是有很大帮助作用的，这些产品可以帮助你在这些磁带、驱动器和设备的软错误转变成硬错误之前将其解决掉。

那么这其中还存在什么问题吗？这些产品集成到了其他环境下的错误管理架构中了吗？与一些SNMP警报相比，从单一管理架构中获得这些数据并非易事。

磁盘

谈到磁盘硬件监控，你也将面临类似的难题。磁盘有一个错误值的指令集，它可以通过SMART技术收集和定义。如果你有JBOD或者低端RAID的话，你就可以购买这种套件来收集这些SMART数据。

那么那些拥有来自不同厂商的大型RAID系统的人怎么办？所有这些厂商都根据他们从驱动器厂商那里收集来的信息以及他们自己多年积累下来的数据信息实现对SMART数据的监控以及预先检测出可能发生故障的驱动器，出于某些对性能有具体要求的情况，一些厂商选择更换驱动器，而不会接受重新尝试低性能的产品，尤其是一些使用SATA驱动器的厂商。所有这些都很好，但是你却无法详细了解其中的信息，所有这些都是向RAID控制器中完成和管理的，你看不到其中任何情况。

因此我们再次提出，这其中存在什么问题？我有一些问题和担心。

·正如弗朗西斯·培根所说，知识就是力量。我希望了解RAID控制器内发生的什么、其中作出了怎样的决策、为什么会发生磁盘驱动器故障。

·在过去10年时间内，我很多次看到一个现象——尤其是在新驱动器产品发布的时候，驱动器的故障率是很高的。如果我之前了解到一些相关数据的话，也许我对厂商提供的这些故障率有一些心理准备了（当然，他们是不希望让我知道的）。

·没有一个错误信息被集成到了这种环境中，所有我能获取到的也许就是一些SNMP警报或者一些访问RAID控制器的细节信息。

出于这些原因，我更愿意让RAID厂商为我提供一些表面之下的深层数据信息，这样我就可以作出更好的决策。问题是，你如何在一个企业监控架构之下获得所有这些数据？答案是：并不容易。

通道错误率

光纤通道和其他许多技术都有一个第10E12位的渠道错误率，但是通过纠错代码可以修正到一个更高的数字。就我所知，光纤通道已经被修正到大约第10E21位。这就意味着超过这个范围之外的错误或者不能被检测出来，或者被误修正。

但是我一直在想一个问题，如果通道被损坏的话会发生什么情况（参看文章：无形中的数据损失 何时突破技术局限？）。如果通道错误率是第10E12位，然后开始出现问题，这对第10E21的纠错率有怎样的影响、什么时候通道开始出现问题？那么第10E11或者第10E10的错误率呢？我还无法回答这些问题，至少是公开回答。不管数字是多少，纠错率在一个非线性环境下会有所降低。当然这方面我没有任何可以公开的信息，但是我可以说这也许是非常大幅度的降低，我估计大约是4到5个数量级。这就是为什么我希望收集这方面信息、能够将其与整个数据路径联系起来的原因。

实际上是有很多关于整个数据路径的错误数据和信息的，但问题是没有一种通用的方法来通过一个管理工具或者所有这些数据信息。我经常从使用一款工具到另一款工具来检测问题所在。随着存储环境变得越来越复杂，能够将所有数据路径错误、警报以及低层级数据联系到一起固然是件好事。SNMP警报就是这样，总是无法给你提供关于什么导致了警报的信息。也许我的问题太多了，但是将这些问题解决也许就能让许多人的工作生活更加轻松。