Ceph的結構、工作原理及流程是怎樣的

Ceph的結構、工作原理及流程是怎樣的，針對這個問題，這篇文章詳細介紹了相對應的分析和解答，希望可以幫助更多想解決這個問題的小伙伴找到更簡單易行的方法。

Ceph的結構

Ceph系統(tǒng)的層次結構

Ceph存儲系統(tǒng)的邏輯層次結構如下圖所示：

自下向上，可以將Ceph系統(tǒng)分為四個層次：

（1）基礎存儲系統(tǒng)RADOS（Reliable, Autonomic, Distributed Object Store，即可靠的、自動化的、分布式的對象存儲）

顧名思義，這一層本身就是一個完整的對象存儲系統(tǒng)，所有存儲在Ceph系統(tǒng)中的用戶數(shù)據(jù)事實上最終都是由這一層來存儲的。而Ceph的高可靠、高可擴展、高性能、高自動化等等特性本質上也是由這一層所提供的。因此，理解RADOS是理解Ceph的基礎與關鍵。

物理上，RADOS由大量的存儲設備節(jié)點組層，每個節(jié)點擁有自己的硬件資源（CPU、內(nèi)存、硬盤、網(wǎng)絡），并運行著操作系統(tǒng)和文件系統(tǒng)。4.2、4.3節(jié)將對RADOS進行展開介紹。

（2）基礎庫librados

這一層的功能是對RADOS進行抽象和封裝，并向上層提供API，以便直接基于RADOS（而不是整個Ceph）進行應用開發(fā)。特別要注意的是，RADOS是一個對象存儲系統(tǒng)，因此，librados實現(xiàn)的API也只是針對對象存儲功能的。

RADOS采用C++開發(fā)，所提供的原生librados API包括C和C++兩種，其文檔參見[2]。物理上，librados和基于其上開發(fā)的應用位于同一臺機器，因而也被稱為本地API。應用調(diào)用本機上的librados API，再由后者通過socket與RADOS集群中的節(jié)點通信并完成各種操作。

（3）高層應用接口

這一層包括了三個部分：RADOS GW（RADOS Gateway）、 RBD（Reliable Block Device）和Ceph FS（Ceph File System），其作用是在librados庫的基礎上提供抽象層次更高、更便于應用或客戶端使用的上層接口。

其中，RADOS GW是一個提供與Amazon S3和Swift兼容的RESTful API的gateway，以供相應的對象存儲應用開發(fā)使用。RADOS GW提供的API抽象層次更高，但功能則不如librados強大。因此，開發(fā)者應針對自己的需求選擇使用。

RBD則提供了一個標準的塊設備接口，常用于在虛擬化的場景下為虛擬機創(chuàng)建volume。目前，Red Hat已經(jīng)將RBD驅動集成在KVM/QEMU中，以提高虛擬機訪問性能。

Ceph FS是一個POSIX兼容的分布式文件系統(tǒng)。由于還處在開發(fā)狀態(tài)，因而Ceph官網(wǎng)并不推薦將其用于生產(chǎn)環(huán)境中。

（4）應用層

這一層就是不同場景下對于Ceph各個應用接口的各種應用方式，例如基于librados直接開發(fā)的對象存儲應用，基于RADOS GW開發(fā)的對象存儲應用，基于RBD實現(xiàn)的云硬盤等等。

在上文的介紹中，有一個地方可能容易引起困惑：RADOS自身既然已經(jīng)是一個對象存儲系統(tǒng)，并且也可以提供librados API，為何還要再單獨開發(fā)一個RADOS GW？

理解這個問題，事實上有助于理解RADOS的本質，因此有必要在此加以分析。粗看起來，librados和RADOS GW的區(qū)別在于，librados提供的是本地API，而RADOS GW提供的則是RESTful API，二者的編程模型和實際性能不同。而更進一步說，則和這兩個不同抽象層次的目標應用場景差異有關。換言之，雖然RADOS和S3、Swift同屬分布式對象存儲系統(tǒng)，但RADOS提供的功能更為基礎、也更為豐富。這一點可以通過對比看出。

