主流分布式文件系统总结

1. GlusterFS

文件系统标准的 posix 接口支持，可以做分布式的软件 NAS，效果莫的 HPC 共享存储，k8s/openstack 共享存储。

实现了一个 stack 式可插拔的 plugin 模式，将文件系统的各种 feature 做成了不同的插件，比如 stripe，replicate，hashErasureCode，consistent-hash 等。胖客户端的设计导致了 client 的 cpu 利用率会比较高，虽然用 c 语言实现了协程做以应对网络 io 的高并发。成熟的 3.x 版本，服务器端没有强一致性的元数据设计，最新的 4.x 版本变化很大，主要是解决强者一性、集群扩展性瓶颈等问题扩容麻烦，副本 rebalance 效果不好，坑比较大。

2. cephfs

其底层是一个对象存储系统，即 ceph 的 rados 对象存储。

rados 的 crush 算法比较有特点，是一种伪随机算法，既考虑了硬件的物理拓扑，也考虑了单点失败后，数据修复或者复制过程中，最小化 data migrate。相对于一致性 hash 等副本 allocation 算法，在大规模的场景下，效果比较要好；

rados 的基础上，ceph 支持块存储 ceph RBD，对象 ceph RGW，文件系统 cephfs；ceph RBD 和 ceph RGW 比较成熟，ceph 最初是跟着 openstack 一起火起来。ceph 也可以作为 openstack/k8s 社区有用来共享存储，不过 RBD 只支持 ReadWrite once，不支持多个共享写；

回到 cephfs 上。cephfs 设计的比较理想化，对目录树做了动态分区，每个分区是主备高可用，metadata server 只是内存 cache，持久化在 rados 中。cephfs 的特性过于复杂，bug 比较多。后期社区修改了 bug，但是稳定性方面有待加强。目前只有单目录树的主备方式是可用的，三节点多活问题很多。社区方面，国内也一些创业公司和传统厂家在做 ceph 相关的产品，比如北京的 xsky 吧。

目前 ceph 社区的关注点主要是本地存储引擎 bluestore，以及用户态的 block io stack（intel 的 spdk）。据说国内主流云数据库解决方案也是在 ceph rbd 基础上做的分布式存储引擎。

3. Lustre

比较老牌的分布式文件系统，部署在多个 san 阵列上，不支持副本，支持分布式锁，主要做 HPC 高性能计算；luster 对 posix 的语义应该支持的比较好。之前 intel 在维护社区，主要目的是为了卖自己的 cpu 给一些 HPC 用户，后来 intel 是退出了。

4. HDFS

只支持追加写，设计中没有考虑修改写、截断写、稀疏写等复杂的 posix 语义，目的并不是通用的文件系统，一般作为 hadoop ecosystem 的存储引擎；HDFS 在 bigdata 领域使用很广泛，但其实 big data 用 s3 也是可以的。