这是Ceph开发每周谈的第九十六篇文章，记录从17年10月17号到17年10月23号的社区开发情况。笔者从前年开始做Ceph的技术模块分析到今年中告一段落，想必有挺多人期待下一篇Ceph技术分析。考虑到Ceph的发展已经从前年的一穷二白到现在的如火如荼，但对于社区的方向和实况仍有所脱节，笔者考虑开始Ceph开发每周谈这个系列。每篇文章都会综述上周技术更新，围绕几个热点进行深度解析，如果正好有产业届新闻的话就进行解读，最后有读者反馈问题的话并且值得一聊的话，就附上答疑部分。
-
一句话消息
无
-
dmClock Update
最近来自 SK 的团队分享了在 dmClock 上的进展，在当前 Ceph QoS 计划中，首先有以下几个实体可以作为 QoS 对象:
- RBD Image
- Pool
- CephFS Directory
- Client 或者一组 Client
- 数据集
目前主要针对 1 和 2 作为第一优先级的 QoS 对象实现，而之前的文章也提到过，目前主要通过 Reservation、Weight 和 Limit 来实现 QoS 控制。
对于每一个 QoS 对象来说，首先需要在 OSD 中实现以下前置条件:
- 对于每个客户端来说，每个请求具有唯一的标识符，客户端和请求形成全局唯一
- 必须将每个请求对应的 QoS 控制信息持久化
- OSD 能够通过标识符从来访的请求中找到 QoS 控制信息
比如以 Pool 作为 QoS 对象的实现主要利用 OSDMap 存储 QoS 控制信息，这样每个 OSD 都可以通过 OSDMap 获得准确的 QoS 控制信息，如果是 RBD Image，则将 QoS 信息存储在Image Header 对象中，每个 OSD 通过 RBD Session 来获得(需要在 OSD 侧额外实现 RBD Session)，因为通过每个 RBD 对象的名字可以得到该镜像头对象的信息。
接下来需要将 dmClock 的 Delta、Rho 和 Phase 参数插入到 MOSDOp 和 MOSDOpReply 这两个客户端 IO 消息类中，在 OSD 侧，所有消息都是通过 Op Queue 进行分发处理，目前整个Op Queue 为了性能问题会做分区，每个分区被多个线程共享，相当于多个队列。这使得 QoS 在 OSD 侧控制变得困难，因此目前必须要将 OSD Shard 设为 1，相当于 OSD 有唯一的 Op Queue 进行处理。
另一个是对于背景 IO (Scrub，Recovery)的权重控制问题，背景 IO 同样需要计算 Delta 和 Rho 在 OSD 侧。
有了信息以后就可以进行限速了，在整个限速体系的设计:
通过对 oid 的监控来实现对应带宽的计算，然后反向回馈 dmClock 队列是否暂停处理相应请求，而预留请求会被继续，因为这相当于最小性能保证。那么如何发现 OSD 达到压力瓶颈，目前主要通过延迟检测，每 200ms 来对比前后的带宽差别来权衡当前压力。
目前主要针对 Pool，可以通过 reservation 来实现 IOPS 的实现，上图的测试证明了实现。