方案对比：什么时候不该用 Ceph
开源不等于便宜。把授权费、运维成本、技术支持一起算进去。
学完这节你能做到
- 按场景对比 Ceph / GPFS ECE / Weka / VastData / XSKY
- 说明 CephFS 不建议用于 AI 训练场景的原因
- 产出一份带取舍理由的选型建议
开源不等于便宜
Ceph 没有软件授权费，所以看起来最便宜。但一套存储的总成本包括：
TCO = 硬件 + 软件授权 + 实施人力 + 运维人力 + 故障损失 + 技术支持
Ceph 省掉的是"软件授权"这一项，代价是"运维人力"和"故障损失"这两项显著变高——没有原厂支持，出事只能自己扛。一个能独立处理 Ceph 疑难故障的工程师，市场价格并不便宜，而且很难招。
判断依据不是"要不要花钱"，而是"这笔钱花在授权上，还是花在人上"。
高性能文件系统横评
| 方案 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|
| VastData | 多协议统一（NFS/SMB/S3/块），支持多租户与 QoS，支持去重，建设成本低（平摊授权费），原厂支持 | 性能比 GPFS ECE 稍弱，采购周期长 | 多租户场景，需要 QoS 和技术支持 |
| GPFS ECE | 高性能，业界广泛使用，授权费低 | 多租户支持弱，通常只有第三方技术支持 | 单租户高性能场景，预算有限 |
| Weka | 性能高于 GPFS ECE，支持多租户 | 授权费高，第三方技术支持 | 极致性能需求，预算充足 |
| CephFS | 开源无授权费，支持多租户 | 不支持 QoS，元数据缓存受节点内存限制，不足时性能锐减，运维成本高，无技术支持 | 预算有限的非 AI 通用共享文件存储 |
这是选型里最需要记住的一条结论，理由在 L2 的 CephFS 一节讲过：
AI 训练数据集常是海量小文件，每个 epoch 都要遍历一遍，产生数千万次元数据操作。CephFS 的 MDS 把热元数据放在内存里，缓存装不下时性能是断崖式下跌而不是线性变慢，而缓存上限受单机内存约束，无法通过加节点线性扩展。
同时 CephFS 不支持 QoS，多个训练任务之间无法做性能隔离，一个人跑满就所有人一起卡。
AI 场景应该评估 GPFS ECE、Weka、VastData。
对象存储横评
| 方案 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|
| XSKY XEOS | 功能齐全，支持 QoS，原厂支持，支持大规模，稳定 | 授权费高 | 生产环境，需要稳定性和技术支持 |
| Ceph RGW | 开源无授权费 | 稳定性欠于 XEOS，QoS 较弱，海量对象数下的稳定性未充分验证，无技术支持 | 预算有限的非关键业务 |
| VastData S3 | 高性能，与文件系统复用同一集群，支持 QoS，原厂支持，支持大规模 | 全闪成本高，只适合高性能场景 | 高性能对象存储需求 |
海量对象是对象存储的分水岭。L2 的 RGW 一节讲过 index 池和分片的问题——这些坑在几百万对象时不明显，到几十亿对象时会集中爆发。如果业务规模会走到那一步，商业方案的"已验证规模"就是实实在在的价值。
块存储横评
| 方案 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|
| VastData Block | 高性能，原厂支持 | 当前版本尚不支持 QoS | 高性能块存储，可接受较新产品 |
| Ceph RBD | 开源无授权费，块存储子系统成熟 | 全闪配置性能普通，无技术支持 | 预算有限，虚拟机/数据库等通用块存储 |
Ceph RBD 是 Ceph 三种存储里最成熟稳定的一个，社区验证最充分。它的短板不是稳定性，而是"全闪之后性能提升不成比例"——软件栈开销在全闪环境下占比过高，这也是 L3 上一节延迟估算里那 200~500 µs 软件开销的现实含义。
其它路线
| 方案 | 定位 |
|---|---|
| 3FS | 面向 AI 的高性能分布式文件系统，较新 |
| JuiceFS | 元数据用外部数据库 + 数据放对象存储，适合计算在云上、已有 RDS 和对象存储的环境 |
| Longhorn | K8s 原生的轻量块存储，适合小规模和边缘场景 |
| 本地盘 (local-storage) | 缓存数据、或应用自身有 HA 的数据库 |
| NFS | 外部带 HA 的 NAS，或小规模/开发环境自建 |
选型不必非黑即白：一个集群里不同业务用不同存储是常态。比如 GPFS 承载 AI 训练、Ceph RBD 承载虚拟机、XEOS 承载归档。
一套可复用的选型流程
1. 拿到需求确认单（L3 第一节的输出）
2. 按语义筛：块 / 文件 / 对象，先砍掉不匹配的
3. 按硬指标筛：容量规模、带宽、IOPS、延迟、QoS、多租户
4. 用 storplan 算各方案的配置与成本
5. 算 TCO：授权 + 硬件 + 人力 + 支持
6. 列出每个方案的风险，标明哪些是可承受的
7. 给出推荐 + 备选，并写清推荐理由
招标或 POC 场景下，问这几个问题最能看出深浅：
- 规模验证：现网最大的部署是多少节点、多少容量、多少对象数？能提供参考客户吗？
- 故障行为：坏一块盘、宕一台机器、断一个机架，分别会发生什么？重建期间性能下降多少？
- QoS 能力：能否限制单租户的带宽、IOPS 和元数据 IOPS？（很多方案只能限前两个）
- 扩容路径：能否在线扩容？扩容期间性能影响？能否缩容？
- 升级方式：滚动升级还是需要停机？跨大版本怎么升？
- 支持响应：SLA 是多少？中文支持吗？现场支持吗？
- 退出成本：数据怎么迁出？有没有标准协议兜底？
POC 一定要测恢复期间的性能，而不只是测健康状态下的峰值——健康状态的数字所有厂商都很好看。
客户要为 200 张 GPU 的训练集群选共享文件存储，数据集是 5000 万个小文件，预算充足且要求多租户隔离。最不合适的方案是？
评估一款没用过的存储时，下面哪些问题最有价值？（多选）
关于开源与商业方案的成本，下面哪个理解最准确？
这节课的落点
- 开源省的是授权费，付出的是运维人力和故障风险，按 TCO 比较
- 高性能文件系统：VastData（多租户+支持）/ GPFS ECE（性价比）/ Weka（极致性能）/ CephFS（非 AI 通用场景）
- CephFS 不用于 AI：元数据缓存瓶颈 + 无 QoS
- 对象存储：XEOS 稳而贵，RGW 便宜但海量对象规模未充分验证
- 块存储：RBD 成熟但全闪性能普通
- 一个环境里不同业务用不同存储是常态，不必非黑即白
- 评估陌生方案先问故障行为、规模验证、QoS 粒度和退出成本；POC 必测恢复期性能