Ceph开发每周谈 Vol 15—Unix Socket / BlueStore 压缩和 Checksum

2016年03月 · 麦子迈

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

  • 上周综述

最后一个 Jewel 开发版本 10.0.4 在上周释出,本周共合并了 138 个 commits,仍然在等待 RBD Mirror 和 RGW 的 multisite 一些 bug fix。值得注意的是,上周修复了一个 Hammer 版本 Cache Tier 可能造成 Data Corrupt 的严重 Bug,这个 Fix 会在 0.94.7 版本中修复。

  • AsyncMessenger Unix Socket

上周富士通提交了针对同机器的网络优化,优先选择 Unix Socket 而不是 TCP Socket,使得如果在单机大量 OSD 如 12 个 OSD 的情况下,CPU 利用率降低同时带宽能力得到提高。根据测试的情况,单机 4 个 OSD 情况下,带宽就提高了5-10%,CPU 也得到了10%的下降。

  • BlueStore 压缩/Checksum

上周邮件列表的重点讨论内容是 BlueStore 的压缩实现问题,BlueStore 由于自身管理 Device 的存储空间和分配关系,因此压缩特性实现在这层次会大大减少实现于上层可能的 Read Before Write 问题,同时,由于 BlueStore 的 Allocator 和 Onode 本身就带有这类 flags,扩展这些结构就能够兼容并支持压缩特性。社区的主要讨论点在于处理 Overwrite 或者 Partial Write 的一些实现,如何尽量减小 IO 的请求。同时 BlueStore 支持各种不同的 size,这使得 Compression Extent 要尽可能包含更多信息。而另一个事情是 checksum 的嵌入,之前 FileStore 一直想实现端到端的 data checksum,但是在 filestore 之上实现 checksum 的性能损耗太大了。正好 bluestore 即将引入 compression,那么 data checksum 的引入也会比较自然。因为 checksum,compression,encryption 所面临的逻辑管理问题是一致的。checksum 的引入会使得 ceph 成为第一个端到端数据校验的分布式存储系统,将大大提高分布式存储潜在的数据 silent corrupt 可能性。