商业方案巡礼：Weka / VastData / XSKY
知道市面上有什么、各自强在哪，选型时才不会只会推 Ceph。
学完这节你能做到
- 说出三家方案的架构特点与典型场景
- 识别各自的隐性成本
- 在招标场景下提出有效的技术问题
为什么要了解你可能用不上的产品
两个现实理由：
- 选型时你要能说"不"。只会 Ceph 的工程师，给出的方案永远是 Ceph——哪怕场景明显不合适
- 招标和 POC 时你是技术把关人。厂商的 PPT 都很漂亮，能问出关键问题的人才不会被忽悠
这一节过一遍市面上的主要方案，重点不是记住参数，而是理解每家的架构取舍。
Weka
定位：极致性能的并行文件系统，AI / HPC 场景的高端选择。
架构特点：
- 完全用户态实现，绕过内核文件系统栈，配合 SR-IOV / DPDK 直通网卡与 NVMe
- 自研的分布式元数据，不存在 CephFS 那种单点元数据缓存瓶颈
- 支持分层：热数据在 NVMe，冷数据自动下沉到对象存储
- 多协议：POSIX 客户端、NFS、SMB、S3
取舍：
| 优点 | 缺点 |
|---|---|
| 性能高于 GPFS ECE | 软件授权费高 |
| 支持多租户 | 第三方技术支持（国内原厂支持有限） |
| 小文件与元数据性能突出 | 生态相对小众，运维人才难找 |
适用：极致性能需求且预算充足。
VastData
定位：全闪统一存储，DASE 架构，多协议一套集群搞定。
DASE（Disaggregated Shared Everything）的核心是把状态和计算彻底分离：
计算节点（CNode，无状态）
↕ NVMe-oF over 网络
存储机箱（DBox：QLC SSD + 少量 SCM 作写缓存）
因为 CNode 无状态，所有 CNode 都能访问全部数据，扩容计算和扩容容量可以独立进行。这与 Ceph "每个 OSD 独占自己的盘"是根本不同的架构思路。
取舍：
| 优点 | 缺点 |
|---|---|
| 多协议统一（NFS/SMB/S3/块），可平替 Ceph | 性能比 GPFS ECE 稍弱 |
| 支持多租户与 QoS | 采购周期较长 |
| 支持去重压缩，建设成本相对低 | 块存储当前版本还不支持 QoS |
| 原厂技术支持 | 全闪成本高，不适合纯容量型场景 |
适用：多租户场景，需要 QoS 和技术支持；或者想用一套集群同时提供文件、对象、块。
XSKY XEOS
定位：大规模对象存储，国内商业方案。
取舍：
| 优点 | 缺点 |
|---|---|
| 功能齐全，支持 QoS | 软件授权费高 |
| 原厂技术支持，中文服务 | |
| 支持大规模，稳定性经过验证 |
对比 Ceph RGW 的关键差异在海量对象数的稳定性。L2 讲过 index 池和 bucket 分片的坑——这些问题在几百万对象时不明显，到几十亿对象时集中爆发。XEOS 的价值就在于这个规模已经被验证过。
适用：生产环境的对象存储，需要稳定性和技术支持。
其它值得知道的
| 方案 | 一句话定位 | 什么时候考虑 |
|---|---|---|
| 3FS | 面向 AI 的高性能分布式文件系统 | 关注新技术，愿意承担较新项目的风险 |
| JuiceFS | 元数据放外部数据库 + 数据放对象存储 | 计算在云上，已有 RDS 和对象存储 |
| Longhorn | K8s 原生轻量块存储 | 小规模、边缘、开发测试 |
| local-storage | 本地盘的 CSI 封装 | 缓存数据，或应用自身有 HA（如 etcd、分布式数据库） |
| NFS | 最通用的文件共享 | 外部带 HA 的 NAS；或小规模/开发环境自建 |
它把文件系统拆成两半：元数据放 Redis / MySQL / TiKV 这类外部数据库，数据切块后放对象存储。
这个设计的价值在云环境：你不需要自己运维存储集群，直接用云商的 RDS 和对象存储，成本低且弹性好。代价是元数据数据库成为性能和可用性的关键路径，而且延迟高于本地部署的并行文件系统。
看到这个架构，你应该能立刻推断出它的适用边界——这就是学习架构取舍而不是记参数的价值。
一张横向对照表
按"该选谁"的角度整理：
| 场景 | 首选 | 备选 | 不建议 |
|---|---|---|---|
| AI 训练（海量小文件、多租户） | Weka / VastData | GPFS ECE | CephFS |
| AI 训练（单租户、预算有限） | GPFS ECE | VastData | CephFS |
| HPC 并行计算 | GPFS ECE / Weka | VastData | CephFS |
| 通用共享文件（非 AI） | CephFS / NFS | GPFS | |
| 虚拟机 / 数据库块存储 | Ceph RBD | VastData Block | 对象存储 |
| 大规模对象存储（生产关键） | XSKY XEOS | VastData S3 | Ceph RGW |
| 对象存储（非关键、预算紧） | Ceph RGW | ||
| 备份归档 | Ceph RGW + EC | XEOS | 全闪方案 |
| 云上文件系统 | JuiceFS | 自建 Ceph | |
| K8s 小规模块存储 | Longhorn / local-storage | Ceph RBD | 商业方案（过重） |
评估陌生方案的七个问题
L3 的选型课里列过，这里再强调一遍，因为它是这一节真正要带走的东西：
- 规模验证：现网最大部署多少节点/容量/对象数？有参考客户吗？
- 故障行为：坏盘、宕机、断机架分别怎样？重建期间性能下降多少？
- QoS 粒度：能限带宽、IOPS 吗？能限元数据 IOPS 吗？
- 扩容路径：能在线扩容？影响多大？能缩容吗？
- 升级方式：滚动还是停机？跨大版本怎么办？
- 支持能力：SLA？中文支持？现场支持？
- 退出成本：数据怎么迁出？有标准协议兜底吗？
- 恢复期间的性能——健康状态的峰值所有厂商都很漂亮，降级状态才见真章
- 元数据密集负载——用你真实的数据集结构去测，不要用厂商提供的测试脚本
- 异常操作——拔盘、断网、杀进程，看它怎么反应、怎么报警、多久恢复
只测峰值带宽的 POC 等于没测。
VastData 的 DASE 架构与 Ceph 最根本的架构差异是什么？
客户要建一套几十亿对象规模的生产对象存储，稳定性要求高，预算充足。最合适的是？
做存储 POC 时，下面哪些是必须测的？（多选）
这节课的落点
- Weka：性能天花板，授权贵、支持弱、人才难找
- VastData：DASE 架构（无状态计算 + 共享存储），多协议统一 + QoS + 原厂支持
- XEOS：大规模对象存储的稳定选择，价值在于规模已被验证
- JuiceFS：云环境的低成本方案，元数据库是关键路径
- 选型看场景对照表，但更重要的是理解每家的架构取舍
- 评估陌生方案问七个问题；POC 必测降级性能、元数据负载、异常行为
延伸资料
- ·k8s-in-action
storage/weka/ - ·k8s-in-action
storage/vast/ - ·k8s-in-action
storage/xsky/ - ·Storplan 容量与性能规划 ↗