由于Swift和S3支持的API功能近似，這里以Swift舉例說明。Swift提供的API功能主要包括：

• 用戶管理操作：用戶認證、獲取賬戶信息、列出容器列表等；

• 容器管理操作：創(chuàng)建/刪除容器、讀取容器信息、列出容器內(nèi)對象列表等；

• 對象管理操作：對象的寫入、讀取、復制、更新、刪除、訪問許可設置、元數(shù)據(jù)讀取或更新等。

由此可見，Swift（以及S3）提供的API所操作的“對象”只有三個：用戶賬戶、用戶存儲數(shù)據(jù)對象的容器、數(shù)據(jù)對象。并且，所有的操作均不涉及存儲系統(tǒng) 的底層硬件或系統(tǒng)信息。不難看出，這樣的API設計完全是針對對象存儲應用開發(fā)者和對象存儲應用用戶的，并且假定其開發(fā)者和用戶關心的內(nèi)容更偏重于賬戶和數(shù)據(jù)的管理，而對底層存儲系統(tǒng)細節(jié)不感興趣，更不關心效率、性能等方面的深入優(yōu)化。 

而librados API的設計思想則與此完全不同。一方面，librados中沒有賬戶、容器這樣的高層概念；另一方面，librados API向開發(fā)者開放了大量的RADOS狀態(tài)信息與配置參數(shù)，允許開發(fā)者對RADOS系統(tǒng)以及其中存儲的對象的狀態(tài)進行觀察，并強有力地對系統(tǒng)存儲策略進行控制。換言之，通過調(diào)用librados API，應用不僅能夠實現(xiàn)對數(shù)據(jù)對象的操作，還能夠實現(xiàn)對RADOS系統(tǒng)的管理和配置。這對于S3和Swift的RESTful API設計是不可想像的，也是沒有必要的。 

基于上述分析對比，不難看出，librados事實上更適合對于系統(tǒng)有著深刻理解，同時對于功能定制擴展和性能深度優(yōu)化有著強烈需求的高級用戶?；趌ibrados的開發(fā)可能更適合于在私有Ceph系統(tǒng)上開發(fā)專用應用，或者為基于Ceph的公有存儲系統(tǒng)開發(fā)后臺數(shù)據(jù)管理、處理應用。而RADOS GW則更適合于常見的基于web的對象存儲應用開發(fā)，例如公有云上的對象存儲服務。 

RADOS的邏輯結構 

RADOS的系統(tǒng)邏輯結構如下圖所示

在使用RADOS系統(tǒng)時，大量的客戶端程序通過與OSD或者monitor的交互獲取cluster map，然后直接在本地進行計算，得出對象的存儲位置后，便直接與對應的OSD通信，完成數(shù)據(jù)的各種操作?？梢?，在此過程中，只要保證cluster map不頻繁更新，則客戶端顯然可以不依賴于任何元數(shù)據(jù)服務器，不進行任何查表操作，便完成數(shù)據(jù)訪問流程。在RADOS的運行過程中，cluster map的更新完全取決于系統(tǒng)的狀態(tài)變化，而導致這一變化的常見事件只有兩種：OSD出現(xiàn)故障，或者RADOS規(guī)模擴大。而正常應用場景下，這兩種事件發(fā)生 的頻率顯然遠遠低于客戶端對數(shù)據(jù)進行訪問的頻率。

 OSD的邏輯結構

根據(jù)定義，OSD可以被抽象為兩個組成部分，即系統(tǒng)部分和守護進程（OSD deamon）部分。

OSD的系統(tǒng)部分本質上就是一臺安裝了操作系統(tǒng)和文件系統(tǒng)的計算機，其硬件部分至少包括一個單核的處理器、一定數(shù)量的內(nèi)存、一塊硬盤以及一張網(wǎng)卡。

由于這么小規(guī)模的x86架構服務器并不實用（事實上也見不到），因而實際應用中通常將多個OSD集中部署在一臺更大規(guī)模的服務器上。在選擇系統(tǒng)配置時，應當 能夠保證每個OSD占用一定的計算能力、一定量的內(nèi)存和一塊硬盤。同時，應當保證該服務器具備足夠的網(wǎng)絡帶寬。具體的硬件配置選擇可以參考。

