CEPH ARCHITECTURE

THE CEPH STORAGE CLUSTER

ceph 通過 RADOS 提供了一個可以無限擴展的集羣存儲系統，可以通過 RADOS - A Scalable, Reliable Storage Service for Petabyte-scale Storage Clusters 這篇文章瞭解更多細節。

ceph storage cluster 主要由兩種daemon 組成：

Ceph Monitor
Ceph OSD Daemon

graph TB
    A(OSDs)   
    B(Monitors)

Ceph Monitor 保存了 cluster map 的原版拷貝. Ceph monitor cluster 爲 monitor damon 提供高可用，避免單點故障. 集羣存儲客戶端（OSD）可通過 Ceph Monitor 來恢復 cluster map 拷貝。

Ceph OSD daemon 會檢測自己和其他節點的狀態（通過端口間的心跳消息）並上報 monitor

STORAING DATA

ceph 集羣存儲從客戶端接受數據( 可能通過 Ceph Black Device, Ceph Object Storage 或者 Ceph Filesystem 以及通過 librados 工具庫寫入)。數據被作爲對象存儲到ceph，每個對象都會對應文件系統中的某個文件(存儲在OSD中). ceph OSD Daemon 會負責磁盤的讀寫操作.

graph LR
    A(Object)-->B[File]
    B --> C((Disk))

Ceph OSD daemon 將所有的數據存在同一個目錄

Ceph OSD Daemons store all data as objects in a flat namespace (e.g., no hierarchy of directories).

一個 Object 包含一個id, 二進制數據和元數據組成的key/value對.

Note : An object ID is unique across the entire cluster, not just the local filesystem.

SCALABILITY AND HIGH AVAILABILITY

在傳統架構中，一個複雜的系統往往會有一個集中式的訪問入口(e.g: gateway, broker, facade, etc.) 這種模型在某種程度上限制了系統的性能和可擴展性,並且存在單點故障的隱患(e.g: 當中心組件掛掉,會導致整個系統不可用)

Ceph 實現了去中心化,客戶端直接與 Ceph OSD Daemon 交互. Ceph OSD Daemons 會從其他節點複製數據拷貝來保障數據安全和高可用.Ceph 同時使用 Ceph Monitor cluster 來保障高可用. 爲了實現去中心化, Ceph 使用了 CRUSH 算法.

CRUSH INTRODUCTION

Ceph client 和 Ceph OSD Daemons 都通過 CRUSH 算法來定位 Object 存儲位置, 而不是依賴於某個表來查詢. 相比傳統方案, CRUSH 提供了一個更好的數據管理機制, CRUSH 使用智能數據複製來確保彈性(可以定義Object的副本數量),更適用於超大規模的存儲集羣. 關於 CRUSH 的詳述,參考:
CRUSH - Controlled, Scalable, Decentralized Placement of Replicated Data

CLUSTER MAP

Ceph depends upon Ceph Clients and Ceph OSD Daemons having knowledge of the cluster topology(拓撲學), which is inclusive of 5 maps collectively referred to as the “Cluster Map”:

The Monitor Map: Contains the cluster fsid, the position, name address and port of each monitor. It also indicates the current epoch, when the map was created, and the last time it changed. To view a monitor map, execute ceph mon dump.

The OSD Map: Contains the cluster fsid, when the map was created and last modified, a list of pools, replica sizes, PG numbers, a list of OSDs and their status (e.g., up, in). To view an OSD map, execute ceph osd dump.

The PG Map: Contains the PG version, its time stamp, the last OSD map epoch, the full ratios, and details on each placement group such as the PG ID, the Up Set, the Acting Set, the state of the PG (e.g., active + clean), and data usage statistics for each pool.

The CRUSH Map: Contains a list of storage devices, the failure domain hierarchy (e.g., device, host, rack, row, room, etc.), and rules for traversing the hierarchy when storing data. To view a CRUSH map, execute ceph osd getcrushmap -o {filename}; then, decompile it by executing crushtool -d {comp-crushmap-filename} -o {decomp-crushmap-filename}. You can view the decompiled map in a text editor or with cat.

The MDS Map: Contains the current MDS map epoch, when the map was created, and the last time it changed. It also contains the pool for storing metadata, a list of metadata servers, and which metadata servers are up and in. To view an MDS map, execute ceph fs dump.

Each map maintains an iterative(迭代的) history of its operating state changes. Ceph Monitors maintain a master copy of the cluster map including the cluster members, state, changes, and the overall health of the Ceph Storage Cluster.

