关于Ceph现状与未来的一些思考
转自：https://www.ustack.com/blog/sikao/
Ceph从2004年提交了第一行代码，至今为止已经10年了。这个起源于Sage博士论文，最早致力于开发下一代高性能分布式文件系统的项目，现在也成为了开源社区众人皆知的明星项目。特别是随着云计算的发展，Ceph乘上了OpenStack的春风，受到各大厂商的待见，Intel、DreamHost、SanDisk、CISCO、Yahoo等公司都或多或少的参与其中。RedHat更是一掷千金，直接砸了1.75亿美金将Sage创建的Inktank公司及其Ceph团队收入囊中，将其作为IaaS三大组件计算、网络、存储之一。
在这十年的发展过程中，Ceph似乎越来越向着云计算的方向靠拢，最先的CephFS文件系统已经不再是开发重点，甚至开发已经陷入了停滞状态。而与虚拟化相关的RBD、RGW则成了发展重点，成为发展最快的模块。但是从代码中仍然能够看到各种遗迹，似乎在告诉后来人这段饶了一个大弯的历史。
Ceph发展现在仍然快的眼花缭乱，让我们暂时停下脚步，看看经过十年发展后，现在Ceph的优势与缺点。
一、优势
- CRUSH算法
CRUSH算法是Ceph最初的两大创新之一（另一个是基于动态子树分区的元数据集群），也是整个RADOS的基石，是Ceph最引以为豪的地方。
CRUSH在一致性哈希基础上很好的考虑了容灾域的隔离，能够实现各类负载的副本放置规则，例如跨机房、机架感知等。同时， CRUSH算法支持副本和EC两种数据冗余方式，还提供了四种不同类型的Bucket（Uniform, List, Tree, Straw），充分考虑了实际生产过程中硬件的迭代式部署方式，虽然实际生产中大多数情况下的都是只用了一种Straw。
另外根据Sage的论文，CRUSH算法具有相当好的可扩展性，在数千OSD的情况下仍然能保证良好的负载平衡。但这更多是理论层面的，目前还没有人给出在数PB规模的生产环境中的测试结果。
总的来看，CRUSH算法仍然是目前经过实践检验的最好的数据分布算法之一。
2. 统一存储架构
Ceph最初设计的RADOS是为其实现一个高性能的文件系统服务的，并没有考虑对于块设备、对象存储的支持，也就没有什么RBD、RADOS GateWay，跟别提OpenStack和qemu之类的了。但谁想无心插柳柳成荫，由于 RADOS 出色的设计和独立简洁的访问接口，再加上Sage敏锐的眼光，Ceph社区果断推出了用于支持云计算的分布式块存储RBD和分布式对象存储RADOS GateWay，并将开发中心全面转向云计算领域。
不得不说，RADOS的设计还是非常的优秀。从架构上来看，RBD和RADOSGateWay实际上都只是RADOS的客户端而已，但得益于RADOS的优秀设计，RBD和RADOSGateWay的设计和实现都很简单，不需要考虑横向扩展、冗余、容灾、负载平衡的等复杂的分布式系统问题，同时能够提供足够多的特性和足够优秀的性能，因此迅速得到了社区的认可。另一方面，Ceph为OpenStack提供了良好的支持，成为了目前最火的OpenStack底层存储系统。乘着云计算和OpenStack的东风，Ceph作为一个统一存储系统，似乎大有舍我取谁之势。
3.丰富的特性
Ceph的特性不可谓不多，从分布式系统最基本的横向扩展、动态伸缩、冗余容灾、负载平衡等，到生产环境环境中非常实用的滚动升级、多存储池、延迟删除等，再到高大上的CephFS集群、快照、纠删码、跨存储池缓存等，不可谓不强大。
但是就像大多数开源系统一样，Ceph的基本特性，或者说真正在生产环境中用的上的特性还是非常靠谱的，但其他“高级”特性就只能打一个问号了。特别是在CephFS模块，由于Ceph社区目前的开发重点主要还是与云计算相关的部分，即RBD和RADOSGateWay，导致CephFS的开发停滞了很久，相关的特性，例如元数据集群、快照等，目前都不满足生产环境的要求。
二、缺点
- 代码质量
代码质量的问题，实际上是个仁者见仁智者见智的问题。
Ceph主要使用C/C++语言编写，同时外围的很多脚本和工具用了Python。之所以要说明Ceph的语言构成，是因为代码质量实际上是和语言具有密切的关系。不否认用C++也能写出优雅的代码，但相比于更加“现代”的语言，要想写出具备同样可读性、结构良好、调理清晰代码，C++要困难很多。但是，由于存储作为底层系统，对效率的追求是无止境的，因此不太可能舍弃对于内存等底层系统资源的控制，而使用Java/Python这类的语言。而作为一个开源项目，期望所有的贡献者都是C++的高手，未免有些强人所难，这似乎成了一个死结。其他类似的开源项目怎么办呢？貌似他们都用的纯c……
另一方面，Ceph广泛使用了STL，在部分核心代码中还是用了BOOST，这两者在底层核心系统代码中的可用性也一直存在争议。这更加加剧了代码质量的挑战性。
最关键的是，Ceph似乎已经被太多已经背负了太多的历史包袱，比如最核心的osd模块，最初的设计包含OSD和PG类，其中PG类负责PG的通用逻辑，OSD负责管理所有的PG。然后PG的子类ReplicatedPG实现了以副本作为冗余模式的PG。这里就存在了两个半类：OSD、PG及其子类ReplicatedPG，这两个半类实现了osd模块99%的逻辑，可以想象这两个半类会有多大。
在目前的master分支上，相关文件的大小分别是：
OSD.h+OSD.cc = 2383行+8604行 = 10987行
PG.h+PG.cc = 2256行+7611行 = 9867行
ReplicatedPG.h+ReplicatedPG.cc = 1487行+12665行 = 14152行
需要特别注意的是，从C++继承的角度上，理解一个类，必须理解他的父类，也就是说，如果你想理解ReplicatedPG，理论上你必须同时理解PG，也就是说，要同时理解20000+行代码！
更加丧心病狂的是，这两个半类之间存在密切而复杂的调用关系，相互之间直接使用整个类，而没有什么实际上的接口隔离。严重加剧了理解代码的难度。
在EC功能以一种奇葩的方式加入到osd中之后，整个场面更加混乱。按照最初的设计，实现EC应该增加PG的一个子类，类似ErasureCodePG。但是由于ReplicatedPG包含了太多通用的代码，实际上已经和PG合二为一了，所以EC只能在ReplicatedPG的基础上改造。于是又出现了PGBackend的概念和相关的实现，这只能说是挑战人脑的极限了。
Ceph社区也曾试着梳理代码，比如添加OSDService类，作为PG与OSD通讯的接口。这样所有的PG全部调用OSDService而非OSD，相当于做了OSD与PG之间的隔离。但是似乎并没有起到足够的效果，现在已经名存实亡了。
Ceph在这样的代码质量下，还能向前走多久，委实是一件令人担忧的事情。
2. 性能
Ceph的性能总的来说还是不错的，基本上能发挥出物理硬件的性能，但是存在以下几个隐患：
1）数据双倍写入。Ceph本地存储接口（FileStore）为了支持事务，引入了日志（Journal）机制。所有的写入操作都需要先写入日志（XFS模式下），然后再写入本地文件系统。简单来说就是一份数据需要写两遍，日志+本地文件系统。这就造成了在大规模连续IO的情况下，实际上磁盘输出的吞吐量只有其物理性能的一半。
2）IO路径过长。这个问题在Ceph的客户端和服务器端都存在。以osd为例，一个IO需要经过message、OSD、FileJournal、FileStore多个模块才能完成，每个模块之间都涉及到队列和线程切换，部分模块在对IO进行处理时还要进行内存拷贝，导致整体性能不高。
3）对高性能硬件的支持有待改进。Ceph最开始是为HDD设计的，没有充分考虑全SSD，甚至更先进的PCIe SSD和NVRAM的情况NVRAM。导致这些硬件的物理性能在Ceph中无法充分发挥出来，特别是延迟和IOPS，受比较大的影响。
3. CephFS
CephFS现在在整个Ceph系统中处于一个较为尴尬的情况，因为POSIX这种借口似乎在云计算中没有用武之地，导致了社区对这个模块的关注不足，也就没有什么进展。
CephFS作为最初Ceph的设计目标，Sage投入了巨大的精力，几乎实现了所有需要的特性，并且进行了大量工程层面的优化。
正所谓成也萧何败萧何，Ceph想把CephFS模块做到足够强大，甚至是最强大，但强大的同时也意味着不菲的代价。元数据动态子树分区、目录分片、快照、权限控制、IOPS优化、故障恢复、分布式缓存、强弱一致性控制，这些高大上的名词背后都意味着复杂的工程性任务，更不要说将这些叠加在一起。很多时候，叠加不是想加，而是相乘的关系。最终的结果就是整个MDS的工程难度已经超过了可以掌控的程度，无法做出足够成熟、稳定的系统。
目前CephFS宣称其单MDS的模式是稳定的，MDS的集群的模式是不稳定的。而快照功能默认关闭，今后也够呛会有开启的可能了。
4. 业务连续性
Ceph中的RADOS采用强一致性设计，即Write-All-Read-One，这种模式的好处在于读取效率较高，而且工程难度较低，比较适合与读多写少的系统。
Write-All-Read-One的特点是必须等待所有的副本全部写入完毕才算是写入成功，这实际上对系统硬件的可靠性要求较高，因为如果在写入过程中存在任意硬件故障，则写入过程都要受影响。通常表现为卡顿，一般在数秒级别，时间长短和判断故障的机制以及故障恢复过程中IO的处理策略相关。
但是当集群非常非常大时，Write-All-Read-One对于硬件可靠性的要求几乎是无法满足的。想象一下一个10PB的系统，按照最大4TB每块盘的计算，就有2500块磁盘。按照我们以往的运维经验，每周存在一块磁盘故障是完全正常的。这种场景下，如果数据分布足够分散，实际上一块磁盘可能涉及到很多数据块，也就是说一块磁盘故障会影响很多IO，而这种情况每周发生一次。这对业务连续性的影响是已经是不可忽略的。
生产环境中的场景比这个更加复杂，因为磁盘或者硬件的故障可能不仅表现为不可写，还有可能是慢或者不稳定。这些情况对于业务连续性的影响也更加严重。
5. 社区
Ceph社区现在已经有很多厂商实际上或者号称参入进来，其中不乏Intel、Dreamhost、SanDisk这样的大厂，也不乏UnitedStack这样的Start-Up公司，还有电信、大学、研究所这类非存储领域的公司或单位。但实际上整个Ceph还是掌握在Inktank或者说RedHat的手中，绝大多数核心代码由他们贡献，也是他们Review和Merge。总的来说还是一个集权组织。
更加重要的是，Ceph相比OpenStack这种成熟完善的开源社区，缺乏足够的基础设施，例如成熟的单元测试、集成测试、测试环境、Reivew流程、贡献指引、代码规范等。导致整个社区仍然是人治、而非法制的过程，代码和系统的发展方向本质是由RedHat公司控制的。
对于以上这些问题，Ceph社区也非常清楚，并且正在或者将要改进。例如为了增加了对于SSD的支持，改进数据双倍写入问题以及更完善的社区建设和基础设施等。这些都增加了人们对Ceph的信心。
总的来说，Ceph瑕不掩瑜，仍然是一个优秀，甚至出色的开源存储系统。如果说分布式存储在云计算时代是风口上的猪，那么Ceph也是一直优秀的猪。
未来是什么样子，我们拭目以待。
关于作者：袁冬博士，UnitedStack产品副总裁，负责UnitedStack产品、售前和对外合作工作；云计算专家，在云计算、虚拟化、分布式系统和企业级应用等方面有丰富的经验；对分布式存储、非结构数据存储和存储虚拟化有深刻地理解，在云存储和企业级存储领域有丰富的研发与实践经验；Ceph等开源存储项目的核心代码贡献者。
