1. 什么是Ceph？
首先，我們從 Ceph的官方網站上，可以看到：“Ceph is a unified, distributed storage system designed for Excellent performance, reliability and scalability.” 從它的定義上我們可以明確它是一種存儲系統，而且可以明確它所具備的兩點特性：
（1）統一性（ unified ）：意味著可以同時提供對象存儲、塊存儲和文件系統存儲三種接口功能。
（2）分布式（ distributed ）：意味著其內部節點架構是以分布式集群算法為依托的。
接下來，我們從其架構原理以及讀寫原理上來分析其如何支撐定義當中所提到的各個特性。
2. Ceph的架構原理
2.1 Ceph存儲功能架構
從功能角度來講，Ceph本身的架構比較清晰明了，主要分應用接口層、存儲基礎接口層以及存儲對象層，接口層主要對客戶端的訪問負責，分為本地語言綁定接口(C/C++, JAVA, Python/ target=_blank class=infotextkey>Python)、RESTful (S3/Swift)、塊存儲設備接口、文件系統接口。從這個點上，其完整詮釋了“統一性（ unified ）”的特性。
具體如圖2.1所示：
圖2.1 Ceph存儲系統功能圖
（1）基礎存儲系統（RADOS）
RADOS是理解Ceph的基礎與核心。
物理上，RADOS由大量的存儲設備節點組成，每個節點擁有自己的硬件資源（CPU、內存、硬盤、網絡），并運行著操作系統和文件系統。邏輯上，RADOS是一個完整的分布式對象存儲系統，數據的組織和存儲以及Ceph本身的高可靠、高可擴展、高性能等使命都是依托于這個對象。
（2）基礎庫（LIBRADOS）
LIBRADOS是基于RADOS對象在功能層和開發層進行的抽象和封裝。
從使用功能上，其向上提供使用接口API（RADOSGW、RBD、FS）。從開發上功能上，其向上直接提供本地開發語言的API，主要包括C、C++、JAVA、Python等。這樣應用上的特殊需求變更就不會涉及到Ceph存儲本身，保障其安全性并且解除了存儲系統和上層應用的耦合性。
（3）存儲應用接口（ RADOS GW、 RBD 、 Ceph FS ）
存儲應用接口層 包括了三個部分：RADOS Gateway、 Reliable Block Device 、 Ceph FS，其作用是在librados庫的基礎上提供抽象層次更高、更便于應用或客戶端 直接 使用的上層接口。其中，RADOS GW是一個提供S3 RESTful API的 網關 ，以供相應的對象存儲應用 使用；RBD則提供了一個標準的塊設備接口 ；Ceph FS是一個POSIX兼容的分布式文件系統。
讀到此處，可能很多人都會有一個疑問：“既然Librados API能提供對象存儲應用可以使用的接口，為什么還要搞一個RadosGW API？”
其實這個是基于不同使用者維度來考慮的，就像應用系統的使用者和開發者兩個不同維度。使用者僅僅需要知道這個應用系統提供了什么功能，到什么界面去完成使用就可以了。但是開發者可能需要從后臺代碼當中去解決一系列基于性能、并發量、易用易維護性等維度出現的問題。同樣，對于RadosGW API來講，它僅僅提供了一些通用、固定、易用的少數使用維度的接口，而Librados API則是一個豐富的具備各種使用、開發等維度的接口庫。
2.2 Ceph物理組件架構
RADOS是Ceph的核心，我們談及的物理組件架構也只是RADOS的物理架構。
如圖2.2所示，RADOS集群是由若干服務器組成，每一個服務器上都相應會運行RADOS的核心守護進程（OSD、MON、MDS）。具體守護進程的數量需要根據集群的規模和既定的規則來配置。
圖2.2 RADOS物理組件架構
結合圖2.2，我們首先來看每一個集群節點上面的守護進程的主要作用：
OSD Daemon：兩方面主要作用，一方面負責數據的處理操作，另外一方面負責監控本身以及其他OSD進程的健康狀態并匯報給MON。OSD守護進程在每一個PG（Placement Group）當中，會有主次（Primary、Replication）之分，Primary主要負責數據的讀寫交互，Replication主要負責數據副本的復制。其故障處理機制主要靠集群的Crush算法來維持Primary和Replication之間的轉化和工作接替。所有提供磁盤的節點上都要安裝OSD 守護進程。
MON Daemon：三方面主要作用，首先是監控集群的全局狀態（OSD Daemon Map、MON Map、PG Map、Crush Map），這里面包括了OSD和MON組成的集群配置信息，也包括了數據的映射關系。其次是管理集群內部狀態，當OSD守護進程故障之后的系列恢復工作，包括數據的復制恢復。最后是與客戶端的查詢及授權工作，返回客戶端查詢的元數據信息以及授權信息。安裝節點數目為2N+1，至少三個來保障集群算法的正常運行。
MDS Daemon：它是Ceph FS的元數據管理進程，主要是負責文件系統的元數據管理，它不需要運行在太多的服務器節點上。安裝節點模式保持主備保護即可。
2.3 Ceph數據對象組成
Ceph的數據對象組成這部分主要是想闡述從客戶端發出的一個文件請求，到Rados存儲系統寫入的過程當中會涉及到哪些邏輯對象，他們的關系又是如何的？首先，我們先來列出這些對象：
（1）文件（FILE）：用戶需要存儲或者訪問的文件。對于一個基于Ceph開發的對象存儲應用而言，這個文件也就對應于應用中的“對象”，也就是用戶直接操作的“對象”。
（2）對象（Object）：RADOS所看到的“對象”。Object指的是最大size由RADOS限定（通常為2/4MB）之后RADOS直接進行管理的對象。因此，當上層應用向RADOS存入很大的file時，需要將file切分進行存儲。
（3）PG（Placement Group）：PG是一個邏輯概念，闡述的是Object和OSD之間的地址映射關系，該集合里的所有對象都具有相同的映射策略；Object & PG，N：1的映射關系；PG & OSD，1：M的映射關系。一個Object只能映射到一個PG上，一個PG會被映射到多個OSD上。
（4）OSD（Object Storage Device）：存儲對象的邏輯分區，它規定了數據冗余的類型和對應的副本分布策略；支持兩種類型：副本和糾刪碼。
接下來，我們以更直觀的方式來展現在Ceph當中數據是如何組織起來的，如圖2.3：
圖2.3 RADOS物理組件架構
結合圖2.3所示，我們來看數據的詳細映射過程：
（1） File > Object
本次映射為首次映射，即將用戶要操作的File，映射為RADOS能夠處理的Object。
具體映射操作本質上就是按照Object的最大Size對File進行切分，每一個切分后產生的Object將獲得唯一的對象標識Oid。Oid的唯一性必須得到保證，否則后續映射就會出現問題。
（2） Object > PG
完成從File到Object的映射之后， 就需要將每個 Object 獨立地映射到 唯一的 PG 當中 去。
Hash（Oid）& Mask > PGid
根據以上算法， 首先是使用Ceph系統指定的一個靜態哈希函數計算 Oid 的哈希值，將 Oid 映射成為一個近似均勻分布的偽隨機值。然后，將這個偽隨機值和 Mask 按位相與，得到最終的PG序號（ PG id）。根據RADOS的設計，給定PG的總數為 X（X= 2的整數冪）， Mask=X-1 。因此，哈希值計算和按位與操作的整體結果事實上是從所有 X 個PG中近似均勻地隨機選擇一個。基于這一機制，當有大量object和大量PG時，RADOS能夠保證object和PG之間的近似均勻映射。
（3） PG > OSD
最后的 映射就是將PG映射到數據存儲單元OSD。RADOS采用一個名為CRUSH的算法，將 PGid 代入其中，然后得到一組共 N 個OSD。這 N 個OSD即共同負責存儲和維護一個PG中的所有 Object 。和“object -> PG”映射中采用的哈希算法不同，這個CRUSH算法的結果不是絕對不變的，而是受到其他因素的影響。
① 集群狀態（Cluster Map）：系統中的OSD狀態 。數量發生變化時， CLuster Map 可能發生變化，而這種變化將會影響到PG與OSD之間的映射。
② 存儲策略配置。系統管理員可以指定承載同一個PG的3個OSD分別位于數據中心的不同服務器乃至機架上，從而進一步改善存儲的可靠性。
到這里，可能大家又會有一個問題“為什么這里要用CRUSH算法，而不是HASH算法？”
這一次映射，我們對映射算法有兩種要求：
一方面，算法必須能夠隨著系統的節點數量位置的變化，而具備動態調整特性，保障在變化的環境當中仍然可以保持數據分布的均勻性；另外一方面還要有相對的穩定性，也就是說大部分的映射關系不會因為集群的動態變化發生變化，保持一定的穩定性。
而CRUSH算法正是符合了以上的兩點要求，所以最終成為Ceph的核心算法。
3. Ceph的讀寫原理
3.1 Ceph IO流程
Ceph的IO框架當中會涉及到三個角色：客戶端（Client）、元數據節點（MON）、數據節點（OSD）。這個有點類似于Hadoop。客戶端首先發送數據讀寫請求到元數據節點上進行存儲空間的尋址，元數據節點根據數據請求獲取數據的地址空間信息，然后客戶端根據地址空間分布信息分別到所涉及的數據節點上查找相應數據片或者是將數據寫入相應數據節點的存儲空間地址。如圖3.1所示，
圖3.1 Ceph IO流程圖
結合圖3.1，具體說來，包括如下幾個詳細步驟：
（1）Client創建Cluster Handle。
（2）Client讀取配置文件。
（3）Client連接上元數據節點，獲取集群上的數據映射信息。
（4）Client根據CRUSH算法，計算獲得數據的所有OSD節點（Primary），然后進行數據讀寫。
（5）如果是數據的寫操作，Primary OSD會同時寫入另外兩個副本節點數據。
（6）Primary OSD等待另外兩個副本節點寫完數據狀態返回并將ACK信息返回客戶端。
3.2 Ceph故障IO流程
從正常的IO場景下到發生故障后的IO處理，會經過正常讀寫、故障過渡、集群穩定三個階段。正常階段的數據讀寫會通過（Client > Monitor，Client > OSD Primary > OSD Replic）這樣的流程，在整個過程中OSD Primary是數據處理的核心角色。如果OSD Primary 發生故障，就會通過故障偵測機制發現故障節點，然后通過CRUSH算法重新分配新的OSD Primary，重新同步數據一系列過程。如果這個時候客戶端恰好要讀取數據，就會需要新的機制滿足客戶端的讀請求。具體如圖3.2所示：
圖3.2 Ceph故障場景下的IO流程圖
首先，我們來看從正常場景到發生OSD主節點故障的這個階段：
（1）集群內部通過心跳機制發現故障，這個心跳機制分兩種：Monitor和OSD之間的主動和被動檢測機制，OSD之間的相互檢測機制；
（2）新的OSD Primary節點接受任務并選擇合適的OSD Replic節點進行數據同步；
（3）新的OSD Primary節點通知Monitor臨時的數據處理方案（將OSD Replic 節點作為臨時主節點響應客戶端的數據請求處理）。
當新的OSD Primary節點數據同步完成后，進入到正常階段：
（1）通知Monitor更新集群映射配置信息。
（2）正式接管數據讀寫任務，成為Primary OSD節點，集群恢復新的穩定狀態。
4. 結語
從Ceph的架構原理上來看，我們不難看出其定義當中的“擴展性、穩定性”。但是關于“優秀性能”這個描述的特性來講，其實是需要斟酌其語境的。我們不能從其架構的分布式模式上簡單判斷多個節點服務的性能一定是最優秀的。如果單從架構上來看，對一些可以直接以對象方式存儲及訪問的場景來說，Ceph的IO深度以及接口的銜接維度看，更利于發揮其性能的優勢。對于一些大文件存儲讀取場景來講，可以通過2M/4M這樣粒度的切分使得讀寫的性能更容易被橫向擴展的架構發揮出來。但是如果是RBD的模式，尤其是小數據事務處理場景（例如關系數據庫），由于對象可切分的粒度有限，橫向并發讀寫的優勢就發揮不出來了，而且現實業務場景當中的熱點數據問題往往集中在某一部分小粒度的數據片上，很有可能壓力會落到某個或者某幾個OSD上。因此，多維度去看Ceph，才能挖掘其真正價值，后續繼續挖掘其他維度上的優劣。
