?1. 什么是Ceph？

首先，我們從 Ceph的官方網(wǎng)站上，可以看到：“Ceph is a unified, distributed storage system designed for excellent performance, reliability and scalability.” 從它的定義上我們可以明確它是一種存儲(chǔ)系統(tǒng)，而且可以明確它所具備的兩點(diǎn)特性：

（1）統(tǒng)一性（ unified ）：意味著可以同時(shí)提供對(duì)象存儲(chǔ)、塊存儲(chǔ)和文件系統(tǒng)存儲(chǔ)三種接口功能。

（2）分布式（ distributed ）：意味著其內(nèi)部節(jié)點(diǎn)架構(gòu)是以分布式集群算法為依托的。

接下來(lái)，我們從其架構(gòu)原理以及讀寫(xiě)原理上來(lái)分析其如何支撐定義當(dāng)中所提到的各個(gè)特性。

2. Ceph的架構(gòu)原理

2.1 Ceph存儲(chǔ)功能架構(gòu)

從功能角度來(lái)講，Ceph本身的架構(gòu)比較清晰明了，主要分應(yīng)用接口層、存儲(chǔ)基礎(chǔ)接口層以及存儲(chǔ)對(duì)象層，接口層主要對(duì)客戶(hù)端的訪問(wèn)負(fù)責(zé)，分為本地語(yǔ)言綁定接口(C/C++, Java, Python)、RESTful (S3/Swift)、塊存儲(chǔ)設(shè)備接口、文件系統(tǒng)接口。從這個(gè)點(diǎn)上，其完整詮釋了“統(tǒng)一性（ unified ）”的特性。

具體如圖2.1所示：

圖2.1 Ceph存儲(chǔ)系統(tǒng)功能圖

（1）基礎(chǔ)存儲(chǔ)系統(tǒng)（RADOS）

RADOS是理解Ceph的基礎(chǔ)與核心。

物理上，RADOS由大量的存儲(chǔ)設(shè)備節(jié)點(diǎn)組層，每個(gè)節(jié)點(diǎn)擁有自己的硬件資源（CPU、內(nèi)存、硬盤(pán)、網(wǎng)絡(luò)），并運(yùn)行著操作系統(tǒng)和文件系統(tǒng)。邏輯上，RADOS是一個(gè)完整的分布式對(duì)象存儲(chǔ)系統(tǒng)，數(shù)據(jù)的組織和存儲(chǔ)以及Ceph本身的高可靠、高可擴(kuò)展、高性能等使命都是依托于這個(gè)對(duì)象。

（2）基礎(chǔ)庫(kù)（LIBRADOS）

LIBRADOS是基于RADOS對(duì)象在功能層和開(kāi)發(fā)層進(jìn)行的抽象和封裝。

從使用功能上，其向上提供使用接口API（RADOSGW、RBD、FS）。從開(kāi)發(fā)上功能上，其向上直接提供本地開(kāi)發(fā)語(yǔ)言的API，主要包括C、C++、JAVA、Python等。這樣應(yīng)用上的特殊需求變更就不會(huì)涉及到Ceph存儲(chǔ)本身，保障其安全性并且解除了存儲(chǔ)系統(tǒng)和上層應(yīng)用的耦合性。

（3）存儲(chǔ)應(yīng)用接口（ RADOS GW、 RBD 、 Ceph FS ）

存儲(chǔ)應(yīng)用接口層 包括了三個(gè)部分：RADOS Gateway、 Reliable Block Device 、 Ceph FS，其作用是在librados庫(kù)的基礎(chǔ)上提供抽象層次更高、更便于應(yīng)用或客戶(hù)端 直接 使用的上層接口。其中，RADOS GW是一個(gè)提供S3 RESTful API的 網(wǎng)關(guān) ，以供相應(yīng)的對(duì)象存儲(chǔ)應(yīng)用 使用；RBD則提供了一個(gè)標(biāo)準(zhǔn)的塊設(shè)備接口 ；Ceph FS是一個(gè)POSIX兼容的分布式文件系統(tǒng)。

