Ceph是分布式和強一致性的軟件定義存儲產(chǎn)品，隨著越來越多的企業(yè)和組織不斷加入，Ceph存儲系統(tǒng)穩(wěn)定性、可靠性和易管理性得到了很大的提升，在版本演進和迭代中，Ceph存儲的企業(yè)特性也得到了完善。如CephFS、iSCSI協(xié)議、InfiniBand網(wǎng)絡(luò)等特性，但今天筆者將帶領(lǐng)大家深入分析下Ceph***后端存儲BlueStore的架構(gòu)和ObjectStore歷史技術(shù)演進，因為存儲后端的架構(gòu)在一定程度上決定Ceph存儲系統(tǒng)的性能。SUSE也是在***Enterprise Storage 5版本中率先支持***的BlueStore后端存儲技術(shù)。

[[240689]]

BlueStore是Ceph存儲后端ObjectStore的***實現(xiàn)。在Ceph系統(tǒng)中，數(shù)據(jù)首先通過Hash算法分布到每個節(jié)點OSD上，最終由ObjectStore寫到磁盤上實現(xiàn)數(shù)據(jù)保存和持久化。那么，首先來看看ObjectStore架構(gòu)。

ObjectStore架構(gòu)介紹

Ceph后端支持多種存儲引擎，這些存儲后端模塊是以插件式的方式被管理，目前支持的實現(xiàn)方式包括Filestore(默認(rèn)存儲后端)，KeyValue Store、Memstore、NewStore和***的Bluestore。

從架構(gòu)上來看，ObjectStore封裝了下層存儲引擎的所有IO操作，并向上層提供對象(Object)、事務(wù)(Transaction)語義接口。在這里，MemStore是基于內(nèi)存的實現(xiàn)存儲接口功能;KeyValue Store主要基于KV數(shù)據(jù)庫(如LevelDB，RocksDB等)實現(xiàn)接口功能。

一直以來，F(xiàn)ileStore是Ceph目前默認(rèn)的ObjectStore后端存儲引擎(仍然是其他Ceph存儲的默認(rèn)后端)，F(xiàn)ileStore基于Journal機制實現(xiàn)了事務(wù)處理能力，除了支持事務(wù)特性(consistency、atomic等)以外，Journal還可將多個小IO寫合并為順序?qū)慗ournal來提升系統(tǒng)性能。

ObjectStore接口主要包括三個部分，***部分是Object的讀寫操作，類似于POSIX的部分接口;第二部分是Object的屬性(xattr)讀寫操作，這類操作是KV操作，它與某一個Object關(guān)聯(lián);第三部分是關(guān)聯(lián)Object的KV操作(在Ceph中稱為omap)。

ObjectStore后端存儲引擎之FileStore

FileStore是利用文件系統(tǒng)的Posix接口實現(xiàn)ObjectStore API。每個Object在FileStore層會被看成是一個文件，Object的屬性(xattr)會利用文件的xattr屬性進行存取，由于有些文件系統(tǒng)(如ext4)對xattr的長度有限制，因此，在FileStore中，超出長度限制的Metadata會被存儲在DBObjectMap里。而Object的KV關(guān)系則直接利用DBObjectMap功能實現(xiàn)。

但是FileStore存在一些問題，例如Journal機制使一次寫請求在OSD端往下寫時，變?yōu)閮纱螌懖僮?同步寫Journal，異步寫入Object);當(dāng)然，可以通過SSD實現(xiàn)Journal可緩解Journal和object寫操作的性能影響;寫入的每個Object都對應(yīng)OSD本地文件系統(tǒng)的一個物理文件，對于大量小Object存儲場景來說，OSD端無法緩存本地所有文件的元數(shù)據(jù)，這使讀寫操作可能需要多次本地IO操作，系統(tǒng)性能差等。

ObjectStore后端存儲引擎之NewStore

為了解決上述FileStore的問題，Ceph引入了新的存儲引擎NewStore(又被稱為KeyFile Store)，其關(guān)鍵結(jié)構(gòu)如下圖所示：

