悲催的存储工程师 SAN故障经验的分享

一般来说，企业级主存储是相当稳定的，如果没有强壮的存储设备，就不能奢望应用程序可靠，它们本身就有一大堆问题，如果存储也闹别扭，事情只会变得更糟，这就是为什么企业愿意把大部分IT预算用于购买最好，最可靠的存储基础设施的原因。

冗余磁盘，冗余控制器，镜像缓存，以及冗余存储网络都旨在提供具备容错能力的存储基础设施，在关键任务环境中，这些都是必需的，但即使是最高强度的冗余存储架构在人面前也是毫无保障的。

在我接触过的企业存储设备中，只有一个没有因硬件故障导致灾难性后果，相反，我已经记不清有多少因文档糟糕、技术支持胡乱建议、培训不充分，以及软件或固件等原因导致存储灾难性故障，我想说的是，大部分都是人的原因造成的。

就在上个月，我就亲眼目睹了两起主存储崩溃事件。

在企业存储基础设施中，用户由两个独立的但同样重要的小组支持：设备小组和管理小组，故事就发生了他们中间。

固件版本不匹配

在第一起案例中，在现有存储环境中引入了新的存储设备，按照设想，新旧存储设备可以实现无缝整合，最终实现用新设备替换掉旧设备的目的。

由于新系统采用了最新的硬件，需要的固件版本比当前的旧系统要高，按正常情况，升级现有系统的固件版本，和新系统匹配是没有问题的，但它需要一个维护窗口。

根据相关文档的解释，这里使用的两个固件版本似乎可以共存，数据迁移可以平滑地从旧系统转移到新系统，因此数据转移工作就在两个固件版本不同的存储设备之间开始了。

起初，事情进展顺利，测试数据成功转移到了新设备，性能测试结果超出预期，没有发现任何问题，接下来，一些非关键的数据卷也成功迁移了，于是决定迁移所有的生产数据，由于数据量巨大，迁移过程花了几天时间才完成。

就在迁移完成大家终于松了一口气的时候(不到30分钟)，新存储设备(现在存储了组织的所有生产数据)从存储网络掉线了，变得完全不可访问，幸运的是，这事儿发生在周六早上，很少有用户注意到，但最终导致整个虚拟服务器基础设施无法使用。

重新给新设备加电后，它又返回到存储网络了，大家齐心协力花了几个小时将所有系统全部上线，最后还算幸运，数据未丢失，也未遭到破坏。

接下来的任务是找出究竟发生了什么，是新设备不可靠?难道有硬件或实施问题在测试期间未被发现?两周后，在厂家技术支持人员的帮助下，确定这起故障是两个设备因固件不匹配引起的，最后，厂家也修改了相关文档，建议任何时候应尽量将所有设备的固件版本升级为一致。

当然，在厂商提供的那些文档中，我们还是看到许多用词不明确的地方，给读者留下了许多想象的空间，从这个案例中我们总结出一个经验：文档不一定可靠，千万不要自以为是!

倒霉的现场技术人员

在第二个案例中，生产存储阵列开始出现一些瞬时错误，这些错误似乎表明后端光纤通道循环出了问题，由于所有系统在控制器和磁盘之间的连接使用了多个冗余循环，不能立即确定究竟是哪里出了问题，但对进一步调查和修复行动提供了保证。

这个阵列签订了高级支持合同，因此厂商很快就派遣了一位技术人员抵达现场，确定问题的根源，这位技术人员到了现场就立即投入到工作中，首先阅读了系统日志，并对硬件做了简单检查，看了看各种线缆和收发器是否连接正确。

但他什么问题也没有发现，于是，他插上一根串口线，接到设备的维护端口，在管理软件中发出特定的命令，直接从控制器导出了原始性能数据，其目的是让控制器吐出详细的错误信息，以便更高级的工程师解码分析。

串口和控制器的软件内核是直接相通的，输错一个字符就可能引起严重的后果，在这种情况下，如果你在终端模拟器按下Ctrl-Z，会导致两个冗余控制器同时重启，所有入站存储连接会被突然重置，会发生什么只有求佛主保佑。

仔细看看你的键盘，你会发现Ctrl和Z键隔得并不远，如果事先不知道同时按下它们后果有多严重，或一不小心误按，我想你会一辈子记得这事的。

和第一起案例一样，幸亏中断时间不长，也没有导致数据丢失或破坏，但还是花了几个小时才将各种应用程序重新上线。

教训

事后看来，不管文档上有没有明确说明，在固件不匹配的情况下做任何事情都是自找麻烦，此外，在处理大量数据迁移时不能掉以轻心，想一边喝咖啡一边操作还得悠着点。

也许你从来没有想过一个完全冗余的企业级存储网络还会全部宕掉，是的，这种事情虽然很少见，但的确发生过。在众多存储事故中，我发现大部分都是人为因素造成的，有可能就是你，或你的同事，也可能是新进入的厂商。

各路存储厂商都在努力让自己的管理系统变得更具吸引力，更友好的管理界面，但他们忽略了天天摆弄这些软件和硬件的IT人员，软硬件环境越来越复杂，谁也不能保证不会出现误操作。

除了厂商要做好严格的保护设计，文档实时更新外，作为用户一方，也要加强自身维护队伍的建设，在不确定会引起什么后果之前，最好不要急着动手。

原文出处：http://www.infoworld.com/d/data-explosion/tale-two-san-failures-224

原文名：A tale of two SAN failures

作者：Matt Prigge

微信扫一扫实时了解行业动态

微信扫一扫分享本文给好友