簡言之: cluster map 描述集羣中所有 OSD, Monitor 信息,狀態及其邏輯關係.

HIGH AVAILABILITY MONITORS

Ceph Clients 需要先從 Ceph Monitor 處獲取最新的 cluster map, 然後才能進行讀寫.爲了避免 Ceph Monitor 的單點故障,需要爲Ceph Monitor 添加集羣.

在 Ceph Monitor 集羣中, 潛在的bug或者其他原因(如服務器故障,網絡不通等)導致部分Monitor 在當前集羣狀態中失效. 由於這個原因, Ceph Monitor cluster 中必須有超過半數的節點可用才能決定 cluster 是否工作.(e.g: 1, 2:3, 3:5, 4:6, etc.) 各個Monitor間通過 Paxos 算法來達成共識.

HIGH AVAILABILITY AUTHENTICATION

爲了預防 man-in-the-middle attacks (中間人攻擊,ARP欺騙), Ceph 提供了 cephx 來鑑定 user 和 daemon.

NOTE : The cephx protocol does not address data encryption in transport (e.g., SSL/TLS) or encryption at rest.

cephx 使用對稱密鑰來認證,這就意味着客戶端和Monitor都需要一份密鑰拷貝.在部署集羣的時候,要確保 client 和 Monitor 都擁有相同的key文件.

由於 ceph 的去中心化設計, 這就意味着客戶端需要直接和OSDs產生交互.爲了保護數據, Ceph提供其cephx認證系統，用於認證用戶操作Ceph客戶端。

首先 Ceph 客戶端需要和 monitor 通信(默認情況下會指定一個名爲admin的用戶來進行認證). Monitor 會返回一個認證的數據結構,裏面包含了用於獲取Ceph服務的會話密鑰. 會話密鑰本身由用戶密鑰加密,因此只有該用戶能夠從Ceph monitor 請求服務. 客戶端使用會話密鑰想monitor請求服務,隨後monitor提供一個用於和OSDs直接交互的 ticket. Ceph Monitor 和 OSDs 使用同一個密碼,所以客戶端能於 Ceph Monitor 管轄下的每一個 OSD 交互. 想大多數認證方法, ticket 存在過期時間, 攻擊者無法使用一個過期的ticket來請求.因此只要密鑰未在過期前被泄露, 中間的攻擊者就無計可施.

爲了使用 cephx, 需要先設置系統管理賬號. 一般通過 ceph auth get-or-create-key 命令來生成 client.admin 用戶的用戶名和密鑰. 另外需要將生成的密鑰copy 一份至 Ceph 客戶端上去. 如下圖所示:

Note : The client.admin user must provide the user ID and secret key to the user in a secure manner

爲了達成認證, 分如下步驟:

客戶端需要向 monitor 傳遞用戶名,如admin
隨後monitor生成一個會話密鑰,並用與該用戶名相關聯的祕密密鑰進行加密。
將加密的會話密鑰傳送至客戶端之後,客戶端使用共享密鑰解密,得到解密後會話密鑰.(會話密鑰定義了當前會話的用戶)
在獲得會話密鑰之後,客戶端代表會話密鑰簽名的用戶(即admin)請求ticket.
Monitor 生成ticket, 使用admin對應的密鑰加密後發送給客戶端.
客戶端解密,並利用該ticket向集羣中的OSDs或者MDS發送請求.

總體流程如下所示:

疑問: 若存在多個OSD, ceph Client 與哪個通信?

SMART DAEMONS ENABLE HYPERSCALE

在許多集羣架構中, 一個最基本作用的就是核心組件要知道哪些節點是能夠訪問的.然後集羣的入口(如apigw等的組件)向客戶端提供服務–這樣的做法在面對PB級別數據流量的時候會成爲瓶頸.

爲了消除瓶頸,ceph 的 OSD Daemon 和 Ceph Client 之間是相互感知的.像Ceph客戶端，每個Ceph OSD守護進程都知道集羣中的其他Ceph OSD守護進程。這使得Ceph OSD守護進程能夠與其他Ceph OSD守護進程和Ceph Monitor直接交互。此外，它使Ceph客戶端可以直接與Ceph OSD守護進程進行交互。

