写点什么

关于 Ceph 现状与未来的一些思考

2015 年 6 月 26 日

在这十年的发展过程中,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 算法仍然是目前经过实践检验的最好的数据分布算法之一。

统一存储架构

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 作为一个统一存储系统,似乎大有舍我取谁之势。

丰富的特性

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 在这样的代码质量下,还能向前走多久,委实是一件令人担忧的事情。

性能

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,受比较大的影响。

CephFS

CephFS 现在在整个 Ceph 系统中处于一个较为尴尬的情况,因为 POSIX 这种借口似乎在云计算中没有用武之地,导致了社区对这个模块的关注不足,也就没有什么进展。

CephFS 作为最初 Ceph 的设计目标,Sage 投入了巨大的精力,几乎实现了所有需要的特性,并且进行了大量工程层面的优化。

正所谓成也萧何败萧何,Ceph 想把 CephFS 模块做到足够强大,甚至是最强大,但强大的同时也意味着不菲的代价。元数据动态子树分区、目录分片、快照、权限控制、IOPS 优化、故障恢复、分布式缓存、强弱一致性控制,这些高大上的名词背后都意味着复杂的工程性任务,更不要说将这些叠加在一起。很多时候,叠加不是想加,而是相乘的关系。最终的结果就是整个 MDS 的工程难度已经超过了可以掌控的程度,无法做出足够成熟、稳定的系统。

目前 CephFS 宣称其单 MDS 的模式是稳定的,MDS 的集群的模式是不稳定的。而快照功能默认关闭,今后也够呛会有开启的可能了。

业务连续性

Ceph 中的 RADOS 采用强一致性设计,即 Write-All-Read-One,这种模式的好处在于读取效率较高,而且工程难度较低,比较适合与读多写少的系统。

Write-All-Read-One 的特点是必须等待所有的副本全部写入完毕才算是写入成功,这实际上对系统硬件的可靠性要求较高,因为如果在写入过程中存在任意硬件故障,则写入过程都要受影响。通常表现为卡顿,一般在数秒级别,时间长短和判断故障的机制以及故障恢复过程中 IO 的处理策略相关。

但是当集群非常非常大时,Write-All-Read-One 对于硬件可靠性的要求几乎是无法满足的。想象一下一个 10PB 的系统,按照最大 4TB 每块盘的计算,就有 2500 块磁盘。按照我们以往的运维经验,每周存在一块磁盘故障是完全正常的。这种场景下,如果数据分布足够分散,实际上一块磁盘可能涉及到很多数据块,也就是说一块磁盘故障会影响很多 IO,而这种情况每周发生一次。这对业务连续性的影响是已经是不可忽略的。

生产环境中的场景比这个更加复杂,因为磁盘或者硬件的故障可能不仅表现为不可写,还有可能是慢或者不稳定。这些情况对于业务连续性的影响也更加严重。

社区

Ceph 社区现在已经有很多厂商实际上或者号称参入进来,其中不乏 Intel、Dreamhost、SanDisk 这样的大厂,也不乏 UnitedStack 这样的 Start-Up 公司,还有电信、大学、研究所这类非存储领域的公司或单位。但实际上整个 Ceph 还是掌握在 Inktank 或者说 RedHat 的手中,绝大多数核心代码由他们贡献,也是他们 Review 和 Merge。总的来说还是一个集权组织。

更加重要的是,Ceph 相比 OpenStack 这种成熟完善的开源社区,缺乏足够的基础设施,例如成熟的单元测试、集成测试、测试环境、Reivew 流程、贡献指引、代码规范等。导致整个社区仍然是人治、而非法制的过程,代码和系统的发展方向本质是由 RedHat 公司控制的。

对于以上这些问题,Ceph 社区也非常清楚,并且正在或者将要改进。例如为了增加了对于 SSD 的支持,改进数据双倍写入问题以及更完善的社区建设和基础设施等。这些都增加了人们对 Ceph 的信心。

总的来说,Ceph 瑕不掩瑜,仍然是一个优秀,甚至出色的开源存储系统。如果说分布式存储在云计算时代是风口上的猪,那么 Ceph 也是一直优秀的猪。

未来是什么样子,我们拭目以待。

编后语

为了更好地向读者输出更优质的内容,InfoQ 将精选来自国内外的优秀文章,经过整理审校后,发布到网站。本篇文章作者为袁冬,原文链接为『关于Ceph 现状与未来的一些思考』。


感谢郭蕾对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作,请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博( @InfoQ @丁晓昀),微信(微信号: InfoQChina )关注我们,并与我们的编辑和其他读者朋友交流(欢迎加入 InfoQ 读者交流群)。

2015 年 6 月 26 日 00:235126

评论

发布
暂无评论
发现更多内容

沟通是一门艺术

石云升

情绪控制 沟通艺术

微服务的基建工作

看山

微服务 基础设施

第二周学习总结

Vincent

极客时间 极客大学 作业

论商品促销代码的优雅性

架构师修行之路

区块链数字钱包定制开发,数字货币钱包开发费用

13530558032

云算力挖矿平台APP,一站式云算力挖矿系统开发

13530558032

智能化转型将加速数字经济变革

CECBC区块链专委会

人工智能 数字经济

架构师训练营 -- 第11周作业

stardust20

Apache 软件基金会顶级项目 Pulsar 达成新里程碑:全球贡献者超 300 位!

Apache Pulsar

Apache Apache Pulsar 消息系统 消息中间件

Spring系列篇:Spring容器基本使用及原理

简爱W

开源流数据公司 StreamNative 推出 Pulsar 云服务,推进企业“流优先”进程

Apache Pulsar

Apache Pulsar 消息系统 消息中间件

区块链承兑商支付系统开发,USDT支付软件搭建

13530558032

第11周学习总结

赵龙

架构师第十一周作业及总结

傻傻的帅

微服务编程范式

看山

微服务 范式

一次开零售店的经历(1)

石云升

零售店

银行热衷拿区块链专利 背后有何意图

CECBC区块链专委会

区块链 银行

架构师训练营第十一周作业

张明森

第11周作业

赵龙

安全系列之——主流Hash散列算法介绍和使用

诸葛小猿

hash 散列函数 md5 sha1 murmurhash

架构师训练营第11周作业

Bruce Xiong

一次开零售店的经历(2)

石云升

零售店

有益思考一则:框架性思维

石君

学习 方法论

第二周作业

Vincent

极客时间 作业

ArCall 升级丨新增多项功能,可支持多人在线语音

anyRTC开发者

音视频 WebRTC 直播 RTC

游戏夜读 | 什么才值得纪念?

game1night

薪水真的不是工作的全部

escray

学习 面试 面试现场

悬挂引用是如何被Rust消灭的?

袁承兴

rust 内存模型 指针 引用 泛型

一起学MySQL性能优化

xcbeyond

MySQL 性能优化 MySQL性能优化

跨过语言银河,构筑智能鹊桥:百度NLP的十年、今夕与未来

脑极体

架构师训练营第十一周总结

张明森

InfoQ 极客传媒开发者生态共创计划线上发布会

InfoQ 极客传媒开发者生态共创计划线上发布会

关于Ceph现状与未来的一些思考-InfoQ