Ceph中OSD 、OSDMap和PG、PGMap的示例分析

這篇文章將為大家詳細講解有關Ceph中OSD 、OSDMap和PG、PGMap的示例分析，小編覺得挺實用的，因此分享給大家做個參考，希望大家閱讀完這篇文章后可以有所收獲。

圖A

Ceph致力于提供PB級的集群存儲能力，并且提供自動故障恢復，方便的擴容和縮容能力，這些能力在典型的分布式存儲系統就需要 Metadata Server 來提供，因為完全分布式系統對于數據遷移和擴容有著非常強的痛點，但是 Metadata Server 另一方面又需要避免單點故障和數據瓶頸的問題。，在這里，Ceph 要提供更自由和更強大的集群自動故障處理和恢復能力，這使得 Metadata Server 是不可或缺的，但是為了避免 Metadata Server 存在瓶頸問題，維護哪些 Metadata 成為最重要的問題。Monitor 作為Ceph的 Metada Server 維護了集群的信息，它包括了6個 Map，分別是 MONMap，OSDMap，PGMap，LogMap，AuthMap，MDSMap。其中 PGMap 和 OSDMap 是最重要的兩張Map，會在本文主要涉及。

OSDMap

OSDMap 是 Ceph 集群中所有 OSD 的信息，所有 OSD 節點的改變如進程退出，節點的加入和退出或者節點權重的變化都會反映到這張 Map 上。這張 Map 不僅會被 Monitor 掌握，OSD 節點和 Client 也會從 Monitor 得到這張表，因此實際上我們需要處理所有 “Client” (包括 OSD，Monitor 和 Client)的 OSDMap 持有情況，實際上，每個 “Client” 可能會具有不同版本的 OSDMap，當 Monitor 所掌握的權威 OSDMap 發生變化時，它并不會發送 OSDMap 給所有 “Client” ，而是需要了解到變化的 “Client” 會被 Push，如一個新的 OSD 加入會導致一些 PG 的遷移，那么這些 PG 的 OSD 會得到通知。除此之外，Monitor 也會隨機的挑選一些 OSD 發送 OSDMap。那么如何讓 OSDMap 慢慢傳播呢？比如 OSD.a, OSD.b得到了新的 OSDMap，那么 OSD.c 和 OSD.d 可能部分 PG 也會在 OSD.a, OSD.b 上，這時它們的通信就會附帶上 OSDMap 的 epoch，如果版本較低，OSD.c 和 OSD.d 會主動向 Monitor pull OSDMap，而部分情況 OSD.a, OSD.b 也會主動向 OSD.c 和 OSD.d push 自己的 OSDMap (如果更新)。因此，OSDMap 會在接下來一段時間內慢慢在節點間普及。在集群空閑時，很有可能需要更長的時間完成新 Map的更新，但是這并不會影響 OSD 之間的狀態一致性，因為OSD沒有得到新的Map所有它們不需要知曉新的OSDMap變更。

Ceph 通過管理多個版本的 OSDMap 來避免集群狀態的同步，這使得 Ceph 絲毫不會畏懼在數千個 OSD 規模的節點變更導致集群可能出現的狀態同步。

圖C

當一個 OSD 因為意外 crash 時，其他與該 OSD 保持 Heartbeat 的 OSD 都會發現該 OSD 無法連接，在匯報給 Monitor 后，該 OSD 會被臨時性標記為 OUT，所有位于該 OSD 上的 Primary PG 都會將 Primary 角色交給其他 OSD(下面會解釋)。

PG 和 PGMap

圖E

在 Ceph 中，PG 存在多達十多種狀態和數十種事件的狀態機去處理 PG 可能面臨的異常，每個PG就像一個家族，PG掌握的數據就是其財富，而 OSD 只是一個城堡，每個城堡為多個家族提供了住所，但是為了保證財富的傳承，每個家族都會在多個城堡建立住所。OSD 如果城堡一樣只是為 PG 提供一個通訊地址(IP:Port)和一些基礎設施(如 OSDMap 和消息通訊機制)，當城堡發生意外后，所有家族在其他城堡的住所都會及時更新狀態并且重新選擇新的城堡作為住所。或者城堡從意外中恢復過來，這個城堡的所有家族會與自己家族在其他城堡的住所溝通來得知在意外過程中財富發生變化的情況。這個例子是為了說明Object(即用戶數據)是跟著PG走，而不是跟OSD產生聯系。

從上面的描述中我們可以了解到 Monitor 掌握了整個集群的 OSD 狀態和 PG 狀態，每個PG都是一部分 Object 的擁有者，維護 Object 的信息也每個 PG 的責任，Monitor 不會掌握 Object Level 的信息。因此每個PG都需要維護 PG 的狀態來保證 Object 的一致性。但是每個 PG 的數據和相關故障恢復、遷移所必須的記錄都是由每個 PG 自己維護，也就是存在于每個 PG 所在的 OSD 上。

PGMap 是由 Monitor 維護的所有 PG 的狀態，每個 OSD 都會掌握自己所擁有的 PG 狀態，PG 遷移需要 Monitor 作出決定然后反映到 PGMap 上，相關 OSD 會得到通知去改變其 PG 狀態。在一個新的 OSD 啟動并加入 OSDMap 后，Monitor 會通知這個OSD需要創建和維護的 PG ，當存在多個副本時，PG 的 Primary OSD 會主動與 Replicated 角色的 PG 通信并且溝通 PG 的狀態，其中包括 PG 的最近歷史記錄。通常來說，新的 OSD 會得到其他 PG 的全部數據然后逐漸達成一致，或者 OSD 已經存在該 PG 信息，那么 Primary PG 會比較該 PG 的歷史記錄然后達成 PG 的信息的一致。這個過程稱為 Peering ，它是一個由 Primary PG OSD 發起的“討論”，多個同樣掌握這個 PG 的 OSD 相互之間比較 PG 信息和歷史來最終協商達成一致。

關于“Ceph中OSD 、OSDMap和PG、PGMap的示例分析”這篇文章就分享到這里了，希望以上內容可以對大家有一定的幫助，使各位可以學到更多知識，如果覺得文章不錯，請把它分享出去讓更多的人看到。