存储坏了一块板，业务没停，但整个系统变慢了一百倍

—

料号：00Y5860 / 00RY384（IBM Storwize V5000 节点控制器）

八月初的一个下午，某数据中心的报障电话打过来，描述得很含糊：

「系统没断，但特别慢。」

存储在线，卷都在，主机能读能写，没有任何业务中断告警。可前台点一下要等好几秒，数据库那边队列越排越长。

查主机、查多路径、查交换机、查数据库执行计划——一圈下来什么都没查出来。

最后有人去机房看了一眼存储柜：两块节点控制器，其中一块亮着故障灯。

为什么少一块控制器，会慢一百倍

V5000 的控制柜里有两块节点控制器，双活。设计上坏一块业务不中断——这没错，业务确实没中断。

但还有一半的故事：

写数据进来的时候，为了保证掉电或者单点故障时不丢数据，写缓存必须在两块控制器之间做镜像。一份写在本节点，一份镜像到伙伴节点，两边都落定了才告诉主机「写完了」。

现在一块控制器下线了，镜像做不了。系统不可能拿只有一份、没有冗余的脏数据去冒险，所以它做了一个保守的选择：

直接关掉写缓存，每个写操作直接落到后端磁盘，落完才返回。

于是写延迟不再由内存决定，而是由硬盘决定。亚毫秒变成几十毫秒——一百倍的差距就是这么来的。

这不是故障扩散，是设计使然。系统在用性能换数据安全。

此时冗余已经归零。剩下那块控制器再出问题，业务就真的停了。

所以单控运行状态必须按小时计算响应时效，不能按天。很多人被「业务还在跑」麻痹，把它当成一个不紧急的工单——那是在裸奔。

一、备件基本都不含电池。 市面流通的 00Y5860 绝大多数是裸 canister，商品标题里常常直接写着 without Battery。V5000 的控制器里有独立电池负责掉电保护缓存。是裸件的话，现场就要把旧件上的电池拆下来移装——这一步不提前确认，人和件都到了机房，活干不下去。

二、固件版本要对得上。 新控制器插进去，如果代码级别和在线那块不一致，它不会直接上线，而是停在服务状态等待。正常机制是由在线的伙伴节点把系统软件推给它，自动同步。这个过程需要时间，别以为插上几分钟没上线就是备件坏了。

三、这条是好消息：系统身份不在控制器里。 WWNN 和集群配置存放在控制柜的背板上。换一块新控制器，它会从机框读取身份，主机侧看到的 WWNN 不变——不需要重做集群配置，也不需要在主机侧重新分区。这能省掉大量协调成本。

任何情况下，不能把两块节点控制器同时拔出来。

剩下那块是此刻唯一在跑业务的节点。这句话看着像废话，但在两块都需要检查的时候，是真的有人会犯。

监控要监控「性能」，不只监控「可用性」。

只监控存储在不在线，这类故障会被完全漏掉——它一直在线。应该同时监控卷的写延迟和缓存状态，延迟突变本身就是最灵敏的告警。

文中的架构行为依据 IBM Storwize V5000 的公开资料整理；具体到某台设备的节点错误码和处理动作，请以现场服务助手里读到的实际信息为准。案例细节做过合并与匿名化处理。

手上有 V5000 相关料号需要核对配置或库存的，可以直接留料号。