論開源分布式存儲(chǔ)，Ceph大名鼎鼎。用同一個(gè)存儲(chǔ)池融合提供塊存儲(chǔ)、對象存儲(chǔ)、集群文件系統(tǒng)。在國內(nèi)有近年使用量迅速攀升，Ceph Day峰會(huì)也搬到北京來開了。

大型公司內(nèi)部研發(fā)云虛擬化平臺(tái)，常使用開源方案Openstack或者Kubernetes，配套的為虛機(jī)或容器提供塊存儲(chǔ)的開源方案，幾乎為Ceph莫屬。對象存儲(chǔ)幾年發(fā)展迅速，圖像、視頻、網(wǎng)站資源等皆可適用，有初創(chuàng)公司基于Ceph搭建存儲(chǔ)服務(wù)方案。企業(yè)存儲(chǔ)方面，國外有Redhat收購了Inktank，后者由Ceph初創(chuàng)作者Sage Weil創(chuàng)建；國內(nèi)有XSky星辰天合，聚集了大量從早期就開始專注Ceph的專家。（P.S.關(guān)于國內(nèi)誰在大規(guī)模使用Ceph，上Ceph Day看Slides可以知道。）

可以將Ceph理解為分布式管理層，加上每個(gè)存儲(chǔ)節(jié)點(diǎn)（OSD）的存儲(chǔ)后端。社區(qū)成熟的存儲(chǔ)后端使用FileStore，用戶數(shù)據(jù)被映射成對象，以文件的形式存儲(chǔ)在文件系統(tǒng)上。文件系統(tǒng)可以是EXT4、BtrFS、XFS等。最近兩年，因?yàn)镕ileStore的種種問題，由Sage Wei推動(dòng)，Ceph社區(qū)合力推出了新的存儲(chǔ)后端，BlueStore。

BlueStore有獨(dú)特的架構(gòu)，解決了Ceph社區(qū)一直煩惱的FileStore的日志雙寫問題，測試性能比FileStore提高了一倍。這讓人非常想深入剖析BlueStore。另一方面，公有云內(nèi)部開發(fā)的存儲(chǔ)系統(tǒng)也如同Ceph，歷久年月不斷翻新；像Ceph社區(qū)這樣，能夠提出全新架構(gòu)，把性能提升一倍，是非常值得借鑒的。

關(guān)于Ceph BlueStore的資料

CDM（Ceph Developer Monthly）是Ceph開發(fā)者之間的分享會(huì)議，技術(shù)細(xì)節(jié)原汁原味。下面的視頻非常全面地覆蓋了Ceph BlueStore的動(dòng)機(jī)、設(shè)計(jì)、工作流程、未來發(fā)展等等。Slides鏈接如下，但許多內(nèi)容只在視頻中（雖然視頻2016但Slides是2017，但內(nèi)容大體一致）。本文使用了其中的不少插圖。（P.S.經(jīng)過兩年的開發(fā)，如今BlueStore成果顯著；相比應(yīng)用開發(fā)，也可看出底層存儲(chǔ)開發(fā)周期之慢…）

[2016-JUN-21 -- Ceph Tech Talks: Bluestore – YouTube]

[BlueStore, A New Storage Backend for Ceph, One Year In]

System Notes博客發(fā)布了多篇非常深入的Ceph BlueStore解析，甚至也是國內(nèi)最早的。本文也直接使用了其中的插圖。下面的鏈接是其中一篇

[System Notes: ceph存儲(chǔ)引擎bluestore解析]

筆記社區(qū)WuXiangWei的文章有多篇非常深入的Ceph BlueStore剖析。例如BlueFS設(shè)計(jì)、對象到磁盤的映射等。本文也使用其中的插圖。下面的鏈接是其中的一篇

[WuXiangWei：Ceph BlueFS分析]

關(guān)于Ceph BlueStore以及其它幾種存儲(chǔ)后端的寫行為和寫放大的深入解析，有一篇論文。論文中有對各種后端的寫路徑和相關(guān)特性的詳細(xì)描述。

[Understanding Write Behaviors of Storage Backends in CephObject Store]

關(guān)于Ceph的寫路徑，最全面的資料在它的開發(fā)文檔里。其中列舉了BlueStore應(yīng)對不同類型寫入所采取的策略，結(jié)合前述Slides看更加容清楚。

[BlueStore Internals]

為什么需要BlueStore

在上文的CDM的BlueStore介紹中詳細(xì)解釋，歸結(jié)起來，主要有這些方面：

