Ceph的結(jié)構(gòu)、工作原理及流程是怎樣的，針對(duì)這個(gè)問(wèn)題，這篇文章詳細(xì)介紹了相對(duì)應(yīng)的分析和解答，希望可以幫助更多想解決這個(gè)問(wèn)題的小伙伴找到更簡(jiǎn)單易行的方法。
振安網(wǎng)站建設(shè)公司成都創(chuàng)新互聯(lián)公司,振安網(wǎng)站設(shè)計(jì)制作，有大型網(wǎng)站制作公司豐富經(jīng)驗(yàn)。已為振安上1000+提供企業(yè)網(wǎng)站建設(shè)服務(wù)。企業(yè)網(wǎng)站搭建\外貿(mào)營(yíng)銷(xiāo)網(wǎng)站建設(shè)要多少錢(qián)，請(qǐng)找那個(gè)售后服務(wù)好的振安做網(wǎng)站的公司定做！
Ceph存儲(chǔ)系統(tǒng)的邏輯層次結(jié)構(gòu)如下圖所示：
自下向上，可以將Ceph系統(tǒng)分為四個(gè)層次：
（1）基礎(chǔ)存儲(chǔ)系統(tǒng)RADOS（Reliable, Autonomic, Distributed Object Store，即可靠的、自動(dòng)化的、分布式的對(duì)象存儲(chǔ)）
顧名思義，這一層本身就是一個(gè)完整的對(duì)象存儲(chǔ)系統(tǒng)，所有存儲(chǔ)在Ceph系統(tǒng)中的用戶(hù)數(shù)據(jù)事實(shí)上最終都是由這一層來(lái)存儲(chǔ)的。而Ceph的高可靠、高可擴(kuò)展、高性能、高自動(dòng)化等等特性本質(zhì)上也是由這一層所提供的。因此，理解RADOS是理解Ceph的基礎(chǔ)與關(guān)鍵。
物理上，RADOS由大量的存儲(chǔ)設(shè)備節(jié)點(diǎn)組層，每個(gè)節(jié)點(diǎn)擁有自己的硬件資源（CPU、內(nèi)存、硬盤(pán)、網(wǎng)絡(luò)），并運(yùn)行著操作系統(tǒng)和文件系統(tǒng)。4.2、4.3節(jié)將對(duì)RADOS進(jìn)行展開(kāi)介紹。
（2）基礎(chǔ)庫(kù)librados
這一層的功能是對(duì)RADOS進(jìn)行抽象和封裝，并向上層提供API，以便直接基于RADOS（而不是整個(gè)Ceph）進(jìn)行應(yīng)用開(kāi)發(fā)。特別要注意的是，RADOS是一個(gè)對(duì)象存儲(chǔ)系統(tǒng)，因此，librados實(shí)現(xiàn)的API也只是針對(duì)對(duì)象存儲(chǔ)功能的。
RADOS采用C++開(kāi)發(fā)，所提供的原生librados API包括C和C++兩種，其文檔參見(jiàn)[2]。物理上，librados和基于其上開(kāi)發(fā)的應(yīng)用位于同一臺(tái)機(jī)器，因而也被稱(chēng)為本地API。應(yīng)用調(diào)用本機(jī)上的librados API，再由后者通過(guò)socket與RADOS集群中的節(jié)點(diǎn)通信并完成各種操作。
（3）高層應(yīng)用接口
這一層包括了三個(gè)部分：RADOS GW（RADOS Gateway）、 RBD（Reliable Block Device）和Ceph FS（Ceph File System），其作用是在librados庫(kù)的基礎(chǔ)上提供抽象層次更高、更便于應(yīng)用或客戶(hù)端使用的上層接口。
其中，RADOS GW是一個(gè)提供與Amazon S3和Swift兼容的RESTful API的gateway，以供相應(yīng)的對(duì)象存儲(chǔ)應(yīng)用開(kāi)發(fā)使用。RADOS GW提供的API抽象層次更高，但功能則不如librados強(qiáng)大。因此，開(kāi)發(fā)者應(yīng)針對(duì)自己的需求選擇使用。
RBD則提供了一個(gè)標(biāo)準(zhǔn)的塊設(shè)備接口，常用于在虛擬化的場(chǎng)景下為虛擬機(jī)創(chuàng)建volume。目前，Red Hat已經(jīng)將RBD驅(qū)動(dòng)集成在KVM/QEMU中，以提高虛擬機(jī)訪問(wèn)性能。
Ceph FS是一個(gè)POSIX兼容的分布式文件系統(tǒng)。由于還處在開(kāi)發(fā)狀態(tài)，因而Ceph官網(wǎng)并不推薦將其用于生產(chǎn)環(huán)境中。
（4）應(yīng)用層
這一層就是不同場(chǎng)景下對(duì)于Ceph各個(gè)應(yīng)用接口的各種應(yīng)用方式，例如基于librados直接開(kāi)發(fā)的對(duì)象存儲(chǔ)應(yīng)用，基于RADOS GW開(kāi)發(fā)的對(duì)象存儲(chǔ)應(yīng)用，基于RBD實(shí)現(xiàn)的云硬盤(pán)等等。
在上文的介紹中，有一個(gè)地方可能容易引起困惑：RADOS自身既然已經(jīng)是一個(gè)對(duì)象存儲(chǔ)系統(tǒng)，并且也可以提供librados API，為何還要再單獨(dú)開(kāi)發(fā)一個(gè)RADOS GW？
理解這個(gè)問(wèn)題，事實(shí)上有助于理解RADOS的本質(zhì)，因此有必要在此加以分析。粗看起來(lái)，librados和RADOS GW的區(qū)別在于，librados提供的是本地API，而RADOS GW提供的則是RESTful API，二者的編程模型和實(shí)際性能不同。而更進(jìn)一步說(shuō)，則和這兩個(gè)不同抽象層次的目標(biāo)應(yīng)用場(chǎng)景差異有關(guān)。換言之，雖然RADOS和S3、Swift同屬分布式對(duì)象存儲(chǔ)系統(tǒng)，但RADOS提供的功能更為基礎(chǔ)、也更為豐富。這一點(diǎn)可以通過(guò)對(duì)比看出。
由于Swift和S3支持的API功能近似，這里以Swift舉例說(shuō)明。Swift提供的API功能主要包括：
用戶(hù)管理操作：用戶(hù)認(rèn)證、獲取賬戶(hù)信息、列出容器列表等；
容器管理操作：創(chuàng)建/刪除容器、讀取容器信息、列出容器內(nèi)對(duì)象列表等；
對(duì)象管理操作：對(duì)象的寫(xiě)入、讀取、復(fù)制、更新、刪除、訪問(wèn)許可設(shè)置、元數(shù)據(jù)讀取或更新等。
由此可見(jiàn)，Swift（以及S3）提供的API所操作的“對(duì)象”只有三個(gè)：用戶(hù)賬戶(hù)、用戶(hù)存儲(chǔ)數(shù)據(jù)對(duì)象的容器、數(shù)據(jù)對(duì)象。并且，所有的操作均不涉及存儲(chǔ)系統(tǒng) 的底層硬件或系統(tǒng)信息。不難看出，這樣的API設(shè)計(jì)完全是針對(duì)對(duì)象存儲(chǔ)應(yīng)用開(kāi)發(fā)者和對(duì)象存儲(chǔ)應(yīng)用用戶(hù)的，并且假定其開(kāi)發(fā)者和用戶(hù)關(guān)心的內(nèi)容更偏重于賬戶(hù)和數(shù)據(jù)的管理，而對(duì)底層存儲(chǔ)系統(tǒng)細(xì)節(jié)不感興趣，更不關(guān)心效率、性能等方面的深入優(yōu)化。
而librados API的設(shè)計(jì)思想則與此完全不同。一方面，librados中沒(méi)有賬戶(hù)、容器這樣的高層概念；另一方面，librados API向開(kāi)發(fā)者開(kāi)放了大量的RADOS狀態(tài)信息與配置參數(shù)，允許開(kāi)發(fā)者對(duì)RADOS系統(tǒng)以及其中存儲(chǔ)的對(duì)象的狀態(tài)進(jìn)行觀察，并強(qiáng)有力地對(duì)系統(tǒng)存儲(chǔ)策略進(jìn)行控制。換言之，通過(guò)調(diào)用librados API，應(yīng)用不僅能夠?qū)崿F(xiàn)對(duì)數(shù)據(jù)對(duì)象的操作，還能夠?qū)崿F(xiàn)對(duì)RADOS系統(tǒng)的管理和配置。這對(duì)于S3和Swift的RESTful API設(shè)計(jì)是不可想像的，也是沒(méi)有必要的。
基于上述分析對(duì)比，不難看出，librados事實(shí)上更適合對(duì)于系統(tǒng)有著深刻理解，同時(shí)對(duì)于功能定制擴(kuò)展和性能深度優(yōu)化有著強(qiáng)烈需求的高級(jí)用戶(hù)?；趌ibrados的開(kāi)發(fā)可能更適合于在私有Ceph系統(tǒng)上開(kāi)發(fā)專(zhuān)用應(yīng)用，或者為基于Ceph的公有存儲(chǔ)系統(tǒng)開(kāi)發(fā)后臺(tái)數(shù)據(jù)管理、處理應(yīng)用。而RADOS GW則更適合于常見(jiàn)的基于web的對(duì)象存儲(chǔ)應(yīng)用開(kāi)發(fā)，例如公有云上的對(duì)象存儲(chǔ)服務(wù)。
RADOS的系統(tǒng)邏輯結(jié)構(gòu)如下圖所示
在使用RADOS系統(tǒng)時(shí)，大量的客戶(hù)端程序通過(guò)與OSD或者monitor的交互獲取cluster map，然后直接在本地進(jìn)行計(jì)算，得出對(duì)象的存儲(chǔ)位置后，便直接與對(duì)應(yīng)的OSD通信，完成數(shù)據(jù)的各種操作?？梢?jiàn)，在此過(guò)程中，只要保證cluster map不頻繁更新，則客戶(hù)端顯然可以不依賴(lài)于任何元數(shù)據(jù)服務(wù)器，不進(jìn)行任何查表操作，便完成數(shù)據(jù)訪問(wèn)流程。在RADOS的運(yùn)行過(guò)程中，cluster map的更新完全取決于系統(tǒng)的狀態(tài)變化，而導(dǎo)致這一變化的常見(jiàn)事件只有兩種：OSD出現(xiàn)故障，或者RADOS規(guī)模擴(kuò)大。而正常應(yīng)用場(chǎng)景下，這兩種事件發(fā)生 的頻率顯然遠(yuǎn)遠(yuǎn)低于客戶(hù)端對(duì)數(shù)據(jù)進(jìn)行訪問(wèn)的頻率。
根據(jù)定義，OSD可以被抽象為兩個(gè)組成部分，即系統(tǒng)部分和守護(hù)進(jìn)程（OSD deamon）部分。
OSD的系統(tǒng)部分本質(zhì)上就是一臺(tái)安裝了操作系統(tǒng)和文件系統(tǒng)的計(jì)算機(jī)，其硬件部分至少包括一個(gè)單核的處理器、一定數(shù)量的內(nèi)存、一塊硬盤(pán)以及一張網(wǎng)卡。
由于這么小規(guī)模的x86架構(gòu)服務(wù)器并不實(shí)用（事實(shí)上也見(jiàn)不到），因而實(shí)際應(yīng)用中通常將多個(gè)OSD集中部署在一臺(tái)更大規(guī)模的服務(wù)器上。在選擇系統(tǒng)配置時(shí)，應(yīng)當(dāng) 能夠保證每個(gè)OSD占用一定的計(jì)算能力、一定量的內(nèi)存和一塊硬盤(pán)。同時(shí)，應(yīng)當(dāng)保證該服務(wù)器具備足夠的網(wǎng)絡(luò)帶寬。具體的硬件配置選擇可以參考。
在 上述系統(tǒng)平臺(tái)上，每個(gè)OSD擁有一個(gè)自己的OSD deamon。這個(gè)deamon負(fù)責(zé)完成OSD的所有邏輯功能，包括與monitor和其他OSD（事實(shí)上是其他OSD的deamon）通信以維護(hù)更新系 統(tǒng)狀態(tài)，與其他OSD共同完成數(shù)據(jù)的存儲(chǔ)和維護(hù)，與client通信完成各種數(shù)據(jù)對(duì)象操作等等。
Ceph系統(tǒng)的邏輯結(jié)構(gòu)就介紹到這里。下篇文章將著重說(shuō)明Ceph（主要是RADOS）的工作原理和操作流程。
如圖所示，RADOS集群主要由兩種節(jié)點(diǎn)組成。一種是為數(shù)眾多的、負(fù)責(zé)完成數(shù)據(jù)存儲(chǔ)和維護(hù)功能的OSD（Object Storage Device），另一種則是若干個(gè)負(fù)責(zé)完成系統(tǒng)狀態(tài)檢測(cè)和維護(hù)的monitor。OSD和monitor之間相互傳輸節(jié)點(diǎn)狀態(tài)信息，共同得出系統(tǒng)的總體工 作狀態(tài)，并形成一個(gè)全局系統(tǒng)狀態(tài)記錄數(shù)據(jù)結(jié)構(gòu)，即所謂的cluster map。這個(gè)數(shù)據(jù)結(jié)構(gòu)與RADOS提供的特定算法相配合，便實(shí)現(xiàn)了Ceph“無(wú)需查表，算算就好”的核心機(jī)制以及若干優(yōu)秀特性。
本節(jié)將對(duì)Ceph的工作原理和若干關(guān)鍵工作流程進(jìn)行扼要介紹。如前所述，由于Ceph的功能實(shí)現(xiàn)本質(zhì)上依托于RADOS，因而，此處的介紹事實(shí)上也是針對(duì)RADOS進(jìn)行。對(duì)于上層的部分，特別是RADOS GW和RBD，由于現(xiàn)有的文檔中（包括Sage的論文中）并未詳細(xì)介紹，還請(qǐng)讀者多多包涵。
首先介紹RADOS中最為核心的、基于計(jì)算的對(duì)象尋址機(jī)制，然后說(shuō)明對(duì)象存取的工作流程，之后介紹RADOS集群維護(hù)的工作過(guò)程，最后結(jié)合Ceph的結(jié)構(gòu)和原理對(duì)其技術(shù)優(yōu)勢(shì)加以回顧和剖析。
Ceph系統(tǒng)中的尋址流程如下圖所示：
上圖左側(cè)的幾個(gè)概念說(shuō)明如下：
1. File —— 此處的file就是用戶(hù)需要存儲(chǔ)或者訪問(wèn)的文件。對(duì)于一個(gè)基于Ceph開(kāi)發(fā)的對(duì)象存儲(chǔ)應(yīng)用而言，這個(gè)file也就對(duì)應(yīng)于應(yīng)用中的“對(duì)象”，也就是用戶(hù)直接操作的“對(duì)象”。
2. Ojbect —— 此處的object是RADOS所看到的“對(duì)象”。Object與上面提到的file的區(qū)別是，object的最大size由RADOS限定（通常為2MB或4MB），以便實(shí)現(xiàn)底層存儲(chǔ)的組織管理。因此，當(dāng)上層應(yīng)用向RADOS存入size很大的file時(shí)，需要將file切分成統(tǒng)一大小的一系列object（最后一個(gè)的大小可以不同）進(jìn)行存儲(chǔ)。為避免混淆，在本文中將盡量避免使用中文的“對(duì)象”這一名詞，而直接使用file或object進(jìn)行說(shuō)明。
3. PG（Placement Group）—— 顧名思義，PG的用途是對(duì)object的存儲(chǔ)進(jìn)行組織和位置映射。具體而言，一個(gè)PG負(fù)責(zé)組織若干個(gè)object（可以為數(shù)千個(gè)甚至更多），但一個(gè)object只能被映射到一個(gè)PG中，即，PG和object之間是“一對(duì)多”映射關(guān)系。同時(shí)，一個(gè)PG會(huì)被映射到n個(gè)OSD上，而每個(gè)OSD上都會(huì)承載大量的PG，即，PG和OSD之間是“多對(duì)多”映射關(guān)系。在實(shí)踐當(dāng)中，n至少為2，如果用于生產(chǎn)環(huán)境，則至少為3。一個(gè)OSD上的PG則可達(dá)到數(shù)百個(gè)。事實(shí)上，PG數(shù)量的設(shè)置牽扯到數(shù)據(jù)分布的均勻性問(wèn)題。關(guān)于這一點(diǎn)，下文還將有所展開(kāi)。
4. OSD —— 即object storage device，前文已經(jīng)詳細(xì)介紹，此處不再展開(kāi)。唯一需要說(shuō)明的是，OSD的數(shù)量事實(shí)上也關(guān)系到系統(tǒng)的數(shù)據(jù)分布均勻性，因此其數(shù)量不應(yīng)太少。在實(shí)踐當(dāng)中，至少也應(yīng)該是數(shù)十上百個(gè)的量級(jí)才有助于Ceph系統(tǒng)的設(shè)計(jì)發(fā)揮其應(yīng)有的優(yōu)勢(shì)。
5. Failure domain —— 這個(gè)概念在論文中并沒(méi)有進(jìn)行定義，好在對(duì)分布式存儲(chǔ)系統(tǒng)有一定概念的讀者應(yīng)該能夠了解其大意。
基于上述定義，便可以對(duì)尋址流程進(jìn)行解釋了。具體而言， Ceph中的尋址至少要經(jīng)歷以下三次映射：
1. File -> object映射
這次映射的目的是，將用戶(hù)要操作的file，映射為RADOS能夠處理的object。其映射十分簡(jiǎn)單，本質(zhì)上就是按照object的最大size對(duì)file進(jìn)行切分，相當(dāng)于RAID中的條帶化過(guò)程。這種切分的好處有二：一是讓大小不限的file變成最大size一致、可以被RADOS高效管理的object；二是讓對(duì)單一file實(shí)施的串行處理變?yōu)閷?duì)多個(gè)object實(shí)施的并行化處理。
每一個(gè)切分后產(chǎn)生的object將獲得唯一的oid，即object id。其產(chǎn)生方式也是線(xiàn)性映射，極其簡(jiǎn)單。圖中，ino是待操作file的元數(shù)據(jù)，可以簡(jiǎn)單理解為該file的唯一id。ono則是由該file切分產(chǎn)生的某個(gè)object的序號(hào)。而oid就是將這個(gè)序號(hào)簡(jiǎn)單連綴在該file id之后得到的。舉例而言，如果一個(gè)id為filename的file被切分成了三個(gè)object，則其object序號(hào)依次為0、1和2，而最終得到的oid就依次為filename0、filename1和filename2。
這里隱含的問(wèn)題是，ino的唯一性必須得到保證，否則后續(xù)映射無(wú)法正確進(jìn)行。
2. Object -> PG映射
在file被映射為一個(gè)或多個(gè)object之后，就需要將每個(gè)object獨(dú)立地映射到一個(gè)PG中去。這個(gè)映射過(guò)程也很簡(jiǎn)單，如圖中所示，其計(jì)算公式是：
hash(oid) & mask -> pgid
由此可見(jiàn)，其計(jì)算由兩步組成。首先是使用Ceph系統(tǒng)指定的一個(gè)靜態(tài)哈希函數(shù)計(jì)算oid的哈希值，將oid映射成為一個(gè)近似均勻分布的偽隨機(jī)值。然后，將這個(gè)偽隨機(jī)值和mask按位相與，得到最終的PG序號(hào)（pgid）。根據(jù)RADOS的設(shè)計(jì)，給定PG的總數(shù)為m（m應(yīng)該為2的整數(shù)冪），則mask的值為m-1。因此，哈希值計(jì)算和按位與操作的整體結(jié)果事實(shí)上是從所有m個(gè)PG中近似均勻地隨機(jī)選擇一個(gè)?；谶@一機(jī)制，當(dāng)有大量object和大量PG時(shí)，RADOS能夠保證object和PG之間的近似均勻映射。又因?yàn)閛bject是由file切分而來(lái)，大部分object的size相同，因而，這一映射最終保證了，各個(gè)PG中存儲(chǔ)的object的總數(shù)據(jù)量近似均勻。
從介紹不難看出，這里反復(fù)強(qiáng)調(diào)了“大量”。只有當(dāng)object和PG的數(shù)量較多時(shí)，這種偽隨機(jī)關(guān)系的近似均勻性才能成立，Ceph的數(shù)據(jù)存儲(chǔ)均勻性才有保證。為保證“大量”的成立，一方面，object的最大size應(yīng)該被合理配置，以使得同樣數(shù)量的file能夠被切分成更多的object；另一方面，Ceph也推薦PG總數(shù)應(yīng)該為OSD總數(shù)的數(shù)百倍，以保證有足夠數(shù)量的PG可供映射。
3. PG -> OSD映射
第三次映射就是將作為object的邏輯組織單元的PG映射到數(shù)據(jù)的實(shí)際存儲(chǔ)單元OSD。如圖所示，RADOS采用一個(gè)名為CRUSH的算法，將pgid代入其中，然后得到一組共n個(gè)OSD。這n個(gè)OSD即共同負(fù)責(zé)存儲(chǔ)和維護(hù)一個(gè)PG中的所有object。前已述及，n的數(shù)值可以根據(jù)實(shí)際應(yīng)用中對(duì)于可靠性的需求而配置，在生產(chǎn)環(huán)境下通常為3。具體到每個(gè)OSD，則由其上運(yùn)行的OSD deamon負(fù)責(zé)執(zhí)行映射到本地的object在本地文件系統(tǒng)中的存儲(chǔ)、訪問(wèn)、元數(shù)據(jù)維護(hù)等操作。
和“object -> PG”映射中采用的哈希算法不同，這個(gè)CRUSH算法的結(jié)果不是絕對(duì)不變的，而是受到其他因素的影響。其影響因素主要有二：
一是當(dāng)前系統(tǒng)狀態(tài)，也就是上文邏輯結(jié)構(gòu)中曾經(jīng)提及的cluster map。當(dāng)系統(tǒng)中的OSD狀態(tài)、數(shù)量發(fā)生變化時(shí)，cluster map可能發(fā)生變化，而這種變化將會(huì)影響到PG與OSD之間的映射。
二是存儲(chǔ)策略配置。這里的策略主要與安全相關(guān)。利用策略配置，系統(tǒng)管理員可以指定承載同一個(gè)PG的3個(gè)OSD分別位于數(shù)據(jù)中心的不同服務(wù)器乃至機(jī)架上，從而進(jìn)一步改善存儲(chǔ)的可靠性。
因此，只有在系統(tǒng)狀態(tài)（cluster map）和存儲(chǔ)策略都不發(fā)生變化的時(shí)候，PG和OSD之間的映射關(guān)系才是固定不變的。在實(shí)際使用當(dāng)中，策略一經(jīng)配置通常不會(huì)改變。而系統(tǒng)狀態(tài)的改變或者是由于設(shè)備損壞，或者是因?yàn)榇鎯?chǔ)集群規(guī)模擴(kuò)大。好在Ceph本身提供了對(duì)于這種變化的自動(dòng)化支持，因而，即便PG與OSD之間的映射關(guān)系發(fā)生了變化，也并不會(huì)對(duì)應(yīng)用造成困擾。事實(shí)上，Ceph正是需要有目的的利用這種動(dòng)態(tài)映射關(guān)系。正是利用了CRUSH的動(dòng)態(tài)特性，Ceph可以將一個(gè)PG根據(jù)需要?jiǎng)討B(tài)遷移到不同的OSD組合上，從而自動(dòng)化地實(shí)現(xiàn)高可靠性、數(shù)據(jù)分布re-blancing等特性。
之所以在此次映射中使用CRUSH算法，而不是其他哈希算法，原因之一正是CRUSH具有上述可配置特性，可以根據(jù)管理員的配置參數(shù)決定OSD的物理位置映射策略；另一方面是因?yàn)镃RUSH具有特殊的“穩(wěn)定性”，也即，當(dāng)系統(tǒng)中加入新的OSD，導(dǎo)致系統(tǒng)規(guī)模增大時(shí)，大部分PG與OSD之間的映射關(guān)系不會(huì)發(fā)生改變，只有少部分PG的映射關(guān)系會(huì)發(fā)生變化并引發(fā)數(shù)據(jù)遷移。這種可配置性和穩(wěn)定性都不是普通哈希算法所能提供的。因此，CRUSH算法的設(shè)計(jì)也是Ceph的核心內(nèi)容之一，具體介紹可以參考。
至此為止，Ceph通過(guò)三次映射，完成了從file到object、PG和OSD整個(gè)映射過(guò)程。通觀整個(gè)過(guò)程，可以看到，這里沒(méi)有任何的全局性查表操作需求。至于唯一的全局性數(shù)據(jù)結(jié)構(gòu)cluster map，在后文中將加以介紹。可以在這里指明的是，cluster map的維護(hù)和操作都是輕量級(jí)的，不會(huì)對(duì)系統(tǒng)的可擴(kuò)展性、性能等因素造成不良影響。
一個(gè)可能出現(xiàn)的困惑是：為什么需要同時(shí)設(shè)計(jì)第二次和第三次映射？難道不重復(fù)么？關(guān)于這一點(diǎn)，Sage在其論文中解說(shuō)不多，而筆者個(gè)人的分析如下：
我們可以反過(guò)來(lái)想像一下，如果沒(méi)有PG這一層映射，又會(huì)怎么樣呢？在這種情況下，一定需要采用某種算法，將object直接映射到一組OSD上。如果這種算法是某種固定映射的哈希算法，則意味著一個(gè)object將被固定映射在一組OSD上，當(dāng)其中一個(gè)或多個(gè)OSD損壞時(shí)，object無(wú)法被自動(dòng)遷移至其他OSD上（因?yàn)橛成浜瘮?shù)不允許），當(dāng)系統(tǒng)為了擴(kuò)容新增了OSD時(shí)，object也無(wú)法被re-balance到新的OSD上（同樣因?yàn)橛成浜瘮?shù)不允許）。這些限制都違背了Ceph系統(tǒng)高可靠性、高自動(dòng)化的設(shè)計(jì)初衷。
如果采用一個(gè)動(dòng)態(tài)算法（例如仍然采用CRUSH算法）來(lái)完成這一映射，似乎是可以避免靜態(tài)映射導(dǎo)致的問(wèn)題。但是，其結(jié)果將是各個(gè)OSD所處理的本地元數(shù)據(jù)量爆增，由此帶來(lái)的計(jì)算復(fù)雜度和維護(hù)工作量也是難以承受的。
例如，在Ceph的現(xiàn)有機(jī)制中，一個(gè)OSD平時(shí)需要和與其共同承載同一個(gè)PG的其他OSD交換信息，以確定各自是否工作正常，是否需要進(jìn)行維護(hù)操作。由于一個(gè)OSD上大約承載數(shù)百個(gè)PG，每個(gè)PG內(nèi)通常有3個(gè)OSD，因此，一段時(shí)間內(nèi)，一個(gè)OSD大約需要進(jìn)行數(shù)百至數(shù)千次OSD信息交換。
然而，如果沒(méi)有PG的存在，則一個(gè)OSD需要和與其共同承載同一個(gè)object的其他OSD交換信息。由于每個(gè)OSD上承載的object很可能高達(dá)數(shù)百萬(wàn)個(gè)，因此，同樣長(zhǎng)度的一段時(shí)間內(nèi)，一個(gè)OSD大約需要進(jìn)行的OSD間信息交換將暴漲至數(shù)百萬(wàn)乃至數(shù)千萬(wàn)次。而這種狀態(tài)維護(hù)成本顯然過(guò)高。
綜上所述，筆者認(rèn)為，引入PG的好處至少有二：一方面實(shí)現(xiàn)了object和OSD之間的動(dòng)態(tài)映射，從而為Ceph的可靠性、自動(dòng)化等特性的實(shí)現(xiàn)留下了空間；另一方面也有效簡(jiǎn)化了數(shù)據(jù)的存儲(chǔ)組織，大大降低了系統(tǒng)的維護(hù)管理開(kāi)銷(xiāo)。理解這一點(diǎn)，對(duì)于徹底理解Ceph的對(duì)象尋址機(jī)制，是十分重要的。
此處將首先以file寫(xiě)入過(guò)程為例，對(duì)數(shù)據(jù)操作流程進(jìn)行說(shuō)明。
為簡(jiǎn)化說(shuō)明，便于理解，此處進(jìn)行若干假定。首先，假定待寫(xiě)入的file較小，無(wú)需切分，僅被映射為一個(gè)object。其次，假定系統(tǒng)中一個(gè)PG被映射到3個(gè)OSD上。
基于上述假定，則file寫(xiě)入流程可以被下圖表示：
如圖所示，當(dāng)某個(gè)client需要向Ceph集群寫(xiě)入一個(gè)file時(shí)，首先需要在本地完成5.1節(jié)中所敘述的尋址流程，將file變?yōu)橐粋€(gè)object，然后找出存儲(chǔ)該object的一組三個(gè)OSD。這三個(gè)OSD具有各自不同的序號(hào)，序號(hào)最靠前的那個(gè)OSD就是這一組中的Primary OSD，而后兩個(gè)則依次是Secondary OSD和Tertiary OSD。
找出三個(gè)OSD后，client將直接和Primary OSD通信，發(fā)起寫(xiě)入操作（步驟1）。Primary OSD收到請(qǐng)求后，分別向Secondary OSD和Tertiary OSD發(fā)起寫(xiě)入操作（步驟2、3）。當(dāng)Secondary OSD和Tertiary OSD各自完成寫(xiě)入操作后，將分別向Primary OSD發(fā)送確認(rèn)信息（步驟4、5）。當(dāng)Primary OSD確信其他兩個(gè)OSD的寫(xiě)入完成后，則自己也完成數(shù)據(jù)寫(xiě)入，并向client確認(rèn)object寫(xiě)入操作完成（步驟6）。
之所以采用這樣的寫(xiě)入流程，本質(zhì)上是為了保證寫(xiě)入過(guò)程中的可靠性，盡可能避免造成數(shù)據(jù)丟失。同時(shí)，由于client只需要向Primary OSD發(fā)送數(shù)據(jù)，因此，在Internet使用場(chǎng)景下的外網(wǎng)帶寬和整體訪問(wèn)延遲又得到了一定程度的優(yōu)化。
當(dāng)然，這種可靠性機(jī)制必然導(dǎo)致較長(zhǎng)的延遲，特別是，如果等到所有的OSD都將數(shù)據(jù)寫(xiě)入磁盤(pán)后再向client發(fā)送確認(rèn)信號(hào)，則整體延遲可能難以忍受。因此，Ceph可以分兩次向client進(jìn)行確認(rèn)。當(dāng)各個(gè)OSD都將數(shù)據(jù)寫(xiě)入內(nèi)存緩沖區(qū)后，就先向client發(fā)送一次確認(rèn)，此時(shí)client即可以向下執(zhí)行。待各個(gè)OSD都將數(shù)據(jù)寫(xiě)入磁盤(pán)后，會(huì)向client發(fā)送一個(gè)最終確認(rèn)信號(hào)，此時(shí)client可以根據(jù)需要?jiǎng)h除本地?cái)?shù)據(jù)。
分析上述流程可以看出，在正常情況下，client可以獨(dú)立完成OSD尋址操作，而不必依賴(lài)于其他系統(tǒng)模塊。因此，大量的client可以同時(shí)和大量的OSD進(jìn)行并行操作。同時(shí)，如果一個(gè)file被切分成多個(gè)object，這多個(gè)object也可被并行發(fā)送至多個(gè)OSD。
從OSD的角度來(lái)看，由于同一個(gè)OSD在不同的PG中的角色不同，因此，其工作壓力也可以被盡可能均勻地分擔(dān)，從而避免單個(gè)OSD變成性能瓶頸。
如果需要讀取數(shù)據(jù)，client只需完成同樣的尋址過(guò)程，并直接和Primary OSD聯(lián)系。目前的Ceph設(shè)計(jì)中，被讀取的數(shù)據(jù)僅由Primary OSD提供。但目前也有分散讀取壓力以提高性能的討論。
前面的介紹中已經(jīng)提到，由若干個(gè)monitor共同負(fù)責(zé)整個(gè)Ceph集群中所有OSD狀態(tài)的發(fā)現(xiàn)與記錄，并且共同形成cluster map的master版本，然后擴(kuò)散至全體OSD以及client。OSD使用cluster map進(jìn)行數(shù)據(jù)的維護(hù)，而client使用cluster map進(jìn)行數(shù)據(jù)的尋址。
在集群中，各個(gè)monitor的功能總體上是一樣的，其相互間的關(guān)系可以被簡(jiǎn)單理解為主從備份關(guān)系。因此，在下面的討論中不對(duì)各個(gè)monitor加以區(qū)分。
略顯出乎意料的是，monitor并不主動(dòng)輪詢(xún)各個(gè)OSD的當(dāng)前狀態(tài)。正相反，OSD需要向monitor上報(bào)狀態(tài)信息。常見(jiàn)的上報(bào)有兩種情況：一是新的OSD被加入集群，二是某個(gè)OSD發(fā)現(xiàn)自身或者其他OSD發(fā)生異常。在收到這些上報(bào)信息后，monitor將更新cluster map信息并加以擴(kuò)散。其細(xì)節(jié)將在下文中加以介紹。
Cluster map的實(shí)際內(nèi)容包括：
（1） Epoch，即版本號(hào)。Cluster map的epoch是一個(gè)單調(diào)遞增序列。Epoch越大，則cluster map版本越新。因此，持有不同版本cluster map的OSD或client可以簡(jiǎn)單地通過(guò)比較epoch決定應(yīng)該遵從誰(shuí)手中的版本。而monitor手中必定有epoch最大、版本最新的cluster map。當(dāng)任意兩方在通信時(shí)發(fā)現(xiàn)彼此epoch值不同時(shí)，將默認(rèn)先將cluster map同步至高版本一方的狀態(tài)，再進(jìn)行后續(xù)操作。
（2）各個(gè)OSD的網(wǎng)絡(luò)地址。
（3）各個(gè)OSD的狀態(tài)。OSD狀態(tài)的描述分為兩個(gè)維度：up或者down（表明OSD是否正常工作），in或者out（表明OSD是否在至少一個(gè)PG中）。因此，對(duì)于任意一個(gè)OSD，共有四種可能的狀態(tài)：
—— Up且in：說(shuō)明該OSD正常運(yùn)行，且已經(jīng)承載至少一個(gè)PG的數(shù)據(jù)。這是一個(gè)OSD的標(biāo)準(zhǔn)工作狀態(tài)；
—— Up且out：說(shuō)明該OSD正常運(yùn)行，但并未承載任何PG，其中也沒(méi)有數(shù)據(jù)。一個(gè)新的OSD剛剛被加入Ceph集群后，便會(huì)處于這一狀態(tài)。而一個(gè)出現(xiàn)故障的OSD被修復(fù)后，重新加入Ceph集群時(shí)，也是處于這一狀態(tài)；
—— Down且in：說(shuō)明該OSD發(fā)生異常，但仍然承載著至少一個(gè)PG，其中仍然存儲(chǔ)著數(shù)據(jù)。這種狀態(tài)下的OSD剛剛被發(fā)現(xiàn)存在異常，可能仍能恢復(fù)正常，也可能會(huì)徹底無(wú)法工作；
—— Down且out：說(shuō)明該OSD已經(jīng)徹底發(fā)生故障，且已經(jīng)不再承載任何PG。
（4）CRUSH算法配置參數(shù)。表明了Ceph集群的物理層級(jí)關(guān)系（cluster hierarchy），位置映射規(guī)則（placement rules）。
根據(jù)cluster map的定義可以看出，其版本變化通常只會(huì)由（3）和（4）兩項(xiàng)信息的變化觸發(fā)。而這兩者相比，（3）發(fā)生變化的概率更高一些。這可以通過(guò)下面對(duì)OSD工作狀態(tài)變化過(guò)程的介紹加以反映。
一個(gè)新的OSD上線(xiàn)后，首先根據(jù)配置信息與monitor通信。Monitor將其加入cluster map，并設(shè)置為up且out狀態(tài)，再將最新版本的cluster map發(fā)給這個(gè)新OSD。
收到monitor發(fā)來(lái)的cluster map之后，這個(gè)新OSD計(jì)算出自己所承載的PG（為簡(jiǎn)化討論，此處我們假定這個(gè)新的OSD開(kāi)始只承載一個(gè)PG），以及和自己承載同一個(gè)PG的其他OSD。然后，新OSD將與這些OSD取得聯(lián)系。如果這個(gè)PG目前處于降級(jí)狀態(tài)（即承載該P(yáng)G的OSD個(gè)數(shù)少于正常值，如正常應(yīng)該是3個(gè)，此時(shí)只有2個(gè)或1個(gè)。這種情況通常是OSD故障所致），則其他OSD將把這個(gè)PG內(nèi)的所有對(duì)象和元數(shù)據(jù)復(fù)制給新OSD。數(shù)據(jù)復(fù)制完成后，新OSD被置為up且in狀態(tài)。而cluster map內(nèi)容也將據(jù)此更新。這事實(shí)上是一個(gè)自動(dòng)化的failure recovery過(guò)程。當(dāng)然，即便沒(méi)有新的OSD加入，降級(jí)的PG也將計(jì)算出其他OSD實(shí)現(xiàn)failure recovery。
如果該P(yáng)G目前一切正常，則這個(gè)新OSD將替換掉現(xiàn)有OSD中的一個(gè)（PG內(nèi)將重新選出Primary OSD），并承擔(dān)其數(shù)據(jù)。在數(shù)據(jù)復(fù)制完成后，新OSD被置為up且in狀態(tài)，而被替換的OSD將退出該P(yáng)G（但狀態(tài)通常仍然為up且in，因?yàn)檫€要承載其他PG）。而cluster map內(nèi)容也將據(jù)此更新。這事實(shí)上是一個(gè)自動(dòng)化的數(shù)據(jù)re-balancing過(guò)程。
如果一個(gè)OSD發(fā)現(xiàn)和自己共同承載一個(gè)PG的另一個(gè)OSD無(wú)法聯(lián)通，則會(huì)將這一情況上報(bào)monitor。此外，如果一個(gè)OSD deamon發(fā)現(xiàn)自身工作狀態(tài)異常，也將把異常情況主動(dòng)上報(bào)給monitor。在上述情況下，monitor將把出現(xiàn)問(wèn)題的OSD的狀態(tài)設(shè)為down且in。如果超過(guò)某一預(yù)訂時(shí)間期限，該OSD仍然無(wú)法恢復(fù)正常，則其狀態(tài)將被設(shè)置為down且out。反之，如果該OSD能夠恢復(fù)正常，則其狀態(tài)會(huì)恢復(fù)為up且in。在上述這些狀態(tài)變化發(fā)生之后，monitor都將更新cluster map并進(jìn)行擴(kuò)散。這事實(shí)上是自動(dòng)化的failure detection過(guò)程。
由之前介紹可以看出，對(duì)于一個(gè)Ceph集群而言，即便由數(shù)千個(gè)甚至更多OSD組成，cluster map的數(shù)據(jù)結(jié)構(gòu)大小也并不驚人。同時(shí)，cluster map的狀態(tài)更新并不會(huì)頻繁發(fā)生。即便如此，Ceph依然對(duì)cluster map信息的擴(kuò)散機(jī)制進(jìn)行了優(yōu)化，以便減輕相關(guān)計(jì)算和通信壓力。
首先，cluster map信息是以增量形式擴(kuò)散的。如果任意一次通信的雙方發(fā)現(xiàn)其epoch不一致，則版本更新的一方將把二者所擁有的cluster map的差異發(fā)送給另外一方。
其次，cluster map信息是以異步且lazy的形式擴(kuò)散的。也即，monitor并不會(huì)在每一次cluster map版本更新后都將新版本廣播至全體OSD，而是在有OSD向自己上報(bào)信息時(shí)，將更新回復(fù)給對(duì)方。類(lèi)似的，各個(gè)OSD也是在和其他OSD通信時(shí)，將更新發(fā)送給版本低于自己的對(duì)方。
基于上述機(jī)制，Ceph避免了由于cluster map版本更新而引起的廣播風(fēng)暴。這雖然是一種異步且lazy的機(jī)制，但根據(jù)Sage論文中的結(jié)論，對(duì)于一個(gè)由n個(gè)OSD組成的Ceph集群，任何一次版本更新能夠在O(log(n))時(shí)間復(fù)雜度內(nèi)擴(kuò)散到集群中的任何一個(gè)OSD上。
一個(gè)可能被問(wèn)到的問(wèn)題是：既然這是一種異步和lazy的擴(kuò)散機(jī)制，則在版本擴(kuò)散過(guò)程中，系統(tǒng)必定出現(xiàn)各個(gè)OSD看到的cluster map不一致的情況，這是否會(huì)導(dǎo)致問(wèn)題？答案是：不會(huì)。事實(shí)上，如果一個(gè)client和它要訪問(wèn)的PG內(nèi)部的各個(gè)OSD看到的cluster map狀態(tài)一致，則訪問(wèn)操作就可以正確進(jìn)行。而如果這個(gè)client或者PG中的某個(gè)OSD和其他幾方的cluster map不一致，則根據(jù)Ceph的機(jī)制設(shè)計(jì)，這幾方將首先同步cluster map至最新?tīng)顟B(tài)，并進(jìn)行必要的數(shù)據(jù)re-balancing操作，然后即可繼續(xù)正常訪問(wèn)。
通過(guò)上述介紹，我們可以簡(jiǎn)要了解Ceph究竟是如果基于cluster map機(jī)制，并由monitor、OSD和client共同配合完成集群狀態(tài)的維護(hù)與數(shù)據(jù)訪問(wèn)的。特別的，基于這個(gè)機(jī)制，事實(shí)上可以自然而然的完成自動(dòng)化的數(shù)據(jù)備份、數(shù)據(jù)re-balancing、故障探測(cè)和故障恢復(fù)，并不需要復(fù)雜的特殊設(shè)計(jì)。這一點(diǎn)確實(shí)讓人印象深刻。
關(guān)于Ceph的結(jié)構(gòu)、工作原理及流程是怎樣的問(wèn)題的解答就分享到這里了，希望以上內(nèi)容可以對(duì)大家有一定的幫助，如果你還有很多疑惑沒(méi)有解開(kāi)，可以關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道了解更多相關(guān)知識(shí)。
重慶分公司
重慶分公司
