Ceph存儲系統(tǒng)的設(shè)計目標是提供高性能、高可擴展性、 高可用的分布式存儲服務(wù)。它采用 RADOS在動態(tài)變化和異構(gòu)的存儲設(shè) 備集群上，提供了一種穩(wěn)定、可擴展、高性能的單一邏輯對象 存儲接口和能夠?qū)崿F(xiàn)節(jié)點自適應(yīng)和自管理的存儲系統(tǒng)。數(shù)據(jù)的放置采取 CRUSH 算法，客戶端根據(jù)算法確定對象的位置并直接訪問存儲節(jié)點，不需要訪 問元數(shù)據(jù)服務(wù)器。CRUSH算法具有更好的擴展性和性能。本文介紹Ceph 的集群架構(gòu)、數(shù)據(jù)放置方法以及數(shù)據(jù)讀寫路徑，并在此基礎(chǔ)上分析其性能特點和瓶頸。

RADOS可提供高可靠、高性能和全分布式的對象存儲 服務(wù)。對象的分布可以基于集群中各節(jié)點的實時狀態(tài),也可以自定義故障域來調(diào)整數(shù)據(jù)分布。塊設(shè)備和文件都被抽象包裝為對象，對象則是兼具安全和強一致性語義的抽象數(shù)據(jù)類型，因此 RADOS可在大規(guī)模異構(gòu)存儲集群中實現(xiàn)動態(tài)數(shù)據(jù) 與負載均衡。

對象存儲設(shè)備(OSD)是 RADOS 集群的基本存儲單元，它的主要功能是存儲、備份、恢復(fù)數(shù)據(jù)，并與其他 OSD之間進行負載均衡和心跳檢查等。一塊硬盤 通常對應(yīng)一個 OSD,由 OSD對硬盤存儲進行管理,但有時一 個分區(qū)也可以成為一個 OSD，每個 OSD皆可提供完備和具有強一致性語義的本地對象存儲服務(wù)。MDS是元數(shù)據(jù)服務(wù)器，向外提供 CephFS在服務(wù)時發(fā)出的處理元 數(shù)據(jù)的請求，將客戶端對文件的請求轉(zhuǎn)換為對對象的請求。RADOS中可以有多個 MDS分擔元數(shù)據(jù)查詢的工作。

RADOS取得高可擴展性的關(guān)鍵在于徹底拋棄了傳統(tǒng)存 儲系統(tǒng)中的中心元數(shù)據(jù)節(jié)點，另辟蹊徑地以基于可擴展哈希 的受控副本分布算法——CRUSH 來代替.通過 CRUSH 算法，客戶端可以計算出所要訪問的對象所在的 OSD。

與以往 的方法相比，CRUSH 的數(shù)據(jù)管理機制更好，它把工作分配給 集群內(nèi)的所有客戶端和 OSD 來處理,因此具有極大的伸縮性。CRUSH 用智能數(shù)據(jù)復(fù)制來確保彈性，更能適應(yīng)超大規(guī)模存儲。如圖所示，從文件到對象以及PG(Placement Group)都 是邏輯上的映射，從PG到OSD的映射采用CRUSH 算法，以保證在增刪集群節(jié)點時能找到對應(yīng)的數(shù)據(jù)位置。

根據(jù)Weil的研究，CRUSH算法具有相當好的可擴展性，在數(shù)千個 OSD的情況下仍然能保證良好的負載平衡。但這更多的是理論層面上，目前還沒有研究人員給出在數(shù) PB 規(guī)模的生產(chǎn)環(huán)境中的測試結(jié)果。

CRUSH算法是Ceph最 初 的 兩 大 創(chuàng) 新 之 一，也是整個RADOS的基石。CRUSH在一致性哈希的基礎(chǔ)上很好地考慮了容災(zāi)域的隔離,能夠?qū)崿F(xiàn)各類負載的副本放置規(guī)則，例如 跨機房、機架感知等。同時，CRUSH 算法支持多副本和糾刪碼這兩種數(shù)據(jù)冗余方式，還提供了４種不同類型的 Bucket (Uniform、List、Tree、Straw)，充分考慮了實際生產(chǎn)過程中硬 件的迭代式部署方式。

CRUSH 雖然提供了快速數(shù)據(jù)定位方法,但也有一定的缺陷。首先，在選擇OSD 時會出現(xiàn)權(quán)重失衡的情況，即低權(quán)重的OSD雖然在實際中可用，但是與其他復(fù)制節(jié)點相差較大且需二次哈希；其次，在增刪OSD時會有數(shù)據(jù)的額外遷移；最后，完全依賴哈希的隨機性可能會導(dǎo)致OSD的容量使用率不均衡，在實際環(huán)境中出現(xiàn)過超過40％的差異。因此，從2017年發(fā)布的Luminous版本起，Ceph提供了被稱為upmap的新機制，用于手動指定PG的分布位置來達到均衡數(shù)據(jù)的效果。

