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社區。