Ceph分散式儲存技術解讀

1. 什麼是Ceph?

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

(1)統一性( unified )：意味著可以同時提供物件儲存、塊儲存和檔案系統儲存三種介面功能。

(2)分散式( distributed )：意味著其內部節點架構是以分散式叢集演算法為依託的。

接下來，我們從其架構原理以及讀寫原理上來分析其如何支撐定義當中所提到的各個特性。

2. Ceph的架構原理

2.1 Ceph儲存功能架構

從功能角度來講，Ceph本身的架構比較清晰明瞭，主要分應用介面層、儲存基礎介面層以及儲存物件層，介面層主要對客戶端的訪問負責，分為本地語言繫結介面(C/C++, Java, Python)、RESTful (S3/Swift)、塊儲存裝置介面、檔案系統介面。從這個點上，其完整詮釋了“統一性( unified )”的特性。

具體如圖2.1所示：

圖2.1 Ceph儲存系統功能圖

(1)基礎儲存系統(RADOS)

RADOS是理解Ceph的基礎與核心。

物理上，RADOS由大量的儲存裝置節點組層，每個節點擁有自己的硬體資源(CPU、記憶體、硬碟、網路)，並執行著作業系統和檔案系統。邏輯上，RADOS是一個完整的分散式物件儲存系統，資料的組織和儲存以及Ceph本身的高可靠、高可擴充套件、高效能等使命都是依託於這個物件。

(2)基礎庫(LIBRADOS)

LIBRADOS是基於RADOS物件在功能層和開發層進行的抽象和封裝。

從使用功能上，其向上提供使用介面API(RADOSGW、RBD、FS)。從開發上功能上，其向上直接提供本地開發語言的API，主要包括C、C++、JAVA、Python等。這樣應用上的特殊需求變更就不會涉及到Ceph儲存本身，保障其安全性並且解除了儲存系統和上層應用的耦合性。

(3)儲存應用介面( RADOS GW、 RBD 、 Ceph FS )

儲存應用介面層 包括了三個部分：RADOS Gateway、 Reliable Block Device 、 Ceph FS，其作用是在librados庫的基礎上提供抽象層次更高、更便於應用或客戶端 直接 使用的上層介面。其中，RADOS GW是一個提供S3 RESTful API的 閘道器 ，以供相應的物件儲存應用 使用;RBD則提供了一個標準的塊裝置介面 ;Ceph FS是一個POSIX相容的分散式檔案系統。

讀到此處，可能很多人都會有一個疑問：“既然Librados API能提供物件儲存應用可以使用的介面，為什麼還要搞一個RadosGW API?”

其實這個是基於不同使用者維度來考慮的，就像應用系統的使用者和開發者兩個不同維度。使用者僅僅需要知道這個應用系統提供了什麼功能，到什麼介面去完成使用就可以了。但是開發者可能需要從後臺程式碼當中去解決一系列基於效能、併發量、易用易維護性等維度出現的問題。同樣，對於RadosGW API來講，它僅僅提供了一些通用、固定、易用的少數使用維度的介面，而Librados API則是一個豐富的具備各種使用、開發等維度的介面庫。

2.2 Ceph物理元件架構

RADOS是Ceph的核心，我們談及的物理元件架構也是隻RADOS的物理架構。

如圖2.2所示，RADOS叢集是由若干伺服器組成，每一個伺服器上都相應會執行RADOS的核心守護程式(OSD、MON、MDS)。具體守護程式的數量需要根據叢集的規模和既定的規則來配置。

圖2.2 RADOS物理元件架構

結合圖2.2，我們首先來看每一個叢集節點上面的守護程式的主要作用：

OSD Daemon：兩方面主要作用，一方面負責資料的處理操作，另外一方面負責監控本身以及其他OSD程式的健康狀態並彙報給MON。OSD守護程式在每一個PG(Placement Group)當中，會有主次(Primary、Replication)之分，Primary主要負責資料的讀寫互動，Replication主要負責資料副本的複製。其故障處理機制主要靠叢集的Crush演算法來維持Primary和Replication之間的轉化和工作接替。所有提供磁碟的節點上都要安裝OSD 守護程式。