在 上述系統(tǒng)平臺上，每個OSD擁有一個自己的OSD deamon。這個deamon負責完成OSD的所有邏輯功能，包括與monitor和其他OSD（事實上是其他OSD的deamon）通信以維護更新系 統(tǒng)狀態(tài)，與其他OSD共同完成數(shù)據(jù)的存儲和維護，與client通信完成各種數(shù)據(jù)對象操作等等。

Ceph系統(tǒng)的邏輯結構就介紹到這里。下篇文章將著重說明Ceph（主要是RADOS）的工作原理和操作流程。

如圖所示，RADOS集群主要由兩種節(jié)點組成。一種是為數(shù)眾多的、負責完成數(shù)據(jù)存儲和維護功能的OSD（Object Storage Device），另一種則是若干個負責完成系統(tǒng)狀態(tài)檢測和維護的monitor。OSD和monitor之間相互傳輸節(jié)點狀態(tài)信息，共同得出系統(tǒng)的總體工 作狀態(tài)，并形成一個全局系統(tǒng)狀態(tài)記錄數(shù)據(jù)結構，即所謂的cluster map。這個數(shù)據(jù)結構與RADOS提供的特定算法相配合，便實現(xiàn)了Ceph“無需查表，算算就好”的核心機制以及若干優(yōu)秀特性。 

Ceph的工作原理及流程

本節(jié)將對Ceph的工作原理和若干關鍵工作流程進行扼要介紹。如前所述，由于Ceph的功能實現(xiàn)本質上依托于RADOS，因而，此處的介紹事實上也是針對RADOS進行。對于上層的部分，特別是RADOS GW和RBD，由于現(xiàn)有的文檔中（包括Sage的論文中）并未詳細介紹，還請讀者多多包涵。

首先介紹RADOS中最為核心的、基于計算的對象尋址機制，然后說明對象存取的工作流程，之后介紹RADOS集群維護的工作過程，最后結合Ceph的結構和原理對其技術優(yōu)勢加以回顧和剖析。

尋址流程

Ceph系統(tǒng)中的尋址流程如下圖所示：

上圖左側的幾個概念說明如下：

1. File —— 此處的file就是用戶需要存儲或者訪問的文件。對于一個基于Ceph開發(fā)的對象存儲應用而言，這個file也就對應于應用中的“對象”，也就是用戶直接操作的“對象”。

2. Ojbect —— 此處的object是RADOS所看到的“對象”。Object與上面提到的file的區(qū)別是，object的最大size由RADOS限定（通常為2MB或4MB），以便實現(xiàn)底層存儲的組織管理。因此，當上層應用向RADOS存入size很大的file時，需要將file切分成統(tǒng)一大小的一系列object（最后一個的大小可以不同）進行存儲。為避免混淆，在本文中將盡量避免使用中文的“對象”這一名詞，而直接使用file或object進行說明。

3. PG（Placement Group）—— 顧名思義，PG的用途是對object的存儲進行組織和位置映射。具體而言，一個PG負責組織若干個object（可以為數(shù)千個甚至更多），但一個object只能被映射到一個PG中，即，PG和object之間是“一對多”映射關系。同時，一個PG會被映射到n個OSD上，而每個OSD上都會承載大量的PG，即，PG和OSD之間是“多對多”映射關系。在實踐當中，n至少為2，如果用于生產(chǎn)環(huán)境，則至少為3。一個OSD上的PG則可達到數(shù)百個。事實上，PG數(shù)量的設置牽扯到數(shù)據(jù)分布的均勻性問題。關于這一點，下文還將有所展開。

4. OSD —— 即object storage device，前文已經(jīng)詳細介紹，此處不再展開。唯一需要說明的是，OSD的數(shù)量事實上也關系到系統(tǒng)的數(shù)據(jù)分布均勻性，因此其數(shù)量不應太少。在實踐當中，至少也應該是數(shù)十上百個的量級才有助于Ceph系統(tǒng)的設計發(fā)揮其應有的優(yōu)勢。

