千卡 AI 集群下的 JuiceFS 规划：容量、Meta、Gateway 与 Cache 怎么算

AI 集群上共享文件系统的规划，不能只问“需要多少 PB”。真正决定落地规模的变量至少有 4 个：GPU 客户端数量、总吞吐目标、总文件数、故障域与容量水位。

本文以千卡级 AI 集群为例，整理 JuiceFS 方案评审时最容易混淆的几个问题：Gateway/Cache 到底跟谁扩展，Meta 是按文件系统数量算还是按总文件数算，社区版和企业版在超大命名空间下该怎么选。

juicefs-ai-capacity-planning

1. 先拆开 4 个维度

容量由对象存储层决定。对象存储节点数量受总容量、EC 策略、目标水位、磁盘规格和故障域影响。

接入层由 GPU 客户端规模和吞吐目标决定。Gateway、Cache 或等价接入组件不应该简单按文件系统个数乘，而应该看并发客户端、热点数据、回源带宽和业务峰值。

Meta 由总文件数、目录层级、元数据访问压力和产品形态决定。文件系统数量只是隔离和治理维度，不会自动把总元数据量变小。

文件系统拆分由命名空间、权限隔离、故障域、团队边界和运维复杂度决定。一个文件系统更简单，多个文件系统更利于隔离，但也会增加配额、凭据、挂载和数据治理成本。

2. 容量规划公式

对象存储容量可以按以下公式估算：

单节点原始容量 = 单盘容量 * 单节点数据盘数量
EC 后逻辑容量 = 单节点原始容量 * data_chunks / (data_chunks + parity_chunks)
目标可用容量 = 节点数 * EC 后逻辑容量 * 目标水位

例如一台存储节点有 24 块 7.68TB NVMe，采用 EC 8+2，则单节点原始容量约为 184.32TB，EC 后逻辑容量约为 147.456TB。若按 80% 水位规划，每节点可承载的规划容量约为 117.96TB。

如果目标是 16.5PB 级逻辑容量，按 80% 水位反推，存储节点下限约为 140 台。这个数字只是容量口径，还没有包含后续扩容余量、故障恢复、热点倾斜和业务峰值冗余。

3. 故障域要和容量水位一起看

“允许两个 rack 临时故障”与“两个 rack 永久丢失仍可无感恢复”不是一回事。

如果两个 rack 是临时故障，并且故障期间通过 Ceph 运维策略避免立即回填，集群可以在降级状态下维持业务，等待故障 rack 恢复后再回到正常水位。

如果两个 rack 永久丢失，则必须重新计算剩余节点容量、水位和恢复策略。此时要么补节点，要么接受水位上升和恢复窗口变长，不能把临时故障口径直接写成永久容灾能力。

下面这张图把 16.5PB 容量下限、140 台节点、12 台/rack 和 2 个 rack 故障口径放到同一个视图里。这样可以避免把“临时降级运行”误写成“永久容灾能力”。

juicefs-fault-domain-watermark

生产规划里建议明确 3 个值：

指标	推荐写法
正常水位	例如 70% 到 80%，保留扩容与恢复空间
临时故障策略	明确是否暂停回填、最长容忍时间和恢复流程
永久故障策略	明确补节点、重平衡和容量水位重新评估方式

4. Gateway 与 Cache 跟随客户端规模

很多方案评审会把 Gateway/Cache 误解成“每个文件系统固定几台”。这在小规模场景里看似成立，但到千卡级 AI 集群就会失真。

Gateway/Cache 更合理的驱动因素是 GPU 客户端数量、并发训练任务、数据集热点、回源带宽和读写峰值。

例如按“每 100 个 GPU 客户端配置 4 台 Gateway、1 台 Cache”的经验口径，千卡级集群的接入层大约需要 40 到 44 台 Gateway、10 到 11 台 Cache。无论最终是 1 个文件系统还是多个文件系统，接入层都要服务同一批 GPU 客户端和吞吐目标。

下面这张图说明 Gateway/Cache 是跟随 GPU 客户端和吞吐目标扩展，而不是跟文件系统数量简单相乘。文件系统数量影响隔离方式，接入层总规模仍要回到客户端规模。

juicefs-gateway-cache-sizing

如果只部署 1 个文件系统，Gateway/Cache 可以共同服务同一个命名空间。如果拆成多个文件系统，可以按业务组、训练队列或数据域把 Gateway/Cache 自然切分，但总规模仍要回到客户端和吞吐需求上。

