历经十年：关于Ceph现状与未来的一些思考
|
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分支上，相关文件的大小分别是：
需要特别注意的是，从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的性能总的来说还是不错的，基本上能发挥出物理硬件的性能，但是存在以下几个隐患： （编辑：云计算网_宿迁站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