RADOS提供了分布式對象存儲能力，并在此基礎(chǔ)上擴展了塊存儲和文件存儲功能。RADOS中單個對象的大小根據(jù)配置文件指定（一般為４M）。LIBRADOS提供的庫可以訪問任意對象的內(nèi)容。RGW提供了一個基于Bucket的對象存儲服務(wù)。RGW提供的服務(wù)兼 容AWS(Amazon WebServices)的S3 以及Openstack的Swift。RGW的對象可大于４M，當其大小超過４M時，RGW會將該對象分為首對象和多個數(shù)據(jù)對象。

塊存儲接口提供類似磁盤的連續(xù)字節(jié)序列的存儲能力，這是存儲數(shù)據(jù)應(yīng)用最廣泛的形式。磁盤陣列、存儲區(qū)域網(wǎng)絡(luò)、iSCSI都可以提供塊存儲功能。Ceph的塊存儲利用 RADOS 功能,支持復(fù)制、快照、一致性和高可用等特性。塊設(shè)備是精 簡配置的，并且可調(diào)整大小。Ceph的RBD可使用內(nèi)核模塊或librbd與OSD進行交互。RBD設(shè)備默認在名為rbd的資源池中。每個rbd在創(chuàng)建后會生成一個 名為rbdName。

文件系統(tǒng)接口是通過 CephFS實現(xiàn)的。CephFS文件系 統(tǒng)中的數(shù)據(jù)(文件內(nèi)容)和元數(shù)據(jù)(目錄、文件)都以對象的形 式被保存在 OSD上?？蛻舳丝梢允褂胏eph fuse掛載為應(yīng)用 層模式或者使用內(nèi)核的mount ceph掛載為內(nèi)核模式。兩種模式都是與 MDS通信，以獲得文件系統(tǒng)的目錄結(jié)構(gòu)信息，并訪問對應(yīng)的OSD。CephFS的元數(shù)據(jù)也被保存在對象中，其對象的前綴為msd_，保存的內(nèi)容包括文件系統(tǒng)的索引節(jié)點、元數(shù)據(jù)日志和快照等。MDS在啟動時會讀取文件系統(tǒng)元數(shù)據(jù)對象并將其緩存在內(nèi)存中，客戶端需要與之通信以查詢 或更新元數(shù)據(jù)信息。

Ceph是一個通用的分布式文件系 統(tǒng),適 用 于 不 同 的 場 景.內(nèi)部機制的優(yōu)化對所有的場景都會產(chǎn)生性能的提升，但是優(yōu)化的難度和復(fù)雜度也最高。

在分布式存儲系統(tǒng)中，數(shù)據(jù)被分散在大量的存儲服務(wù)器上，大部分分布式存儲系統(tǒng)都直接使用本地文件系統(tǒng)來存儲 數(shù)據(jù)，如HDFS，Lustre等。 高性能、高可靠的分布式存儲系統(tǒng)離不開高效、一致、穩(wěn)定、可靠的本地文件系統(tǒng)。本地文件系統(tǒng)的代碼已經(jīng)過長時間的測試和性能優(yōu)化，對于數(shù)據(jù)持久化和空間管理也有相應(yīng)的方案。文件系統(tǒng)提供了 POSIX接口，通過這個接口，分布式文件系統(tǒng)可以切換不同的本地文件系統(tǒng)。

Ceph早期的版本采用將對象存儲在本地文件系統(tǒng)的存儲后端的方式，該方式被稱為 FileStore。FileStore通過POSIX接口將對象和對象屬性放在本地文件系統(tǒng)上，如 XFS、ext4、btrfs等。最初，對象屬性被存儲在POSIX擴展文件屬性(xattrs)中，但當后來對象屬性超出xattrs的大小或計數(shù)限制時，F(xiàn)ileStore就在LevelDB中存放對象屬性。本地文件系統(tǒng)不能很好地適配 Ceph的對象存儲需求的原因主要包括以下幾個方面。

１)數(shù)據(jù)和元數(shù)據(jù)分離不徹底，導(dǎo)致對象尋址慢。FileStore根據(jù)對象前綴將其放置在不同目錄下，對象在進行訪問時需要多次尋址，且同一目錄下的文件也沒有排序。

２)本地文件系統(tǒng)不支持對象的事務(wù)操作。FileStore為了支持寫事務(wù)的特性，通過寫前日志功能來保證事務(wù)的原子性。這導(dǎo)致了數(shù)據(jù)“雙寫”的問題，造成了一半磁盤性能的浪費。

