Ceph是根據加州大學Santa Cruz分校的Sage Weil的博士論文所設計開發的新一代自由軟體分散式檔案系統，其設計目標是良好的可擴充套件性(PB級別以上)、高效能及高可靠性。Ceph其命名和UCSC（Ceph 的誕生地）的吉祥物有關，這個吉祥物是“Sammy”，一個香蕉色的蛞蝓，就是頭足類中無殼的軟體動物。這些有多觸角的頭足類動物，是對一個分散式檔案系統高度並行的形象比喻。
其設計遵循了三個原則：資料與元資料的分離，動態的分散式的元資料管理，可靠統一的分散式物件儲存機制。本文將從Ceph的架構出發，綜合性的介紹Ceph分散式檔案系統特點及其實現方式。
一、Ceph基本架構
Ceph是一個高可用、易於管理、開源的分散式儲存系統，可以在一套系統中同時提供物件儲存、塊儲存以及檔案儲存服務。其主要由Ceph儲存系統的核心RADOS以及塊存取介面、物件存取介面和檔案系統介面組成，如圖所示

Ceph的底層是RADOS，它的意思是“A reliable,autonomous, distributed object storage”。 RADOS作為Ceph分散式檔案系統的一個子專案，是為了滿足Ceph的需求而設計的，但是，其也可以單獨作為一種分散式資料儲存系統，給其他的有類似需求的分散式檔案系統提供資料儲存服務。Ceph檔案系統, Ceph物件儲存和Ceph塊裝置從RADOS的儲存叢集中讀去和寫入資料。
Ceph作為一個分散式儲存系統，其對外提供的介面，決定了其通用性以及擴充套件性。如上圖架構圖中所示的那樣，Ceph對外提供了豐富多樣的服務介面，包括多種程式語言介面LIBRADOS（備註，上圖來自Ceph中文社群，社群人員在翻譯的過程中將字母L遺失掉了）、物件儲存介面(RADOSGW)、塊儲存介面（RBD)以及檔案系統介面(Ceph FS)。其中LIBRADOS程式設計介面是其他各種客戶端介面的基礎，其他介面都是基於LIBRADOS來進行擴充套件實現的。

1.1. RADOS
Ceph中RADOS(Reliable Autonomic Distributed Object Store)儲存叢集是所有其他客戶端介面使用和部署的基礎。RADOS由兩個元件組成：
OSD： Object StorageDevice，提供儲存資源。
Monitor：維護整個Ceph叢集的全域性狀態。

典型的RADOS部署架構由少量的Monitor監控器以及大量的OSD儲存裝置組成，它能夠在動態變化的基於異質結構的儲存裝置叢集之上提供一種穩定的、可擴充套件的、高效能的單一邏輯物件儲存介面。
RADOS系統的架構如圖所示：

我們看到，RADOS不是某種元件，而是由OSD(Object Storage Device)叢集和Monitor叢集組成。通常，一個RADOS系統中，OSD叢集是由大量的智慧化的OSD節點組成；Monitor叢集是由少量的Monitor節點組成。OSD叢集負責儲存所有物件的資料。Monitors叢集負責管理Ceph叢集中所有成員、關係、屬性以及資料分發等資訊。

1.2. Ceph客戶端介面(Clients)
我們將Ceph架構中除了底層基礎RADOS之上的LIBRADOS、RADOSGW、RBD以及Ceph FS統一稱為Ceph客戶端介面。而LIBRADOS又是Ceph其它如RADOSGW、RBD以及Ceph FS的基礎。簡而言之就是RADOSGW、RBD以及Ceph FS根據LIBRADOS提供的多程式語言介面開發。所以他們之間是一個階梯級的關係。
1.2.1. RADOSGW
RADOSGW(RADOS Gmeway)，又叫Ceph物件儲存閘道器，是一個底層基於librados向客戶端提供RESTful介面的物件儲存介面。目前Ceph支援兩種API介面：
(1) S3.compatible：S3相容的介面，提供與Amazon S3大部分RESTfuI API介面相容的API介面。
(2) Swift.compatible：提供與OpenStack Swift大部分介面相容的API介面。Ceph的物件儲存使用閘道器守護程序（radosgw）, radosgw結構圖如圖所示：

