H3C 8020

H3C 3PAR 8020 硬盘更换后 PD ID 跳号（原 ID14 丢失、新盘 ID24）完整原理 + 修复方案
一、先解释为什么 ID 会自动跳到 24（根因）
3PAR PD ID 分配机制
PD ID 是系统全局自增序列号，不是和槽位绑定：
故障盘 PD14 标记为failed后，你仅执行servicemag resume完成数据回迁，但没有执行dismisspd 14清除失效的 PD14 记录；
系统中 PD14 条目永久残留标记为失效，无法复用；
新插入硬盘系统分配下一个未占用最大 ID，直接跳到 24，出现 ID 断层。
标准正确更换流程（不会跳 ID）
完整流程必须包含：servicemag start → 拔坏盘 → 插新盘 → servicemag resume → 数据同步完成 → dismisspd 旧PDID
你缺失dismisspd 14清理失效硬盘条目，导致 ID 无法回收复用。
关键结论
当前在线状态下，无法直接把 PD24 修改为 PD14，系统无命令支持手动指定 PD ID；
想要恢复原 ID14，必须回退更换流程重新操作，步骤分两套方案：
二、方案 1：业务允许停机，回退重做更换（推荐，恢复 PD=14）
前置校验
bash
运行
# 确认新盘PD24完整同步完成，无relocating任务
servicemag status
showpd -s
# 确认故障盘PD14状态为failed
showpd 14
完整回退操作步骤
拔出新硬盘（PD24）
硬盘槽位断电拔出，等待系统识别盘缺失。
清除新盘 PD24 配置
bash
运行
dismisspd 24
清理残留失效 PD14 条目（核心，释放 ID14）
bash
运行
# 必须等servicemag全流程结束才能执行
dismisspd 14
执行后showpd不再显示 ID14，ID14 序列号释放可复用。
4. 重新执行标准硬盘更换流程
bash
运行
# 1. 标记槽位维护模式（替换原故障盘14对应槽位）
servicemag start <cage号> <mag槽位号>
# 2. 插入新硬盘到原故障槽位
# 3. 启动数据回迁
servicemag resume <cage号> <mag槽位号>
# 4. 等待数据同步100%完成
servicemag status
同步完成后，新硬盘自动复用 PD ID=14，ID 不再跳号。
三、方案 2：业务不允许停机，保留 ID24 不回退（折中方案）
1. 现状影响说明
ID 断层不影响存储性能、数据安全、CPG、RAID、重构，仅运维查询showpd -i时 ID 不连续，无业务风险；
仅影响运维台账、监控告警匹配（原监控绑定 ID14 会失效，需修改监控对应 PD24）。
2. 运维适配优化操作
清理失效 PD14 条目（消除无效 failed 记录）
bash
运行
dismisspd 14
台账 / 监控修改：将原 PD14 监控告警、硬盘台账更新为 PD24；
统一用showpd -i通过CagePos槽位定位硬盘，不再依赖 PD ID（推荐长期运维习惯）。
四、关键命令详解
dismisspd <PDID>
作用：彻底从系统数据库删除失效硬盘的 PD ID 记录，释放 ID 序列号供新硬盘复用；
前提：该 PD 对应槽位已完成 servicemag 数据迁移、硬盘已拔出 / 替换完成。
servicemag start <cage> <mag>
预迁移槽位内硬盘数据到热备 chunklet，标记槽位待更换；
servicemag resume <cage> <mag>
新硬盘插入后，将热备数据回迁至新盘；
showpd -failed
查看残留失效故障硬盘条目，确认是否需要 dismisspd 清理。
五、后续更换硬盘标准化流程（避免再次跳 ID）
发现硬盘故障，执行 servicemag start -pdid 旧ID
等待数据迁移完成，拔下故障硬盘
插入同规格新硬盘，自动执行servicemag resume（未自动则手动执行）
servicemag status确认回迁 100% 完成
必执行：dismisspd 旧故障 PDID，释放 ID 序列号
showpd -i校验新硬盘复用原 PD ID，无断层
六、常见误区澄清
误区：有命令可以直接修改现有 PD24 的 ID 为 14
纠正：3PAR StoreServ 无setpd id类修改 PD 序列号的命令，PD ID 是系统全局自增主键，创建后不可修改；只能删除旧条目重新更换复用 ID。
误区：不 dismisspd 也能复用 ID
纠正：failed 状态的 PD 条目永久占用 ID，系统不会分配给新硬盘，必然跳号。
误区：ID 断层会导致数据损坏
纠正：PD ID 仅为管理序列号，和数据分布、chunklet、CPG 无关，完全不影响业务稳定性。

核心结论

为什么不建议修改 ID？

1. 底层架构限制：3PAR 的 servicemag 机制和底层操作系统（InformOS）中，并没有提供类似 changepdid 这样的命令来手动将一块在线健康盘“重命名”或“改回”旧 ID。
2. 潜在风险极高：强行通过底层未公开指令修改物理盘 ID，极易破坏阵列的拓扑映射关系，导致数据丢失或阵列崩溃。
3. 无实际收益：3PAR 是基于逻辑块寻址的，上层业务（主机、虚拟化平台）只认 LUN/WWN，根本不关心底层物理盘是 14 还是 24。

当前必须确认的关键事项

1. 检查物理盘状态：
   执行 showpd -i 24，确认新盘状态为 normal 或 ready，且没有 degraded 或 failed 的告警。
2. 检查重构进度：
   执行 showarrayrebuild 或 showtask，确认后台的数据同步/重构任务进度已达到 100% 且状态为 completed。
3. 检查存储池健康度：
   执行 showcpg -s，确认对应 CPG 的状态为 OK，且 Usr、Snp、Adm 等空间分配比例恢复正常，没有处于降级（Degraded）状态。

💡 运维建议

• 接受系统行为：在 3PAR 的日常运维中，换盘后 ID 顺位是标准的系统预期行为。请在您的运维台账或资产管理系统中，将原槽位对应的 PDID 从 14 更新为 24 即可。
• 重构期间禁忌：在 showarrayrebuild 显示重构未完成期间，严禁进行存储下电、拔插其他硬盘或执行 createcpg / tunevv 等配置变更操作，以免引发二次故障。

考虑到换盘后自动resume,新盘自动顺位，且原盘断层，也看不到原盘。我是不是应该按照以下顺序可以避免

1、完整流程：showpd发现fail盘,并且确认数据迁移走，先 dismisspd 旧PDID → 拔坏盘 → 插新盘 → servicemag resume → 数据同步完成，这样原ID就不变。

或者2、showpd发现fail盘,并且确认数据迁移走， 拔坏盘 → dismisspd 旧PDID   → 插新盘 → servicemag resume → 数据同步完成，这样原ID就不变。

或者3、 servicemag start → 拔坏盘 → 插新盘 →自动 servicemag resume  → dismisspd 旧PDID  数据同步完成