讀到此處，可能很多人都會(huì)有一個(gè)疑問(wèn)：“既然Librados API能提供對(duì)象存儲(chǔ)應(yīng)用可以使用的接口，為什么還要搞一個(gè)RadosGW API？”

其實(shí)這個(gè)是基于不同使用者維度來(lái)考慮的，就像應(yīng)用系統(tǒng)的使用者和開(kāi)發(fā)者兩個(gè)不同維度。使用者僅僅需要知道這個(gè)應(yīng)用系統(tǒng)提供了什么功能，到什么界面去完成使用就可以了。但是開(kāi)發(fā)者可能需要從后臺(tái)代碼當(dāng)中去解決一系列基于性能、并發(fā)量、易用易維護(hù)性等維度出現(xiàn)的問(wèn)題。同樣，對(duì)于RadosGW API來(lái)講，它僅僅提供了一些通用、固定、易用的少數(shù)使用維度的接口，而Librados API則是一個(gè)豐富的具備各種使用、開(kāi)發(fā)等維度的接口庫(kù)。

2.2 Ceph物理組件架構(gòu)

RADOS是Ceph的核心，我們談及的物理組件架構(gòu)也是只RADOS的物理架構(gòu)。

如圖2.2所示，RADOS集群是由若干服務(wù)器組成，每一個(gè)服務(wù)器上都相應(yīng)會(huì)運(yùn)行RADOS的核心守護(hù)進(jìn)程（OSD、MON、MDS）。具體守護(hù)進(jìn)程的數(shù)量需要根據(jù)集群的規(guī)模和既定的規(guī)則來(lái)配置。

圖2.2 RADOS物理組件架構(gòu)

結(jié)合圖2.2，我們首先來(lái)看每一個(gè)集群節(jié)點(diǎn)上面的守護(hù)進(jìn)程的主要作用：

OSD Daemon：兩方面主要作用，一方面負(fù)責(zé)數(shù)據(jù)的處理操作，另外一方面負(fù)責(zé)監(jiān)控本身以及其他OSD進(jìn)程的健康狀態(tài)并匯報(bào)給MON。OSD守護(hù)進(jìn)程在每一個(gè)PG（Placement Group）當(dāng)中，會(huì)有主次（Primary、Replication）之分，Primary主要負(fù)責(zé)數(shù)據(jù)的讀寫(xiě)交互，Replication主要負(fù)責(zé)數(shù)據(jù)副本的復(fù)制。其故障處理機(jī)制主要靠集群的Crush算法來(lái)維持Primary和Replication之間的轉(zhuǎn)化和工作接替。所有提供磁盤(pán)的節(jié)點(diǎn)上都要安裝OSD 守護(hù)進(jìn)程。

MON Daemon：三方面主要作用，首先是監(jiān)控集群的全局狀態(tài)（OSD Daemon Map、MON Map、PG Map、Crush Map），這里面包括了OSD和MON組成的集群配置信息，也包括了數(shù)據(jù)的映射關(guān)系。其次是管理集群內(nèi)部狀態(tài)，當(dāng)OSD守護(hù)進(jìn)程故障之后的系列恢復(fù)工作，包括數(shù)據(jù)的復(fù)制恢復(fù)。最后是與客戶(hù)端的查詢(xún)及授權(quán)工作，返回客戶(hù)端查詢(xún)的元數(shù)據(jù)信息以及授權(quán)信息。安裝節(jié)點(diǎn)數(shù)目為2N+1，至少三個(gè)來(lái)保障集群算法的正常運(yùn)行。

MDS Daemon：它是Ceph FS的元數(shù)據(jù)管理進(jìn)程，主要是負(fù)責(zé)文件系統(tǒng)的元數(shù)據(jù)管理，它不需要運(yùn)行在太多的服務(wù)器節(jié)點(diǎn)上。安裝節(jié)點(diǎn)模式保持主備保護(hù)即可。

2.3 Ceph數(shù)據(jù)對(duì)象組成

Ceph的數(shù)據(jù)對(duì)象組成這部分主要是想闡述從客戶(hù)端發(fā)出的一個(gè)文件請(qǐng)求，到Rados存儲(chǔ)系統(tǒng)寫(xiě)入的過(guò)程當(dāng)中會(huì)涉及到哪些邏輯對(duì)象，他們的關(guān)系又是如何的？首先，我們先來(lái)列出這些對(duì)象：

