詳解Ceph數據是如何布局的？

Ceph項目始於2004年，是為優秀的性能、可靠性和可擴展性而設計的統一的分散式存儲系統。

在使用RADOS系統時，客戶端程序通過與OSD或者Monitor的交互獲取ClusterMap，然後直接在本地進行計算，得出對象的存儲位置後，便直接與對應的OSD通信，完成數據的各種操作。可見，在此過程中，只要保證ClusterMap不頻繁更新，則客戶端顯然可以不依賴於任何元數據伺服器，不進行任何查表操作，便完成數據訪問流程。

在RADOS的運行過程中，Cluster Map的更新完全取決於系統的狀態變化，而導致這一變化的常見事件只有兩種(OSD出現故障或者RADOS規模擴大)。而正常應用場景下，這兩種事件發生的頻率顯然遠遠低於客戶端對數據進行訪問的頻率。

OSD依賴底層文件系統Xattrs來記錄對象狀態和元數據，Xattr必須提供足夠的容量大小，ext4僅4KB，xfs 64KB，而btrfs沒有限制，Btrfs不夠穩定，ext4 Xattr太小，生產部署推薦xfs測試推薦btrfs。

Client：部署在Linux伺服器上，實現數據切片，通過Crush演算法定位對象位置，並進行對象數據的讀寫。

OSD：存儲數據，處理數據複製，恢復，回填，重新調整，並向Monitor報告一些檢測信息。單集群至少需要2個OSD，一般情況下一個OSD對應一塊物理硬碟，部署btrfs、xfs或ext4的本地文件系統。

Monitor：實現OSD集群的狀態監控，維護OSD(守護進程)映射,分組(PG)映射，和CRUSH映射。

Metadata Cluster：元數據集群，用於管理文件元數據，僅CephFS需要。

Ceph系統的邏輯架構和概念對理解數據布局和架構十分重要，所以有必要在此進行說明。

一個Cluster可邏輯上劃分為多個Pool。

一個 Pool 包含若干個邏輯PG(Placement Group)，同時可定義Pool內的副本數量。

一個物理文件會被切分為多個Object。

每個Object會被映射到一個PG，一個PG內可包含多個Object。

一個PG映射到一組OSD，其中第一個OSD是主(Primary)，其餘的是從(Secondary)，承擔相同PG的OSD間通過心跳來相互監控存活狀態。

許多 PG 可以映射到某個OSD。

引入PG的概念後，OSD只和PG相關，簡化了OSD的數據存儲；同時實現了Object到OSD的動態映射，OSD的添加和故障不影響Object的映射。

在Ceph的現有機制中，一個OSD平時需要和與其共同承載同一個PG的其他OSD交換信息，以確定各自是否工作正常，是否需要進行維護操作。由於一個OSD上大約承載數百個PG，每個PG內通常有3個OSD，因此，一段時間內，一個OSD大約需要進行數百至數千次OSD信息交換。

然而，如果沒有PG的存在，則一個OSD需要和與其共同承載同一個Object的其他OSD交換信息。由於每個OSD上承載的Object很可能高達數百萬個，因此，同樣長度的一段時間內，一個OSD大約需要進行的OSD間信息交換將暴漲至數百萬乃至數千萬次。而這種狀態維護成本顯然過高。

數據定址流程可分三個映射過程，首先要將用戶要操作的File，映射為RADOS能夠處理的Object。就是簡單的按照Object的Size對File進行切分，相當於RAID中的條帶化過程。接著把Object映射到PG，在File被映射為一個或多個Object之後，就需要將每個Object獨立地映射到一個PG中去。第三次映射就是將作為Object的邏輯組織單元的PG映射到數據的實際存儲單元OSD。

1.File ->Object映射

這次映射的目的是，將用戶要操作的File，映射為RADOS能夠處理的Object。其映射十分簡單，本質上就是按照object的最大size對file進行切分，相當於RAID中的條帶化過程。這種切分的好處有二。

一是讓大小不限的File變成最大Size一致、可以被RADOS高效管理的Object。

二是讓對單一File實施的串列處理變為對多個Object實施的並行化處理。

2.Object -> PG映射

在File被映射為一個或多個Object之後，就需要將每個Object獨立地映射到一個PG中去。這個映射過程也很簡單，如圖中所示，其計算公式是(Hash(OID) & Mask -> PGID)。

3. PG -> OSD映射

第三次映射就是將作為Object的邏輯組織單元的PG映射到數據的實際存儲單元OSD。如圖所示，RADOS採用一個名為CRUSH的演算法，將PGID代入其中，然後得到一組共N個OSD。這N個OSD即共同負責存儲和維護一個PG中的所有Object。

1.File ——此處的file就是用戶需要存儲或者訪問的文件。對於一個基於Ceph開發的對象存儲應用而言，這個file也就對應於應用中的「對象」，也就是用戶直接操作的「對象」。將用戶操作的File切分為RADOS層面的Object，每個Object一般為2MB或4MB，大小可設置。

2. Ojbect ——此處的object是RADOS所看到的「對象」。Object與上面提到的file的區別是，Object的最大Size由RADOS限定(通常為2MB或4MB)，以便實現底層存儲的組織管理。因此，當上層應用向RADOS存入Size很大的File時，需要將File切分成統一大小的一系列Object(最後一個的大小可以不同)進行存儲。為避免混淆，在本文中將盡量避免使用中文的「對象」這一名詞，而直接使用File或Object進行說明。每個Object通過哈希演算法映射到唯一的PG。

3. PG(Placement Group)——顧名思義，PG的用途是對Object的存儲進行組織和位置映射。具體而言，一個PG負責組織若干個Object(可以為數千個甚至更多)，但一個object只能被映射到一個PG中，即，PG和object之間是「一對多」映射關係。同時，一個PG會被映射到N個OSD上，而每個OSD上都會承載大量的PG，即，PG和OSD之間是「多對多」映射關係。在實踐當中，N至少為2，如果用於生產環境，則至少為3。一個OSD上的PG則可達到數百個。

事實上，PG數量的設置牽扯到數據分布的均勻性問題。關於這一點，下文還將有所展開。每個PG通過CRUSH演算法映射到實際存儲單元OSD，PG和OSD間是多對多的映射關係.

4. OSD ——即Object Storage Device，OSD的數量事實上也關係到系統的數據分布均勻性，因此其數量不應太少。在實踐當中，至少也應該是數十上百個的量級才有助於Ceph系統的設計發揮其應有的優勢。OSD在物理上可劃分為多個故障域(機房、機架、伺服器)，可通過策略配置使PG的不同副本位於不同的故障域中。

溫馨提示：

求知若渴, 虛心若愚

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！