5. Failure domain —— 這個概念在論文中并沒有進行定義，好在對分布式存儲系統(tǒng)有一定概念的讀者應該能夠了解其大意。

基于上述定義，便可以對尋址流程進行解釋了。具體而言， Ceph中的尋址至少要經(jīng)歷以下三次映射：

1. File -> object映射

這次映射的目的是，將用戶要操作的file，映射為RADOS能夠處理的object。其映射十分簡單，本質上就是按照object的最大size對file進行切分，相當于RAID中的條帶化過程。這種切分的好處有二：一是讓大小不限的file變成最大size一致、可以被RADOS高效管理的object；二是讓對單一file實施的串行處理變?yōu)閷Χ鄠€object實施的并行化處理。

每一個切分后產(chǎn)生的object將獲得唯一的oid，即object id。其產(chǎn)生方式也是線性映射，極其簡單。圖中，ino是待操作file的元數(shù)據(jù)，可以簡單理解為該file的唯一id。ono則是由該file切分產(chǎn)生的某個object的序號。而oid就是將這個序號簡單連綴在該file id之后得到的。舉例而言，如果一個id為filename的file被切分成了三個object，則其object序號依次為0、1和2，而最終得到的oid就依次為filename0、filename1和filename2。

這里隱含的問題是，ino的唯一性必須得到保證，否則后續(xù)映射無法正確進行。

2. Object -> PG映射

在file被映射為一個或多個object之后，就需要將每個object獨立地映射到一個PG中去。這個映射過程也很簡單，如圖中所示，其計算公式是：

hash(oid) & mask -> pgid

由此可見，其計算由兩步組成。首先是使用Ceph系統(tǒng)指定的一個靜態(tài)哈希函數(shù)計算oid的哈希值，將oid映射成為一個近似均勻分布的偽隨機值。然后，將這個偽隨機值和mask按位相與，得到最終的PG序號（pgid）。根據(jù)RADOS的設計，給定PG的總數(shù)為m（m應該為2的整數(shù)冪），則mask的值為m-1。因此，哈希值計算和按位與操作的整體結果事實上是從所有m個PG中近似均勻地隨機選擇一個?；谶@一機制，當有大量object和大量PG時，RADOS能夠保證object和PG之間的近似均勻映射。又因為object是由file切分而來，大部分object的size相同，因而，這一映射最終保證了，各個PG中存儲的object的總數(shù)據(jù)量近似均勻。

從介紹不難看出，這里反復強調(diào)了“大量”。只有當object和PG的數(shù)量較多時，這種偽隨機關系的近似均勻性才能成立，Ceph的數(shù)據(jù)存儲均勻性才有保證。為保證“大量”的成立，一方面，object的最大size應該被合理配置，以使得同樣數(shù)量的file能夠被切分成更多的object；另一方面，Ceph也推薦PG總數(shù)應該為OSD總數(shù)的數(shù)百倍，以保證有足夠數(shù)量的PG可供映射。

3. PG -> OSD映射

第三次映射就是將作為object的邏輯組織單元的PG映射到數(shù)據(jù)的實際存儲單元OSD。如圖所示，RADOS采用一個名為CRUSH的算法，將pgid代入其中，然后得到一組共n個OSD。這n個OSD即共同負責存儲和維護一個PG中的所有object。前已述及，n的數(shù)值可以根據(jù)實際應用中對于可靠性的需求而配置，在生產(chǎn)環(huán)境下通常為3。具體到每個OSD，則由其上運行的OSD deamon負責執(zhí)行映射到本地的object在本地文件系統(tǒng)中的存儲、訪問、元數(shù)據(jù)維護等操作。

和“object -> PG”映射中采用的哈希算法不同，這個CRUSH算法的結果不是絕對不變的，而是受到其他因素的影響。其影響因素主要有二：

