4. 文件存储 CephFS
本章目标
- 部署 MDS 并挂载 CephFS，理解元数据池与数据池的分离
- 理解 MDS active/standby 与元数据缓存对性能的决定性影响
- 知道 CephFS 的适用与不适用边界
4.1 CephFS = 元数据池 + 数据池
CephFS 把一个文件系统拆成两个 pool：
文件系统 myfs
/ \
metadataPool dataPools
（目录树、inode、 （文件内容切成 4MiB 对象）
xattr、打开文件表） 可副本、可 EC 4+2
通常：ssd + 3副本 通常：EC 提得盘率为什么分离？元数据是小、随机、极热的负载（一次 ls 可能摸几百个 inode），必须 SSD + 副本伺候；文件数据是大块顺序，EC 便宜大碗。一套 pool 伺候两种负载必然两头不讨好 —— 这与 rook 指南里 metadataPool.deviceClass 必须为 ssd 的硬性要求是同一条经验。
4.2 MDS：POSIX 语义的提供者
RBD 为什么不需要元数据服务？因为"块 0 到块 N"的映射就是简单切分，客户端自己算。而 POSIX 文件系统要回答"路径 /a/b/c.txt 在哪"、"谁能读"、"我读到的是别人写过的"—— 这些一致性答案由 MDS 集中给出：
- MDS 维护目录树与 inode，把"文件→对象列表"的映射告诉客户端
- 客户端之后的数据读写直接找 OSD（MDS 不在数据路径上）
- 通过 capabilities（caps） 机制做多客户端缓存一致性：谁持有写 cap、谁只有读 cap，避免每次操作都问 MDS
ceph fs status 查看 active/standby：MDS 是 active + standby（不是负载均衡），元数据热点天然受限于单个 active MDS 的能力 —— 这是 CephFS 边界的根源。
内存是 MDS 的性能命脉。rook 手册给出的实战数字：生产 metadataServer.resources.memory 至少 32Gi；每条元数据约占 3KB 内存，热元数据全在内存时性能最好，内存不足会频繁回收缓存造成"断崖式"性能下降 —— 表现为"平时挺好，一到大促/高峰就卡"。
4.3 挂载方式
# 内核客户端（推荐：性能好，随内核发布）
mount -t ceph mon1,mon2,mon3:/ /mnt/cephfs -o name=admin,secret=<key>
# 子目录挂载 + 只读示例：
mount -t ceph ...:/subdir /mnt/ro -o name=xx,secret=xx,ro
# FUSE（ceph-fuse）：功能新、可移植；性能略低
ceph-fuse /mnt/cephfs内核客户端版本跟内核走（新特性滞后），FUSE 跟 Ceph 版本走。实验环境两者都试一遍，注意多客户端同挂时的缓存一致性由 caps 保证 —— 但应用层自己缓存文件内容（如 NFS export 后再 export）依然危险。
4.4 适用边界
| 适用 ✅ | 慎用 ⚠️ |
|---|---|
| 共享目录、家目录、容器共享卷（RWX） | 海量小文件 + 极高元数据 OPS 的 AI 训练场景（storplan 选型表明确标注） |
| 中等规模的文件服务、备份目标 | 超大单目录（百万级 entry 的 ls） |
| 混合负载的统一存储 | 对 P99 极敏感的低延迟共享 |
AI 场景慎用的根因：训练是"数千客户端同时打开百万小文件"，元数据压力集中在单 active MDS + 每元数据 3KB 内存的缓存模型上，容量与 OPS 都容易撞墙。这正是 GPFS ECE / Weka / VastData 的主场 —— 第三篇选型详细对比。
本章小结
- 双池设计：元数据池（ssd+副本）与数据池（EC）各司其职
- MDS 管语义与一致性（caps），数据路径直连 OSD
- MDS 内存 ≥32Gi 是生产硬要求；性能断崖多来自元数据缓存不足
- 共享目录用 CephFS；海量小文件 AI 负载慎用