簡(jiǎn)述分布式存儲(chǔ)中本地存儲(chǔ)引擎

最近幾年存儲(chǔ)介質(zhì)得到了高速發(fā)展，單位存儲(chǔ)介質(zhì)的性能越來越高，從原來的機(jī)械硬盤不足 100 IOPS 到現(xiàn)在的 NVMe SSD 一塊就能達(dá)到 50W IOPS，但與之形成反差的是 CPU 的速度提升并沒有那么多，根據(jù) Red Hat 的相關(guān)數(shù)據(jù)統(tǒng)計(jì)，存儲(chǔ)介質(zhì)由原來的單盤幾十 IOPS 到現(xiàn)在的單盤 50 萬 IOPS，但是 CPU 的主頻增長(zhǎng)的速度相對(duì)并沒有那么快，而不同的存儲(chǔ)介質(zhì)每個(gè) IO 需要的 CPU 時(shí)鐘周期也各不相同，如在 HDD 中一個(gè) IO 需要 2000 萬時(shí)鐘周期，在 NMVE 設(shè)備中只需要 6000 時(shí)鐘周期。

▲圖表及數(shù)據(jù)均來源于Red Hat

With a cpu clocked at 3ghz you can afford：

HDD： ~20 million cycles/IO

SSD： 300，000 cycles/IO

NVMe： 6000 cycles/IO

在這樣的背景下，對(duì)于存儲(chǔ)軟件來說能否發(fā)揮出存儲(chǔ)介質(zhì)的高性能，其關(guān)鍵是如何高效利用 CPU，其中，單核 CPU 能夠提供的 IOPS，是存儲(chǔ)系統(tǒng)的一個(gè)關(guān)鍵指標(biāo)。

而分布式存儲(chǔ)作為當(dāng)前存儲(chǔ)系統(tǒng)的一個(gè)重要分支，其軟件定義的特征，能夠更好更快地適配新硬件的發(fā)展，成為了存儲(chǔ)領(lǐng)域的熱點(diǎn)。

我們先簡(jiǎn)單地聊聊分布式存儲(chǔ)中開源領(lǐng)域在適配新硬件的進(jìn)展，而說到開源的分布式存儲(chǔ)，我們一定會(huì)想到明星開源項(xiàng)目 Ceph，它在國(guó)內(nèi)外都被廣泛使用，其良好的擴(kuò)展性和穩(wěn)定性也獲得大家一致認(rèn)可。

在 Ceph 的迭代發(fā)展中，其本地存儲(chǔ)引擎 ObjectStore 也經(jīng)過了兩代的發(fā)展，由最初的 FileStore，到現(xiàn)在廣泛使用的 BlueStore，但是這些存儲(chǔ)引擎對(duì)于高性能的存儲(chǔ)介質(zhì)（如 NVMe SSD 等）都存在一定的不足。

所以 Ceph 社區(qū)也在 2018 年提出了新一代本地存儲(chǔ)引擎 SeaStore，對(duì)細(xì)節(jié)感興趣的讀者可以訪問 https://docs.ceph.com/docs/master/dev/seastore/。

下面筆者根據(jù)個(gè)人的理解對(duì) SeaStore 的設(shè)計(jì)做一個(gè)簡(jiǎn)單解讀。

SeaStore 的設(shè)計(jì)目標(biāo)

面向NVMe 設(shè)計(jì)，不考慮 PEME 和 HDD。

使用SPDK 實(shí)現(xiàn)用戶態(tài) IO。

使用Seastar 框架進(jìn)行基于 future&promise 的編程方式實(shí)現(xiàn) run-to-completion。

結(jié)合Seastar 的網(wǎng)絡(luò)消息層實(shí)現(xiàn)讀寫路徑上的零（最小）拷貝。

對(duì)于目標(biāo) 1、2，面向 NVMe 的設(shè)計(jì)，筆者認(rèn)為主要是指當(dāng)前的 NVMe 設(shè)備是可以使用用戶態(tài)驅(qū)動(dòng)的，即可以不通過系統(tǒng)內(nèi)核，使用 Polling 模型能夠明顯降低 IO 延時(shí)。

同時(shí)對(duì)于 NVMe 設(shè)備來說，由于其 erase-before-write 特性帶來的 GC 問題需要被高效解決，理論上通過 discard 作為一種 hint 機(jī)制可以讓上層軟件啟發(fā)底層閃存去安排 GC，但實(shí)際上大部分閃存設(shè)備的 discard 實(shí)現(xiàn)的并不理想，因此需要上層軟件的介入。

