文章目錄

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

一、Ceph 集群角色

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

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

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

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

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

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

二、Ceph 元數(shù)據(jù)保存方式

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

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

2.1 xattrs(擴展屬性)

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

2.2 omap(object map 對象映射)

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

2.2.1 filestore 與 leveldb

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

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

filestore 數(shù)據(jù)寫入的過程

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

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

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

2.2.2 bluestore 與 rocksdb

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

特點

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

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

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

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

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

三、CRUSH 算法簡介

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

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

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

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

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

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

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

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。