存储双活（Active-Active）架构在企业数据中心里越来越常见。理论上它应该提供自动故障切换，但实际上——配置不当的话，出问题时不但不切换，还会脑裂（Split-Brain），让业务直接停摆。

这篇文章记录一次真实的华为 OceanStor 双活脑裂处理过程。不是理论推演，是现场踩坑后的复盘。

故障现象

某医院核心业务系统（HIS + PACS）使用两台华为 OceanStor 5500 V5 做双活，仲裁服务器采用第三方机房部署。

故障当时的表现：

1. HIS 系统无法写入，医生工作站提示数据库连接失败
2. 存储管理界面显示双活 Pair 状态为 Split（脑裂）
3. 仲裁服务器网络通畅，但仲裁没有生效
4. 两个存储节点均可管理，但 LUN 在各自节点上均为只读

排查过程

第一步：确认仲裁状态

首先检查仲裁链路和状态：

# 在存储 CLI 中查看仲裁状态
admin:/> show split_arbitrator_status

输出显示仲裁服务器可达，但仲裁机制未触发。原因是脑裂时两个节点都认为自己持有最新数据，仲裁也无法裁决——这就是典型的仲裁配置不当导致脑裂无法自愈。

华为双活仲裁的正确配置要求仲裁心跳和存储心跳在不同网络平面上。现场排查发现两个存储节点的心跳链路和仲裁链路混用了同一块物理网卡，导致脑裂时心跳同时中断，仲裁失去了判断依据。

第二步：确认数据一致性

脑裂最怕数据不一致。在强制恢复前必须确认主备数据一致：

1. 将其中一个存储节点降级为 Standalone 模式
2. 记录降级时的数据版本号（LUN Generation）
3. 登录备节点检查差异化数据（主要是 IO 落盘时序差异）

这一步操作了大约 40 分钟。如果发现数据不一致，需要走数据回滚流程，不能直接拉起。

第三步：判断主节点

确定哪台是主节点（即业务在故障前正常写入的那台）：

• 检查两个节点上业务 LUN 的修改时间
• 对比 IO 统计信息中的 Read/Write 计数
• 检查数据库日志中最后的提交记录

确认主节点后，将主节点配置为 Active，备节点做数据同步。

第四步：恢复业务

执行强制接管：

# 主节点接管所有 LUN
admin:/> change lun_migration master_lun_id=xxx target_node=0A

# 将业务存储映射到计算节点
admin:/> add host_attach host=HIS_HOST lun=xxx

# 重新检查双活配置
admin:/> show consistency_group status

至此业务恢复。HIS 系统验证正常后通知院方上线。整个过程从接到电话到业务恢复，大约 1 小时 20 分钟。

根本原因分析

• 根因一： 双活心跳链路和仲裁链路未隔离。两路心跳必须走不同物理接口/网段
• 根因二： 仲裁超时参数配置为默认值，未根据实际网络延迟优化
• 根因三： 原厂交付后未做脑裂场景的容灾演练