在實際的Ceph叢集中，radosgw是一個監聽RESTfulAPI訪問的後臺程序，s3 API和Swift APl使用同一個名稱空間，即共享同一個名稱空間；所以，你可以用其中一個介面寫入資料而又用另外一個介面讀出資料。
1.2.2. RBD
一個數據塊是一個位元組序列（例如，一個512位元組的資料塊）。基於資料塊儲存介面最常見的介質，如硬碟，光碟，軟盤，甚至是傳統的9磁軌的磁帶的方式來儲存資料。塊裝置介面的普及使得虛擬塊裝置成為構建像Ceph海量資料儲存系統理想選擇。
在一個Ceph的叢集中， Ceph的塊裝置支援自動精簡配置，調整大小和儲存資料。Ceph的塊裝置可以充分利用 RADOS功能，實現如快照，複製和資料一致性。Ceph的RADOS塊裝置（即RBD）通過RADOS協議與核心模組或librbd的庫進行互動。。RBD的結構如圖所示：

在Ceph中，如果客戶端要想使用儲存叢集服務提供的塊儲存，必須要先安裝相應的Linux核心模組Kernel Module，或者使用librbd程式設計介面。
1.2.3. Ceph FS
Ceph檔案系統（CEPH FS）是一個POSIX相容的檔案系統，使用Ceph的儲存叢集來儲存其資料。Ceph的檔案系統使用相同的Ceph的儲存集群系統比如Ceph的塊裝置，Ceph的S3和SwiftAPI物件儲存，或本機繫結（librados）。CEPH FS的結構圖如下所示：

CEPH FS是一個符合POSIX標準的檔案系統介面，同時支援使用者空間檔案系統FUSE。在CEPH FS中，與物件儲存介面與塊儲存介面最大的不同就是在叢集中增加了檔案系統元資料服務節點MDS(Ceph Metadata Server)。MDS也支援多臺機器分散式的部署，以實現系統的高可用性。檔案系統客戶端需要安裝對應的Linux核心模組Ceph FS KernelObject或者Ceph FS FUSE元件。

二、Ceph資料儲存
2.1. 資料儲存過程
Ceph儲存叢集從客戶端接收檔案，每個檔案都會被客戶端切分成一個或多個物件，然後將這些物件進行分組，再根據一定的策略儲存到叢集的OSD節點中，其儲存過程如圖所示：

圖中，物件的分發需要經過兩個階段的計算，才能得到儲存該物件的OSD，然後將物件儲存到OSD中對應的位置。
(1) 物件到PG的對映。PG(PlaccmentGroup)是物件的邏輯集合。PG是系統向OSD節點分發資料的基本單位，相同PG裡的物件將被分發到相同的OSD節點中(一個主OSD節點多個備份OSD節點)。物件的PG是由物件ID號通過Hash演算法，結合其他一些修正引數得到的。
(2) PG到相應的OSD的對映，RADOS系統利用相應的雜湊演算法根據系統當前的狀態以及PG的ID號，將各個PG分發到OSD叢集中。OSD叢集是根據物理節點的容錯區域(比如機架、機房等)來進行劃分的。
Ceph中的OSD節點將所有的物件儲存在一個沒有分層和目錄的統一的命名空問中。每個物件都包含一個ID號、若干二進位制資料以及相應的元資料。
ID號在整個儲存叢集中是唯一的；元資料標識了所儲存資料的屬性。一個物件在OSD節點中的儲存方式大致如圖所示。

