这是Ceph开发每周谈的第九篇文章，记录从16年2月1号到16年2月7号的社区开发情况。笔者从前年开始做Ceph的技术模块分析到今年中告一段落，想必有挺多人期待下一篇Ceph技术分析。考虑到Ceph的发展已经从前年的一穷二白到现在的如火如荼，但对于社区的方向和实况仍有所脱节，笔者考虑开始Ceph开发每周谈这个系列。每篇文章都会综述上周技术更新，围绕几个热点进行深度解析，如果正好有产业届新闻的话就进行解读，最后有读者反馈问题的话并且值得一聊的话，就附上答疑部分。
-
上周综述
这周三晚上举行了第一次 CDM(Ceph Developer Monthly)，大约有50多名开发者参与其中。
-
压缩
在早几期我们就交流过 Ceph Maillist 对于压缩的讨论，目前已经在 PR 中的网络传输压缩和 EC 场景压缩。EC 实际上可以在 Ceph 的多个层面做，比如客户端如 RGW，LibRBD，也可以在 PGBackend 层也就是目前已经实现的部分，最后是 ObjectStore 层面，通过新增接口允许上层主动发出压缩提示，同时 ObjectStore 也可以后台捕捉未压缩对象进行智能处理。之前 Mirantis 坚持在 OSD 同意做压缩，使得不同的接口都能够享受到压缩的好处，但是从实现和效果上来讲，公用基础压缩组件，在不同的客户端接口实现压缩的效果更好，Samuel Just 一直是给 RADOS 减负的倡导者，因此，在他的力推下，压缩功能会在客户端实现，如 Rados Gateway，Mirantis Hanmean 承接了这个项目。按照目前已有的压缩组件来说，应该很快能看到。另一方面，针对块和文件，实际上在客户端的复杂度非常高，因此 Sage Weil 提议在 ObjectStore 做后台压缩，前端可以发出压缩提示。这样前后端共同发力。
-
加密
加密跟压缩在实现逻辑上很相似，但是区别在于加密还要增加一个 Key Manager，在之前我们就聊过 Ceph 本身对接 Key Manager 非常复杂，这次讨论也主要确定了各个接口各自行事，比如在块场景下，OpenStack 本身就有 Key Manager，而且 QEMU 今年刚支持块级的加密特性，因此块场景 Ceph 寄希望于上层云平台统一管理，对于 Ceph 自身透明化。在对象存储级别，AWS S3 本身在协议上就定义了加密支持，因此也会比较平滑。在加密上，Mirantis 也一直寄希望于在 OSD 级别同意实现，但是 Samuel Just 不太同意在这层做任何加密逻辑，况且把 Key Manager 的工作交给 Ceph 本身就不太合理，因为实际上加密的 Key 通常由实际用户自己保存，存储系统管理员不应该接触，如果交给 OSD，那么存储系统管理员就可以掌握所有 Key，这个本身就不合理。因此，Ceph 会在 Rados Gateway 实现加密对接，在块场景被动接受，不会做整个加密框架和实现。
-
EC 全场景支持
EC Overwrite 主要是为了让 EC Backend 能够在更多的 Ceph 场景中发挥作用，使得块和文件都有机会直接使用 Erasue Code 作为后端。目前的实现由 XSky 实现并在 PR 列表上。这次主要讨论了性能优化问题，由 BlueStore 提供对 Erasue Code 合适的 no copy 接口来解决 apply 的原子性问题