容量快满的时候最自然的反应是加一批新盘把水位压下去。但分布式对象存储里「加盘」和「旧数据自动搬匀」是两件事新写入确实会落进新盘已经在老盘上的对象却不会自己挪窝过一阵子你就会看到新池很空、老池很满比例越来越歪。RustFS 1.0.0 的多池Server Pool模型把扩容和再均衡拆成了两个独立动作扩完容再跑一次 rebalance才能把已用容量比例真正拉平。新盘加上了为什么容量比例还是歪的RustFS 分布式部署把多个存储端点写进同一个RUSTFS_VOLUMES逻辑上是一个集群。往这个集群追加密集的新端点、组成一个新池之后新写入会按可用池去分布但已经存在的对象始终留在它们原来所在的池里。这不是 bug是布局决定的对象的纠删码分片在写入那一刻就固定落到了某个纠删集和某组盘上扩容动作本身不加任何旧对象的校验分片也不拷贝任何东西。所以「加盘」只解决未来的写入去向「搬匀」是另一件消耗磁盘、网络和 CPU 的活得显式发起。理解这一点能少踩一个大坑有人以为扩容完集群就自动均衡了结果老池一路涨到满、新池还是空的读写压力全压在老盘上。分布式才能加池单盘部署走另一条路先确认前提多池扩容只在分布式部署里有意义。单节点单盘single-node single-drive的布局不支持原地加池文档明确要求这种部署通过 S3 拷贝的方式迁移到更大的集群而不是在自身上扩容。所以动手前先看清自己是不是分布式拓扑不是的话这整篇的rc admin pool命令都不适用。在 Kubernetes 上用官方 Helm chart多池等价于 chart 里的pools开关把现有布局描述成 pool 0再把新容量作为 pool 1 追加进pools.listhelm upgrade即可。这里有个硬性约束要记住池列表是只追加的列表索引决定 StatefulSet 的名字永远不要删掉或重排已有条目要下线一个池得先走rc admin decommission把它排空再从列表里移除。扩容这一步怎么落裸机或容器部署下扩容用的是rcRustFS 命令行客户端的管理接口。先在管理机上配好集群别名和具备扩容权限的凭证rcaliassetrustfs http://rustfs.example.com:9000 rc admin pool list rustfspool list能看到当前每个池的端点、布局和已用情况扩容前先确认现有拓扑健康。发起扩容、看进度、必要时中止分别对应rc adminexpandstart rustfs rc adminexpandstatus rustfs rc adminexpandstop rustfs扩容过程是滚动的新池的节点会经历若干轮崩溃重启直到每个池的每一个节点都能被互相解析到集群才收敛。这段 crash loop 在日志里看着吓人但只要最终能互相解析、服务拒绝启动的报错消失就是正常的不用当故障去救。收敛完成后再跑 rebalance顺序别反。rebalance 把旧对象摊开集群收敛后用一条命令把现有对象在所有活跃池之间重新分布rc admin rebalance start rustfs rc admin rebalance status rustfsstatus给出的不只是「在跑没在跑」还有操作 ID、每个池的已用情况、已移动字节数、对象与版本数、剩余桶数、已用时间和能算出来时的预计完成时间。控制台里也有对应的 Rebalance 页面能看到各池的已用容量比例在收敛。几个边界条件提前知道能省很多事至少要有两个活跃池rebalance 才有意义只有一个池时接口直接返回NotImplemented。已经在跑一次 rebalance或者正在 decommission 一个池新的 rebalance 会被拒绝不能叠加。中途stop不会把已经搬走的对象移回原池已经在新池的就是新池的别指望回滚。对象搬运吃磁盘、网络和 CPU安排在流量低谷做别跟业务高峰撞车。验证是否真完成看status是不是Completed、剩余桶数是不是零、有没有失败上报再把扩容前的各池已用比例记下来对比最后通过 S3 端点读一个老对象、写一个测试对象确认读写都正常。控制台页面报告 Completed 之后再确认所有节点和磁盘仍然在线这一步不能省。缩容和退役也走同一套容量不是只增不减要下线一批老硬件时走decommission把池排空再把它从布局里摘掉rc admin decommission start rustfs--pool1rc admin decommission status rustfs退役只在多池、且非 legacy 布局的部署上支持单池或旧布局会返回NotImplemented。和扩容一样退役的源池在被排空期间会拒绝新的普通写入和新的 multipart 上传进行中的分片上传允许 drain 完所以挑一个低峰窗口、先确认数据确实在往别处搬再动刀。把扩容和再均衡拆开看整件事就清楚多了扩容决定「新数据去哪」rebalance 决定「旧数据怎么摊」退役决定「老硬件怎么退」。三者都是rc admin下的独立动作互不自动触发也不会因为一次重启就偷偷帮你搬数据。想顺着官方文档把命令参数和前置条件看全扩容与再均衡的章节在 RustFS 官方文档的扩容说明Kubernetes 上多池的写法在 官方云原生安装文档 的 Server pools 一节。RustFS 的 1.0.0 正式版于 2026 年 9 月 16 日发布多池与 rebalance 作为 GA 能力随版本提供相关命令和示例在 GitHub 的 rustfs/rustfs 仓库。加盘不难难的是记得扩完再 rebalance 一次。