而對儲存資料的語義解釋完全交給相應的客戶端來完成，比如，Ceph FS客戶端將檔案元資料(比如所有者、建立日期、修改日期等)作為物件屬性儲存在Ceph中。
2.2. CRUSH演算法
Ceph作為一個高可用、高效能的物件儲存系統，其資料讀取及寫入方式是保證其高可用性及高效能的重要手段。對於已知的資料物件，Ccph通過使用CRUSH(ControlledReplication Under Scalable Hashing)演算法計算出其在Ceph叢集中的位置，然後直接與對應的OSD裝置進行互動，進行資料讀取或者寫入。
例如其寫入資料的其主要過程如圖所示。

首先，客戶端獲取Ceph儲存系統的狀態資訊Cluster Map，然後根據狀態資訊以及將要寫入的Pool的CRUSH相關資訊，獲取到資料將要寫入的OSD，最後
OSD將資料寫入到其中相應的儲存位置。其中相關概念的解釋如下：
(1) 叢集地圖(Cluster Map)：Ceph依賴於客戶端以及OSD程序中儲存有整個叢集相關的拓撲資訊，來實現叢集的管理和資料的讀寫。整個叢集相關的拓撲資訊就稱之為“Cluster Map”。Cluster Map主要儲存Monitor叢集、OSD叢集、MDS叢集等相關的拓撲結構資訊以及狀態資訊。
(2) 儲存池(P001)：是對Ceph叢集進行的邏輯劃分，主要設定其中儲存物件的許可權、備份數目、PG數以及CRUSH規則等屬性。
在傳統的儲存系統中，要查詢資料通常是依賴於查詢系統的的檔案索引表找到對應的資料在磁碟中的位置。而在Ceph物件儲存系統中，客戶端與OSD節點都使用CRUSH演算法來高效的計算所儲存資料的相關資訊。相對於傳統的方式，CRUSH提供了一種更好的資料管理機制，它能夠將資料管理的大部分工作都分配給客戶端和OSD節點，這樣為叢集的擴大和儲存容量的動態擴充套件帶來了很大的方便。CRUSH是一種偽隨機資料分佈演算法，它能夠在具有層級結構的儲存叢集中有效的分發物件副本。
CRUSH演算法是根據叢集中儲存裝置的權重來進行資料分發的，資料在各個OSD裝置上近似均勻概率分佈。CRUSH中，資料在儲存裝置上的分佈是根據一個層次化的叢集地圖(Cluster Map)來決定的。叢集地圖是由可用的儲存資源以及由這些儲存資源構建的叢集的邏輯單元組成。比如一個Ceph儲存叢集的叢集地圖的結構可能是一排排大型的機櫃，每個機櫃中包含多個機架，每個機架中放置著儲存裝置。資料分發策略是依照資料的存放規則(placement rules)進行定義的，存放規則是指資料在備份以及存放時應該遵循的相關約定，比如約定一個物件的三個副本應該存放在三個不同的物理機架上。
給定一個值為x的整數，CRUSH將根據相應的策略進行雜湊計算輸出一個
有序的包含n個儲存目標的序列：
CRUSH(x)=(osd1，osd2，osd3osdn)
CRUSH利用健壯的雜湊函式，其得到的結果依賴於叢集地圖Cluster Map、存放規貝則(placementmles)和輸入x。並且CRUSH是一個偽隨機演算法，兩個相似的輸入得到的結果是沒有明顯的相關性的。這樣就能確保Ceph中資料分佈是隨機均勻的。
2.3. 資料一致性
Ceph中，為了保持資料的一致性，在PG內部通常會進行物件的淨化過程(scrubobjects)。資料淨化通常每天進行一次(通常在資料I/O量不大，進行系統維護時進行)。OSD裝置還能夠通過進行資料物件bit-for-bit的對比進行深度的資料淨化，用以找到普通資料淨化中不易察覺的問題(比如磁碟扇區損壞等)。通過資料維護和淨化，為資料的一致性提供了保障。