對(duì)于目標(biāo) 3、4，是從如何降低 CPU 的角度去考慮底層存儲(chǔ)設(shè)計(jì)的，如上文中也提到對(duì)于高性能的分布式存儲(chǔ)，CPU 會(huì)成為系統(tǒng)瓶頸，如何提高 CPU 的有效使用率是一個(gè)重點(diǎn)考慮的問題。

目標(biāo) 3 中采用 run-to-completion 的方式能夠避免線程切換和鎖的開銷，從而有效提高 CPU 的使用率，Intel 曾經(jīng)發(fā)布報(bào)告說明，在 Block Size 為 4KB 的情況下，單線程利用 SPDK 能夠提供高達(dá) 1039 萬 IOPS，充分說明了使用單線程異步編程的方式能夠有效提升 CPU 的使用率。

而目標(biāo) 4 則需要充分結(jié)合網(wǎng)絡(luò)模型，一致性協(xié)議等，實(shí)現(xiàn)零拷貝，來降低在模塊中內(nèi)存拷貝次數(shù)。

基于 SeaStore 的設(shè)計(jì)目標(biāo)，具體的設(shè)計(jì)方案中主要考慮了通過 segment 的數(shù)據(jù)布局來實(shí)現(xiàn)的 NMVE 設(shè)備的 GC 優(yōu)化，以及上層如果控制 GC 時(shí)的相關(guān)處理，同時(shí)在文檔中也提到了用 B-tree 的方式實(shí)現(xiàn)元數(shù)據(jù)的存儲(chǔ)，而沒有采用類似 bluestore 中使用 RocksDB 來存儲(chǔ)元數(shù)據(jù)的方式。

但是筆者認(rèn)為，這個(gè)設(shè)計(jì)對(duì)于實(shí)現(xiàn)的難度可能比較高，當(dāng)前的 rados 不僅僅是存儲(chǔ)數(shù)據(jù)還有大量的元數(shù)據(jù)存儲(chǔ)的功能。如 OMAP 和 XATTR，這些小的 KV 信息實(shí)際如果采用新寫一個(gè) B-tree 的方式進(jìn)行存儲(chǔ)，那相當(dāng)于需要實(shí)現(xiàn)一個(gè)專有的小型 KV 數(shù)據(jù)庫(kù)，這個(gè)功能實(shí)現(xiàn)難度會(huì)非常大，而類似直接使用簡(jiǎn)單的 B-tree 存儲(chǔ)元數(shù)據(jù)就會(huì)落入類型 XFS 等文件系統(tǒng)存儲(chǔ)元數(shù)據(jù)的困境，不能存儲(chǔ)大量 xattr 的問題。

上文中只是簡(jiǎn)單的描述的 Ceph 對(duì)下一代存儲(chǔ)引擎的設(shè)計(jì)構(gòu)思，如果想等到具體的開源來實(shí)現(xiàn)估計(jì)還需要個(gè) 3 到 5 年的開發(fā)周期。

而我們對(duì)高性能分布式存儲(chǔ)的需求又非常熱切，所以深信服存儲(chǔ)團(tuán)隊(duì)就獨(dú)立設(shè)計(jì)了一個(gè)全新的存儲(chǔ)引擎來滿足高性能分布式存儲(chǔ)的需求。

下面我們簡(jiǎn)單介紹深信服企業(yè)級(jí)分布式存儲(chǔ) EDS 團(tuán)隊(duì)在高性能本地存儲(chǔ)的實(shí)踐之路。

PFStore 設(shè)計(jì)與實(shí)現(xiàn)

PFStore（Phoenix Fast Store）是 EDS 團(tuán)隊(duì)自研的基于 SPDK 的用戶態(tài)本地存儲(chǔ)引擎，它的核心架構(gòu)如下圖所示。

在系統(tǒng)中主要有數(shù)據(jù)管理和元數(shù)據(jù)管理兩大核心模塊，下面介紹一下兩大核心模塊的職責(zé)和技術(shù)特點(diǎn)：

數(shù)據(jù)管理模塊職責(zé)：

