这是Ceph开发每周谈的第五十篇文章，记录从16年11月21号到16年11月28号的社区开发情况。笔者从前年开始做Ceph的技术模块分析到今年中告一段落，想必有挺多人期待下一篇Ceph技术分析。考虑到Ceph的发展已经从前年的一穷二白到现在的如火如荼，但对于社区的方向和实况仍有所脱节，笔者考虑开始Ceph开发每周谈这个系列。每篇文章都会综述上周技术更新，围绕几个热点进行深度解析，如果正好有产业届新闻的话就进行解读，最后有读者反馈问题的话并且值得一聊的话，就附上答疑部分。
-
一句话消息
DataCentred(http://www.datacentred.co.uk/blog/telegraf-1-1-released-added-datacentred/) 团队发布了 Telegraf 1.1 版本，主要用于帮助 Ceph 运维人员方便的监控 Ceph 集群，减少运维操作，增加自动化。
Mirantis 发布了新的 Ceph 部署工具 Decapod，相比于 ceph-deploy，主要提供了一个 stand-alone 的方式，能够管理部署并且进行分发。https://github.com/Mirantis/ceph-lcm
OpenStack Superuser 发布了如何整合 Ceph 到 OpenStack，讨论了为什么 OpenStack 和 Ceph 组合在一起是一个神奇的组合。 http://superuser.openstack.org/articles/ceph-as-storage-for-openstack/
-
异步 Recovery
Recovery和 Backfill 是 Ceph 里面的两种数据恢复方式。Recovery 也叫做 log based recovery，或增量恢复，即可以通过 pg log 推算出 pg 的某个副本上有哪些对象缺失，只要将这些缺失的对象恢复即可。而 backfill 也可以称做 backfill recovery，或全量恢复。可能是由于 pg 的某个副本 osd 下线时间太长或者是新加入 osd 到集群，导致它上面的 pg log 跟 peering 阶段选出来的权威 pg log 没有重合。此时由于有部分 pg log 缺失，是无法通过比较 pg log 得出哪些对象是缺失的，只能通过做 backfill 来恢复数据。而 backfill 的做法是依据对象的 hash 排序扫描 pg 中的所有对象，依次进行恢复。
Recovery 和 backfill 对客户端做 IO 操作的影响是不同的。如果某个 PG 在做 recovery，而此时正好有客户端 IO 访问到一个降级的对象，这个 IO 会触发这个对象的恢复操作，并等待恢复完成之后才继续执行。而如果 PG 是做 backfill 的话，由于在peering阶段会为该 PG 生成一个 PG temp，将其临时映射到一组其他的 OSD 上，此时该 PG 上的 IO 操作是不会被阻塞的。但需要注意的是，该 PG 会在后台做 backfill 操作。对于已经做完 backfill 操作的对象，而整个 PG 的 backfill 还没有完成的话，如果该对象又有新的写操作，此时需要将这些写也更新到 backfill 目标 osd 中。
正是由于访问降级的对象时需要同步做恢复的这个原因，导致如果某个 OSD 在段时间下线后重新上线或者某个存储节点重启后其上面的 OSD 重新上线时，会同时存在大量的IO访问到降级的对象，此时需要同时进行这些对象的恢复操作，导致了系统资源忙于做数据恢复，而无法做更多的 IO，IOPS 甚至降低到正常情况下的1-2%。这个过程会持续很长一段时间。
为了解决这个问题，XSKY 提出并实现了一种异步的 recovery 数据恢复方式，结合了现有的 recovery 和 backfill 的优点，即基于 pg log 做数据恢复，同时不阻塞 IO 操作。有兴趣的读者可以上https://github.com/ceph/ceph/pull/11918
-
Ceph 一周一问题
Q: 如何给 Ceph 做贡献?
A: 在最近几周里，经常有开发者问到这个问题。因为参与到一个广泛的活跃的社区中间是一个令人有成就感的事情。事实上，Ceph 非常欢迎新的开发者能够加入其中。从笔者的角度来说，对 Ceph 贡献的第一步必须是熟悉 Ceph 并且去使用它。只有熟悉 Ceph 的使用方式，再去理解其背后的设计和实现原理会更佳清晰。很多时候，一个看起来难以理解的代码逻辑从使用角度能够深入的话，就非常简单。其次，从使用的方面深入，比如使用块比较多，那就从块的 API 开始，一步步向下去探索 IO 路径。理解 IO 的全貌对于开发者来说也比较关键。第三，定期浏览邮件列表和 Tracker.ceph.com 来找到社区的关注点，这个时候无论是新的用户 Bug 还是自己找到了一些小问题，都很容易产生一个 Pull Request 提交到 Github。一个完整的 Pull Request 到合并过程是一个良好的开始，不用刚开始去纠结于一些大的模块设计问题。另外，尽量避免在参与早期去在邮件列表问某些实现问题，大部分时候开发者很难回答这些问题，因为回答的背后需要了解提问者目前对于 Ceph 的认知，这个上下文需要不断的磨合。因此，对于很多代码问题，对于陌生的用户，很难得到开发者的积极响应。