一是當前系統(tǒng)狀態(tài)，也就是上文邏輯結構中曾經(jīng)提及的cluster map。當系統(tǒng)中的OSD狀態(tài)、數(shù)量發(fā)生變化時，cluster map可能發(fā)生變化，而這種變化將會影響到PG與OSD之間的映射。

二是存儲策略配置。這里的策略主要與安全相關。利用策略配置，系統(tǒng)管理員可以指定承載同一個PG的3個OSD分別位于數(shù)據(jù)中心的不同服務器乃至機架上，從而進一步改善存儲的可靠性。

因此，只有在系統(tǒng)狀態(tài)（cluster map）和存儲策略都不發(fā)生變化的時候，PG和OSD之間的映射關系才是固定不變的。在實際使用當中，策略一經(jīng)配置通常不會改變。而系統(tǒng)狀態(tài)的改變或者是由于設備損壞，或者是因為存儲集群規(guī)模擴大。好在Ceph本身提供了對于這種變化的自動化支持，因而，即便PG與OSD之間的映射關系發(fā)生了變化，也并不會對應用造成困擾。事實上，Ceph正是需要有目的的利用這種動態(tài)映射關系。正是利用了CRUSH的動態(tài)特性，Ceph可以將一個PG根據(jù)需要動態(tài)遷移到不同的OSD組合上，從而自動化地實現(xiàn)高可靠性、數(shù)據(jù)分布re-blancing等特性。

之所以在此次映射中使用CRUSH算法，而不是其他哈希算法，原因之一正是CRUSH具有上述可配置特性，可以根據(jù)管理員的配置參數(shù)決定OSD的物理位置映射策略；另一方面是因為CRUSH具有特殊的“穩(wěn)定性”，也即，當系統(tǒng)中加入新的OSD，導致系統(tǒng)規(guī)模增大時，大部分PG與OSD之間的映射關系不會發(fā)生改變，只有少部分PG的映射關系會發(fā)生變化并引發(fā)數(shù)據(jù)遷移。這種可配置性和穩(wěn)定性都不是普通哈希算法所能提供的。因此，CRUSH算法的設計也是Ceph的核心內(nèi)容之一，具體介紹可以參考。

至此為止，Ceph通過三次映射，完成了從file到object、PG和OSD整個映射過程。通觀整個過程，可以看到，這里沒有任何的全局性查表操作需求。至于唯一的全局性數(shù)據(jù)結構cluster map，在后文中將加以介紹。可以在這里指明的是，cluster map的維護和操作都是輕量級的，不會對系統(tǒng)的可擴展性、性能等因素造成不良影響。

一個可能出現(xiàn)的困惑是：為什么需要同時設計第二次和第三次映射？難道不重復么？關于這一點，Sage在其論文中解說不多，而筆者個人的分析如下：

我們可以反過來想像一下，如果沒有PG這一層映射，又會怎么樣呢？在這種情況下，一定需要采用某種算法，將object直接映射到一組OSD上。如果這種算法是某種固定映射的哈希算法，則意味著一個object將被固定映射在一組OSD上，當其中一個或多個OSD損壞時，object無法被自動遷移至其他OSD上（因為映射函數(shù)不允許），當系統(tǒng)為了擴容新增了OSD時，object也無法被re-balance到新的OSD上（同樣因為映射函數(shù)不允許）。這些限制都違背了Ceph系統(tǒng)高可靠性、高自動化的設計初衷。

如果采用一個動態(tài)算法（例如仍然采用CRUSH算法）來完成這一映射，似乎是可以避免靜態(tài)映射導致的問題。但是，其結果將是各個OSD所處理的本地元數(shù)據(jù)量爆增，由此帶來的計算復雜度和維護工作量也是難以承受的。

例如，在Ceph的現(xiàn)有機制中，一個OSD平時需要和與其共同承載同一個PG的其他OSD交換信息，以確定各自是否工作正常，是否需要進行維護操作。由于一個OSD上大約承載數(shù)百個PG，每個PG內(nèi)通常有3個OSD，因此，一段時間內(nèi)，一個OSD大約需要進行數(shù)百至數(shù)千次OSD信息交換。