NewStore解耦Object與本地物理文件間的一一對應(yīng)關(guān)系，通過索引結(jié)構(gòu)(上圖中ONode)在Object和本地物理文件建立映射關(guān)系，并使用KV數(shù)據(jù)庫存儲索引數(shù)據(jù);在保證事務(wù)特性的同時，對于Object的操作無需Journal支持;在KV數(shù)據(jù)庫上層建立Onode數(shù)據(jù)cache以加速讀取操作;單個Object可以有多個fragement文件，多個Object也可共存于一個fragement文件，更加靈活。

ObjectStore后端存儲引擎之BlueStore

NewStore使用RocksDB存儲Ceph日志，同時Ceph的真正數(shù)據(jù)對象存儲在文件系統(tǒng)中。如今有了BlueStore技術(shù)，數(shù)據(jù)對象可以無需任何文件系統(tǒng)的接口支持，而是直操作存儲在物理磁盤設(shè)備上的數(shù)據(jù)。

BlueStore初衷就是為了減少寫放大，并針對SSD做優(yōu)化，直接管理裸盤(物理磁盤設(shè)備)，從理論上來講，進一步規(guī)避了如ext4、xfs等文件系統(tǒng)部分的開銷，BlueStore是一個全新的 OSD存儲后端，通過塊設(shè)備提升存儲性能。Bluestore整體架構(gòu)如下。

BlueStore直接管理裸設(shè)備，拋棄了本地文件系統(tǒng)，BlockDevice實現(xiàn)在用戶態(tài)下直接對裸設(shè)備進行I/O操作。既然是直接管理裸設(shè)備就必然需要進行裸設(shè)備的空間管理，對應(yīng)的就是Allocator，目前支持Stupid Allocator和Bitmap Allocator兩種分配器。

相關(guān)的元數(shù)據(jù)以KV的形式保存到KV數(shù)據(jù)庫里，默認(rèn)使用的是RocksDB，RocksDB本身雖然是基于文件系統(tǒng)，不能直接操作裸設(shè)備，但是RocksDB可將系統(tǒng)相關(guān)的處理抽象成Env，用戶可用實現(xiàn)相應(yīng)的接口來操作。

RocksDB默認(rèn)的Env是PosixEnv，直接對接本地文件系統(tǒng)。為此Bluestore實現(xiàn)了一個BlueRocksEnv來為RocksDB提供底層系統(tǒng)的封裝，實現(xiàn)了一個小的文件系統(tǒng)BlueFS對接BlueRocksEnv，在系統(tǒng)啟動掛載這個文件系統(tǒng)的時候，將所有的元數(shù)據(jù)都加載到內(nèi)存中，BluesFS的數(shù)據(jù)和日志文件都通過BlockDevice保存到裸設(shè)備上，BlueFS和BlueStore可以共享裸設(shè)備，也可以分別指定不同的設(shè)備。

當(dāng)BlueFS和BlueStore共享設(shè)備時，裸設(shè)備通常被分為兩部分:

設(shè)備的一部分為BlueFS的小分區(qū)，它實現(xiàn)了RocksDB所需的類似文件系統(tǒng)的功能。

設(shè)備的其余部分通常是占據(jù)設(shè)備其余部分的大分區(qū)。它由BlueStore直接管理，包含所有實際數(shù)據(jù)。

在Filestore存儲引擎里，對象的表現(xiàn)形式是對應(yīng)到文件系統(tǒng)里的文件，默認(rèn)4MB大小的文件，但是在目前***的ObjectStore實現(xiàn)——Bluestore里，已經(jīng)沒有傳統(tǒng)的文件系統(tǒng)，而是自己管理裸盤，要求管理對象Onode需要常駐內(nèi)存的數(shù)據(jù)結(jié)構(gòu)中，持久化的時候會以KV的形式存到RocksDB里。

總結(jié)一下，從SUSE Enterprise storage 5存儲版本開始，BlueStore成為Ceph的一個新的存儲后端，它的性能優(yōu)于FileStore，并提供完整的數(shù)據(jù)檢驗和和內(nèi)置壓縮能力。

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

然而，NewStore存儲后端技術(shù) 解耦Object與本地物理文件間的對應(yīng)關(guān)系，通過KV數(shù)據(jù)庫、索引技術(shù)優(yōu)化日志操作。

B lueStore可使 數(shù)據(jù)對象無需任何文件系統(tǒng)的接口，就可以直接存儲在物理塊設(shè)備上，所以，B lueStore可以 極大的提升Ceph存儲系統(tǒng)性能。