文章目錄

• 一、Ceph 集群角色
• 二、Ceph 元數據保存方式
• • 2.1 xattrs(擴展屬性)
  • 2.2 omap(object map 對象映射)
  • • 2.2.1 filestore 與 leveldb
    • 2.2.2 bluestore 與 rocksdb
• 三、CRUSH 算法簡介

一、Ceph 集群角色

若干的 Ceph OSD（對象存儲守護程序） 至少需要一個 Ceph Monitors 監視器（1,3,5,7...） 兩個或以上的 Ceph 管理器 managers（mgr），運行 Ceph 文件系統客戶端時，還需要高可用的 Ceph Metadata Server(文件系統元數據服務器)。 #非必須安裝 RADOS cluster:由多臺 host 存儲服務器組成的 ceph 集群。 OSD(Object Storage Daemon)：每臺存儲服務器的磁盤組成的存儲空間。 Mon(Monitor)：ceph 的監視器,維護 OSD 和 PG 的集群狀態，一個 ceph 集群至少要有一個 mon，可以是一三五七等等這樣的奇數個。 Mgr(Manager)：負責跟蹤運行時指標和 Ceph 集群的當前狀態，包括存儲利用率，當前性能 指標和系統負載等。

Monitor(ceph-mon)：ceph 監視器 （簡稱：mon）
在一個主機上運行的一個守護進程，用于維護集群狀態映射(maintains maps of the cluster state)。
包括 ceph 集群中有多少存儲池、每個存儲池有多少 PG 以及存儲池和 PG 的映 射關系等。
monitor map, manager map, the OSD map, the MDS map, and the CRUSH map，這 些映射是 Ceph 守護程序相互協調所需的關鍵群集狀態，此外監視器還負責管理守護程序和 客戶端之間的身份驗證(認證使用 cephX 協議)。通常至少需要三個監視器才能實現冗余和高可用性

Managers(ceph-mgr)的功能：
在一個主機上運行的一個守護進程，Ceph Manager 守護程序（ceph-mgr）負責跟蹤運行時指標和 Ceph 集群的當前狀態，包括存儲利用率，當前性能指標和系統負載。Ceph Manager 守護程序還托管基于 python 的模塊來管理和公開 Ceph 集群信息，包括基于 Web 的 Ceph 儀表板和 REST API。高可用性通常至少需要兩個管理器。

Ceph OSDs(對象存儲守護程序 ceph-osd)：
提供存儲數據，一個磁盤就是一個 OSD，因此一個服務器的 OSD 不能超過磁盤的總數， OSD 用于處理 ceph 集群數據復制，恢復，重新平衡，并通過檢查其他 Ceph OSD 守護程序的 心跳來向 Ceph 監視器和管理器提供一些監視信息。通常至少需要 3 個 Ceph OSD 才能實現 冗余和高可用性。
相當于給每一個磁盤起一個OSD進程，如果磁盤壞了，OSD進程也就掛了。

MDS(ceph 元數據服務器，ceph-mds)：
代表 ceph文件系統(NFS/CIFS)存儲元數據，(即 Ceph塊設備和 Ceph對象存儲不使用 MDS) ，只有啟用 Ceph FS 才是必須啟用的組件。

Ceph 的管理節點：
1.ceph 的常用管理接口是一組命令行工具程序，例如 rados、ceph、rbd 等命令，ceph 管理 員可以從某個特定的 ceph-mon 節點執行管理操作
2.推薦使用部署專用的管理節點對 ceph 進行配置管理、升級與后期維護，方便后期權限管理，管理節點的權限只對管理人員開放，可以避免一些不必要的誤操作的發生。

二、Ceph 元數據保存方式

Ceph 對象數據的元數據信息放在哪里呢? 對象數據的元數據以 key-value 的形式存在，在 RADOS 中有兩種實現：xattrs 和 omap。

ceph 可選后端支持多種存儲引擎，比如 filestore，kvstore，memstore，目前是以 kvstore 的 形式存儲對象數據的元數據信息。

2.1 xattrs(擴展屬性)