Ceph客戶端，Ceph監視器和Ceph OSD守護進程互相交流的能力意味着Ceph OSD守護進程可以利用Ceph節點的CPU和RAM輕鬆執行會使中央服務器惡化的任務。利用這種計算能力的能力有以下幾個主要優點：
1. OSDs 直接向客戶端提供服務:由於任何網絡設備支持的併發連接數有限制,因此集中式的訪問在高併發下會受物理條件限制. ceph 客戶端直接訪問OSDs, 在提高性能和系統容量的同時,還能消除單點故障.
2. OSD 成員關係和狀態: OSD 進程加入集羣后會彙報其狀態.最基礎的,OSD 進程的 up 和 down 反映了OSD 是否在運行以及能否爲客戶端提供服務. down &in 意味着OSD守護進程失敗. 如果OSD 守護進程未運行(e.g., 服務器故障), OSD 無法通知Monitor自己的處於 down 狀態. OSD會間歇性的像Monitor 發送心跳消息. 如果Monitor 在特定時間間隔內未收到消息,就會標記該OSD 爲 down 狀態. 這是一個故障安全的機制. 然而,一般來說: 當一個OSD 失敗,鄰近的OSD 守護進程會發現並上報至Monitor. 這就減輕了 Ceph Monitor 的複雜度.
3. 數據清洗: 作爲數據一致性和數據清潔的一部分, OSD 能夠通過 PG 來清洗 object .具體來說就是,Ceph OSD守護進程可以將一個PG中的對象元數據與其他OSD中存儲的PG中的副本進行比較, 以此捕獲bug和文件系統錯誤(通常每天執行一次). OSD也執行通過對object數據逐個字節的對比來實現更深層次的清洗.深度清洗可以發現輕度清洗中捕獲不到的磁盤壞道(通常每週執行一次),不過期間會影響性能.
4. 複製: 像Ceph客戶端一樣，Ceph OSD守護進程使用CRUSH算法，但是Ceph OSD Daemon使用它來計算應該存儲對象的副本（並重新平衡）,在典型的寫操作場景下,客戶端使用CRUSH 算法來計算Object存儲的位置,並將對象映射到 pool 和 PG, 然後查看CRUSH映射以標識 PG 的 Primary OSD.

客戶端將object 寫入到 PG 對應的 Primary OSD, 隨後 Primary OSD 會將object 複製到第二個和第三個 OSD(默認Object的拷貝數爲3), 當所有副本存儲成功後,會向客戶端返回響應.過程如下圖所示:

憑藉執行數據複製的能力，Ceph OSD守護進程可以減輕Ceph客戶的負擔，同時確保高數據可用性和數據安全性。

DYNAMIC CLUSTER MANAGEMENT

Ceph設計的關鍵是自主，自我修復和智能Ceph OSD守護進程。我們來深入瞭解CRUSH如何使現代雲存儲基礎架構能夠放置數據，重新平衡羣集並動態地從故障中恢復

ABOUT POOLS

Ceph 存儲系統支持”pool”的概念,作爲存儲對象的邏輯分區.
Ceph客戶端從Ceph Monitor檢索 cluster map，並將對象寫入pool。 pool 的大小或副本數，CRUSH規則集和 PG 數決定了Ceph如何放置數據。
如下圖所示:

pool 至少需要如下配置:
- object 的 owner和訪問權限
- PG 個數
- 使用的 CRUSH 規則集

MAPPING PGs TO OSDs

每個 pool 包含若干 PG. CRUSH 將 OSD 動態的關聯到 PG. 當客戶端要存儲一個object, CRUSH 會將object映射到某個PG 上.

PG 想當與 OSD Daemon 和 Ceph client 之間的一個邏輯層.Ceph存儲集羣必須能夠在動態存儲對象的情況下增長（或縮小）並重新平衡（再平衡）. 如果Ceph client 知道對象和object的對應關係,這將在Ceph客戶端和Ceph OSD守護進程之間建立緊密的耦合.相反，CRUSH算法將每個對象映射到一個 PG，然後將每個 PG 映射到一個或多個Ceph OSD守護進程。這種邏輯層允許Ceph在新的Ceph OSD守護進程和底層OSD設備上線時動態重新平衡。下圖描繪CRUSH如何將對象映射到 PG，將 PG 映射到OSD。(概念有些類似lvm)

使用 cluster map 的副本和CRUSH算法，客戶端可以準確計算在讀取或寫入特定對象時要使用的OSD。

疑問： 一個PG能關聯多少個OSD？

CALCULATING PG IDS

當客戶端連接到了Ceph Monitor，就會獲得一份最新的 cluster map 拷貝。通過 cluster map 客戶端可以知道集羣中所有組件的信息。然而，卻無法得知object的存儲位置。