然而，如果沒有PG的存在，則一個OSD需要和與其共同承載同一個object的其他OSD交換信息。由于每個OSD上承載的object很可能高達數(shù)百萬個，因此，同樣長度的一段時間內(nèi)，一個OSD大約需要進行的OSD間信息交換將暴漲至數(shù)百萬乃至數(shù)千萬次。而這種狀態(tài)維護成本顯然過高。

綜上所述，筆者認為，引入PG的好處至少有二：一方面實現(xiàn)了object和OSD之間的動態(tài)映射，從而為Ceph的可靠性、自動化等特性的實現(xiàn)留下了空間；另一方面也有效簡化了數(shù)據(jù)的存儲組織，大大降低了系統(tǒng)的維護管理開銷。理解這一點，對于徹底理解Ceph的對象尋址機制，是十分重要的。

數(shù)據(jù)操作流程

此處將首先以file寫入過程為例，對數(shù)據(jù)操作流程進行說明。

為簡化說明，便于理解，此處進行若干假定。首先，假定待寫入的file較小，無需切分，僅被映射為一個object。其次，假定系統(tǒng)中一個PG被映射到3個OSD上。

基于上述假定，則file寫入流程可以被下圖表示：

如圖所示，當某個client需要向Ceph集群寫入一個file時，首先需要在本地完成5.1節(jié)中所敘述的尋址流程，將file變?yōu)橐粋€object，然后找出存儲該object的一組三個OSD。這三個OSD具有各自不同的序號，序號最靠前的那個OSD就是這一組中的Primary OSD，而后兩個則依次是Secondary OSD和Tertiary OSD。

找出三個OSD后，client將直接和Primary OSD通信，發(fā)起寫入操作（步驟1）。Primary OSD收到請求后，分別向Secondary OSD和Tertiary OSD發(fā)起寫入操作（步驟2、3）。當Secondary OSD和Tertiary OSD各自完成寫入操作后，將分別向Primary OSD發(fā)送確認信息（步驟4、5）。當Primary OSD確信其他兩個OSD的寫入完成后，則自己也完成數(shù)據(jù)寫入，并向client確認object寫入操作完成（步驟6）。

之所以采用這樣的寫入流程，本質上是為了保證寫入過程中的可靠性，盡可能避免造成數(shù)據(jù)丟失。同時，由于client只需要向Primary OSD發(fā)送數(shù)據(jù)，因此，在Internet使用場景下的外網(wǎng)帶寬和整體訪問延遲又得到了一定程度的優(yōu)化。

當然，這種可靠性機制必然導致較長的延遲，特別是，如果等到所有的OSD都將數(shù)據(jù)寫入磁盤后再向client發(fā)送確認信號，則整體延遲可能難以忍受。因此，Ceph可以分兩次向client進行確認。當各個OSD都將數(shù)據(jù)寫入內(nèi)存緩沖區(qū)后，就先向client發(fā)送一次確認，此時client即可以向下執(zhí)行。待各個OSD都將數(shù)據(jù)寫入磁盤后，會向client發(fā)送一個最終確認信號，此時client可以根據(jù)需要刪除本地數(shù)據(jù)。

分析上述流程可以看出，在正常情況下，client可以獨立完成OSD尋址操作，而不必依賴于其他系統(tǒng)模塊。因此，大量的client可以同時和大量的OSD進行并行操作。同時，如果一個file被切分成多個object，這多個object也可被并行發(fā)送至多個OSD。

從OSD的角度來看，由于同一個OSD在不同的PG中的角色不同，因此，其工作壓力也可以被盡可能均勻地分擔，從而避免單個OSD變成性能瓶頸。

如果需要讀取數(shù)據(jù)，client只需完成同樣的尋址過程，并直接和Primary OSD聯(lián)系。目前的Ceph設計中，被讀取的數(shù)據(jù)僅由Primary OSD提供。但目前也有分散讀取壓力以提高性能的討論。

集群維護

