解析Ceph 恢復與資料一致性

**：

作為乙個面向大規模的分布式儲存系統，故障處理是作為乙個常態異常處理。ceph 為了細化和保證故障發生和故障恢復的集群高可用性和一致性，在設計上將故障分為兩類:

ceph 將所有資料域劃分成若干個 pg(placement group)管理，每個 pg 都存活在乙個 osd 節點上，因此 pg 是管理、恢復資料的主體。而 monitor 節點不參與使用者資料的任何操作，只提供了 pg 選舉的協調作用。pg 所屬資料的處理和恢復都由 pg 本身進行協調。

首先這裡考慮臨時性故障的處理，ceph 引入了 pglog 的概念，顧名思義，pglog 由 pg 維護並且記錄了該 pg 所有的操作，其非常類似於關係型資料庫領域的 undo log，同時需要將 pglog 與 journal 概念劃分清楚，journal 是底層單機儲存模組用來維護事務一致性的，它是資料庫領域的 redo log。undo log 和 redo log 在資料庫的作用與 ceph 的 pglog 和 journal 作用是一致的。pglog 通常只儲存 pg 最近幾千條的操作記錄，但是在 pg 處於 degraded 狀態時，pglog 會儲存更多的日誌條目期望能在故障 pg 重新上線後用來恢復資料。下面來簡單描述故障發生導致 osd 下線的流程:

某乙個 osd 下線

如果 osd 主動下線它會通知 monitor 自己下線，請做好相關通知工作。如果是異常下線，那麼其他 osd 和 monitor 會通過 heartbeat 來得知 osd 下線同樣讓 monitor 知曉

monitor 重新計算該 osd 擁有的的 primary pg，並將結果主動通知這些 pg 所在的 osd

pg 將自己設為 degraded 狀態後，將會減小自己的副本數，並增加儲存的 pglog 條目數

故障發生後，如果一定時間後重新上線故障 osd，那麼 pg 會進行以下流程:

1. 故障 osd 上線，通知 monitor 並註冊，該 osd 在上線前會讀取存在持久裝置的 pglog，

2. monitor 得知該 osd 的舊有 id，因此會繼續使用以前的 pg 分配，之前該 osd 下線造成的 degraded pg 會被通知該 osd 已重新加入

3. 這時候分為兩種情況，注意這個情況下 pg 會標誌自己為 peering 狀態並暫時停止處理請求:

3.1 第一種情況是故障 osd 所擁有的 primary pg

3.1.1 它作為這部分資料"權責"主體，需要傳送查詢 pg 元資料請求給所有屬於該 pg 的 replicate 角色節點。

3.1.2 該 pg 的 replicate 角色節點實際上在故障 osd 下線時期間成為了 primary 角色並維護了「權威」的 pglog，該 pg 在得到故障 osd 的 primary pg 的查詢請求後會傳送回應

3.1.3 primary pg 通過對比 replicate pg 傳送的元資料和 pg 版本資訊後發現處於落後狀態，因此它會合併得到的 pglog並建立「權威」 pglog，同時會建立 missing 列表來標記過時資料

3.1.4 primary pg 在完成「權威」 pglog 的建立後就可以標誌自己處於 active 狀態

3.2 第二種情況是故障 osd 所擁有的 replicate pg

3.2.1 這時上線後故障 osd 的 replicate pg 會得到 primary pg 的查詢請求，傳送自己這份「過時」的元資料和 pglog

3.2.2 primary pg 對比資料後發現該 pg 落後並且過時，比通過 pglog 建立了 missing 列表

3.2.3 primary pg 標記自己處於 active 狀態

4. pg 開始接受 io 請求，但是 pg 所屬的故障節點仍存在過時資料，故障節點的 primary pg 會發起 pull 請求從 replicate 節點獲得最新資料，replicate pg 會得到其他 osd 節點上的 primary pg 的 push 請求來恢復資料

5. 恢復完成後標記自己 clean

第三步是 pg 唯一不處理請求的階段，它通常會在 1s 內完成來減少不可用時間。但是這裡仍然有其他問題，比如在恢復期間故障 osd 會維護 missing 列表，如果 io 正好是處於 missing 列表的資料，那麼 pg 會進行恢復資料的「插隊」操作，主動將該 io 涉及的資料從 replicate pg 拉過來，提前恢復該部分資料。這個情況造成的延遲大概在幾十公釐，通常來說是可接受的。

上面的流程的前提故障 osd 在 pglog 儲存的最大條目數以內加入集群都會利用 pglog 恢復，那麼如果在 n 天之後或者發生了永久故障需要新盤加入集群時，pglog 就無法起到恢復資料的作用，這時候就需要 backfill(全量拷貝) 流程介入。backfill 會將所有資料複製到新上線的 pg，這裡的流程跟上述過程基本一致，唯一的差異就是在第三步 primary pg 發現 pglog 已經不足以恢復資料時，這時候同樣分為兩種情況:

故障 osd 擁有 primary pg，該 pg 在對比 pglog 後發現需要全量拷貝資料，那麼毫無疑問 primary pg 在複製期間已經無法處理請求，它會傳送乙個特殊請求給 monitor 告知自己需要全量複製，需要將 replicate pg 臨時性提公升為 primary，等到自己完成了複製過程才會重新接管 primary 角色

故障 osd 擁有 replicate pg，該 pg 的 primary 角色會發起 backfill 流程向該 pg 複製資料，由於故障 osd 是 replicate 角色，因此不影響正常 io 的處理

除此之外，恢復資料還需要涉及到恢復資料的頻寬控制、優先順序等細節問題，這裡就不一一贅述了。

總的來說，ceph 的恢復模組設計原則是在保證資料強一致性的前提下，盡量細化恢復過程來提高資料可用性(請求能得到及時處理)，這個細化過程勢必帶來了極大的複雜性，因此恢復模組實際上也是 ceph 最複雜的設計之一，值得儲存系統領域的開發者借鑑。

解析Ceph 恢復與資料一致性

Ceph恢復與資料一致性

資料一致性

資料一致性

相關推薦