Object locations get computed

客戶端只需要輸入 object ID和pool信息。通過object id, a hash code, pool的PG數量和pool name就能計算出object位於哪個PG中。Ceph 客戶端計算PG IDs 的步驟如下：

The client inputs the pool ID and the object ID. (e.g., pool = “liverpool” and object-id = “john”)

Ceph takes the object ID and hashes it.

Ceph calculates the hash modulo(以…爲模) the number of PGs. (e.g., 58) to get a PG ID.

Ceph gets the pool ID given the pool name (e.g., “liverpool” = 4)

Ceph prepends(預先考慮) the pool ID to the PG ID (e.g., 4.58).

在本地計算object位置要比通過session查詢快得多。CRUSH 算法允許客戶端計算出object的存儲位置，並且可以讓客戶端直接向 primary OSD 中存儲/讀取數據。

PEERING AND SETS

Ceph OSD Daemons 除了檢測彼此間心跳之外，還會將所有OSD中PG存儲的objects(以及object metadata)狀態相一致。這個過程稱之爲 “peering”(OSD 還負責數據一致性檢查).

Another thing Ceph OSD daemons do is called ‘peering’, which is the process of bringing all of the OSDs that store a Placement Group (PG) into agreement about the state of all of the objects (and their metadata) in that PG

Note : Agreeing on the state does not mean that the PGs have the latest contents.

Ceph 存儲集羣中每個Object至少會有兩份拷貝（i.e.,size=2）,這是爲保障數據安全性的最低要求。爲了實現高可用，應該存儲2份以上拷貝（e.g.,size=3 & min size=2）,只有這樣集羣才能在降級狀態下繼續保障數據安全。

一般osd守護進程以osd.0, osd.1等命名，而不是osd.primary, osd.secondary。方便起見， primary osd 即第一個 Acting Set 的osd， primary osd 負責 peering 過程，並且只有primary osd能接收客戶端發起的寫請求.

當一系列的OSD負責一個 PG 時，這一系列OSD，我們把它們稱爲一個 Acting Set。

Ceph OSD Daemon 可能不總是處於 up. 當位於Acting Set 中的OSD狀態爲 up時，那麼這個OSD就是 Up Set 中的一員。這兩者有很大區別，因爲當位於 Up Set 中的OSD Daemon失敗後，Ceph重新映射PGs和OSD Daemons.

Note : In an Acting Set for a PG containing osd.25, osd.32 and osd.61, the first OSD, osd.25, is the Primary. If that OSD fails, the Secondary, osd.32, becomes the Primary, and osd.25 will be removed from the Up Set.

REBALANCING

當你向Ceph存儲集羣中新增了一個OSD Daemon時，cluster map會被更新（PG對應的OSD會發生改變）。
http://docs.ceph.com/docs/master/architecture/#rebalancing

Referring back to Calculating PG IDs, this changes the cluster map. Consequently, it changes object placement, because it changes an input for the calculations.

這裏提到了增加OSD會改變object的存儲位置，因爲它改變了計算的輸入。
但根據 Caculating PG IDs中的描述，客戶端在計算位置時，只需要輸入object id + pool name + pg num. 其中object id和pool name 應該是不變的，pg num 在pool創建的時候就指定了，因此也不會隨着新OSD的加入而發生變化。因此個人感覺這段描述有誤。

下圖展示了 rebalanceing 過程：

Note :
1. 當Ceph 存儲集羣具有一定規模的時候，加入新的OSD時，只有少部分PG和OSD的映射關係會發生改變。
2. 即使處於 rebalancing 狀態，CRUSH也是穩定的（因爲大部分PG和OSD映射不會變化）。因此可以不必擔心 rebalancing 期間會導致負載波動。

DATA CONSISTENCY

作爲保持數據一致性和清潔度的一部分，Ceph OSD還可以擦除 PG 內的對象。也就是說，Ceph OSD可以將一個 PG 中的對象元數據與其他OSD中存儲的 PG 中的副本進行比較。清洗（通常每天執行）會捕獲OSD錯誤或文件系統錯誤。 OSD也可以通過比較比特中的數據進行更深的清洗。深度清洗（通常每週執行一次）可以發現在清洗過程察覺不到的磁盤壞道。

有關配置清洗的詳細信息，請參閱Data Scrubbing。

ERASURE CODING

