3par +node to node rescue

基础概念
node-to-node rescue：集群内正常运行节点，通过节点私有互联以太网（Inter-node Link），把 3PAR OS 系统镜像同步到故障 / 新更换控制器，完成系统修复，是更换控制器最常用自动流程。
前提：仅集群内至少 1 台节点正常运行，依靠节点私有互联网卡传输系统文件；区别于 SP 救援（Service Processor 救援）。
一、rescue 失败高频根因（优先级排序）
1、节点私有互联链路故障（最高概率）
3PAR 节点之间内置私有互联网口（inter-node Ethernet），rescue 数据流走这条链路：
故障现象：新节点上电，无法和存活节点建立 rescue 通信；rescue 反复超时失败。
排查：
1）检查背板 midplane 物理接触、控制器是否完全插紧、扳手锁死；
2）更换控制器槽位交叉测试；
3）串口接入故障节点，观察 Whack 启动日志，有无peer node unreachable；
2-node 机型：两块控制器依靠背板内部互联，无外部网线，背板接触不良直接 rescue 中断。
2、控制器硬件型号不匹配
同阵列两块控制器PN 备件号必须完全一致；
例：8200 控制器不同子版本、不同代硬件不能混用；硬件型号不一致，rescue 流程直接拒绝启动。
核查：shownode -d对比原有控制器 Part Number。
3、新控制器缺少阵列标识（SN/W19 不匹配，致命）
新备件控制器出厂为空，未写入阵列 SN、W19 哈希值，存活节点识别为 “不属于本阵列”，拒绝发起 rescue 同步。
两种场景区分：
✅ 最优方案：把故障控制器两块内置系统硬盘拆下，装入新控制器，硬盘自带 SN/W19，上电自动 rescue；
❌ 如果没有迁移系统盘：必须串口进入 Whack 手动写入 sys_serial、w19，参数必须从正常节点 shownode -prom 获取。
重点：W19 不能自己推算，必须从原阵列正常节点复制。
4、两端 3PAR OS 版本差距过大
存活节点 OS 版本与新控制器内置 BootOS 版本跨度太大，rescue 协议不兼容，同步中断。
现象：rescue 开始传输一段后报错终止。
解决：优先迁移原系统盘；无法迁移则改用 SP 救援方式单独刷入对应版本 OS。
5、rescue 流程被固件 / Bug 阻断
部分 3PAR OS 版本存在已知问题：
TMWO 参数异常；
控制器 NEM 固件版本过低；
上电时序异常，rescue 自动重试逻辑卡死。
处理：控制器断电静置 5 分钟，重新上电再次尝试。
6、系统盘介质故障
原故障控制器系统硬盘损坏，就算迁移硬盘也无法完成 rescue；只能使用 SP 救援。
二、标准化排查操作步骤
硬件核对
新旧控制器 PN 完全一致；重新插拔控制器，确认扳手锁紧，短按 Reset 重启。
确认是否迁移系统盘
如果有原故障节点两块系统盘：优先装入新控制器，上电等待自动 rescue（推荐）；
无系统盘：必须串口 Whack 写入阵列 SN、W19。
串口观测启动日志（最有效的定位手段）
Console 直连故障控制器，观察打印：
找不到 peer 节点 → 私有互联 / 背板问题；
握手被拒绝 → SN/W19 不匹配；
文件传输中途断开 → 版本不兼容 / 硬件链路不稳定。
备选救援方案（node-to-node rescue 彻底不行时）
改用 SP Service Processor 救援：通过 SP 网口单独给控制器刷 OS，绕过节点间私有互联。
三、重要风险提醒
严禁多次反复强制上电重试 rescue，长时间失败可能损坏控制器 Flash；
2-node 阵列 rescue 期间不要操作磁盘柜、不要断电正常运行节点；
不要随意执行 evictnode 驱逐故障节点，操作失误会丢失集群仲裁，业务中断；
W19、阵列 SN 大小写严格区分，错误写入会导致控制器无法加入集群。