它是一個(gè) segment 空間管理的基礎(chǔ)單元，所有的數(shù)據(jù)都是以追加寫入的，即底層的 SSD 都是順序?qū)懭氲?，這樣能夠盡可能發(fā)揮每塊 SSD 的性能，降低 SSD 本身 GC 帶來的開銷。

同時(shí)整個(gè) store 的系統(tǒng)都是基于 SPDK 的中 spdk_thread 編程模型實(shí)現(xiàn)的，整個(gè) IO 過程全部在一個(gè)獨(dú)立線程中完成，所以不會(huì)有線程切換和鎖的開銷。

當(dāng)然全異步的編程方式會(huì)導(dǎo)致開發(fā)的難度比較高，所以我們研發(fā)內(nèi)部也提煉了一套基于狀態(tài)機(jī)的異步編程方式，在各個(gè)子系統(tǒng)都采用一個(gè)子狀態(tài)機(jī)，這樣既保證了系統(tǒng)的高性能，也保證了系統(tǒng)的可維護(hù)性和可擴(kuò)展性。

元數(shù)據(jù)管理模塊職責(zé)：

對(duì)于元數(shù)據(jù)的存儲(chǔ)，我們借鑒了 Ceph 中 BlueStore 的 Rocksdb 方式，也是采用一個(gè)簡(jiǎn)化的用戶態(tài)文件系統(tǒng) PLFS 來對(duì)接 Rocksdb。

而采用這樣的方式，也是因?yàn)槲覀冎攸c(diǎn)考查了 LSM 和 B-tree 的存儲(chǔ)結(jié)構(gòu)的不同及能夠帶來的收益，對(duì)于存儲(chǔ)引擎中頻繁的數(shù)據(jù)寫入，相對(duì)簡(jiǎn)潔的元數(shù)據(jù)管理（本地存儲(chǔ)引擎提供的對(duì)象存儲(chǔ)接口，元數(shù)據(jù)層次是平鋪的），采用 LSM 有利于提升系統(tǒng)寫性能。

下面分別介紹一下本地存儲(chǔ)引擎的技術(shù)特點(diǎn)。

元數(shù)據(jù)引擎技術(shù)特點(diǎn)：

使用自研 Journal，替換 RocksDB 的 WAL，這樣元數(shù)據(jù)的修改都是增量地寫入到 Journal 中，在后期定時(shí)刷盤時(shí)才寫入到 RocksDB 中。 這個(gè)改進(jìn)是基于下面幾點(diǎn)方面的原因： a） PLStore 是全異步的編程模型，而 RocksDB 的接口是同步的，會(huì)阻塞整個(gè) IO 路徑，性能比較差。 b） Journal 的數(shù)據(jù)是增量更新的，這樣能夠?qū)崿F(xiàn)聚合的方式寫入，降低元數(shù)據(jù)寫入次數(shù)。 c） Journal 不僅僅記錄了 Object 的元數(shù)據(jù)更新，還承載了分布式一致性協(xié)議中的 LOG 功能（類似 Ceph 中的 PGLOG），而多個(gè)功能融合能夠減少數(shù)據(jù)的寫入次數(shù)。

改進(jìn) RocksDB 的 compact 處理，在數(shù)據(jù)聚合時(shí)在內(nèi)存中建立一個(gè)基于 B-tree 的位置索引，這樣在 RocksDB 的數(shù)據(jù)讀取時(shí)，可以直接通過索引獲得數(shù)據(jù)的位置信息，然后利用位置信息直接通過異步的數(shù)據(jù)讀取口。 這樣就將原有的 RocksDB 同步讀接口改造成了異步，能夠明顯地提升單線程下的讀取能力，通過實(shí)測(cè)有 5-8 倍的提升。

數(shù)據(jù)存儲(chǔ)引擎技術(shù)特點(diǎn)：

對(duì)于數(shù)據(jù)使用追加寫的方式，更加有利于發(fā)揮每塊 SSD 性能，能夠?qū)崿F(xiàn)更加豐富的數(shù)據(jù)邏輯空間管理，為存儲(chǔ)的一些高級(jí)特性，如快照、克隆、壓縮重刪的實(shí)現(xiàn)提供基礎(chǔ)。

與此同時(shí)，使得我們需要在 store 層實(shí)現(xiàn)空間回收（GC），而空間回收的設(shè)計(jì)對(duì)提升追加寫的存儲(chǔ)系統(tǒng)性能和穩(wěn)定性至關(guān)重要。

