ZSTACK平台僵尸资源清理实战指南

你有没有想过一个问题：平台上那些“跑着但没人用”的虚拟机、“创建了但从没挂载”的云硬盘、“拍了但早过期”的快照——它们加起来，占了你多少存储空间？

在日常巡检中我们发现，一个中等规模的私有云环境里，通常有15%到30%的资源属于“僵尸状态”。它们不报错、不告警、不影响业务，但实实在在地占着你的存储容量和资源配额。等到哪天真需要空间了，才发现配额早被这些“幽灵”吃完了。

Q1：哪些资源最容易变成“僵尸”？怎么把它们找出来？

超过90天没人碰的虚拟机。它们还显示“运行中”，但已经三个月没有任何登录、重启、配置变更。在平台的资源使用统计里，如果一台虚拟机CPU使用率持续低于2%，而且没有网络流量，基本就能判定是僵尸了。

创建了但从没挂载的云硬盘。可能是当初测试时随手建的，也可能是某次操作后卸下来忘了清理。在存储管理中筛选状态为“可用”（未挂载）且创建时间超过30天的云盘，就能把它们揪出来。

堆积的过期快照。快照是好东西，但不能无限存。特别是某些存储类型的快照是链式结构，越积越多不只占空间，还会拖慢整体读写性能。如果你从没设置过“快照自动清理策略”，快照很可能已经积了几十甚至上百个。

回收站里的资源。很多人不清楚：删除虚拟机或云盘后，它们会先进入“回收站”，在保留期内仍然占用存储空间。如果回收站保留时间设得很长（比如30天），里面可能压了大量已经确认不需要的资源。

管理节点上的日志文件。系统日志、数据库日志如果没有配置自动轮转清理，日积月累可能占据几十GB。我们见过管理节点系统盘被日志撑满的案例——系统盘满了，整个平台都可能出问题。

Q2：清理的时候，怎么避免误删？

最怕的就是：“看着没用”但其实在默默干活。

先关机观察，不要直接删除。把疑似僵尸的虚拟机先关机，观察7到14天。如果这期间没人来喊“我的服务怎么挂了”，基本确认是可以清理的。直接删除风险太大——万一它是个定时任务服务、日志收集节点或者内部DNS，删了就是一场事故。

批量清理快照时要分批做。一次性删除大量快照会导致存储后台大量数据整理操作，可能短时间内拖慢整体存储性能。建议每次删10个以内，选业务低峰期操作，删完观察一下存储延迟再继续。

清空回收站前再确认一次。回收站是“误删”后的最后安全网。清空之前，快速过一遍最近一周删除的资源列表，确认没有“手滑删掉”需要恢复的。

日志不要直接rm删除。正在被系统写入的日志文件如果直接删除，空间不会立即释放（文件句柄还在），而且可能导致对应的服务异常。正确的做法是配置日志轮转策略让系统自动管理，或者先“截断”文件（清空内容但保留文件），再等日志系统自动重建。

Q3：怎么建立长效机制，而不是每次都靠人工“大扫除”？

靠人记忆去定期清理，迟早会忘。好的做法是把清理动作“自动化”或“制度化”：

配置快照自动清理策略。平台支持“定时快照+保留策略”的组合——比如每天自动快照，保留最近5个，超出的自动删除。配好之后就不用操心了。

调整回收站保留时间。默认可能是30天。如果你的存储空间本来就紧张，可以考虑调整为7天——绝大多数“删错了”的情况会在几天内发现。

每月做一次资源审查。把它作为常规运维流程的一部分。内容很简单：导出资源统计报表，看看有多少90天未操作的虚拟机、多少未挂载的云盘、快照总量是否在合理范围内。把这些数据纳入月度运维报告。

确保日志轮转策略在运行。管理节点的系统日志、数据库日志都应该配置了自动轮转和过期清理。检查一下配置是否存在、是否在正常工作。如果没配置，花10分钟配一下，能省掉未来很多麻烦。

设置存储容量告警。这是最后一道防线——即使前面的策略都没执行好，至少在容量到达危险水平时能收到通知。建议阈值设在80%。

自查清单：5件事帮你摸清“家底”

• 导出资源统计报表，看看有多少90天未操作的虚拟机和未挂载的云盘
• 检查快照总量——是否有虚拟机快照超过5个？是否配置了自动清理策略？
• 看一眼回收站设置：保留时间是多少天？里面是否有大量积压？
• 登录管理节点看磁盘使用率——/var/log 目录是否超过10GB？日志轮转是否正常？
• 存储容量告警是否已配置？通知渠道是否畅通？

这些情况建议联系技术支持

• 需要批量清理大量快照（超过100个），想确认对业务的影响范围
• 存储已经超过85%，需要帮你制定紧急清理的优先级
• 快照链过长导致读写性能下降，需要评估重建方案
• 资源删除后空间没有正常释放，怀疑平台回收机制异常
• 管理节点磁盘满导致服务异常，需要紧急恢复
• 想要定制化的自动清理脚本或运维巡检方案

来源：互联网