Ceph开发每周谈Vol2

2015年12月 · 麦子迈

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

本周综述

这个星期依旧是平淡的一周,从月初起 sepia lab 的机器进行大迁移,因此大部分测试都停滞下来导致代码的合并变得非常缓慢。目前 ovh 是仅存的社区测试环境。

后台加密特性

Mirantis 的同学在最近半年发起了多个巨大功能的讨论,包括前段时间的 EC 压缩(下次讨论这个富有争议的实现),本周提出了后台加密特性的引入。Ceph 加密特性内置的确是敏感存储系统的一个极具竞争力的功能,但是实际上充满了巨大挑战。

目前 Ceph 仅有的加密是依赖于 dm-crypt 内核模块,换句话说,Ceph 的部署工具支持使用 dm-crypt 配置底下存储盘,使得 Ceph 的落盘 IO 都通过 dm-crypt 加密写入。显而易见,这个方案并不能提供完整的安全保证,而且因为并不能感知到 Ceph 的 IO 使得冗余的加密操作频繁发生。Mirantis 同学提出几个问题比如实际上主 OSD 加密分发到副本可以避免 dm-crypt 的多次加密,Journal 和某些数据实际上并不需要加密,dm-crypt 的 per io 加密会有性能问题等等。

但是,Greg 和 Martin 是相当反对的,认为其并没有带来任何新的突破:

  1. dm-crypt 实际上提供了较好的性能,也并不会产生 context switch
  2. dm-crypt 被广泛使用,且易于理解
  3. 任何完整的加密安全方案都离不开 key 的整合,这个 Ceph 内置加密实现并没有解决加密系统的最关键问题
  4. 带来的复杂性是难以预估的
  5. 加密算法相对于现在的 CPU 能力来说并不会产生太严重的性能问题,而在 OSD 之上的加密管理却很可能带来严重的加密数据管理损耗,相对于简单的 dm-crypt 来说

因此,社区的其它开发中都给这个特性投了负分,Sage 更加期待去加强现有的 dm-crypt 方案,去覆盖更加广泛的 IO 路径。

EC Overwrite 特性

ErasureCode 相比副本机制,可以通过更低的存储代价获得相同的可靠性,适用于一次写多次读的应用场景。EC的最常用的编码RS(k, m),k块数据块,编码为m块校验块,可以容忍任意m块丢失。同时,为保证数据一致性,EC的写需要至少k块完成,才算写成功。通常情况下,EC 相比于副本在同样的可靠性下,只需要 1.5 x 的额外存储成本,而副本可能需要 3x。当然 EC 的最大问题是恢复的效率,目前学术界对于 EC 的改进也主要围绕恢复进行优化。而当前 Ceph 的 EC 写已存在的对象只支持追加模式,因为追加的数据,即使写失败了,也可以很方便的回滚,但这样需要修改数据时,就只能全读全写了。因此,目前 Ceph 的 EC 特性只能在对象存储时使用,或者作为 Tier 模式的冷池,并不能直接被 RBD 和 CephFS 使用。而 EC Overwrite 就是为了解决这个问题而需要做的事情。

为支持完整的EC写,设计了EC部分覆盖写的三种模式: whole-strip-write,read-modify-write,parity-delta-write。目前主要先实现前两种。如果数据足够编码条带,则直接写,不够的话,会先去对应分片拉缺少的数据。重新编解码后,就回得到完整的要修改的数据。然后修改的数据会先保存到临时对象中,所有临时对象写成功后,就可以返回客户端了,再由主OSD统一把临时对象合并到原来的对象。

这样带来两个问题,当集群状态发生改变时,PG涉及的OSD会通过主OSD发起peering来同步状态,检查PGLog数据是否一致。而EC的覆盖写可能只涉及一部分OSD,PGLog的就会不一致,权威日志的判断就会有问题;其次,临时对象的合并后,这次修改就是不能回滚了,需要在PGlog中标记。这些操作都需要我们在PG层增加额外的接口支持EC的部分写,同时在ECBackend中需要新接口能让PG层感知到合并操作。

目前 EC Overwrite 由 Sammul,Sandisk 的 Allen 和 XSky的Tianshan 一起开发。