Ceph Peering以及数据均衡的改进思路

前言

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

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

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

背景知识

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

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

优化思路

  1. 针对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状态转换的一个简图:
Ceph Peering以及数据均衡的改进思路_第1张图片
我们在原状态图中添加子状态DeferPeering和RepDeferPeering,将部分Peering请求添加到延迟队列中,分批或者有IO落到相应的PG上,再发起Peering。下面是修改后的PG状态图:
Ceph Peering以及数据均衡的改进思路_第2张图片
2. 针对Recovery/Backfill阶段:
2.1 利用PG Log中的dirty extent进行增量恢复
默认情况下,Recovery/Backfill以对象为单位进行读取->传输->写入的恢复过程。在RBD场景下,通常一个对象为4MB,也就是说:不管对象中的脏数据是多大,都需要复制整个对象,在随机io场景下,数据的放大是很严重的,比如:一个对象只有4k的数据发生了更改,却要复制4MB的对象,放大了1024倍。

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

op obj everison
M “abc” 5.13

New:

op obj eversion dirty_extents
M “abc” 5.13

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

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

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

Tips: M版本中,Ceph将所有类型的IO请求都放入到了相同的shardedwq队列中,添加流量控制机制,最好将Recovery/Backfill相关的请求,如:PUSH/PULL请求抽取出来放到独立的队列,由独立的线程(池)来处理,会有更好的性能表现。

通过上述改进,数据平衡对业务的影响可以控制在30%以内。

本文只提供可行的实现思路,不提供实现细节,如有不清楚的地方,可以给我留言。

你可能感兴趣的:(Ceph,存储)