糾錯碼池將 object 存儲爲 k+m 塊。 k 爲數據塊， m 爲編碼塊。爲了將每個塊存儲到同一 Acting Set 的OSD中（及同一個PG中），需要設置 pool size=k+m, 塊的順序被作爲object的屬性存儲在metadata中。

例如，消除編碼池中有5個OSD（K+M=5）,其中兩個塊丟失（M=2）

READING AND WRITING ENCODED CHUNKS

一個名爲 NYAN 的object, 數據部分爲 ABCDEFGHI 寫入糾錯碼池中，糾錯碼函數將數據分爲3個數據塊。分別是ABC, DEF, GHI. 如果內容長度不爲k 的倍數，將會被填充。此外還會產生m 個編碼塊，分別爲YXY 和GQC. 每個塊都存儲在同一Acting Set的OSD中。這些塊都有相同的object name (NAYN)，但位於不同的OSD中。數據塊之間的順序被保存爲object的一個屬性（shard_t）。如下圖所示：

其中QGC位於的OSD4，處於 OUT 狀態無法被讀取，DEF 位於的OSD2，讀取速度太慢，即：在解碼過程中，EFG 和 GQC數據塊缺失（它們被稱爲擦除）。當object NYAN 從糾錯碼的pool中讀取出來時，糾錯碼函數讀取3個數據塊：ABC, GHI, YXY. 然後重新構成原始內容ABCDEFGHI.

INTERRUPTED FULL WRITES

在糾錯碼池中，在Up set 中的 primary OSD 接受所有的寫操作，並負責將有效數據轉化成k+m 個數據塊，隨後傳送至OSD。它還負責維護PG日誌的權威版本。

下圖中，一個有糾錯功能的PG, k=2 + m=1,並由三個OSD支持。分別爲OSD1，OSD2，OSD3。一個經過編碼的對象存儲在OSD中：塊D1v1（第一個數據塊，版本爲1）位於OSD1，塊D2v1 位於OSD2以及塊C1v1（第一個糾錯碼塊，版本1）位於OSD3. 每個OSD上的PG日誌是相同的。（i.e.1,1 對應着epoch 1, version 1）

OSD1 作爲primay從客戶端接受了一個 WRITE FULL 請求，即將object全部替換，而不是重寫其中某個部分。版本2創建的object會覆蓋版本1. OSD1將v2 object 編碼成3個數據塊：D1v2, D2v2, C1v2,並分別分佈到OSD1，OSD2，OSD3。OSD1除了要負責存儲快的寫入以外，也會維護一份PG日誌的權威版本。

當一個OSD收到消息寫入數據塊時，同時也會在PG的log中創建一個新的條目，來反映此次修改。例如：只要OSD3存儲C1v2,就會在日誌中添加一條1,2 (i.e. epoch 1,version 2)。

由於OSDs是異步的，當OSD1已經寫入D1v2時，D2v2可能還在傳送當中。即OSD2中存儲的仍是D2v1.如下圖所示：

如果一切順利,日誌的last_complete指針可以從1,1移動到1,2。

最後，可以刪除用於存儲對象先前版本的塊的文件：OSD 1上的D1v1，OSD 2上的D2v1和OSD 3上的C1v1。

但是，如果D2v2仍在傳輸過程中，OSD1掛了，版本2的object只有一部分被寫入了：OSD3 有一部分糾錯碼但並不足以恢復數據。這樣一來就丟失了兩個數據塊：D1v2 和 D2v2.

OSD 4成爲新的primary OSD，並發現last_complete日誌條目（即，在此條目之前的所有對象在之前的Acting Set中都是可用的）爲1,1，並且將成爲新的權威日誌。

OSD 3中發現的日誌條目1,2是從OSD 4提供的新權威日誌中相異：它被丟，並且包含C1v2塊的文件被刪除。在刷新過程中，將通過糾錯碼重構D1v1數據塊，並將其存儲在新的主OSD 4上。

CACHE TIERING

高速緩存層爲Ceph客戶端存儲在後端存儲層中的數據子集提供了更好的I / O性能。高速緩存層需要創建一個pool 來關聯一個快速存儲設備（e.g. ssd）,並設置爲高速緩存層。一些便宜的低速設備可配置爲後端存儲層。Ceph Objecter 會決定object的存儲位置，分層代理決定何時將緩存層中的數據刷新到後端存儲層。因此，緩存層和後備存儲層對Ceph客戶端是完全透明的。

Ceph ARCHITECTURE