前面的介紹中已經(jīng)提到，由若干個monitor共同負責整個Ceph集群中所有OSD狀態(tài)的發(fā)現(xiàn)與記錄，并且共同形成cluster map的master版本，然后擴散至全體OSD以及client。OSD使用cluster map進行數(shù)據(jù)的維護，而client使用cluster map進行數(shù)據(jù)的尋址。

在集群中，各個monitor的功能總體上是一樣的，其相互間的關系可以被簡單理解為主從備份關系。因此，在下面的討論中不對各個monitor加以區(qū)分。

略顯出乎意料的是，monitor并不主動輪詢各個OSD的當前狀態(tài)。正相反，OSD需要向monitor上報狀態(tài)信息。常見的上報有兩種情況：一是新的OSD被加入集群，二是某個OSD發(fā)現(xiàn)自身或者其他OSD發(fā)生異常。在收到這些上報信息后，monitor將更新cluster map信息并加以擴散。其細節(jié)將在下文中加以介紹。

Cluster map的實際內(nèi)容包括：

（1） Epoch，即版本號。Cluster map的epoch是一個單調(diào)遞增序列。Epoch越大，則cluster map版本越新。因此，持有不同版本cluster map的OSD或client可以簡單地通過比較epoch決定應該遵從誰手中的版本。而monitor手中必定有epoch最大、版本最新的cluster map。當任意兩方在通信時發(fā)現(xiàn)彼此epoch值不同時，將默認先將cluster map同步至高版本一方的狀態(tài)，再進行后續(xù)操作。

（2）各個OSD的網(wǎng)絡地址。

（3）各個OSD的狀態(tài)。OSD狀態(tài)的描述分為兩個維度：up或者down（表明OSD是否正常工作），in或者out（表明OSD是否在至少一個PG中）。因此，對于任意一個OSD，共有四種可能的狀態(tài)：

—— Up且in：說明該OSD正常運行，且已經(jīng)承載至少一個PG的數(shù)據(jù)。這是一個OSD的標準工作狀態(tài)；

—— Up且out：說明該OSD正常運行，但并未承載任何PG，其中也沒有數(shù)據(jù)。一個新的OSD剛剛被加入Ceph集群后，便會處于這一狀態(tài)。而一個出現(xiàn)故障的OSD被修復后，重新加入Ceph集群時，也是處于這一狀態(tài)；

—— Down且in：說明該OSD發(fā)生異常，但仍然承載著至少一個PG，其中仍然存儲著數(shù)據(jù)。這種狀態(tài)下的OSD剛剛被發(fā)現(xiàn)存在異常，可能仍能恢復正常，也可能會徹底無法工作；

—— Down且out：說明該OSD已經(jīng)徹底發(fā)生故障，且已經(jīng)不再承載任何PG。

（4）CRUSH算法配置參數(shù)。表明了Ceph集群的物理層級關系（cluster hierarchy），位置映射規(guī)則（placement rules）。

根據(jù)cluster map的定義可以看出，其版本變化通常只會由（3）和（4）兩項信息的變化觸發(fā)。而這兩者相比，（3）發(fā)生變化的概率更高一些。這可以通過下面對OSD工作狀態(tài)變化過程的介紹加以反映。

一個新的OSD上線后，首先根據(jù)配置信息與monitor通信。Monitor將其加入cluster map，并設置為up且out狀態(tài)，再將最新版本的cluster map發(fā)給這個新OSD。

收到monitor發(fā)來的cluster map之后，這個新OSD計算出自己所承載的PG（為簡化討論，此處我們假定這個新的OSD開始只承載一個PG），以及和自己承載同一個PG的其他OSD。然后，新OSD將與這些OSD取得聯(lián)系。如果這個PG目前處于降級狀態(tài)（即承載該PG的OSD個數(shù)少于正常值，如正常應該是3個，此時只有2個或1個。這種情況通常是OSD故障所致），則其他OSD將把這個PG內(nèi)的所有對象和元數(shù)據(jù)復制給新OSD。數(shù)據(jù)復制完成后，新OSD被置為up且in狀態(tài)。而cluster map內(nèi)容也將據(jù)此更新。這事實上是一個自動化的failure recovery過程。當然，即便沒有新的OSD加入，降級的PG也將計算出其他OSD實現(xiàn)failure recovery。

