雲計算存儲之Ceph架構是怎麼樣的？

Ceph架構是怎麼樣的？

1. Ceph存儲系統的邏輯層次結構圖

---

2. Ceph系統邏輯層次結構，自下向上，能夠分爲四個層次

2.1 基礎存儲系統RADOS

**RADOS，Reliable, Autonomic, Distributed Object Store，便可靠的、自動化的、分佈式的對象存儲系統。**顧名思義，這一層自己就是一個完整的對象存儲系統，全部存儲在Ceph系統中的用戶數據事實上最終都是由這一層來存儲的。而Ceph的高可靠、高可擴展、高性能、高自動化等等特性本質上也是由這一層所提供的。所以，理解RADOS是理解Ceph的基礎與關鍵。

物理上，RADOS由大量的存儲設備節點組成，每一個節點擁有本身的硬件資源（CPU、內存、硬盤、網絡），並運行着操做系統和文件系統。

2.2 基礎庫librados

這一層的功能是對RADOS進行抽象和封裝，並向上層提供API，以便直接基於RADOS（而不是整個Ceph）進行應用開發。特別要注意的是，RADOS是一個對象存儲系統，所以，librados實現的API也只是針對對象存儲功能的。

RADOS採用C++開發，所提供的原生librados API包括C和C++兩種。物理上，librados和基於其上開發的應用位於同一臺機器，於是也被稱爲本地API。應用調用本機上的librados API，再由後者經過socket與RADOS集羣中的節點通訊並完成各類操做。

2.3 高層應用接口

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

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

RBD則提供了一個標準的塊設備接口，經常使用於在虛擬化的場景下爲虛擬機建立volume。目前，Red Hat已經將RBD驅動集成在KVM/QEMU中，以提升虛擬機訪問性能。

Ceph FS是一個POSIX兼容的分佈式文件系統。因爲還處在開發狀態，於是Ceph官網並不推薦將其用於生產環境中。

2.4 應用層

這一層就是不一樣場景下對於Ceph各個應用接口的各類應用方式，例如基於librados直接開發的對象存儲應用，基於RADOS GW開發的對象存儲應用，基於RBD實現的雲硬盤等等。

---

3. 一些疑問

在上文的介紹中，有一個地方可能容易引發困惑：RADOS自身既然已是一個對象存儲系統，而且也能夠提供librados API，爲什麼還要再單獨開發一個RADOS GW？

理解這個問題，事實上有助於理解RADOS的本質，所以有必要在此加以分析。粗看起來，librados和RADOS GW的區別在於，librados提供的是本地API，而RADOS GW提供的則是RESTful API，兩者的編程模型和實際性能不一樣。而更進一步說，則和這兩個不一樣抽象層次的目標應用場景差別有關。換言之，雖然RADOS和S三、Swift同屬分佈式對象存儲系統，但RADOS提供的功能更爲基礎、也更爲豐富。這一點能夠經過對比看出。

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

用戶管理操做：用戶認證、獲取帳戶信息、列出容器列表等；
容器管理操做：建立/刪除容器、讀取容器信息、列出容器內對象列表等；
對象管理操做：對象的寫入、讀取、複製、更新、刪除、訪問許可設置、元數據讀取或更新等。
因而可知，Swift（以及S3）提供的API所操做的「對象」只有三個：用戶帳戶、用戶存儲數據對象的容器、數據對象。而且，全部的操做均不涉及存儲系統 的底層硬件或系統信息。不難看出，這樣的API設計徹底是針對對象存儲應用開發者和對象存儲應用用戶的，而且假定其開發者和用戶關心的內容更偏重於帳戶和數據的管理，而對底層存儲系統細節不感興趣，更不關心效率、性能等方面的深刻優化。

而librados API的設計思想則與此徹底不一樣。一方面，librados中沒有帳戶、容器這樣的高層概念；另外一方面，librados API向開發者開放了大量的RADOS狀態信息與配置參數，容許開發者對RADOS系統以及其中存儲的對象的狀態進行觀察，並強有力地對系統存儲策略進行控制。換言之，經過調用librados API，應用不只可以實現對數據對象的操做，還可以實現對RADOS系統的管理和配置。這對於S3和Swift的RESTful API設計是不可想像的，也是沒有必要的。

基於上述分析對比，不難看出，librados事實上更適合對於系統有着深入理解，同時對於功能定製擴展和性能深度優化有着強烈需求的高級用戶。基於librados的開發可能更適合於在私有Ceph系統上開發專用應用，或者爲基於Ceph的公有存儲系統開發後臺數據管理、處理應用。而RADOS GW則更適合於常見的基於web的對象存儲應用開發，例如公有云上的對象存儲服務。

---

4. RADOS的邏輯結構

RADOS的系統邏輯結構以下圖所示

RADOS集羣主要由兩種節點組成。一種是 爲數衆多的、負責完成數據存儲和維護功能的OSD（Object Storage Device），另外一種則是 若干個負責完成系統狀態檢測和維護的monitor。OSD和monitor之間相互傳輸節點狀態信息，共同得出系統的整體工做狀態，並造成一個全局系統狀態記錄數據結構，即所謂的cluster map。這個數據結構與RADOS提供的特定算法相配合，便實現了Ceph「無需查表，算算就好」的核心機制以及若干優秀特性。

在使用RADOS系統時，大量的客戶端程序經過與OSD或者monitor的交互獲取cluster map，而後直接在本地進行計算，得出對象的存儲位置後，便直接與對應的OSD通訊，完成數據的各類操做。可見，在此過程當中，只要保證cluster map不頻繁更新，則客戶端顯然能夠不依賴於任何元數據服務器，不進行任何查表操做，便完成數據訪問流程。在RADOS的運行過程當中，cluster map的更新徹底取決於系統的狀態變化，而致使這一變化的常見事件只有兩種：OSD出現故障，或者RADOS規模擴大。而正常應用場景下，這兩種事件發生的頻率顯然遠遠低於客戶端對數據進行訪問的頻率。

---

5. OSD的邏輯結構

根據定義，OSD能夠被抽象爲兩個組成部分，即系統部分和守護進程（OSD deamon）部分。OSD的系統部分本質上就是一臺安裝了操做系統和文件系統的計算機，其硬件部分至少包括一個單核的處理器、必定數量的內存、一塊硬盤以及一張網卡。

因爲這麼小規模的x86架構服務器並不實用（事實上也見不到），於是實際應用中一般將多個OSD集中部署在一臺更大規模的服務器上。在選擇系統配置時，應當可以保證每一個OSD佔用必定的計算能力、必定量的內存和一塊硬盤。同時，應當保證該服務器具有足夠的網絡帶寬。

在上述系統平臺上，每一個OSD擁有一個本身的OSD deamon。這個deamon負責完成OSD的全部邏輯功能，包括與monitor和其餘OSD（事實上是其餘OSD的deamon）通訊以維護更新系統狀態，與其餘OSD共同完成數據的存儲和維護，與client通訊完成各類數據對象操做等等。