适用场景
- 产品：
ZCF - 组件：
ZStack Cloud、ZStone - ZStack Cloud 版本：
5.4.x - ZStone 版本：
5.4.x - 部署形态：双管理节点
- 触发条件：主存储物理容量偏高，排查发现大量 Trash 卷未被彻底释放。
问题现象
- 主存储物理容量达到
89.83.x%。 - 虚拟容量为
31.41.x%。 - 共有
796个rbd卷仍堆积在 Trash 中，占用大量物理空间。
判断方法
- 先确认
ceph -s健康。 - 使用
rbd trash ls -p pool-xxx检查指定池中的 Trash 卷。 - 清理完成后再次检查
rbd trash ls与存储 UI，确认卷已不存在。
原因说明
根因是 V5 ZStone Trash 机制下大量 rbd 卷没有彻底释放，导致主存储物理空间被持续占用，从而逼近写满风险。
解决方案
- 执行前准备
- 风险等级：中风险
- 删除前必须确认目标卷确实位于 Trash 内。
- 删除后没有回退方案。
- 建议先关闭云平台全局高可用。
- 处理步骤
- 关闭云平台全局高可用。
- 预期结果：平台进入受控维护状态。
- 持续观察 Ceph 状态：
watch -n 2 ceph -s- 预期结果：确保清理过程前后存储集群维持健康。
- 单卷核查方法：
rbd trash ls -p pool-xxx | grep xxxx- 预期结果：确认目标卷确实存在于 Trash。
- 如需单卷强制删除：
rbd trash remove -p pool-xxx xxx --force- 预期结果：单个 Trash 卷被彻底移除。
- 本次文档建议的主方法是平台 CLI 批量删除：
rbd trash ls -p pool-xxx zstack-cli LogInByAccount accountName=admin password=<账户密码>
CleanUpStorageTrashOnPrimaryStorage force=true uuid=xxx- 其中
uuid=xxx为目标主存储 UUID。 - 执行后会返回被清理卷的信息。
- 预期结果：指定主存储上的 Trash 卷被批量清理。
- 清理完成后再次检查：
rbd trash ls -p pool-xxx- 同时在存储 UI 核实卷已不存在。
- 预期结果：Trash 卷消失，存储空间得到释放。
验证方法
- 检查
rbd trash ls -p pool-xxx输出为空或明显减少。 - 检查存储 UI 中对应 Trash 卷已消失。
- 检查主存储物理容量下降到安全范围。
- 检查
ceph -s始终健康。
风险与回滚
- 风险：误删非预期卷会造成不可逆的数据丢失。
- 风险等级：中。
- 回滚：删除后无任何回退方案。