三、擴充套件性和高可用性
在傳統的分散式系統中，客戶端通常與一箇中央節點進行互動，這樣通常存在著單點故障問題，而且不利於系統的擴充套件。Ceph中客戶端是直接與OSD節點進行互動，而不需要通過中心節點。對同一個物件，Ceph通常會在不同的OSD節點上建立多個備份，這樣就保證了資料可靠性和高可用性。Ceph對元資料伺服器也採用高可用的叢集管理，這樣也提高了系統元資料的的高可用性。Ceph的良好的高可用性和擴充套件性是系統設計的核心，這其中用到了很多精巧的設計和演算法，下面就對實現Ceph的一些關鍵的實現技術進行介紹。
3.1. 高可用性的Monitor叢集
在Ceph的客戶端讀或者寫資料之前，他們必須先通過Ceph Monitor來獲取最新的Cluster Map的副本。如果只有一個Monitor節點，Ceph儲存叢集也可以正常工作，但是這樣會有單點的風險(如果這一臺Monitor節點宕機了，整個Ceph
叢集就無法正常工作)。Ceph中支援多臺Monitor節點組成高可用的叢集來提高整個Ceph系統的高可用性。Ceph中通過Paxos演算法來保持Monitor叢集中各個節點的狀態一致性。
3.2. 高可用性的MDS叢集
在通過Ceph FS介面使用Ceph叢集時，Ceph叢集中需要部署MDS(Metadata Server)程序，通常也是使用叢集的方式進行部署。MDS叢集的主要作用是將所有的檔案系統元資料(目錄、檔案擁有者、訪問許可權等)存放在高可用的記憶體中。這樣，客戶端簡單的檔案操作(ls，cd等)將由MDS叢集快速的響應，而不用消耗OSD裝置的I/O，實現了元資料與資料的分離。為Ceph FS檔案系統介面將能提供了效能上的保證。
Ccph FS旨在提供POSIX相容的檔案系統介面，依賴於MDS中執行的ceph-mds程序，該程序不僅能夠作為一個單一的程序執行，還可以分散式的執行在多個伺服器上，實現了高可用性和擴充套件性。
(1) 高可用性：通常在Ceph叢集中有多個ceph-mds程序在執行。當一個Ceph-mds出現執行故障時，備用的其他的ceph-mds能夠立刻接替失效的ceph-mds的工作。這個過程主要依賴於Ceph中的日誌機制並且通過高可用的Monitor程序來完成相關的恢復工作。
(2) 擴充套件性：Ceph叢集中可以分散式的部署多個ceph-mds程序例項，他們共同完成Ceph檔案系統相關的工作，並且能夠動態的實現負載均衡。
3.3. 超大規模智慧守護（OSD）
在許多傳統的叢集架構中，往往設立一箇中心節點來掌控整個叢集的全部元資料資訊，這樣不僅會因為單點問題對系統的高可用性造成影響，而且中心節點的效能也會成為系統橫向擴充套件的瓶頸。在Ceph就沒有這樣的瓶頸，在Ceph中，每個Ceph的客戶端和OSD節點都儲存有整個系統相關的拓撲資訊。這樣，客戶端就能直接和儲存資料的OSD節點進行互動，OSD節點相互之間也能直接進行互動。Ceph中去中心節點的架構能夠帶來以下一些好處：
(1) OSD節點能直接為客戶端提供服務：我們知道，任何網路裝置都有一個併發連線的上限。中心節點結構的分散式叢集中，中心節點往往是整個系統性能的瓶頸。Ceph中客戶端能與存放資料的OSD節點直接通訊，而不用經過任何的中心節點，這樣整個系統不僅沒有單點問題，而且效能就得到了很大的提升。
(2) OSD節點參與系統的維護：通常一個OSD節點加入到Ceph儲存叢集中，要向叢集中的Monitor節點彙報自己的狀態。如果OSD節點宕機，則需要系統能自動檢測出來。這通常是由Monitor節點週期性的對各個OSD節點中的相關服務進行檢測來實現。如果Monitor節點檢測的週期間隔太短會影響系統的效能；而如果檢測週期間隔太長，則會使整個系統有較長的時間處於不一致的狀態。Ceph中允許OSD節點對相鄰的OSD節點的狀態進行檢測，如果相鄰的節點有狀態變化，OSD節點則會主動向整個叢集進行彙報，同時叢集中相關的Cluster Map得到更新。這樣大大減輕了Monitor節點的壓力。系統的擴充套件性和高可用性得到很大的提升。
(3) OSD節點定期的資料清潔：資料清潔是指，一個OSD節點中儲存的物件與另外一個儲存該物件副本的OSD節點之間進行物件的元資料對比，依此來找出檔案系統相關的錯誤。Ceph中OSD節點能夠自動的進行資料清潔(通常是一天一次)。除了普通的資料清潔，Ceph中OSD節點還可以通過對相同物件不同副本中的資料進行按位(bit-for-bit)的深度資料清潔(通常一週一次)。這種資料清潔機制對系統的資料一致性有很大的幫助。
(4) 資料智慧備份：和Ceph客戶端一樣，Ceph OSD節點也使用CRUSH演算法。但是和客戶端使用CRUSH演算法來查詢資料不同，Ceph OSD節點使用該演算法來計算物件的備份副本應該被儲存在哪個位置。資料智慧備份的大致流程如圖所示：