３)本地文件系統(tǒng)也有日志等保證一致性的操作，這進一步導(dǎo)致了寫放大。

使用本地文件系統(tǒng)作為后端存儲的弊端導(dǎo)致了FileStore的性能很差。我們測試的結(jié)果表明，在三副本條件下的塊存儲服務(wù)寫性能甚至達不到硬盤自身性能的１/３。

針對 FileStore的缺陷，Ceph社區(qū)于2015年重新開發(fā)了BlueStore。兩種存儲后端的邏 輯結(jié)構(gòu)如圖所示。BlueStore通過直接管理裸設(shè)備，縮短了IO 路徑。Ceph社區(qū)設(shè)計了一個簡化的文件系統(tǒng) BlueFS，該文件系統(tǒng)繞過了本地文件系統(tǒng)層，解決了文件系統(tǒng)層次結(jié)構(gòu)遍歷效率低的問題。它通過使用KV索引來存儲元數(shù)據(jù)，嚴格分離元數(shù)據(jù)和數(shù)據(jù)，提高了索引效率。這些改進解決了日志“雙寫”的問題，帶來了較大的讀寫性能提升。

雖然BlueStore在設(shè)計時考慮了與SSD及 NVMeSSD閃 存的適配，但其對新硬件或混合存儲的支持不佳。除此之外，BlueStore的設(shè)計也存在一些問題，如數(shù)據(jù)和元數(shù)據(jù)被存儲在不同的位置，元數(shù)據(jù)結(jié)構(gòu)和IO邏輯都較復(fù)雜，在IO較小的情況下可能存在雙寫問題，同時元數(shù)據(jù)占用內(nèi)存較大。

閃存盤在寫入前需要將原有數(shù)據(jù)擦除?，F(xiàn)有的NVMe設(shè)備并未記錄哪些地址在寫入前需要被擦除，因此導(dǎo)致設(shè)備內(nèi)部的垃圾回收效率低下。原則上，異步的垃圾回收可以提高寫入效率，若不修改磁盤布局則垃圾回收的粒度較小，但 是實際上該操作在設(shè)備和中間層實現(xiàn)的效果并不佳。針對閃存盤的特點，Ceph社區(qū)提出了一種新的磁盤布局方式 SeaStore，該布局在較高層次的驅(qū)動上進行垃圾回收。其基本思想是將設(shè)備空間分為多個空閑段，每個段的大小為100MB 到10GB，所有數(shù)據(jù)順序地被流式傳輸?shù)皆O(shè)備的段上，在刪除數(shù)據(jù)時僅做標記不進行垃圾回收，當段中的利用率降低至某個利用率閾值時，會將其中的數(shù)據(jù)移到另一個段中。

10T 技術(shù)資源大放送！包括但不限于：Linux、虛擬化、容器、云計算、網(wǎng)絡(luò)、Python、Go 等。在開源Linux公眾號內(nèi)回復(fù) 10T，即可免費獲??！

清理工作和寫入工作混合在一起，以避免寫延遲的波動。當數(shù)據(jù)全部清理完成后就丟棄整個段，設(shè)備可以擦除和回收這個段。SeaStore主要應(yīng)用于NVMe設(shè)備，使用 SeaStore框架進行基于未來規(guī)劃模型的編程方式來實現(xiàn) run-to-completion模型，當其與SPDK 和 DPDK結(jié)合使用時，可以在網(wǎng)絡(luò)消息層實現(xiàn)讀寫路徑上的零(最小)拷貝。目前該 存儲引擎還在開發(fā)中，性能提升效果尚不明確。

國內(nèi)的深信服公司設(shè)計了一個基于 SPDK的用戶態(tài)本地存儲引擎——PFStore來滿足高性能分布式存儲的需求，對數(shù)據(jù)使用追加寫的方式,將元數(shù)據(jù)修改增量寫入日志，在后 期定時刷盤時再把數(shù)據(jù)寫入RocksDB中。另外，該引擎啟動多個實例來分別管理SSD的不同分區(qū)，啟動多個 OSD來提升性能的方法。

近幾年，隨著Openchannel SSD、３DXPoint、非易失內(nèi)存、 SMR等新型硬件的成熟和市場，出現(xiàn)了一些針對特定硬件的存儲后端優(yōu)化技術(shù)，我們將在下一次內(nèi)容中詳細介紹面向新型硬件的優(yōu)化技術(shù)。

作者：張 曉、張思蒙、石佳、董聰、李戰(zhàn)懷 

文章來源：架構(gòu)師技術(shù)聯(lián)盟

Linux學習指南
有收獲，點個在看