首先，Ceph原本的FileStore需要兼容Linux下的各種文件系統(tǒng)，如EXT4、BtrFS、XFS。理論上每種文件系統(tǒng)都實(shí)現(xiàn)了POSIX協(xié)議，但事實(shí)上，每個(gè)文件系統(tǒng)都有一點(diǎn)“不那么標(biāo)準(zhǔn)”的地方。Ceph的實(shí)現(xiàn)非常注重可靠性，因而需要為每種文件系統(tǒng)引入不同的Walkaround或者Hack；例如Rename不冪等性，等等。這些工作為Ceph的不斷開發(fā)帶來了很大負(fù)擔(dān)。

其次，FileStore構(gòu)建與Linux文件系統(tǒng)之上。POSIX提供了非常強(qiáng)大的功能，但大部分并不是Ceph真正需要的；這些功能成了性能的累贅。另一方面，文件系統(tǒng)的某些功能實(shí)現(xiàn)對Ceph并不友好，例如對目錄遍歷順序的要求，等等。

另一方面，是Ceph日志的雙寫問題。為了保證覆寫中途斷電能夠恢復(fù)，以及為了實(shí)現(xiàn)單OSD內(nèi)的事物支持，在FileStore的寫路徑中，Ceph首先把數(shù)據(jù)和元數(shù)據(jù)修改寫入日志，日志完后后，再把數(shù)據(jù)寫入實(shí)際落盤位置。這種日志方法（WAL）是數(shù)據(jù)庫和文件系統(tǒng)標(biāo)準(zhǔn)的保證ACID的方法，但用在Ceph這里，帶來了問題：

1）數(shù)據(jù)被寫了兩遍，即日志雙寫問題，這意味著Ceph犧牲了一半的磁盤吞吐量。

2）Journaling of Journal問題，這個(gè)在上述Write Behaviors論文中有講。Ceph的FileStore做了一遍日志，而Linux文件系統(tǒng)自身也有日志機(jī)制，實(shí)際上日志被多做了一遍。

3）對于新型的LSM-Tree類存儲(chǔ)，如RocksDB、LevelDB，由于數(shù)據(jù)本身就按照日志形式組織，實(shí)際上沒有再另加一個(gè)單獨(dú)的WAL的必要。

4）更好地發(fā)揮SSD/NVM存儲(chǔ)介質(zhì)的性能。與磁盤不同，基于Flash的存儲(chǔ)有更高的并行能力，需要加以利用。CPU處理速度逐漸更不上存儲(chǔ)，因而需要更好地利用多核并行。存儲(chǔ)中大量使用的隊(duì)列等，容易引發(fā)并發(fā)競爭耗時(shí)，也需要優(yōu)化。另一方面，RocksDB對SSD等有良好支持，它為BlueStore所采用。

另外，社區(qū)曾經(jīng)為了FileStore的問題，提出用LevelDB作存儲(chǔ)后端；對象存儲(chǔ)轉(zhuǎn)換為KeyValue存儲(chǔ)，而不是轉(zhuǎn)換問文件。后來，LevelDB存儲(chǔ)沒有被推廣開，主流還是使用FileStore。但KeyValue的思路被沿用下來，BlueStore就是使用RocksDB來存儲(chǔ)元數(shù)據(jù)的。

展望未來，ScanDisk開源的ZetaScale存儲(chǔ)能夠更加出色地發(fā)揮SSD/NVM/PersistentMemory的性能。它有智能內(nèi)存緩存、最大化并發(fā)和減小響應(yīng)時(shí)間、支持原子操作/快照/事務(wù)，等等特色。Ceph可能將它作為新的存儲(chǔ)后端，或者替換掉BlueStore中的RocksDB；當(dāng)然也可以等RocksDB發(fā)展得更好。（P.S.其實(shí)大半年前已經(jīng)開始做了。）

BlueStore的架構(gòu)

BlueStore的出發(fā)點(diǎn)其實(shí)應(yīng)驗(yàn)了這樣的哲學(xué)，存儲(chǔ)的最常用寫路徑應(yīng)該盡量地短、盡量地簡單，這樣才能有最好的性能，盡管另外的異常處理路徑可能是非常復(fù)雜的。BlueStore的設(shè)計(jì)有如下特色

1）Ceph并不需要POSIX文件系統(tǒng)。拋棄它，實(shí)現(xiàn)一個(gè)盡量簡單的文件系統(tǒng)，專門給RocksDB使用。這個(gè)文件系統(tǒng)叫作BlueFS。

