分区变更是 fabric 级事件
分区变更看起来只是改配置，实际是一次 fabric 级事件：激活 zone set 会重建名称服务视图并向主机发 RSCN，主机侧对应的 SCSI 设备可能被移除后重新加入，多路径会出现路径上下线。如果误删了在用的分区成员，正在运行的数据库或集群会因为 I/O 中断而挂起，部分集群软件在心跳盘不可见时会直接重启节点。变更本身不是问题，缺少基线与回滚边界才是问题。
基本信息
| 变更类型 | 新增 zone、修改成员、新建并激活 cfg、删除成员 |
|---|---|
| 影响范围 | 激活操作在 fabric 内生效并触发 RSCN，多台主机同时感知 |
| 典型现象 | 路径数变化、I/O 短暂排队、SCSI 设备被移除后重建 |
| 验证要点 | 分区生效状态、名称服务可见性、主机路径数与 LUN 数、业务读写 |
| 回滚方式 | 切回上一个 cfg 并重新激活（同样会触发 RSCN） |
| 推荐时机 | 业务低峰并有人值守，避免与其他存储变更叠加 |
变更验证清单
- 变更前归档 cfgshow 与交换机配置，并记录当前激活的 cfg 名称
- 主机侧留存 multipath 与 lsscsi 基线输出，便于逐项比对
- 先在一台主机或一个 zone 上验证，再推广到整组
- 激活后核对生效状态与激活项，确认定义已保存
- 主机侧重新扫描，确认路径数与 LUN 数回到预期
- 业务侧完成一次读写验证，再撤销临时回滚预案
从基线到验证的操作顺序
从基线到验证的操作顺序
# 1. 变更前留下主机侧基线
multipath -ll > /root/mp_before_$(date +%F).txt
lsscsi -t > /root/lsscsi_before_$(date +%F).txt
# 2. 变更前归档分区数据库（以 Brocade 为例）
cfgshow > /root/cfg_before_$(date +%F).txt
cfgactvshow # 记录当前激活的 cfg
# 3. 变更后保存并激活
cfgsave
cfgenable "CFG_PROD_NEW"
# 4. 交换机侧验证
cfgactvshow # 激活项是否为新 cfg
nsshow | head -20 # 名称服务是否稳定
# 5. 主机侧比对路径数
multipath -ll | grep -c running # 与基线数量是否一致风险动作与后果
| 风险动作 | 后果 | 规避方式 |
|---|---|---|
| 删除在用的 zone 成员 | 主机路径与 LUN 消失，业务 I/O 中断 | 先确认该成员没有在用路径，逐个 zone 修改 |
| 激活未保存的配置 | 重载设备后回退到旧配置，故障复现 | 先 cfgsave 再 cfgenable |
| cfg 名拼写错误 | 激活失败，仍在旧配置上运行 | 激活后用 cfgactvshow 确认 |
| 多台主机同时重扫 | 扫描风暴叠加业务压力 | 分批处理，避开业务高峰 |
Brocade 的激活是用新 cfg 整体替换当前生效分区，不是增量叠加；Cisco MDS 的模型是先改 zone 成员再激活 zone set。操作模型不同，具体命令以厂商文档为准。
主机路径数与分区不一致时，优先怀疑分区与激活状态，不要急着拔光纤；误拔光纤会把可回滚的配置问题变成需要现场处理的物理故障。