本文將從邏輯結構的角度對Ceph進行分析。
4.1 Ceph系統的層次結構
Ceph存儲系統的邏輯層次結構如下圖所示[1]。
自下向上，可以將Ceph系統分爲四個層次：
（1）基礎存儲系統RADOS（Reliable, Autonomic, Distributed Object Store，即可靠的、自動化的、分佈式的對象存儲）
顧名思義，這一層本身就是一個完整的對象存儲系統，所有存儲在Ceph系統中的用戶數據事實上最終都是由這一層來存儲的。而Ceph的高可靠、高可擴展、高性能、高自動化等等特性本質上也是由這一層所提供的。因此，理解RADOS是理解Ceph的基礎與關鍵。
物理上，RADOS由大量的存儲設備節點組層，每個節點擁有自己的硬件資源（CPU、內存、硬盤、網絡），並運行着操作系統和文件系統。4.2、4.3節將對RADOS進行展開介紹。
（2）基礎庫librados
這一層的功能是對RADOS進行抽象和封裝，並向上層提供API，以便直接基於RADOS（而不是整個Ceph）進行應用開發。特別要注意的是，RADOS是一個對象存儲系統，因此，librados實現的API也只是針對對象存儲功能的。
RADOS採用C++開發，所提供的原生librados API包括C和C++兩種，其文檔參見[2]。物理上，librados和基於其上開發的應用位於同一臺機器，因而也被稱爲本地API。應用調用本機上的librados API，再由後者通過socket與RADOS集羣中的節點通信並完成各種操作。
（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官網並不推薦將其用於生產環境中。
（4）應用層
這一層就是不同場景下對於Ceph各個應用接口的各種應用方式，例如基於librados直接開發的對象存儲應用，基於RADOS GW開發的對象存儲應用，基於RBD實現的雲硬盤等等。
在上文的介紹中，有一個地方可能容易引起困惑：RADOS自身既然已經是一個對象存儲系統，並且也可以提供librados API，爲何還要再單獨開發一個RADOS GW？
理解這個問題，事實上有助於理解RADOS的本質，因此有必要在此加以分析。粗看起來，librados和RADOS GW的區別在於，librados提供的是本地API，而RADOS GW提供的則是RESTful API，二者的編程模型和實際性能不同。而更進一步說，則和這兩個不同抽象層次的目標應用場景差異有關。換言之，雖然RADOS和S3、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.2 RADOS的邏輯結構
RADOS的系統邏輯結構如下圖所示[3]：
如圖所示，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規模擴大。而正常應用場景下，這兩種事件發生的頻率顯然遠遠低於客戶端對數據進行訪問的頻率。
4.3 OSD的邏輯結構
根據定義，OSD可以被抽象爲兩個組成部分，即系統部分和守護進程（OSD deamon）部分。
OSD的系統部分本質上就是一臺安裝了操作系統和文件系統的計算機，其硬件部分至少包括一個單核的處理器、一定數量的內存、一塊硬盤以及一張網卡。
由於這麼小規模的x86架構服務器並不實用（事實上也見不到），因而實際應用中通常將多個OSD集中部署在一臺更大規模的服務器上。在選擇系統配置時，應當能夠保證每個OSD佔用一定的計算能力、一定量的內存和一塊硬盤。同時，應當保證該服務器具備足夠的網絡帶寬。具體的硬件配置選擇可以參考[4]。
在上述系統平臺上，每個OSD擁有一個自己的OSD deamon。這個deamon負責完成OSD的所有邏輯功能，包括與monitor和其他OSD（事實上是其他OSD的deamon）通信以維護更新系統狀態，與其他OSD共同完成數據的存儲和維護，與client通信完成各種數據對象操作等等。
Ceph系統的邏輯結構就介紹到這裏。下篇文章將着重說明Ceph（主要是RADOS）的工作原理和操作流程。