（1）文件（FILE）：用戶(hù)需要存儲(chǔ)或者訪問(wèn)的文件。對(duì)于一個(gè)基于Ceph開(kāi)發(fā)的對(duì)象存儲(chǔ)應(yīng)用而言，這個(gè)文件也就對(duì)應(yīng)于應(yīng)用中的“對(duì)象”，也就是用戶(hù)直接操作的“對(duì)象”。

（2）對(duì)象（Object）：RADOS所看到的“對(duì)象”。Object指的是最大size由RADOS限定（通常為2/4MB）之后RADOS直接進(jìn)行管理的對(duì)象。因此，當(dāng)上層應(yīng)用向RADOS存入很大的file時(shí)，需要將file切分進(jìn)行存儲(chǔ)。

（3）PG（Placement Group）：PG是一個(gè)邏輯概念，闡述的是Object和OSD之間的地址映射關(guān)系，該集合里的所有對(duì)象都具有相同的映射策略；Object & PG，N：1的映射關(guān)系；PG & OSD，1：M的映射關(guān)系。一個(gè)Object只能映射到一個(gè)PG上，一個(gè)PG會(huì)被映射到多個(gè)OSD上。

（4）OSD（Object Storage Device）：存儲(chǔ)對(duì)象的邏輯分區(qū)，它規(guī)定了數(shù)據(jù)冗余的類(lèi)型和對(duì)應(yīng)的副本分布策略；支持兩種類(lèi)型：副本和糾刪碼。

接下來(lái)，我們以更直觀的方式來(lái)展現(xiàn)在Ceph當(dāng)中數(shù)據(jù)是如何組織起來(lái)的，如圖2.3：

圖2.3 RADOS物理組件架構(gòu)

結(jié)合圖2.3所示，我們來(lái)看數(shù)據(jù)的詳細(xì)映射過(guò)程：

（1） File > Object

本次映射為首次映射，即將用戶(hù)要操作的File，映射為RADOS能夠處理的Object。

具體映射操作本質(zhì)上就是按照Object的最大Size對(duì)File進(jìn)行切分，每一個(gè)切分后產(chǎn)生的Object將獲得唯一的對(duì)象標(biāo)識(shí)Oid。Oid的唯一性必須得到保證，否則后續(xù)映射就會(huì)出現(xiàn)問(wèn)題。

（2） Object > PG

完成從File到Object的映射之后， 就需要將每個(gè) Object 獨(dú)立地映射到 唯一的 PG 當(dāng)中 去。

Hash（Oid）& Mask > PGid

根據(jù)以上算法， 首先是使用Ceph系統(tǒng)指定的一個(gè)靜態(tài)哈希函數(shù)計(jì)算 Oid 的哈希值，將 Oid 映射成為一個(gè)近似均勻分布的偽隨機(jī)值。然后，將這個(gè)偽隨機(jī)值和 Mask 按位相與，得到最終的PG序號(hào)（ PG id）。根據(jù)RADOS的設(shè)計(jì)，給定PG的總數(shù)為 X（X= 2的整數(shù)冪）， Mask=X-1 。因此，哈希值計(jì)算和按位與操作的整體結(jié)果事實(shí)上是從所有 X 個(gè)PG中近似均勻地隨機(jī)選擇一個(gè)。基于這一機(jī)制，當(dāng)有大量object和大量PG時(shí)，RADOS能夠保證object和PG之間的近似均勻映射。

（3） PG > OSD

最后的 映射就是將PG映射到數(shù)據(jù)存儲(chǔ)單元OSD。RADOS采用一個(gè)名為CRUSH的算法，將 PGid 代入其中，然后得到一組共 N 個(gè)OSD。這 N 個(gè)OSD即共同負(fù)責(zé)存儲(chǔ)和維護(hù)一個(gè)PG中的所有 Object 。和“object -> PG”映射中采用的哈希算法不同，這個(gè)CRUSH算法的結(jié)果不是絕對(duì)不變的，而是受到其他因素的影響。

