詳解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的不同副本位于不同的故障域中。

其他

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。