2）元數(shù)據(jù)存儲(chǔ)在RocksDB中，用KeyValue的方式正合適。而數(shù)據(jù)不需要文件系統(tǒng)，直接存儲(chǔ)在裸塊設(shè)備上即可。我們在塊設(shè)備上需要的，其實(shí)是一個(gè)空間分配器（Allocator）。

?

查看BlueStore的代碼，相比FileStore小了很多。Allocator是可插拔更換策略的，大約3000行代碼。BlueFS本就是極簡的文件系統(tǒng)，約3000行代碼。事務(wù)的實(shí)現(xiàn)借用RocksDB對事務(wù)的支持，簡化很多。而且沒有自己實(shí)現(xiàn)日志的需要了，剩下了FileStore中的Journal一塊。

還有一點(diǎn)，如上圖所示，BlueStore中不同組件可以使用不同的塊設(shè)備。例如給RocksDB的WAL文件配備NVRAM，給SST文件配備SSD，給數(shù)據(jù)文件配備磁盤；方案是靈活的。

BlueStore的元數(shù)據(jù)管理

在涉及寫路徑之前，先看看Ceph BlueStore如何管理元數(shù)據(jù)。首先的問題是，對象如何映射成磁盤數(shù)據(jù)結(jié)構(gòu)（Ceph的底層是對象存儲(chǔ)，向上封裝出塊存儲(chǔ)、文件系統(tǒng)）？

Onode代表對象，名字大概是從Linux VFS的Inode沿襲過來的。Onode常駐內(nèi)存，在RocksDB中以KeyValue形式持久化；關(guān)于內(nèi)存Cache的結(jié)構(gòu)，在CDM的Slides中有講。Onode包含多個(gè)lextent，即邏輯extent。Blob通過映射pextent、即物理extent，映射到磁盤上的物理區(qū)域。Blob通常包括來自同一個(gè)對象的多段數(shù)據(jù)，但是也可能被其它對象引用。Bnode是對象快照后，被用于多個(gè)對象共享數(shù)據(jù)的。

?

上面僅是關(guān)于對象映射的。更進(jìn)一步，RocksDB中存儲(chǔ)有許多類型的元數(shù)據(jù)，包括塊分配、對象集合、快照、延遲寫（Deferred Writes）、對象屬性（Omap，即一個(gè)對象上可以附加一些KeyValue對作為屬性，例如給圖片加上地點(diǎn)、日期等），等等。在CDM的Slides中有詳述。

?

BlueStore的寫路徑

寫路徑包含了對事務(wù)的處理，也回答了BlueStore如何解決日志雙寫問題。

首先，Ceph的事務(wù)只工作于單個(gè)OSD內(nèi)，能夠保證多個(gè)對象操作被ACID地執(zhí)行，主要是用于實(shí)現(xiàn)自身的高級功能。每個(gè)PG（Placement Group，類似Dynamo的vnode，將hash映射到同一個(gè)組內(nèi)的對象組到一起）內(nèi)有一個(gè)OpSequencer，通過它保證PG內(nèi)的操作按序執(zhí)行。事務(wù)需要處理的寫分三種：

1）寫到新分配的區(qū)域?？紤]ACID，因?yàn)榇藢懖桓采w已有數(shù)據(jù)，即使中途斷電，因?yàn)镽ocksDB中的元數(shù)據(jù)沒有更新，不用擔(dān)心ACID語義被破壞。后文可見RocksDB的元數(shù)據(jù)更新是在數(shù)據(jù)寫之后做的。因而，日志是不需要的。在數(shù)據(jù)寫完之后，元數(shù)據(jù)更新寫入RocksDB；RocksDB本身支持事務(wù)，元數(shù)據(jù)更新作為RocksDB的事務(wù)提交即可。

2）寫到Blob中的新位置。同理，日志是不需要的。

3）Deferred Writes（延遲寫），只用于覆寫（Overwrite）情況。從上面也可以看到，只有覆寫需要考慮日志問題。如果新寫比塊大小（min_alloc_size）更小，那么會(huì)將其數(shù)據(jù)與元數(shù)據(jù)合并寫入到RocksDB中，之后異步地把數(shù)據(jù)搬到實(shí)際落盤位置；這就是日志了。如果新寫比塊大小更大，那么分割它，整塊的部分寫入新分配塊中，即按（1）處理，；不足的部分按（3）中上種情況處理。

?