在 PLStore 中我們使用數(shù)據(jù)分層管理的方式來減少在進(jìn)行空間回收時(shí)對(duì)底層 SSD 對(duì)性能和壽命的影響。

如上圖所示，我們將數(shù)據(jù)分為 3 個(gè)層次：

熱數(shù)據(jù) ，經(jīng)常被更新的數(shù)據(jù)，并且被集中存放在 SSD zone1 的數(shù)據(jù)區(qū)中

溫?cái)?shù)據(jù) ，被更新次數(shù)較少的數(shù)據(jù)，被集中存放在 SSD zone2 的數(shù)據(jù)區(qū)中

冷數(shù)據(jù) ，最少被更新的數(shù)據(jù)，被集中存放在 SSD zone3 的數(shù)據(jù)區(qū)中

其中 zone 由多個(gè) segment 構(gòu)成，通過數(shù)據(jù)的分層管理，能夠?qū)崿F(xiàn)在空間回收時(shí)將需要被回收的數(shù)據(jù)集中存放，這樣在執(zhí)行空間回收的過程搬動(dòng)的數(shù)據(jù)量較少，在空間回收時(shí)對(duì)正常業(yè)務(wù)的性能影響較小。同時(shí)在執(zhí)行空間回收的過程中需要回寫的數(shù)據(jù)量較少，能夠有效的較低空間回收對(duì) SSD 壽命的影響。

在進(jìn)行數(shù)據(jù)分區(qū)管理后，空間回收是以 segment 為執(zhí)行單位，可以通過靈活的空間回收的策略選擇代價(jià)較?。ㄐ枰釀?dòng)數(shù)據(jù)較少）的 segment 進(jìn)行空間回收，這種空間回收過程對(duì)上層業(yè)務(wù)的性能影響較小，而且配合 SSD 中 discard 指令，還能夠降低對(duì) SSD 的壽命的影響。

在空間回收的處理時(shí)，PFStore 同時(shí)會(huì)配合其 Qos 模塊，選擇合適的時(shí)機(jī)進(jìn)行空間回收，從各個(gè)方向降低對(duì)正常業(yè)務(wù)的影響，避免分布式系統(tǒng)中出現(xiàn)性能抖動(dòng)和“毛刺”。

PFStore 只在一個(gè)線程中運(yùn)行，采用 run-to-completion 的編程模型，這樣既簡(jiǎn)化了系統(tǒng)，也消除了系統(tǒng)的性能抖動(dòng)。但在實(shí)際中一個(gè) CPU 的 core 并不能完全發(fā)揮出一塊 NVMe SSD 的全部性能，所以我們?cè)谝粋€(gè)進(jìn)程中啟動(dòng)多個(gè)獨(dú)立線程，每個(gè)獨(dú)立線程綁定一個(gè) PFStore，而不同的 PFStore 分別管理不同的 SSD 的物理空間，如下圖所示。

總結(jié)

對(duì)于一個(gè)分布式系統(tǒng)而言，本地存儲(chǔ)引擎只是一個(gè)基礎(chǔ)組件，需要與其他模塊，如一致性協(xié)議，網(wǎng)絡(luò)傳輸?shù)饶K相互配合才能發(fā)揮其價(jià)值。Ceph 社區(qū)在 2018 年提出 Seastore 草案后，在 2019 年又重新提出了新的 OSD（Crimson）來滿足高性能應(yīng)用場(chǎng)景的需求。感興趣的同學(xué)可以閱讀 Crimson：A New Ceph OSD for the Age of Persistent Memory and Fast NVMe Storage 的相關(guān)內(nèi)容。

最近幾年存儲(chǔ)領(lǐng)域有著非常大的進(jìn)展，硬件領(lǐng)域中非易失性內(nèi)存、SCM 等技術(shù)的逐步成熟與落地，NVMe-OF 等協(xié)議逐漸被各個(gè)操作系統(tǒng)所支持，同時(shí)學(xué)術(shù)界也出現(xiàn)很多好的 Idea，這些都促進(jìn)了分布式存儲(chǔ)的軟件革新和高速發(fā)展。

深信服 EDS 團(tuán)隊(duì)未來的重點(diǎn)也將放在改進(jìn)軟件架構(gòu)來更好適配硬件，從而提升系統(tǒng)整體的性價(jià)比。