3.4. 智慧負載均衡
當在Ceph叢集中增加或減少OSD裝置時，叢集會執行負載再均衡的過程(rebalancing)。首先，叢集地圖(Cluster Map)會得到更新，PG ID以及OSD叢集相關的資訊都會得到更新。如下圖，簡單展示了增加OSD儲存裝置時資料再均衡的大致過程。其中，一些PG從其原來所處的OSD儲存裝置遷移到了新的OSD儲存裝置。在資料再均衡過程中，CRUSH保持穩定，有許多的PG還是依然保留其原有的配置。並且由於進行了資料的遷出，原有OSD裝置中的剩餘容量也會相應的有所增加。整個資料再均衡過程也是利用的CRUSH演算法，資料依然是均衡的分佈在新的OSD叢集中。

四、小結
在本文中，我們介紹了Ceph分散式檔案系統的基本架構、工作機制及原理。並且從架構和原理的基礎上論述了其優良的特性。綜合看來，Ceph分散式檔案系統有如下的特點：
(1) Ceph的核心RADOS通常是由少量的負責叢集管理的Monitor程序和大量的負責資料儲存的OSD程序構成，採用無中心節點的分散式架構，對資料進行分塊多份儲存。具有良好的擴充套件性和高可用性。
(1) Ceph分散式檔案系統提供了多種客戶端，包括物件儲存介面、塊儲存介面以及檔案系統介面，具有廣泛的適用性，並且客戶端與儲存資料的OSD裝置直接進行資料互動，大大提高了資料的存取效能。
(2) Ceph作為分散式檔案系統，其能夠在維護 POSIX 相容性的同時加入了複製和容錯功能。從2010 年 3 月底，以及可以在Linux 核心（從2.6.34版開始）中找到 Ceph 的身影，作為Linux的檔案系統備選之一，Ceph.ko已經整合入Linux核心之中。雖然目前Ceph 可能還不適用於生產環境，但它對測試目的還是非常有用的。Ceph 不僅僅是一個檔案系統，還是一個有企業級功能的物件儲存生態環境。現在，Ceph已經被整合在主線 Linux 核心中，但只是被標識為實驗性的。在這種狀態下的檔案系統對測試是有用的，但是對生產環境沒有做好準備。但是考慮到Ceph 加入到 Linux 核心的行列，不久的將來，它應該就能用於解決海量儲存的需要了。