适用场景
- 产品：
ZCF - 组件：
ZCE-X - 版本：
4.2.x - 部署形态：双管理节点
- 触发条件：两副本存储池中存在多个异常 OSD，已临时
lost后集群恢复健康，需要逐块更换隔离出来的故障数据盘。
问题现象
- 多个节点的盘同时
error，导致 OSD 异常。 - 异常 OSD 已被临时
lost，当前存储池已恢复健康。 - 仍需继续完成硬件层面实际换盘。
- 注意：每次只更换一个节点上的故障 OSD。
判断方法
- 升级前先确认
ceph -s为健康状态。 - 确认 PostgreSQL 主备同步状态正常，
LSN一致且Diff=0。 - 确认
ES与ETCD集群健康。 - 更换完成后等待数据恢复回到
100%再进入下一块盘。
原因说明
当前风险不在于存储池已经整体不可用，而在于虽然异常 OSD 已临时隔离，但底层故障盘仍需按规范逐块替换。如果在多副本有限的情况下并行操作多个节点，会显著放大数据风险，因此必须单节点、单 OSD、逐步恢复。
解决方案
- 执行前准备
- 风险等级：中风险
- 建议在业务低峰期操作。
- 先关闭云平台全局高可用。
- 先备份双管理数据库。
- 健康检查与数据库备份
- 在两个管理节点备份数据库：
zstack-ctl dump_mysql --file-name zstack-db-backup-master
zstack-ctl dump_mysql --file-name zstack-db-backup-slave- 预期结果：具备数据库回退基础。
- 检查存储集群状态：
ceph -s- 预期结果：集群为
ok状态。
- 检查 PostgreSQL 同步状态：
xms-manage db show-replication-info- 预期结果：主备
LSN一致，Diff=0。
- 检查 ES 与 ETCD 健康：
xms-manage -s- 预期结果：管理侧依赖组件健康。
- 禁止数据恢复并观察状态
- 在存储平台右上角打开“禁止数据恢复”。
- 预期结果：后续换盘过程不会立即触发恢复压力。
- 新开窗口持续观察：
watch -n 1 ceph -s- 预期结果：实时掌握
ceph状态变化。
- 单节点停 OSD 并移出存储池
Note:
单次只能操作一个节点上的 OSD。
- 在问题节点把目标 OSD 类型改为
xstore3：
echo xstore3 > /var/lib/ceph/osd/ceph-{osd_id}/type
cat /var/lib/ceph/osd/ceph-{osd_id}/type- 预期结果：类型标记正确写入。
- 停止目标 OSD：
systemctl stop ceph-osd@{osd_id}
systemctl status ceph-osd@{osd_id}- 预期结果：确认该 OSD 已离线。
- 等待
ceph层面无peering状态后，在存储池中执行“移除硬盘”。
- 预期结果：目标 OSD 数据盘从存储池逻辑移出。
- 在“硬盘管理”中勾选该 OSD，确认所属存储池显示为“暂无”，然后执行删除。
- 预期结果：旧 OSD 记录从平台侧删除。
- 热插拔更换硬盘并重新加回
- 硬件侧热插拔更换故障盘。
- 更换后在主机侧确认系统已识别新盘：
lsblk- 预期结果：新盘被正常识别。
- 在“硬盘管理”中点击“添加硬盘”。
- 勾选新数据盘，按原配置打开缓存开关，并保持与原盘相同的读缓存设置。
- 预期结果：新 OSD 数据盘被正确纳管。
- 等待硬盘状态变为“健康”。
- 在“存储池”中执行“添加硬盘”，把新 OSD 数据盘重新加入原存储池。
- 预期结果：新 OSD 成功回到原存储池。
- 开启数据恢复并收口
- 在控制台中执行“开启数据恢复”。
- 预期结果：存储池开始恢复数据。
- 等待集群数据恢复到
100%。 - 再次检查：
ceph -s- 预期结果：存储状态恢复为
OK。
- 在云平台全局设置中把云主机高可用开关恢复为
True。
- 预期结果：平台恢复正常高可用策略。
- 仅当上述全部完成且状态正常时，再进入下一块故障盘更换。
验证方法
- 检查
ceph -s为健康状态。 - 检查 PostgreSQL、ES、ETCD 健康状态无异常。
- 检查新盘添加后状态为“健康”。
- 检查存储池恢复进度达到
100%。 - 检查云平台高可用已恢复。
风险与回滚
- 风险：误将正常磁盘移出会直接带来数据风险。
- 风险：多节点并行换盘会放大两副本存储池风险。
- 风险：恢复速度过高可能增加业务 IO 延迟。
- 风险等级：中。
- 回退：“更换磁盘无需回退”，因此应依赖严格的单盘、单节点、逐步验证策略控制风险。