① 集群狀態(tài)（Cluster Map）：系統(tǒng)中的OSD狀態(tài) 。數(shù)量發(fā)生變化時(shí)， CLuster Map 可能發(fā)生變化，而這種變化將會(huì)影響到PG與OSD之間的映射。

② 存儲(chǔ)策略配置。系統(tǒng)管理員可以指定承載同一個(gè)PG的3個(gè)OSD分別位于數(shù)據(jù)中心的不同服務(wù)器乃至機(jī)架上，從而進(jìn)一步改善存儲(chǔ)的可靠性。

到這里，可能大家又會(huì)有一個(gè)問(wèn)題“為什么這里要用CRUSH算法，而不是HASH算法？”

這一次映射，我們對(duì)映射算法有兩種要求：

一方面，算法必須能夠隨著系統(tǒng)的節(jié)點(diǎn)數(shù)量位置的變化，而具備動(dòng)態(tài)調(diào)整特性，保障在變化的環(huán)境當(dāng)中仍然可以保持?jǐn)?shù)據(jù)分布的均勻性；另外一方面還要有相對(duì)的穩(wěn)定性，也就是說(shuō)大部分的映射關(guān)系不會(huì)因?yàn)榧旱膭?dòng)態(tài)變化發(fā)生變化，保持一定的穩(wěn)定性。

而CRUSH算法正是符合了以上的兩點(diǎn)要求，所以最終成為Ceph的核心算法。

3. Ceph的讀寫(xiě)原理

3.1 Ceph IO流程

Ceph的IO框架當(dāng)中會(huì)涉及到三個(gè)角色：客戶(hù)端（Client）、元數(shù)據(jù)節(jié)點(diǎn)（MON）、數(shù)據(jù)節(jié)點(diǎn)（OSD）。這個(gè)有點(diǎn)類(lèi)似于Hadoop?？蛻?hù)端首先發(fā)送數(shù)據(jù)讀寫(xiě)請(qǐng)求到元數(shù)據(jù)節(jié)點(diǎn)上進(jìn)行存儲(chǔ)空間的尋址，元數(shù)據(jù)節(jié)點(diǎn)根據(jù)數(shù)據(jù)請(qǐng)求獲取數(shù)據(jù)的地址空間信息，然后客戶(hù)端根據(jù)地址空間分布信息分別到所涉及的數(shù)據(jù)節(jié)點(diǎn)上查找相應(yīng)數(shù)據(jù)片或者是將數(shù)據(jù)寫(xiě)入相應(yīng)數(shù)據(jù)節(jié)點(diǎn)的存儲(chǔ)空間地址。如圖3.1所示，

圖3.1 Ceph IO流程圖

結(jié)合圖3.1，具體說(shuō)來(lái)，包括如下幾個(gè)詳細(xì)步驟：

• Client創(chuàng)建Cluster Handle。
• Client讀取配置文件。
• Client連接上元數(shù)據(jù)節(jié)點(diǎn)，獲取集群上的數(shù)據(jù)映射信息。
• Client根據(jù)CRUSH算法，計(jì)算獲得數(shù)據(jù)的所有OSD節(jié)點(diǎn)（Primary），然后進(jìn)行數(shù)據(jù)讀寫(xiě)。
• 如果是數(shù)據(jù)的寫(xiě)操作，Primary OSD會(huì)同時(shí)寫(xiě)入另外兩個(gè)副本節(jié)點(diǎn)數(shù)據(jù)。
• Primary OSD等待另外兩個(gè)副本節(jié)點(diǎn)寫(xiě)完數(shù)據(jù)狀態(tài)返回并將ACK信息返回客戶(hù)端。

3.2 Ceph故障IO流程