MON Daemon：三方面主要作用，首先是監控叢集的全域性狀態(OSD Daemon Map、MON Map、PG Map、Crush Map)，這裡麵包括了OSD和MON組成的叢集配置資訊，也包括了資料的對映關係。其次是管理叢集內部狀態，當OSD守護程式故障之後的系列恢復工作，包括資料的複製恢復。最後是與客戶端的查詢及授權工作，返回客戶端查詢的後設資料資訊以及授權資訊。安裝節點數目為2N+1，至少三個來保障叢集演算法的正常執行。

MDS Daemon：它是Ceph FS的後設資料管理程式，主要是負責檔案系統的後設資料管理，它不需要執行在太多的伺服器節點上。安裝節點模式保持主備保護即可。

2.3 Ceph資料物件組成

Ceph的資料物件組成這部分主要是想闡述從客戶端發出的一個檔案請求，到Rados儲存系統寫入的過程當中會涉及到哪些邏輯物件，他們的關係又是如何的?首先，我們先來列出這些物件：

(1)檔案(FILE)：使用者需要儲存或者訪問的檔案。對於一個基於Ceph開發的物件儲存應用而言，這個檔案也就對應於應用中的“物件”，也就是使用者直接操作的“物件”。

(2)物件(Object)：RADOS所看到的“物件”。Object指的是最大size由RADOS限定(通常為2/4MB)之後RADOS直接進行管理的物件。因此，當上層應用向RADOS存入很大的file時，需要將file切分進行儲存。

(3)PG(Placement Group)：PG是一個邏輯概念，闡述的是Object和OSD之間的地址對映關係，該集合裡的所有物件都具有相同的對映策略;Object & PG，N：1的對映關係;PG & OSD，1：M的對映關係。一個Object只能對映到一個PG上，一個PG會被對映到多個OSD上。

(4)OSD(Object Storage Device)：儲存物件的邏輯分割槽，它規定了資料冗餘的型別和對應的副本分佈策略;支援兩種型別：副本和糾刪碼。

接下來，我們以更直觀的方式來展現在Ceph當中資料是如何組織起來的，如圖2.3：

圖2.3 RADOS物理元件架構

結合圖2.3所示，我們來看資料的詳細對映過程：

(1) File > Object

本次對映為首次對映，即將使用者要操作的File，對映為RADOS能夠處理的Object。

具體對映操作本質上就是按照Object的最大Size對File進行切分，每一個切分後產生的Object將獲得唯一的物件標識Oid。Oid的唯一性必須得到保證，否則後續對映就會出現問題。

(2) Object > PG

完成從File到Object的對映之後， 就需要將每個 Object 獨立地對映到 唯一的 PG 當中 去。

Hash(Oid)& Mask > PGid

根據以上演算法， 首先是使用Ceph系統指定的一個靜態雜湊函式計算 Oid 的雜湊值，將 Oid 對映成為一個近似均勻分佈的偽隨機值。然後，將這個偽隨機值和 Mask 按位相與，得到最終的PG序號( PG id)。根據RADOS的設計，給定PG的總數為 X(X= 2的整數冪)， Mask=X-1 。因此，雜湊值計算和按位與操作的整體結果事實上是從所有 X 個PG中近似均勻地隨機選擇一個。基於這一機制，當有大量object和大量PG時，RADOS能夠保證object和PG之間的近似均勻對映。

(3) PG > OSD

最後的 對映就是將PG對映到資料儲存單元OSD。RADOS採用一個名為CRUSH的演算法，將 PGid 代入其中，然後得到一組共 N 個OSD。這 N 個OSD即共同負責儲存和維護一個PG中的所有 Object 。和“object -> PG”對映中採用的雜湊演算法不同，這個CRUSH演算法的結果不是絕對不變的，而是受到其他因素的影響。

① 叢集狀態(Cluster Map)：系統中的OSD狀態 。數量發生變化時， CLuster Map 可能發生變化，而這種變化將會影響到PG與OSD之間的對映。

② 儲存策略配置。系統管理員可以指定承載同一個PG的3個OSD分別位於資料中心的不同伺服器乃至機架上，從而進一步改善儲存的可靠性。