5. Meta 按总文件数估算

Meta 规划最容易混淆的是“文件系统数量”和“总文件数”。

如果总文件数不变，只是从 1 个文件系统拆成 10 个文件系统，Meta 总量不会自动乘以 10。真正让 Meta 明显放大的，是总文件数从 500 亿变成 5000 亿。

在一次保守方案估算里，可以使用以下经验口径：

1 亿文件 >= 30GB Meta 内存

按这个口径，500 亿文件约需要 15TB Meta 内存。如果单台 Meta 节点内存为 1.5TB 左右，理论下限约 10 台，工程上建议按 12 到 16 台规划。

如果是 10 个文件系统，每个都要求 500 亿文件，总文件数会变成 5000 亿。此时 Meta 内存估算约为 150TB，已经是完全不同的工程规模，节点数量可能需要按 100 到 140 台级别重新评估。

这个估算不是通用承诺。真实 Meta 规模还会受到文件名长度、目录深度、扩展属性、ACL、快照、文件变更频率和产品版本影响。正式方案要结合厂商 sizing、压测和容量增长模型复核。

6. 1 个文件系统还是多个文件系统

1 个大文件系统的优势是命名空间统一、业务迁移简单、训练任务不用处理多挂载点。适合数据域清晰、权限模型简单、希望统一治理的数据平台。

多个文件系统的优势是隔离更强。不同业务可以拥有独立 Volume、独立挂载 Token、独立 Bucket、独立对象存储凭据、独立配额和审计策略。适合多租户、多团队、强权限边界或不同生命周期的数据域。

但是多个文件系统不是免费的。它会增加凭据分发、挂载管理、数据复制、跨域访问、监控告警和运维排障复杂度。尤其是“每个文件系统都要承载数百亿文件”时，Meta 规模要按总文件数重新计算。

7. 社区版与企业版选择

社区版适合通用共享文件系统、对象存储接入和常规规模场景。Redis、TiKV、MySQL/PostgreSQL 等元数据后端各有适用边界，部署前要按文件数、并发和可用性目标评估。

当需求明确指向单文件系统数百亿文件、正式 SLA、分布式缓存、超大规模元数据和统一命名空间时，更合理的评审方式是引入企业版能力做 sizing。此时要关注分布式元数据、分布式缓存、主动失效、容量扩展和服务支持边界。

可以把方案分成 4 类：

方案	文件系统数量	版本形态	适用判断
A	1 个	社区版	常规规模可讨论，数百亿文件级单命名空间不建议作为正式承诺
B	多个	社区版	可用于业务隔离，但如果每个都极大，总工程复杂度很高
C	1 个	企业版	更适合统一命名空间、超大文件数、正式 SLA 和集中治理
D	多个	企业版	仅在强隔离或明确多租户要求下讨论，总文件数会显著放大 Meta

如果原始需求是“一个统一文件系统承载数百亿文件”，优先评估企业版 1FS。如果需求是“多个租户必须强隔离”，再评估企业版多 FS，并按总文件数重新计算 Meta。

8. 生产落地建议

第一，容量层按水位和故障域规划，不要只按裸容量除一下。至少保留正常水位、临时故障水位和扩容触发水位。

第二，接入层按 GPU 客户端规模和吞吐规划。Gateway/Cache 要随着客户端并发扩展，不要被文件系统数量误导。

第三，Meta 按总文件数规划。拆分文件系统是隔离手段，不是减少总元数据的手段。

第四，读多写少数据集要重视 Cache、warmup 和热点治理。checkpoint、小文件和中间产物要单独建模，不要混在同一个平均吞吐目标里。

第五，所有容量和性能数字都要经过业务压测闭环验证。方案估算只能决定初始规模，不能替代真实 workload 验证。

9. 小结

千卡级 AI 集群的 JuiceFS 规划，核心不是“1FS 还是 10FS”这个表面选择，而是把容量、接入、Meta、缓存和隔离拆开计算。

对象存储节点主要跟容量、水位和故障域走；Gateway/Cache 主要跟 GPU 客户端和吞吐走；Meta 主要跟总文件数走；文件系统数量主要跟权限、命名空间和治理边界走。

只要这 4 条线拆清楚，方案评审就不会被“文件系统数量”和“节点数量”的简单乘法带偏。

参考资料：

第三章-AI 集群下的JuiceFS架构规划