前言
從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的值，實現動態適配。
Tips: M版本中，Ceph將所有類型的IO請求都放入到了相同的shardedwq隊列中，添加流量控制機制，最好將Recovery/Backfill相關的請求，如：PUSH/PULL請求抽取出來放到獨立的隊列，由獨立的線程（池）來處理，會有更好的性能表現。
通過上述改進，數據平衡對業務的影響可以控制在30%以內。
本文只提供可行的實現思路，不提供實現細節，如有不清楚的地方，可以給我留言。