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。

1、peering过程的影响

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

2、peering过程分析

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

1、GetInfo:

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

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

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

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

2、GetLog：

2.1、遍历peer_info，查找best info，将其作为authoritative log；将acting set/peer_info中将处于complete状态的pg以及up set的所有pg存入acting_backfill；

2.2、如果计算出的authoritative log对应的pg是自身，直接post event到GotLog；否则，向其所在的osd发送Query Log请求；

2.3、接收请求的osd应答，并将获取的log merge到本地，状态机post event到GetMissing；如果收不到应答，状态将持续等待；

3、GetMissing：

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

3.2、将收到的每一个应答merge到本地，如果在此期间有osd down掉，这个PG的状态将持续等待；收到所有的应答后，当前pg的状态机进入Activate状态，peering过程结束；

3、总结

从以上分析来看，整个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都会阻塞。

4、现状

为了减少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社区。