轉載自：http://yizhaolingyan.net/?p=11

本文將從邏輯結構的角度對Ceph進行分析。

4.1    Ceph系統的層次結構

        Ceph儲存系統的邏輯層次結構如下圖所示[1]。

        （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++兩種，其文件參見[

        （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或者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）的工作原理和操作流程。