技術棧 | Ceph構件及組件分析
Ceph存儲架構
Ceph 存儲集群由幾個不同的daemon組成，每個daemon負責Ceph 的一個獨特功能并。每個守護進程是彼此獨立的。
下面將簡要介紹每個Ceph組件的功能：
RADOS(Reliable Autonomic Distributed Object Store, RADOS)
RADOS是Ceph 存儲集群的基礎。Ceph 中的一切都以對象的形式存儲，而RADOS 就負責存儲這些對象，而不考慮它們的數據類型。RADOS 層確保數據一致性和可靠性。對于數據一致性，它執行數據復制、故障檢測和恢復。還包括數據在集群節點間的recovery。
OSD
實際存儲數據的進程。通常一個OSD daemon綁定一個物理磁盤。Client write/read 數據最終都會走到OSD去執行write/read操作。
MON(monitor)
Monitor在Ceph集群中扮演者管理者的角色，維護了整個集群的狀態，是Ceph集群中最重要的組件。
Mon保證集群的相關組件在同一時刻能夠達成一致，相當于集群的領導層，負責收集、更新和發布集群信息。為了規避單點故障，在實際的Ceph部署環境中會部署多個Mon，同樣會引來多個Mon之前如何協同工作的問題。在一個標準的Ceph環境中，Monitor的功能可以分為以下兩點
- 管好自己
多個monitor之間如何協同工作，怎么同步數據;
- 管理集群信息
數據的存儲，保證數據存儲的正確性等等。
Librados
簡化訪問RADOS的一種方法，目前支持PHP、Ruby、Java、Python、C和C++語言。它提供了Ceph 存儲集群的一個本地接口RADOS ，并且是其他服務(如RBD 、RGW) 的基礎，以及為CephFS 提供POSIX 接口。librados API 支持直接訪問RADOS ，使得開發者能夠創建自己的接口來訪問Ceph 集群存儲。
RBD
Ceph塊設備。對外提供塊存儲。可以像磁盤一樣被映射、格式化已經掛載到服務器上。支持snapshot。
RGW
Ceph對象網關，提供了一個兼容S3和Swift的restful API接口。RGW還支持多租戶和Openstack的keyston身份驗證服務。
MDS
Ceph元數據服務器，跟蹤文件層次結構并存儲只供CephFS使用的元數據。Ceph塊設備和RADOS網關不需要元數據。MDS不直接給client提供數據服務。
CephFS
提供了一個任意大小且兼容POSlX的分布式文件系統。CephFS 依賴Ceph MDS 來跟蹤文件層次結構，即元數據。
Ceph RADOS
RADOS 是Ceph 存儲系統的核心，也稱為Ceph 存儲集群。Ceph 的所有優秀特性都是由RADOS 提供的，包括分布式對象存儲、高可用性、高可靠性、沒有單點故障、向我修復以及自我管理等。RADOS 層在Ceph 存儲架構中扮演著舉足輕重的角色。Ceph 的數據訪問方法(如RBD 、CephFS 、RADOS GW 和librados ) 的所有操作都是在RADOS 層之上構建的。
當Ceph 集群接收到來向客戶端的寫請求時，CRUSH 算法首先計算出存儲位置，以此決定應該將數據寫入什么地方。然后這些信息傳遞到隊DOS 層進行進一步處理。基于CRUSH 規則集，RADOS 以小對象的形式將數據分發到集群內的所有節點。最后，將這些對象存儲在OSD 中。
當配置的復制數大于1時，隊DOS 負責數據的可靠性。同時，它復制對象，創建副本，并將它們存儲在不同的故障區域中，換言之，同一個對象的副本不會存放在同一個故障區域中。然而，如果有更多個性化需求和更高的可靠性，就需要根據實際需求和基礎架構來優化CRUSH 規則集。RADOS 能夠保證在一個RADOS 集群中的對象副本總是不少于一個，只要你有足夠的設備。
除了跨集群存儲和復制對象之外，RADOS 也確保對象狀態的一致性。在對象不一致的情況下，將會利用剩下的副本執行恢復操作。這個操作自動執行，對于用戶而言是透明的，從而為Ceph 提供了自我管理和自我修復的能力。如果仔細分析Ceph 的架構圖，你會發現它有兩部分: RADOS 在最下部，它完全處于Ceph集群的內部，沒有提供給客戶端直接接口;另一部分就是在RADOS 之上的面向所有客戶端的接口。
Ceph 對象存儲設備
Ceph 的OSD 是Ceph 存儲集群中最重要的一個基礎組件，它負責將實際的數據以對象的形式存儲在每一個集群節點的物理磁盤驅動器中。Ceph 集群中的大部分工作是由OSD 守護進程完成的。存儲用戶數據是真正最耗時的部分。
Ceph OSD 以對象的形式存儲所有客戶端數據，并在客戶端發起數據請求時提供相同的數據。Ceph 集群包含多個OSD 。對于任何讀或寫操作，客戶端首先向monitor 請求集群的map ，然后，它們就可以無須monitor 的干預直接與OSD 進行I/O操作也正是因為產生數據的客戶端能夠直接寫入存儲數據的OSD 而沒有任何額外的數據處理層，才使得數據事務處理速度如此之快。與其他存儲解決方案相比，這種類型的數據存儲和取回機制是Ceph 所獨有的。
Ceph 的核心特性(比如可靠性、自平衡、自恢復和一致性)都始于OSD 。根據配置的副本數， Ceph通過跨集群節點復制每個對象多次來提供可靠性，同時使其具有高可用性容錯性。OSD 上的每個對象都有一個主副本和幾個輔副本，輔副本分散在其他OSD 上。由于Ceph 是一個分布式系統且對象分布在多個OSD 上，因此每一個OSD 對于一些對象而言是主副本。但同時對于其他對象而言就是輔副本，存放輔副本的OSD 受主副本OSD 控制;然而，它們也可能又成為主副本OSD 。
Ceph的OSD由一個已經存在Linux 文件系統的物理磁盤驅動器和10SD 服務組成。
Linux文件系統對于OSD 守護進程而言是相當重要的，因為它決定了支持哪些擴展屬性( XATTR) 。這些文件系統擴展屬性能夠為OSD 守護進程提供內部對象的狀態、快照、元數據和ACL 等信息.這有助于數據管理。
OSD在擁有有效Linux 分區的物理磁盤驅動器上進行操作。Linux 分區可以是Btrfs (B樹文件系統)、XFS 或ext4。Ceph 集群的性能基準測試的主要標準之一就是文件系統的選擇。
Btrfs
與使用XFS 和ext4 文件系統的OSD 相比，使用Btrfs 文件系統的OSD 能夠提供更佳的性能。使用Btrfs 最主要的一個優點是支持寫時復制和可寫的快照，這對于慮擬機的部署和克隆非常有用。在文件系統中它還支持透明的壓縮、普遍的校驗和多設備的統一管理。還支持高效的XATTR 、對于小文件的合井，還有SSD上所熟知的集成卷管理，并支持在線fsck 的特性。然而，盡管有如此多的新特性，Btrfs 目前還不具備應用于生產系統的條件，但對于測試而言它是一個很好的選擇。
XFS
這是一個可靠、成熟且非常穩定的文件系統，因此，我們推薦在生產環境的Ceph 集群中使用它。XFS 是Ceph存儲中最常用的文件系統.也是推薦OSD 使用的文件系統。然而，從另一個方面來看，XFS 又不如Btrfs。XFS 在元數據擴展性上存在性能問題，XFS 也是一種日志文件系統， 也就是說.每次客戶端發送數據以寫入Ceph 集群時，肯先需要寫人口志空間，然后再寫入XFS 文件系統這樣的兩次寫入操作增加了開銷從而使得XFS 的性能不如Btrfs，Btrfs 沒有使用日志。
Ext4
ext4 文件系統也是一種日志文件系統，是一個遠合生產環境下Ceph OSD 使用的文件系統;然而，它的受歡迎程度不如XFS 。從性能的角度來看，ext4 文件系統也不如Btrfs。
Ceph OSD 使用諸如Btrfs 和XFS 的日志文件系統。在將數據提交到備用存儲之前，Ceph 首先將數據寫入一個稱為日志( journal) 的獨立存儲區域，日志是相同的機械磁盤(如OSD) 或不同的SSD 磁盤或分區上一小塊緩沖區大小的分區，甚至也可以是文件系統上的一個文件。在這種機制中，Ceph 的所有寫都是先到日志，然后再到備用存儲，如下圖所示。
Ceph Monitor
顧名思義，Ceph monitor 負責監控整個集群的健康狀況。它們以守護進程的形式存在，這些守護進程通過存儲集群的關鍵信息來維護集群成員狀態、對等節點狀態，以及集群配置信息。Ceph monitor 通過維護整個集群狀態的主副本來完成它的任務。集群map 包括monitor 、OSD 、PG 、CRUSH 和MDS map o 所有這些map 統稱為集群map 。讓我們簡單地瀏覽一下每個map 的功能。
monitor map
它維護著monitor 節點間端到端的信息，其中包括Ceph 集群ID 、monitor 主機名、IP 地址及端口號。它還存儲著當前map 的創建版本和最后一次修改的信息。可以通過下面的命令檢查集群的monitor map:
- # ceph mon dump
OSD map :
它存儲著一些常見的信息，如集群ID、OSD map 創建版本和最后一次修改信息，以及與池相關的信息(如池名字、池ID 、類型、副本數和歸置組) 。它還存儲著OSD 的一些信息，如數目、狀態、權重、最近處于clean 狀態的間隔以及OSD 主機等信息。可以通過執行以下命令獲取集群的OSD map:
- # ceph osd dump
PG map :
它存儲著歸置組的版本、時間戳、最新的OSD map 版本、容量充滿的比例以及容量接近充滿的比例等信息。它同時也跟蹤每個歸置組的ID 、對象數、狀態狀態時間戳、OSD 的叩集合、OSD 的acting 集合，最后還有清洗等信息。要檢查集群的PG map ，執行:
- # ceph pg dump
CRUSH map:
它存儲著集群的存儲設備信息、故障域層次結構以及在故障域中定義如何存儲數據的規則。要查看集群的CRUSH map ，執行:
- # ceph osd crush dump
MDS map:
它存儲著當前MDS map 的版本，map 的創建和修改時間，數據和元數據池的ID ，集群中MDS 的數目以及MDS 的狀態。要查看集群MDS map ，執行:
- # ceph mds dump
一個典型的Ceph 集群通常包含多個monitor 節點。多monitor 的Ceph 架構使用了仲
裁( quorum ) ，使用Paxos 算法為集群提供了分布式決策機制。集群中monitor 數目應該是奇數，最低要求是一個monitor 節點，推薦的數是3 。自monitor開始仲裁操作，至少需要保證一半以上的monitor 始終處于可用狀態，這樣才可以防止其他系統可以看到的腦裂問題。
這就是為什么推薦使用奇數個monitor。在所有的集群monitor 巾，其中有一個是領導者( leader ) 。如果領導者monitor不可用其他monitor 節點也有權成為領導者。生產環境下的集群必須至少有三個monitor節點來提供高可用性。
對于企業級生產環境，建議使用專門的monitor 節點。這樣， 一旦你的OSD 節點發生
故障，只要你有足夠的monitor 運行在獨立的機器上，你仍然可以連接到你的Ceph 集群。在存儲的規劃階段，也應該考慮物理機架的布局。你應該將monitor節點分散到所有的故障域中，例如，不同的開關、電源和物理機架。如果你有多個數據中心連接在同一個高速網絡，monitor 節點應該放到不同的數據中心。
Ceph塊存儲
塊存儲是企業環境中最常見的一種數據存儲格式。Ceph 塊設備也稱為RADOS 塊設備(RBD) ;它為物理層的虛擬機監控程序以及虛擬機提供塊存儲解決方案。Ceph 的RBD 驅動程序已經被集成到Linux 內核( 2.6.39 或更高版本)中，而且已經被QEMU/KVM 支持，它們能無縫地訪問Ceph 塊設備。
Linux主機能全力支持內核RBD (KRB D ) 并通過librados 映射Ceph 塊設備。然后RADOS將Ceph 塊設備的對象以分布式模式存儲在集群中。一旦Ceph 塊設備映射到Linux主機，它也可以當作裸分區或標記為文件系統，然后進行掛載。
Ceph對象網關
Ceph 對象網關，也稱做RADOS 網關，它是一個代理，可以將HTTP 請求轉換為RADOS ，同時也可以把RADOS 請求轉換為HTTP 請求，從而提供RESTful 對象存儲，這兼容S3 和Swift。Ceph 對象存儲使用Ceph 對象網關守護進程( radosgw) 與librgw 、librados (Ceph 集群)交互。這是使用libfcgi 作為FastCGI的一個模塊來實現的，并且可以被任何支持FastCGl的Web 服務器使用。
Ceph文件系統
CephFS 在RADOS 層之上提供了一個兼容POSIX 的文件系統。它使用MDS 作為守護進程，負責管理其元數據并將它和其他數據分開，這有助于降低復雜性并提高可靠性。CephFS 繼承了RADOS 的特性并為數據提供了動態再平衡。
以上是對Ceph的架構和組件做了一些介紹，后續我們將對里面的技術細節進行詳細的討論。