上述基本概述了BlueStore的寫處理。可以看到其是如何解決FileStore的日志雙寫問題的。首先，沒有Linux文件系統(tǒng)了，也就沒有了多余的Journaling of Journal問題。然后，大部分寫是寫到新位置的，而不是覆寫，因此不需要對它們使用日志；寫仍然發(fā)生了兩次，第一次是數(shù)據(jù)落盤，然后是RocksDB事務(wù)提交，但不再需要在日志中包含數(shù)據(jù)了。最后，小的覆寫合并到日志中提交，一次寫完即可返回用戶，之后異步地把數(shù)據(jù)搬到實(shí)際位置（小數(shù)據(jù)合并到日志是個(gè)常用技巧）；大的覆寫被分割，整塊部分用Append-only方式處理，也繞開了日志的需要。至此，成為一個(gè)自然而正常的處理方式。（P.S.總之，個(gè)人感覺日志雙寫不是一個(gè)該存在的問題，不知為何成了一個(gè)問題，好在今天終于不是問題了。）

更深入地，Ceph的開發(fā)文檔中列出了所有的寫策略處理方式?？梢钥吹絀nline Compression也是BlueStore的功能點(diǎn)之一；其中也有對Partial-write問題的處理。

?

CDM的Slides中有BlueStore寫的狀態(tài)機(jī)圖。狀態(tài)機(jī)是存儲(chǔ)中常用的處理方式，處理寫路徑，Ceph的PG Peering過程也有相應(yīng)的狀態(tài)機(jī)。數(shù)據(jù)落盤，對應(yīng)的是PREPARE->AIO_WAIT間的“Initiate some AIO”一步。之后經(jīng)過多個(gè)隊(duì)列，向RocksDB提交事務(wù)，以及完成Deferred Write和Cleanup。直到最終完成。

?

另外，BlueStore使用Direct IO提交數(shù)據(jù)，這樣數(shù)據(jù)會(huì)立即落盤，而不是在內(nèi)核中緩存；從而，存儲(chǔ)系統(tǒng)可以完全自主地控制寫的持久化。這是一個(gè)如今常見的做法。但代價(jià)是，不能利用內(nèi)核緩存，需要自己處理緩存問題；也必須處理好數(shù)據(jù)對齊，以及寫小于一扇區(qū)時(shí)的Partial-write問題。

BlueFS的架構(gòu)

BlueFS以盡量簡單為目的設(shè)計(jì)，專門用于支持RocksDB；RocksDB總之還是需要一個(gè)文件系統(tǒng)來工作的。BlueFS不支持POSIX接口。總的來說，它有這些特點(diǎn)：

1）目錄結(jié)構(gòu)方面，BlueFS只有扁平的目錄結(jié)構(gòu)，沒有樹形層次關(guān)系；用于放置RocksDB的db.wal/，db/，db.slow/文件。這些文件可以被掛載到不同的硬盤上，例如db.wal/放在NVMRAM上；db/包含熱SST數(shù)據(jù)，放在SSD上；db.slow/放在磁盤上。

2）數(shù)據(jù)寫入方面，BlueFS不支持覆寫，只支持追加（Append-only）。塊分配粒度較粗，越1MB。有垃圾回收機(jī)制定期處理被浪費(fèi)掉的空間。

3）對元數(shù)據(jù)的操作記錄到日志，每次掛載時(shí)重放日志，來獲得當(dāng)前的元數(shù)據(jù)。元數(shù)據(jù)生存在內(nèi)存中，并沒有持久化在磁盤上，不需要存儲(chǔ)諸如空閑塊鏈表之類的。當(dāng)日志過大時(shí)，會(huì)進(jìn)行重寫Compact。

下圖見于CDM的Slides，顯示了BlueFS在磁盤上的數(shù)據(jù)結(jié)構(gòu)。Superblock用于存儲(chǔ)整個(gè)文件系統(tǒng)級別的元數(shù)據(jù)，日志和數(shù)據(jù)本著盡量簡單的設(shè)計(jì)，按照追加的方式不斷寫入。關(guān)于寫放大的問題，這是Append-only式通有的，在Write Behaviors論文中有詳述。

BlueStore的性能

如果問為什么BlueStore相比FileStore能夠提高越一倍的吞吐量，可能在于其更加簡單、更加短的寫路徑；解決了雙寫問題，大部分?jǐn)?shù)據(jù)不再需要在日志中多寫一遍；借用RocksDB處理元數(shù)據(jù)，后者實(shí)現(xiàn)成熟，對SSD優(yōu)化良好。

?

更重要的，和Ceph類似，公有云內(nèi)部開發(fā)的存儲(chǔ)系統(tǒng)也歷久年月不斷翻新；像Ceph社區(qū)這樣，能夠提出全新架構(gòu)，把性能提升一倍，是非常值得借鑒的。

總結(jié)

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

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