到這裡，可能大家又會有一個問題“為什麼這裡要用CRUSH演算法，而不是HASH演算法?”

這一次對映，我們對對映演算法有兩種要求：

一方面，演算法必須能夠隨著系統的節點數量位置的變化，而具備動態調整特性，保障在變化的環境當中仍然可以保持資料分佈的均勻性;另外一方面還要有相對的穩定性，也就是說大部分的對映關係不會因為叢集的動態變化發生變化，保持一定的穩定性。

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

3. Ceph的讀寫原理

3.1 Ceph IO流程

Ceph的IO框架當中會涉及到三個角色：客戶端(Client)、後設資料節點(MON)、資料節點(OSD)。這個有點類似於Hadoop。客戶端首先傳送資料讀寫請求到後設資料節點上進行儲存空間的定址，後設資料節點根據資料請求獲取資料的地址空間資訊，然後客戶端根據地址空間分佈資訊分別到所涉及的資料節點上查詢相應資料片或者是將資料寫入相應資料節點的儲存空間地址。如圖3.1所示，

圖3.1 Ceph IO流程圖

結合圖3.1，具體說來，包括如下幾個詳細步驟：

Client建立Cluster Handle。

Client讀取配置檔案。

Client連線上後設資料節點，獲取叢集上的資料對映資訊。

Client根據CRUSH演算法，計算獲得資料的所有OSD節點(Primary)，然後進行資料讀寫。

如果是資料的寫操作，Primary OSD會同時寫入另外兩個副本節點資料。

Primary OSD等待另外兩個副本節點寫完資料狀態返回並將ACK資訊返回客戶端。

3.2 Ceph故障IO流程

從正常的IO場景下到發生故障後的IO處理，會經過正常讀寫、故障過度、叢集穩定三個階段。正常階段的資料讀寫會透過(Client > Monitor，Client > OSD Primary > OSD Replic)這樣的流程，在整個過程中OSD Primary是資料處理的核心角色。如果OSD Primary 發生故障，就會透過故障偵測機制發現故障節點，然後透過CRUSH演算法重新分配新的OSD Primary，重新同步資料一系列過程。如果這個時候客戶端恰好要讀取資料，就會需要新的機制滿足客戶端的讀請求。具體如圖3.2所示：

圖3.2 Ceph故障場景下的IO流程圖

首先，我們來看從正常場景到發生OSD主節點故障的這個階段：

叢集內部透過心跳機制發現故障，這個心跳機制分兩種：Monitor和OSD之間的主動和被動檢測機制，OSD之間的相互檢測機制;

新的OSD Primary節點接受任務並選擇合適的OSD Replic節點進行資料同步;

新的OSD Primary節點通知Monitor臨時的資料處理方案(將OSD Replic 節點作為臨時主節點響應客戶端的資料請求處理)。

當新的OSD Primary節點資料同步完成後，進入到正常階段：

通知Monitor更新叢集對映配置資訊。

正式接管資料讀寫任務，成為Primary OSD節點，叢集恢復新的穩定狀態。

4. 結語

從Ceph的架構原理上來看，我們不難看出其定義當中的“擴充套件性、穩定性”。但是關於“優秀效能”這個描述的特性來講，其實是需要斟酌其語境的。我們不能從其架構的分散式模式上簡單判斷多個節點服務的效能一定是最優秀的。如果單從架構上來看，對一些可以直接以物件方式儲存及訪問的場景來說，Ceph的IO深度以及介面的銜接維度看，更利於發揮其效能的優勢。對於一些大檔案儲存讀取場景來講，可以透過2M/4M這樣粒度的切分使得讀寫的效能更容易被橫向擴充套件的架構發揮出來。但是如果是RBD的模式，尤其是小資料事務處理場景(例如關聯式資料庫)，由於物件可切分的粒度有限，橫向併發讀寫的優勢就發揮不出來了，而且現實業務場景當中的熱點資料問題往往集中在某一部分小粒度的資料片上，很有可能壓力會落到某個或者某幾個OSD上。因此，多維度去看Ceph，才能挖掘其真正價值，後續繼續挖掘其他維度上的優劣。