走出存储错误管理的困境

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

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

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

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

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

·对存储设备内部情况的全面了解
·对从每个连接的渠道错误率的详细信息

存储设备错误的详细信息

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

磁带

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

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

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

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