Ceph开发每周谈Vol 63 | PG Split 风险

2017年03月 · 麦子迈

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

  • 一句话消息

Hammer 版本最新小版本发布,0.94.10

  • Ceph PG Split 问题

有很多用户在使用 Ceph 时,刚开始规划的 PG 数目比较小,后来扩容后发现 PG 不够多,并发不太好,希望能扩容。就希望通过 PG Split 功能来分裂 PG。

但是目前 PG 分裂时,如果 client 发送 OSD 请求出现问题,不会重新发送,有可能造成 IO 丢失。这个问题主要来自:

  1. 大量的状态管理和锁存在于目前的分裂流程

2. 因为 PG 在分裂时,很难确定这个请求该进入哪个 PG 等候

3. 大量的复杂锁存在于 fast_dispatch上

4. 同时,在分裂后,很难重新在 OSD 端排队进入正确的子 PG

 

因此,OSD 考虑在 client side 去保留 pg split op,然后重发,目前这个机制会利用 OSDMap 来管理该类 Op。

 

该部分代码正在 Review,还需要时间才能进入版本。因此,必须了解 PG Split 在生产环境存在风险!

最后欢迎国内开发者加入贡献有深度的内容!