是將元數據保存在對象對應文件的擴展屬性中并保存到系統磁盤上，這要求支持對象存儲的 本地文件系統（一般是 XFS）支持擴展屬性。

2.2 omap(object map 對象映射)

omap：是 object map 的簡稱，是將元數據保存在本地文件系統之外的獨立 key-value 存儲 系統中，在使用filestore 時是 leveldb，在使用 bluestore 時是 rocksdb，由于 filestore 存 在功能問題(需要將磁盤格式化為 XFS 格式)及元數據高可用問題等問題，因此在目前 ceph 主要使用 bluestore。

2.2.1 filestore 與 leveldb

ceph 早期基于 filestore 使用 google 的 levelDB 保存對象的元數據，LevelDb 是一個持久化存 儲的 KV 系統，和 Redis 這種內存型的 KV 系統不同，LevelDb 不會像 Redis 一樣將數據放在內 存從而占用大量的內存空間，而是將大部分數據存儲到磁盤上，但是需要把磁盤上的 levelDB 空間格式化為文件系統(XFS)。

FileStore 將數據保存到與 Posix 兼容的文件系統(例如 Btrfs、XFS、Ext4)。在 Ceph 后端使用傳統的 Linux 文件系統盡管提供了一些好處，但也有代價，如性能、 對象屬性與磁盤本地文件系統屬性匹配存在限制等。

filestore 數據寫入的過程

先把要寫入的數據全部封裝成一個事務，其整理作為一條日志，寫入日志磁盤（一般把 日志放在 ssd 上提高性 能），這個過程叫日志的提交（journal submit）。

把數據寫入對象文件的磁盤中（也就是 OSD 的磁盤中），這個過程叫日志的應用(journal apply)。這個過程不一定寫入磁盤，有可能緩存在本地文件系統的 page cache 中。 當系統在日志提交的過程中出錯，系統重啟后，直接丟棄不完整的日志條目，該條日志對應 的實際對象數據并沒有修改，數據保證了一致性。當日志在應用過程中出錯，由于日志已寫 入到磁盤中，系統重啟后，重放（replay）日志，這樣保證新數據重新完整的寫入，保證了 數據的一致性。

filestore 日志的三個階段
日志的提交（journal submit）：日志寫入日志磁盤。
日志的應用(journal apply)：日志對應的修改更新到對象的磁盤文件中。這個過程不一定寫入 磁盤，有可能緩存在本地文件系統的 page cache 中。
日志的同步（journal sync 或者 journal commit）：確定日志對應的修改操作已經刷到磁盤 中。

2.2.2 bluestore 與 rocksdb

由于 levelDB 依然需要需要磁盤文件系統的支持，后期 facebok 對 levelDB 進行改進為 RocksDB https://github.com/facebook/rocksdb，RocksDB 將對象數據的元數據保存在 RocksDB，但是 RocksDB 的數據又放在哪里呢？放在內存怕丟失，放在本地磁盤但是解決不了高可用，ceph 對象數據放在了每個 OSD 中，那么就在在當前 OSD 中劃分出一部分空間，格式化為 BlueFS 文件系統用于保存 RocksDB 中的元數據信息(稱為 BlueStore)，并實現元數據的高可用， BlueStore 最大的特點是構建在裸磁盤設備之上，并且對諸如 SSD 等新的存儲設備做了很多 優化工作。

特點

對全 SSD 及全 NVMe SSD 閃存適配 繞過本地文件系統層，直接管理裸設備，縮短 IO 路徑 嚴格分離元數據和數據，提高索引效率 使用 KV 索引，解決文件系統目錄結構遍歷效率低的問題 支持多種設備類型 解決日志“雙寫”問題 期望帶來至少 2 倍的寫性能提升和同等讀性能 增加數據校驗及數據壓縮等功能

RocksDB 通過中間層 BlueRocksDB 訪問文件系統的接口。這個文件系統與傳統的 Linux 文件 系統（例如 Ext4 和 XFS）是不同的，它不是在 VFS 下面的通用文件系統，而是一個用戶態的 邏輯。BlueFS 通過函數接口（API，非 POSIX）的方式為 BlueRocksDB 提供類似文件系統的能 力

