系统设计的角度看GlusterFS&&ceph

GlusterFS和ceph是开源领域很火的两个分布式文件系统。技术文章也有不少。这里只谈下个人的一些看法，大家讨论比较多就不提了。

GlusterFS的几大特点：

1.所见即所得，一个文件究竟长什么样，完全取决于client对于posix文件api的解释。副本怎么写，文件从哪里读，等等，都是client决策的。

2.keep is simple and stupid。每个posix的api，都转化为client段的一个rpc调用，每个rcp调用又由client和server端多个插件的pair组成。

3.堆栈式架构，plugin模式，每一种文件系统的特性（副本、预读等），只需要实现一个plugin即可， 当然这个plugin是用c写的一个so库，代码读取来有点复杂，需要有一定C语言功底。而且跟nginx的模块方式不同，nginx的模块是之间是水平关系，GlsuterFS的模块是垂直关系，堆栈式。

4. client出于性能考虑，client采用了coroutine的方式，C语言实现的coroutine代码看起来稍有点别扭。基于rcp的高并发、高吞吐的分布式系统，采用coroutine的方式具有很大的优势。nginx+lua这种高并发的场景，就可以很好的利用lua的native coroutine特性。

GlusterFS不足：

1.没有引入引虚节点（新版本有考虑），扩容时灾难

2.没有一个zookeeper之类集群中台管理模块，可能出现脑裂，且集群更新配置困难。

3.集群配置采用了简单的两两建链的方式，集群规模大了之后，性能有问题，每个集群节点都有与维护n-1一个tcp长链，切更新的时候没有分层广播。

这些问题社区在新版本都计划去解决，拭目以待吧。

ceph是出自于大学实验室的产品，秉承了严谨的学术风范。当然，实验室和社区产品，可能是由于社区方式开发协作困难，不够规范等方面的因素，据说代码质量一般，c++不熟，勿喷。ceph是天生为大规模集群设计的，thousands of nodes。

1.对象存储的思想把存储系统构建简单化，采用伪随机算法计算副本位置，这个跟传统的一致性hash或者中心控制节点的思想截然不同。

2.同一个集群状态管理模块ceph-mon，好像是基于paxos（为什么没用Raft？）

3.考虑到集群规模比较大，状态的传播采用的分级转发的方式（好像没用gossip协议）。

ceph-rbd很火，但是上次看社区又投精力去做fs了的bug-fix了。

ceph出来也不少年了，一开始目标是共产主义色彩的全能型分布式文件系统，搞了挺久文件系统一直没起色，没想到后来因为虚机块存储火（ceph-rbd）了，成了有中国特色的社会主义。有心栽花花不发，无心插柳柳成荫。

感觉GlusterFS和ceph各是两个极端，一个简单，一个复杂。简单的东西，速成，但先天缺陷，想继续拔高很痛苦；复杂的东西，理想色彩太浓厚，如果不是遇到IaaS的迅速发展带来的弹性块存储EBS需求，ceph或许早就流产了。