空间扩容无效？90%存储浪费藏在这3大盲区

文章配图，仅供参考

　　我原以为扩了两台全闪阵列，IO压力能下来。结果监控曲线跟没扩一样，半夜三点还飘红。运维组拉会，老张把咖啡泼在白板上，说“是不是缓存没调？”没人应。窗外打雷，雨点砸在通风窗上，咚、咚、咚——像在敲硬盘盘片。

　　第一个盲区：备份快照的幽灵繁殖。我们那套Veeam，策略写的是“保留7天”，但谁记得它默认带一个“永远保留”的基础镜像？那个镜像压根不进清理队列，光是它自己，三个月长到八百三十二TB。上周我查日志，发现2021年6月建的base image还在跑——比我们新招的实习生入职早整一年。它连挂载都没挂载过，就躺在那儿呼吸式膨胀。这事儿我说不准是不是厂商故意埋的坑，但它的CRC校验值每天变一次，真事。

　　第二个盲区更离谱：CI/CD流水线里跑出来的临时镜像，根本没删。开发部的脚本每次构建都打新tag，却从不gc docker images。我数过，同一套微服务，在registry里塞了四十七个不同tag的相同层。它们共享底层blob，可上层元数据占空间——每删掉一个tag，free -h才跳一下。上周三下午，我就蹲在服务器前，手动docker image prune -f ——删完三十四个，磁盘可用率升了不到百分之一。这时候老周接了个电话，说的是方言，后半句全是“哎哟哎哟”，挂了之后他说：“刚测试环境崩了，数据库连不上。”

　　第三个……算了，先说个闲事。前天在茶水间撞见DBA老陈，他端着搪瓷缸，缸底印着“安全生产先进个人”，边走边搅勺子，糖块卡在缸沿，他舔了一下——真舔，舌头尖探出来一毫米，又缩回去。这人去年帮我调过RPO参数，调得贼准。可他完全不知道，我们备份系统里有一类叫“应用一致性快照”的东西，实际依赖的是应用进程在快照瞬间是否响应SIGUSR1。但我们有个Java服务压根没配handler，它每次快照都假成功。假成功三年。三百七十二次。这事儿我敢打包票，因为我亲手抓包确认过，那个ACK报文发出去之后，应用日志里空了一秒十七毫秒。

　　扩容无效？90%存储浪费藏在这3大盲区。不是算法问题，是人在流程里打盹时，系统自动续费式繁衍。优胜劣汰——淘汰的从来不是技术，是没人看一眼的日志行、没人改一行的cron、没人动一下的 retention policy。我们扩的是物理容量，可浪费长在策略缝里，像霉斑长在机柜后面。

　　那天晚上十一点，我把最后一台新阵列的LUN切进生产，监控依旧红着。我盯着屏幕右下角时间，十八秒过去，没变化；再十八秒，还是没变化。忽然想起去年双十一，也是这个位置，监控绿了一分钟，接着蓝屏了。蓝屏前最后一条日志是：“snapshot_20231111_2359_manual_1111”——那个manual，其实不是人手点的，是另一套调度器误触发的。这事我提过三次，没人改配置，后来连提的人都换岗了。

　　小杨后来把拆下来的旧背板随手插进旁边闲置的服务器——那台服务器连网线都没插，但他插了，咔嗒一声。现在它每天零点定时上报心跳，IP是172.16.0.144，hostname是zabbix-proxy-bak-2019。没人删它，也没人用它，但它活得好好的。像我们留着的那些快照一样，什么也不做，只是存在。

　　我下周二去跟法务过存储合规条款。他们问“冗余副本是否必要”，我说：“是”。但他们没问“是否真的用了”。这话我没说出口，说了也没用——条款里写的不是“用”，是“具备”。

（编辑：站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!