RocksDB 通過中間層 BlueRocksDB 訪問文件系統的接口。這個文件系統與傳統的 Linux 文件 系統（例如 Ext4 和 XFS）是不同的，它不是在 VFS 下面的通用文件系統，而是一個用戶態的邏輯。BlueFS 通過函數接口（API，非 POSIX）的方式為 BlueRocksDB 提供類似文件系統的能力。

BlueStore 的邏輯架構如上圖所示，模塊的劃分都還比較清晰，我們來看下各模塊的作用：
Allocator：負責裸設備的空間管理。
RocksDB：rocksdb 是 facebook 基于 leveldb 開發的一款 kv 數據庫，BlueStore 將元數據全部 存放至 RocksDB 中，這些元數據包括存儲預寫式日志、數據對象元數據、Ceph 的 omap 數 據信息、以及分配器的元數據 。
BlueRocksEnv：這是 RocksDB 與 BlueFS 交互的接口；RocksDB 提供了文件操作的接口 EnvWrapper(Env 封裝器)，可以通過繼承實現該接口來自定義底層的讀寫操作，BlueRocksEnv 就是繼承自 EnvWrapper 實現對 BlueFS 的讀寫。
BlueFS：BlueFS是BlueStore針對RocksDB開發的輕量級文件系統，用于存放RocksDB產生的.sst 和.log 等文件。
BlockDecive：BlueStore 拋棄了傳統的 ext4、xfs 文件系統，使用直接管理裸盤的方式；BlueStore 支持同時使用多種不同類型的設備，在邏輯上 BlueStore 將存儲空間劃分為三層：慢速（Slow） 空間、高速（DB）空間、超高速（WAL）空間，不同的空間可以指定使用不同的設備類型， 當然也可使用同一塊設備。

BlueStore 的設計考慮了 FileStore 中存在的一些硬傷，拋棄了傳統的文件系統直接管理裸設備，縮短了 IO 路徑，同時采用 ROW 的方式，避免了日志雙寫的問題，在寫入性能上有了極大的提高。
寫時重定向-ROW
寫時復制-COW

三、CRUSH 算法簡介

Controllers replication under scalable hashing #可控的、可復制的、可伸縮的一致性 hash 算法。

Ceph 使用 CURSH 算法來存放和管理數據，它是 Ceph 的智能數據分發機制。
Ceph 使用 CRUSH 算法來準確計算數據應該被保存到哪里，以及應該從哪里讀取,和保存元數據不同的 是,CRUSH 按需計算出元數據，因此它就消除了對中心式的服務器／網關的需求,它使得 Ceph 客戶端能夠計算出元數據，該過程也稱為 CRUSH 查找，然后和 OSD 直接通信。

如果是把對象直接映射到 OSD 之上會導致對象與 OSD 的對應關系過于緊密和耦合，當 OSD 由于故障發生變更時將會對整個 ceph 集群產生影響。

于是 ceph 將一個對象映射到 RADOS 集群的時候分為兩步走： 首先使用一致性 hash 算法將對象名稱映射到 PG，然后將 PG ID 基于 CRUSH 算法映射到 OSD 即可查到對象

以上兩個過程都是以”實時計算”的方式完成，而沒有使用傳統的查詢數據與塊設備的對應 表的方式，這樣有效避免了組件的”中心化”問題，也解決了查詢性能和冗余問題。使得 ceph 集群擴展不再受查詢的性能限制。

這個實時計算操作使用的就是 CRUSH 算法 Controllers replication under scalable hashing #可控的、可復制的、可伸縮的數據一致性 hash 算法。CRUSH 是一種分布式算法，類似于一致性 hash 算法，用于為 RADOS 存儲集群控制數據的 分配。

總結：一個pool，500G數據，pool里面有32個PG，如果一個OSD壞了，只需要復制十幾G的數據即可。如果分的PG太少，就會導致復制的量太大。

總結

以上是生活随笔為你收集整理的Ceph 集群基础的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。