從正常的IO場(chǎng)景下到發(fā)生故障后的IO處理，會(huì)經(jīng)過(guò)正常讀寫(xiě)、故障過(guò)度、集群穩(wěn)定三個(gè)階段。正常階段的數(shù)據(jù)讀寫(xiě)會(huì)通過(guò)（Client > Monitor，Client > OSD Primary > OSD Replic）這樣的流程，在整個(gè)過(guò)程中OSD Primary是數(shù)據(jù)處理的核心角色。如果OSD Primary 發(fā)生故障，就會(huì)通過(guò)故障偵測(cè)機(jī)制發(fā)現(xiàn)故障節(jié)點(diǎn)，然后通過(guò)CRUSH算法重新分配新的OSD Primary，重新同步數(shù)據(jù)一系列過(guò)程。如果這個(gè)時(shí)候客戶(hù)端恰好要讀取數(shù)據(jù)，就會(huì)需要新的機(jī)制滿(mǎn)足客戶(hù)端的讀請(qǐng)求。具體如圖3.2所示：

圖3.2 Ceph故障場(chǎng)景下的IO流程圖?

首先，我們來(lái)看從正常場(chǎng)景到發(fā)生OSD主節(jié)點(diǎn)故障的這個(gè)階段：

• 集群內(nèi)部通過(guò)心跳機(jī)制發(fā)現(xiàn)故障，這個(gè)心跳機(jī)制分兩種：Monitor和OSD之間的主動(dòng)和被動(dòng)檢測(cè)機(jī)制，OSD之間的相互檢測(cè)機(jī)制；
• 新的OSD Primary節(jié)點(diǎn)接受任務(wù)并選擇合適的OSD Replic節(jié)點(diǎn)進(jìn)行數(shù)據(jù)同步；
• ?新的OSD Primary節(jié)點(diǎn)通知Monitor臨時(shí)的數(shù)據(jù)處理方案（將OSD Replic 節(jié)點(diǎn)作為臨時(shí)主節(jié)點(diǎn)響應(yīng)客戶(hù)端的數(shù)據(jù)請(qǐng)求處理）。

當(dāng)新的OSD Primary節(jié)點(diǎn)數(shù)據(jù)同步完成后，進(jìn)入到正常階段：

• 通知Monitor更新集群映射配置信息。
• 正式接管數(shù)據(jù)讀寫(xiě)任務(wù)，成為Primary OSD節(jié)點(diǎn)，集群恢復(fù)新的穩(wěn)定狀態(tài)。

4. 結(jié)語(yǔ)

從Ceph的架構(gòu)原理上來(lái)看，我們不難看出其定義當(dāng)中的“擴(kuò)展性、穩(wěn)定性”。但是關(guān)于“優(yōu)秀性能”這個(gè)描述的特性來(lái)講，其實(shí)是需要斟酌其語(yǔ)境的。我們不能從其架構(gòu)的分布式模式上簡(jiǎn)單判斷多個(gè)節(jié)點(diǎn)服務(wù)的性能一定是最優(yōu)秀的。如果單從架構(gòu)上來(lái)看，對(duì)一些可以直接以對(duì)象方式存儲(chǔ)及訪問(wèn)的場(chǎng)景來(lái)說(shuō)，Ceph的IO深度以及接口的銜接維度看，更利于發(fā)揮其性能的優(yōu)勢(shì)。對(duì)于一些大文件存儲(chǔ)讀取場(chǎng)景來(lái)講，可以通過(guò)2M/4M這樣粒度的切分使得讀寫(xiě)的性能更容易被橫向擴(kuò)展的架構(gòu)發(fā)揮出來(lái)。但是如果是RBD的模式，尤其是小數(shù)據(jù)事務(wù)處理場(chǎng)景（例如關(guān)系數(shù)據(jù)庫(kù)），由于對(duì)象可切分的粒度有限，橫向并發(fā)讀寫(xiě)的優(yōu)勢(shì)就發(fā)揮不出來(lái)了，而且現(xiàn)實(shí)業(yè)務(wù)場(chǎng)景當(dāng)中的熱點(diǎn)數(shù)據(jù)問(wèn)題往往集中在某一部分小粒度的數(shù)據(jù)片上，很有可能壓力會(huì)落到某個(gè)或者某幾個(gè)OSD上。因此，多維度去看Ceph，才能挖掘其真正價(jià)值，后續(xù)繼續(xù)挖掘其他維度上的優(yōu)劣。?