Ceph：pg peering过程分析

转自：https://www.ustack.com/blog/ceph%ef%bc%8dpg-peering/

Peering：互为副本的三个(此处为设置的副本个数，一般设置为3)pg的元数据达到一致的过程。官方解释以下：

the process of bringing all of the OSDs that store a Placement Group (PG) into agreement about the state of all of the objects (and their metadata) in that PG. Note that agreeing on the state does not mean that they all have the latest contents.

primary PG和raplica PG： 互为副本的三个pg中，有一个主，另外两个为辅；其中为主的称为primary PG，其余两个都称为replica PG。

一、peering过程的影响

故障osd从新上线后，primary PG和replica PG会进入不一样的处理流程。primary PG会先进入peering状态，在这个状态的pg暂停处理IO请求，在生产环境中表现为集群部分IO不响应，甚至某些云主机由于等待IO形成应用没法正常处理。下面就peering过程的主要操做进行分析。

二、peering过程分析

pg是由boost::statechart实现的状态机，peering经历如下主要过程：

一、GetInfo:

1.一、选取一个epoch区间，对区间内的每一个epoch计算其对应的acting set、acting primary、up set、up primary，将相同的结果做为一个interval；

1.二、判断每一个interval，将up状态的osd加入到prior set；同时将当前的acting set和up set加入到prior set；

1.三、向prior_set中的每一个up状态的osd发送Query INFO请求，并等待接收应答，将接收到的请求保存到peer_info中；

1.四、收到最后一个应答后，状态机post event到GotInfo状态；若是在此期间有一个接收请求的osd down掉，这个PG的状态将持续等待，直到对应的osd恢复；

二、GetLog：

2.一、遍历peer_info，查找best info，将其做为authoritative log；将acting set/peer_info中将处于complete状态的pg以及up set的全部pg存入acting_backfill；

2.二、若是计算出的authoritative log对应的pg是自身，直接post event到GotLog；不然，向其所在的osd发送Query Log请求；

2.三、接收请求的osd应答，并将获取的log merge到本地，状态机post event到GetMissing；若是收不到应答，状态将持续等待；

三、GetMissing：

3.一、遍历acting_backfill，向与primary pg log有交集的pg所在的osd发送Query Log请求；将剩余没有交集的pg放入peer_missing，生成missing set用于后续recovery；

3.二、将收到的每个应答merge到本地，若是在此期间有osd down掉，这个PG的状态将持续等待；收到全部的应答后，当前pg的状态机进入Activate状态，peering过程结束；

三、总结

从以上分析来看，整个peering过程主要分为三个阶段，GetInfo -> GetLog -> GetMissing，首先向prior set、acting set、up set中的每一个osd请求pg infos, 选出authoritative log对应的pg；其次向authoritative log所在的osd请求authoritative log；最后获取recovery过程须要的missing set；

peering时间的长短并不可控，主要是在于请求的osd是否可以及时响应；若是这个阶段某个osd down掉，极可能致使部分pg一直处在peering状态，即全部分布到这个pg上的IO都会阻塞。

四、现状

为了减小peering过程对client形成的影响，社区提出Faster Peering，该plan主要有如下两点：

1）向最近prior set interval中的osd请求log+missing，跳过GetLog阶段；

2）向acting set和up set中的osd请求log+missing，跳过GetMissing阶段；

关于做者：

王松波，UnitedStack有云存储高级软件工程师，有7年以上的Linux kernel研发经验，精通多种架构下的网络性能优化；对云计算、分布式存储有深入理解；目前专一于Ceph社区。