技术文章

BLOG

Ceph开发每周谈首发

2015-12-23 · 麦子迈

这是Ceph开发每周谈的第一篇文章,记录从15年12月7号到12月13号的社区开发情况。笔者从前年开始做Ceph的技术模块分析到今年中告一段落,想必有挺多人期待下一篇Ceph技术分析。考虑到Ceph的发展已经从前年的一穷二白到现在的如火如荼,但对于社区的方向和实况仍有所脱节,笔者考虑开始Ceph开发每周谈这个系列。每篇文章都会综述上周技术更新,围绕几个热点进行深度解析,如果正好有产业届新闻的话就进行解读,最后有读者反馈问题的话并且值得一聊的话,就附上答疑部分。

上周综述

最近一直是老美的假期时间,部分开发者甚至从感恩节一直休息到元旦。社区的几个主力开发者都处于磨工状态,最近的Pull Request一直处于狂热的Bug Fix阶段,Sage 一直忙于PR的测试和修修补补。其实社区已经有一段时间没有BigBang特性进来了,因为大家都在准备手头的大块头,冲刺Jewel版本。Jewel将会像Firefly一样,拥入大量新特性的版本,大家做好期待吧。

Journal 合并改进尝试

众所周知 Ceph 的 Journal 和 Data 存在 Double Write 的问题,但是在实际 SSD 场景下,小 IO 请求(4KB)放大往往达到 2.5 倍,其中的原因是客户端来的一个请求,OSD 会形成一个事务然后写入 Journal。由于 Ceph 采用Direct IO,故4KB的io在加入一些元数据会增长到接近6KB,在Direct IO要求的数据对齐后,会再加入接近2k的padding,最终会形成8k一个事务写入 Journal,因此在小 IO 场景下形成的写放大非常严重。上周的 Journal 改进通过将多个事物进行合并,而后共同使用一个padding,因此在journal层面减少写放大。但是由于该逻辑的引入,使得写journal的逻辑变得复杂,故该逻辑比较适合中速的设备(如sata ssd),不适合高速设备 Pcie SSD。

RDMA/Infiniband 现状

大概每个月都会有 Infiniband 爱好者发邮件问社区 Ceph 对于 RDMA/Infiniband 的状况。恰好笔者过去两年有大量时间花在 Ceph 网络模块上,这次也简单介绍一下这部分近况。Ceph 在14年前都只有一个以线程模型实现的网络库,消耗大量CPU切换和内存消耗,在14年中笔者和来自CohortFS/Mellanox 的开发者差不多同时进行了新网络库的实现,后者使用了Mellanox的Accelio库(一个处于Heavy development的网络实现)。大概在14年下旬,在邮件列表和一次在线视频会议上讨论了两个实现,因为笔者是基于原有的应用协议改写实现(完全兼容原有协议),因此首先合并入主干。大概在年底基于Accelio的方案(XIO)也进入主线,用来试验支持RDMA。

由于Ceph的网络库存在大量的模块依赖和黑魔法,从去年底到今年年中,笔者的网络库才通过了所有QA测试并稳定下来,在Jewel版本应该会替换原有实现。而XIO方案由于涉及上游Accelio的依赖,在过去的半年多时间里没有太大的进展,仅仅停留在跑通IO上。笔者并没有参与到这个实现的开发中,但深知这个模块由于不兼容原有协议,深深地踩入了Ceph的网络黑魔法中。大概在今年中,笔者与Sage Weil沟通并开始着手实现基于ibverbs 的传输协议插件。

NewStore 进展

熟悉 Ceph 存储引擎的开发者肯定对目前的FileStore,KeyValueStore和NewStore有所了解,NewStore是基于KeyValueDB(Metadata)加上FileSystem(Data)的实现,希望拥有成熟文件系统对于数据的空间管理,又拥有KeyValueDB对于元数据高效查询的优势。但在实际的开发过程中碰到众多问题,不能在通用场景下获得超越FileStore的显著性能。

在上个月,Sage Weil发帖宣告实在忍受不了XFS和RocksDB带来的协作问题,忍受不了带来的额外元数据IO,宣布自己将一捅到底,直接实现一个简单用户态伪文件系统(BlueFS),将RocksDB基于此运行。让我们期待这个全新的BlueStore(NewStore的替身)的未来!