自从我们在香港部署了跨机房NFS集群之后，虽然依靠DRBD和Pacemaker实现了高可用，但随着业务横向扩展，NFS逐渐暴露出并发性能瓶颈——特别是在多个节点并发读写高清视频文件、AI中间结果缓存等场景中，文件锁竞争严重、元数据写入阻塞、吞吐上下波动不可预测。于是我启动了新一轮的文件系统评估，目标是在香港本地搭建一套具备横向扩展能力、高并发读写性能、元数据强一致性的分布式文件系统。
在评估过程中，我选择了当前在生产级部署中被广泛采用的两个方案：CephFS 与 GlusterFS，并在香港的Telehouse 与 MEGA-i 机房之间进行了实地部署与压力测试，以下是我完整的落地方案与对比结论。
一、评估目标与测试场景定义
核心需求
- 支持并发挂载与跨机房共享读写；
- 文件系统具备容错能力，不依赖单点元数据服务；
- 具备稳定的顺序与随机读写性能，支持1G+大文件；
- 适配Kubernetes容器挂载、AI训练缓存、视频处理中转等多业务场景。
部署硬件与网络环境
| 项目 | 配置说明 |
|---|---|
| 存储节点 | 3 台 Dell R730，64GB RAM，RAID10 SSD，10GbE |
| 网络拓扑 | Telehouse 与 MEGA-i 之间为L2互通链路，平均 RTT 1.2ms |
| 测试工具 | fio, bonnie++, 自定义 I/O 流调度模拟脚本 |
| 客户端数量 | 分别从香港3个不同数据中心发起挂载与压测 |
二、方案一：CephFS 落地部署与优化
1. 架构设计
[Client Node] -- MDS --+
|
[Client Node] -- MDS --+--> [Ceph MON + OSD Cluster] -- 3副本块存储池
|
[Client Node] ---------+
CephFS依托Ceph底层的RADOS对象存储构建，所有文件映射为对象，支持分布式元数据服务MDS横向扩展。我采用了单MDS起步、备用MDS冷备的方式部署，后期通过 ceph fs set <fs_name> allow_multimds true 启用多活。
2. 部署步骤摘要
# 初始化MON
ceph-deploy new node1 node2 node3
ceph-deploy mon create-initial
# 创建OSD（RAID10设备）
ceph-deploy osd create --data /dev/sdb node1
ceph-deploy osd create --data /dev/sdb node2
ceph-deploy osd create --data /dev/sdb node3
# 创建MDS
ceph-deploy mds create node1 node2
# 创建CephFS文件系统
ceph fs new cephfs cephfs_metadata cephfs_data
3. 客户端挂载配置
# 客户端安装并挂载
yum install ceph-fuse -y
ceph-fuse -n client.admin -m 10.10.10.10:6789 /mnt/cephfs
推荐启用 cephx + krbd 做认证与安全隔离，避免任意访问。
4. 性能优化要点
启用多活 MDS：
ceph fs set cephfs max_mds 2
RADOS参数优化：
osd max backfills = 2
osd recovery max active = 5
osd op threads = 8
三、方案二：GlusterFS 落地部署与优化
1. 架构设计
[Client] <-- FUSE/NFS Mount --> [Brick1@node1] <--+
[Client] <-- FUSE/NFS Mount --> [Brick2@node2] <===> GlusterFS Cluster
[Client] <-- FUSE/NFS Mount --> [Brick3@node3] <--+
GlusterFS结构相对简单，节点之间通过自平衡机制进行文件同步，支持多种卷类型（Replicate、Distribute、Stripe等）。我采用3副本同步卷（Replicate Volume）作为跨机房容错手段。
2. 部署步骤摘要
# 所有节点安装
yum install glusterfs glusterfs-server -y
systemctl enable --now glusterd
# 添加peers
gluster peer probe node2
gluster peer probe node3
# 创建并启动副本卷
gluster volume create gfsvol replica 3 \
node1:/data/brick1 \
node2:/data/brick2 \
node3:/data/brick3 force
gluster volume start gfsvol
3. 客户端挂载配置
# 使用FUSE挂载
mount -t glusterfs node1:/gfsvol /mnt/glusterfs
若用于K8s容器环境，可搭配Heketi或CSI插件做自动卷调度。
4. 性能优化建议
关闭GFID强一致同步延迟（如无分布式应用）：
gluster volume set gfsvol performance.cache-size 512MB
优化IO聚合参数：
gluster volume set gfsvol performance.io-thread-count 16
四、性能对比测试结果（香港本地）
| 指标 | CephFS | GlusterFS |
|---|---|---|
| 顺序读吞吐（单客户端） | 950MB/s | 600MB/s |
| 并发写入吞吐（4并发） | 480MB/s | 380MB/s |
| 小文件创建延迟 | 8ms | 3ms |
| MDS故障恢复时间 | <3s | 无需恢复（无集中MDS） |
| 跨机房同步延迟 | ≤2s（副本机制） | ≤5s（replica机制） |
| 扩展性 | 强（动态扩容OSD/MDS） | 一般（水平扩容需重均衡） |
| K8s原生兼容性 | 高（Rook支持） | 中（CSI稳定性一般） |
五、选型建议与落地实践经验
| 应用场景 | 推荐方案 | 原因 |
|---|---|---|
| AI训练缓存 / 大文件中转 | CephFS | 支持多活MDS、强一致、吞吐更高 |
| 视频处理工作流 / 小文件频繁写入 | GlusterFS | 元数据更新快、部署更简单 |
| 跨机房同步、非容器环境 | GlusterFS | 管理简单，维护成本低 |
| 容器环境存储卷 | CephFS（搭配Rook） | 支持PVC动态挂载，支持快照 |
实际部署经验总结：
- CephFS 虽然初期部署复杂、依赖关系多，但在大规模并发访问场景下表现更稳定，适合构建底层共享平台；
- GlusterFS 部署简单，3节点起步即可支撑日常共享访问，适合中小型、快速交付项目；
- 两者均建议启用独立内网 + jumbo frame 支持，以降低跨节点同步开销；
- 不建议混用传统NFS挂载访问这两者，可能会触发元数据一致性问题。
这次从NFS到CephFS/GlusterFS的转型部署，不仅是一次技术架构的升级，更让我重新认识了“分布式一致性”、“横向扩展成本”与“业务模型匹配”三者之间的微妙平衡。在香港多机房业务逐步走向多租户、容器化、异地热备的背景下，分布式文件系统的选型不能只看性能，更要基于业务模型与维护能力做出判断。
