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

▲圖表及數(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

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

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

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

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

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

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

SeaStore 的設(shè)計目標

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

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

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

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

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

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

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

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

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

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

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

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

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

下面我們簡單介紹深信服企業(yè)級分布式存儲 EDS 團隊在高性能本地存儲的實踐之路。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

數(shù)據(jù)存儲引擎技術(shù)特點：

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

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

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

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

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

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

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

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

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

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

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

總結(jié)

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

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

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