验证要证明的三件事
多路径切换验证不是「把线拔了看还活不活」，而要拿出三个可复现的结论：一条路径故障时 I/O 是否被剩余路径无缝接管、切换过程对上层 I/O 的影响有多大、故障路径恢复后能否自动回到可用状态。验证范围要覆盖主机 HBA 端口、光纤跳线、交换机端口、存储前端端口整条链路，只测其中一环不足以支撑生产结论。
基本信息
| 适用平台 | Linux dm-multipath、Windows MPIO、AIX MPIO、ESXi NMP |
|---|---|
| 前置条件 | 同一 LUN 至少两条来自不同 fabric、不同交换机、不同存储控制器的路径 |
| 观测点 | multipath -ll / mpclaim -s -d、iostat 延迟、应用超时日志 |
| 断链手段 | 交换机端口禁用、拔纤、HBA 端口禁用、多路径软件屏蔽单路径 |
| 权限要求 | 主机 root/管理员 + 交换机管理员，需在变更窗口内执行 |
典型使用场景
- 新主机接入存储后的上线前基线验证，确认冗余路径真实可用
- 交换机固件升级、HBA 驱动更新后的回归验证
- 双活或容灾演练中，验证单控制器、单 fabric 失效时业务不中断
- 故障复盘：确认当时确实发生过切换以及切换耗时
- 扩容新增控制器或前端端口后，确认新路径已被主机识别并参与负载
受控验证流程
受控验证流程
# 1) 记录基线：路径数、每路径对应的 HBA 通道与状态
multipath -ll mpatha | grep -E 'status=|sd[a-z]+'
# 2) 后台持续读 I/O，观察切换期延迟与错误
fio --name=verify --filename=/dev/mapper/mpatha --direct=1 --rw=randread --bs=8k --iodepth=32 --time_based --runtime=600
# 3) 交换机侧禁用一条路径的端口，比拔纤更可控、更易回滚
portdisable 3
# 4) 确认剩余路径仍为 active，应用 I/O 未中断
multipath -ll mpatha
# 5) 恢复端口并确认路径自动回到 active ready
portenable 3 && multipath -ll mpatha输出逐列读法
| 字段 | 含义 | 正常/异常 |
|---|---|---|
| 路径状态 | active ready running 表示路径可用 | failed faulty 表示链路或登录异常 |
| 相邻设备名 | sdX 及其 hostX 通道 | 两条路径落在同一 HBA 端口即为假冗余 |
| dm-X | 内核映射设备，应用访问入口 | multipath 有记录但 dmsetup 无映射说明未生效 |
| prio | ALUA 优先级，优化路径最高 | 全部路径 prio 相同且阵列支持 ALUA 说明未识别 |
| path group | 路径组数量对应控制器或端口组 | 双控制器阵列只有 1 个 PG 说明另一控制器路径缺失 |
切换耗时由多路径参数决定：Linux 侧是 no_path_retry、fast_io_fail_tmo、dev_loss_tmo，Windows MPIO 侧是 PathVerificationPeriod 与 PDORemovePeriod，验证报告要把参数与实测耗时写在一起。
启用 queue_if_no_path 时，若所有路径同时失效且超过 no_path_retry 阈值，I/O 会一直排队，应用表现为无原因的卡死；演练必须包含「全部路径失效」的边界判断，并明确监控与人工干预方式。