Ceph結構是怎么樣的

這篇文章主要介紹了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集群主要由兩種節點組成。一種是為數眾多的、負責完成數據存儲和維護功能的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結構是怎么樣的”這篇文章對大家有幫助，同時也希望大家多多支持億速云，關注億速云行業資訊頻道，更多相關知識等著你來學習!