这是Ceph开发每周谈的第二十八篇文章，记录从16年6月13号到16年6月19号的社区开发情况。笔者从前年开始做Ceph的技术模块分析到今年中告一段落，想必有挺多人期待下一篇Ceph技术分析。考虑到Ceph的发展已经从前年的一穷二白到现在的如火如荼，但对于社区的方向和实况仍有所脱节，笔者考虑开始Ceph开发每周谈这个系列。每篇文章都会综述上周技术更新，围绕几个热点进行深度解析，如果正好有产业届新闻的话就进行解读，最后有读者反馈问题的话并且值得一聊的话，就附上答疑部分。
上周综述
上周主要热点是 BlueStore 和 msgr v2。
OSD 心跳
OSD 心跳指的是在 PG Mapping 的影响，OSD 与 OSD 成为逻辑上相关联的组合，然后这些 OSD 互相之间建立 P2P 的连接来保活，当某一个 OSD 掉线后，互相有心跳连接的 OSD 会汇报给 Mon 去 Mark Down。因此，通常可以发现 Ceph 集群存在大量的非业务 IO 连接，同时心跳也会影响系统的可用性。
在 OSD 的具体实现里，有 Fast Path 和 Slow Path 两种网络消息分发路径，后者是需要经过一个专门的 DispatchQueue 来处理优先级顺序，使得 OSD 能对不同的元数据请求进行调度和限流。而前者是 FIFO 的形式，也更少的需要锁。因此数据消息都是走 Fast Path 方式。而心跳消息在之前都是走 Slow Path，意味着处理时间的不确定性以及可能受底下 IO 影响。在新的实现中，心跳消息移到了 Fast Path，使得心跳不会像过去一样由于底下磁盘原因导致心跳超时了。
Jewel RBD 测试
在 Jewel 中 RBD 默认启用 Exclusive Lock 特性，使得只有一个 librbd instance 可以获得一个卷的 owner，从而当使用 fio 起多个 numjobs 就有可能造成卷的 owner lock 竞争，造成剧烈的性能下降。因此，在 Jewel 中使用 FIO RBD Engine 测试时要么关闭 Exclusive Lock 特性，要么就使用单个 job 进行。
PS:
最后欢迎国内开发者加入贡献有深度的内容