适用场景
- 产品：
ZCF - 组件：
ZCE-X - 版本：
4.2.x - 存储介质： 混合盘 / 纯
SSD/ 纯HDD - 部署形态：双管理节点
- 触发条件：需要先对现有
Ceph存储池执行缩容换盘，再基于新规划创建新的存储池。
问题现象
- 当前场景需要对现有存储池做缩容。
- 缩容过程中不仅要移除
OSD，还要删除对应缓存盘。 - 全部旧资源处理完成后，还需要重新创建新存储池并完成初始化。
判断方法
- 变更前先检查
ceph、数据库同步、ES、ETCD全部健康。 - 单次只处理一个数据节点，确认恢复完成后再做下一节点。
- 新存储池创建后检查
ceph -s和平台资源状态恢复正常。
原因说明
这不是普通换盘，而是“存储池缩容 + OSD 删除 + 缓存盘删除 + 新池重建”的组合变更。风险控制点在于：每次只能对一个节点做踢盘 / 缩容，否则容易引发数据丢失或过度重平衡。
解决方案
- 执行前准备
- 风险等级：中风险
- 先关闭云平台云主机全局高可用。
- 先在双管理节点备份数据库。
- 先检查
ceph、Postgres、Elasticsearch、ETCD状态。
- 健康检查与数据库备份
- 在两个管理节点分别备份数据库：
zstack-ctl dump_mysql node1
zstack-ctl dump_mysql node2- 预期结果：具备回退基础。
- 检查数据库同步：
xms-manage db show-replication-info- 预期结果：主备同步正常。
- 检查
Elasticsearch健康：
/opt/sds/installer/bin/sds-util es_curl localhost:9200/_cluster/health?pretty- 预期结果：状态为
green。
- 检查
ETCD健康：
/opt/sds/bin/etcdctl cluster-health- 预期结果：返回
cluster is healthy。
- 检查
ceph状态为OK。
- 预期结果：环境可进入缩容阶段。
- 单节点缩容移除 OSD
- 在存储 UI 中设置“禁止数据恢复”。
- 预期结果：避免缩容过程中自动触发恢复波动。
- 登录目标节点，标记待移除
OSD：
echo xstore3 > /var/lib/ceph/osd/ceph-{osd_id}/type
cat /var/lib/ceph/osd/ceph-{osd_id}/type- 预期结果：目标
OSD类型已正确修改。
- 停止对应
OSD：
systemctl stop ceph-osd@{osd_id}
systemctl status ceph-osd@{osd_id}- 预期结果：服务状态为
inactive。
- 确认
ceph -s中不存在：
inactivepeeringunknownunfound- 预期结果：集群状态可继续进行存储池剔除。
- 在界面中从存储池移除对应
OSD磁盘。 - 再删除已经剔除的数据盘。
- 删除对应节点的缓存盘。
- 预期结果：单节点目标盘从旧存储池彻底移出。
- 单节点恢复后再处理下一节点
- 每次只允许剔除 一个数据节点 的硬盘。
- 预期结果：避免多节点并发缩容带来的数据风险。
- 完成当前节点剔除后：
- 开启数据恢复
- 开启云平台高可用
- 将存储池恢复
QoS设置为低速 - 预期结果：集群进入温和恢复状态。
- 等待数据恢复完成、集群健康后，再重复处理下一节点。
- 预期结果：缩容步骤分段完成。
- 所有旧节点处理完成后重建新存储池
- 选择存储池并点击创建，根据容量与性能需求配置新存储池。
- 预期结果：新存储池元数据创建完成。
- 选择缓存分区并添加，按规划设置缓存盘缓存分区。
- 预期结果：新池缓存结构建立完成。
- 选择硬盘并创建数据盘。
- 预期结果：新池的数据盘准备完成。
- 在新创建的存储池上执行初始化，并勾选所有需要加入的新节点。
- 预期结果：新存储池初始化完成。
验证方法
- 检查每次缩容后
ceph -s恢复正常。 - 检查每次只对一个节点执行缩容操作。
- 检查新存储池已成功创建并完成初始化。
- 检查云平台高可用与基础健康状态恢复正常。
风险与注意事项
- 风险：一次同时对多个数据节点踢盘会直接带来数据丢失风险。
- 风险：恢复阶段若
QoS不设低速，可能放大对前端业务的带宽冲击。 - 风险等级：中。
回退方法
若换盘结束后发现新硬盘异常：
- 将更换后的硬盘换回原槽位。
- 按原有分区重新添加硬盘。
- 添加
OSD。 - 添加存储池。
- 将存储池恢复
QoS设置为低速。 - 持续观察恢复情况，直到
ceph -s恢复为OK。 - 再开启全局高可用，并完成基础健康检查。