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

創(chuàng)新互聯(lián)建站專注于金平網(wǎng)站建設(shè)服務(wù)及定制，我們擁有豐富的企業(yè)做網(wǎng)站經(jīng)驗(yàn)。 熱誠(chéng)為您提供金平營(yíng)銷型網(wǎng)站建設(shè)，金平網(wǎng)站制作、金平網(wǎng)頁(yè)設(shè)計(jì)、金平網(wǎng)站官網(wǎng)定制、重慶小程序開發(fā)服務(wù)，打造金平網(wǎng)絡(luò)公司原創(chuàng)品牌,更為您提供金平網(wǎng)站排名全網(wǎng)營(yíng)銷落地服務(wù)。

圖A

Ceph致力于提供PB級(jí)的集群存儲(chǔ)能力，并且提供自動(dòng)故障恢復(fù)，方便的擴(kuò)容和縮容能力，這些能力在典型的分布式存儲(chǔ)系統(tǒng)就需要 Metadata Server 來(lái)提供，因?yàn)橥耆植际较到y(tǒng)對(duì)于數(shù)據(jù)遷移和擴(kuò)容有著非常強(qiáng)的痛點(diǎn)，但是 Metadata Server 另一方面又需要避免單點(diǎn)故障和數(shù)據(jù)瓶頸的問(wèn)題。，在這里，Ceph 要提供更自由和更強(qiáng)大的集群自動(dòng)故障處理和恢復(fù)能力，這使得 Metadata Server 是不可或缺的，但是為了避免 Metadata Server 存在瓶頸問(wèn)題，維護(hù)哪些 Metadata 成為最重要的問(wèn)題。Monitor 作為Ceph的 Metada Server 維護(hù)了集群的信息，它包括了6個(gè) Map，分別是 MONMap，OSDMap，PGMap，LogMap，AuthMap，MDSMap。其中 PGMap 和 OSDMap 是最重要的兩張Map，會(huì)在本文主要涉及。

OSDMap

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

Ceph 通過(guò)管理多個(gè)版本的 OSDMap 來(lái)避免集群狀態(tài)的同步，這使得 Ceph 絲毫不會(huì)畏懼在數(shù)千個(gè) OSD 規(guī)模的節(jié)點(diǎn)變更導(dǎo)致集群可能出現(xiàn)的狀態(tài)同步。

圖C

當(dāng)一個(gè) OSD 因?yàn)橐馔?crash 時(shí)，其他與該 OSD 保持 Heartbeat 的 OSD 都會(huì)發(fā)現(xiàn)該 OSD 無(wú)法連接，在匯報(bào)給 Monitor 后，該 OSD 會(huì)被臨時(shí)性標(biāo)記為 OUT，所有位于該 OSD 上的 Primary PG 都會(huì)將 Primary 角色交給其他 OSD(下面會(huì)解釋)。

PG 和 PGMap

圖E

在 Ceph 中，PG 存在多達(dá)十多種狀態(tài)和數(shù)十種事件的狀態(tài)機(jī)去處理 PG 可能面臨的異常，每個(gè)PG就像一個(gè)家族，PG掌握的數(shù)據(jù)就是其財(cái)富，而 OSD 只是一個(gè)城堡，每個(gè)城堡為多個(gè)家族提供了住所，但是為了保證財(cái)富的傳承，每個(gè)家族都會(huì)在多個(gè)城堡建立住所。OSD 如果城堡一樣只是為 PG 提供一個(gè)通訊地址(IP:Port)和一些基礎(chǔ)設(shè)施(如 OSDMap 和消息通訊機(jī)制)，當(dāng)城堡發(fā)生意外后，所有家族在其他城堡的住所都會(huì)及時(shí)更新狀態(tài)并且重新選擇新的城堡作為住所?；蛘叱潜囊馔庵谢謴?fù)過(guò)來(lái)，這個(gè)城堡的所有家族會(huì)與自己家族在其他城堡的住所溝通來(lái)得知在意外過(guò)程中財(cái)富發(fā)生變化的情況。這個(gè)例子是為了說(shuō)明Object(即用戶數(shù)據(jù))是跟著PG走，而不是跟OSD產(chǎn)生聯(lián)系。

從上面的描述中我們可以了解到 Monitor 掌握了整個(gè)集群的 OSD 狀態(tài)和 PG 狀態(tài)，每個(gè)PG都是一部分 Object 的擁有者，維護(hù) Object 的信息也每個(gè) PG 的責(zé)任，Monitor 不會(huì)掌握 Object Level 的信息。因此每個(gè)PG都需要維護(hù) PG 的狀態(tài)來(lái)保證 Object 的一致性。但是每個(gè) PG 的數(shù)據(jù)和相關(guān)故障恢復(fù)、遷移所必須的記錄都是由每個(gè) PG 自己維護(hù)，也就是存在于每個(gè) PG 所在的 OSD 上。

PGMap 是由 Monitor 維護(hù)的所有 PG 的狀態(tài)，每個(gè) OSD 都會(huì)掌握自己所擁有的 PG 狀態(tài)，PG 遷移需要 Monitor 作出決定然后反映到 PGMap 上，相關(guān) OSD 會(huì)得到通知去改變其 PG 狀態(tài)。在一個(gè)新的 OSD 啟動(dòng)并加入 OSDMap 后，Monitor 會(huì)通知這個(gè)OSD需要?jiǎng)?chuàng)建和維護(hù)的 PG ，當(dāng)存在多個(gè)副本時(shí)，PG 的 Primary OSD 會(huì)主動(dòng)與 Replicated 角色的 PG 通信并且溝通 PG 的狀態(tài)，其中包括 PG 的最近歷史記錄。通常來(lái)說(shuō)，新的 OSD 會(huì)得到其他 PG 的全部數(shù)據(jù)然后逐漸達(dá)成一致，或者 OSD 已經(jīng)存在該 PG 信息，那么 Primary PG 會(huì)比較該 PG 的歷史記錄然后達(dá)成 PG 的信息的一致。這個(gè)過(guò)程稱為 Peering ，它是一個(gè)由 Primary PG OSD 發(fā)起的“討論”，多個(gè)同樣掌握這個(gè) PG 的 OSD 相互之間比較 PG 信息和歷史來(lái)最終協(xié)商達(dá)成一致。

關(guān)于“Ceph中OSD 、OSDMap和PG、PGMap的示例分析”這篇文章就分享到這里了，希望以上內(nèi)容可以對(duì)大家有一定的幫助，使各位可以學(xué)到更多知識(shí)，如果覺(jué)得文章不錯(cuò)，請(qǐng)把它分享出去讓更多的人看到。