如果該PG目前一切正常，則這個新OSD將替換掉現(xiàn)有OSD中的一個（PG內(nèi)將重新選出Primary OSD），并承擔其數(shù)據(jù)。在數(shù)據(jù)復制完成后，新OSD被置為up且in狀態(tài)，而被替換的OSD將退出該PG（但狀態(tài)通常仍然為up且in，因為還要承載其他PG）。而cluster map內(nèi)容也將據(jù)此更新。這事實上是一個自動化的數(shù)據(jù)re-balancing過程。

如果一個OSD發(fā)現(xiàn)和自己共同承載一個PG的另一個OSD無法聯(lián)通，則會將這一情況上報monitor。此外，如果一個OSD deamon發(fā)現(xiàn)自身工作狀態(tài)異常，也將把異常情況主動上報給monitor。在上述情況下，monitor將把出現(xiàn)問題的OSD的狀態(tài)設為down且in。如果超過某一預訂時間期限，該OSD仍然無法恢復正常，則其狀態(tài)將被設置為down且out。反之，如果該OSD能夠恢復正常，則其狀態(tài)會恢復為up且in。在上述這些狀態(tài)變化發(fā)生之后，monitor都將更新cluster map并進行擴散。這事實上是自動化的failure detection過程。

由之前介紹可以看出，對于一個Ceph集群而言，即便由數(shù)千個甚至更多OSD組成，cluster map的數(shù)據(jù)結構大小也并不驚人。同時，cluster map的狀態(tài)更新并不會頻繁發(fā)生。即便如此，Ceph依然對cluster map信息的擴散機制進行了優(yōu)化，以便減輕相關計算和通信壓力。

首先，cluster map信息是以增量形式擴散的。如果任意一次通信的雙方發(fā)現(xiàn)其epoch不一致，則版本更新的一方將把二者所擁有的cluster map的差異發(fā)送給另外一方。

其次，cluster map信息是以異步且lazy的形式擴散的。也即，monitor并不會在每一次cluster map版本更新后都將新版本廣播至全體OSD，而是在有OSD向自己上報信息時，將更新回復給對方。類似的，各個OSD也是在和其他OSD通信時，將更新發(fā)送給版本低于自己的對方。

基于上述機制，Ceph避免了由于cluster map版本更新而引起的廣播風暴。這雖然是一種異步且lazy的機制，但根據(jù)Sage論文中的結論，對于一個由n個OSD組成的Ceph集群，任何一次版本更新能夠在O(log(n))時間復雜度內(nèi)擴散到集群中的任何一個OSD上。

一個可能被問到的問題是：既然這是一種異步和lazy的擴散機制，則在版本擴散過程中，系統(tǒng)必定出現(xiàn)各個OSD看到的cluster map不一致的情況，這是否會導致問題？答案是：不會。事實上，如果一個client和它要訪問的PG內(nèi)部的各個OSD看到的cluster map狀態(tài)一致，則訪問操作就可以正確進行。而如果這個client或者PG中的某個OSD和其他幾方的cluster map不一致，則根據(jù)Ceph的機制設計，這幾方將首先同步cluster map至最新狀態(tài)，并進行必要的數(shù)據(jù)re-balancing操作，然后即可繼續(xù)正常訪問。

通過上述介紹，我們可以簡要了解Ceph究竟是如果基于cluster map機制，并由monitor、OSD和client共同配合完成集群狀態(tài)的維護與數(shù)據(jù)訪問的。特別的，基于這個機制，事實上可以自然而然的完成自動化的數(shù)據(jù)備份、數(shù)據(jù)re-balancing、故障探測和故障恢復，并不需要復雜的特殊設計。這一點確實讓人印象深刻。

關于Ceph的結構、工作原理及流程是怎樣的問題的解答就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，如果你還有很多疑惑沒有解開，可以關注億速云行業(yè)資訊頻道了解更多相關知識。