前言

从15年3月接触Ceph分布式存储系统，至今已经5年了；因为工作的需要，对Ceph的主要模块进行了较深入的学习，也在Ceph代码层面做了些许改进，以满足业务需要（我们主要使用M版本）。最近得闲，将过往的一些改进以及优化思路记录下了，希望能对后来者有所帮助。

之前有分享过RBD持久化缓存以及卷QoS，感兴趣的读者可以翻阅前文

这是第一篇：Ceph Peering以及数据均衡的改进

背景知识

在Ceph集群的Crushmap发生变化后（比如：扩容，缩容等操作），Ceph为保证各OSD数据的均衡以及
满足数据副本要求会在各OSD间执行数据均衡：

Peering阶段：在数据均衡前，主OSD发起Peering（可以理解为主备副本OSD握手协商），选出权威OSD（拥有最新PG Log的OSD）以及计算出各OSD之间的差异数据，准备好Missing列表，为后续的数据复制做准备。为了保证，获取的差异数据的一致性，该阶段不允许写， Ceph以PG为粒度执行Peering。
Recovery/Backfill阶段：根据第一阶段中的Missing列表，各OSD通过Push（主OSD发送数据给备OSD）/Pull（主OSD从备OSD拉取数据）数据完成本地数据的修复。 该阶段允许读写，进行以对象为单位的跨网络数据复制，虽然提供了一些控制参数，但还是会消耗大量的磁盘和网络资源。

优化思路

针对Peering阶段：
1.1 分批同步，延迟非主OSD的同步.
默认情况下，PG的主OSD只要确认副本OSD无法连通，就会发起Peering，而各个OSD独立发起Peeering请求，并不会有任何的协商。所以，在出现故障后，会发现大量的PG进入Peering状态。比如：三副本的集群，一个OSD中有300个PG，如果OSD发生离线或者上线，那么这300PG会同时发起Peering，根据CrushMap的（基本）均衡分配策略，实际上需要立即进行Peering的PG只有1/3，剩余的2/3可以延迟进行，那么我们可以通过分批同步，减少同时进行Peering的PG数量来缓解IO被Block的问题。

我们知道与数据恢复相关的PG主要状态为：Init->Reset->Started(包含Start子状态)，在Start状态下，如果是主OSD，则进入Primary状态并发起Peering；如果是副本OSD，则进入Stray状态。下面是默认情况下，PG状态转换的一个简图：
在这里插入图片描述
我们在原状态图中添加子状态DeferPeering和RepDeferPeering，将部分Peering请求添加到延迟队列中，分批或者有IO落到相应的PG上，再发起Peering。下面是修改后的PG状态图：

2. 针对Recovery/Backfill阶段：
2.1 利用PG Log中的dirty extent进行增量恢复
默认情况下，Recovery/Backfill以对象为单位进行读取->传输->写入的恢复过程。在RBD场景下，通常一个对象为4MB，也就是说：不管对象中的脏数据是多大，都需要复制整个对象，在随机io场景下，数据的放大是很严重的，比如：一个对象只有4k的数据发生了更改，却要复制4MB的对象，放大了1024倍。

我们知道Recovery是借助PG Log来识别各副本之间数据的差异的，如果我们能够在PG Log中记录写IO的操作区间<offset, len>，那么就可以实现增量复制，PG Log Entry修改前后示例：
Old:

op	obj	everison
M	“abc”	5.13

New:

op	obj	eversion	dirty_extents
M	“abc”	5.13	<off, len>

有了dirty_extents, 我们就可以通过打包dirty_extents指向的内容进行数据恢复，而不需要复制整个对象。

Tips：对于Truncate（可能扩大也可能缩小卷），快照的COW操作（由于故障情况下，数据恢复次序的原因）操作应该采用默认的方式恢复。

2.2 通过限流来控制数据复制流量
默认情况下，Ceph定义了一些参数来控制Recovery/Backfill的并发度，但实际测试下来，效果并不理想。为此，我们可以通过限流来控制数据复制的速度，比如：基于Leeky Bucket的QoS，更精细些，还可以根据OSD当前繁忙度来动态调节QoS的值，实现动态适配。