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

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

我們先簡單地聊聊分布式存儲中開源領域在適配新硬件的進展，而說到開源的分布式存儲，我們一定會想到明星開源項目 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 的設計做一個簡單解讀。

SeaStore 的設計目標

面向NVMe 設計，不考慮 PEME 和 HDD。

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

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

結合Seastar 的網(wǎng)絡消息層實現(xiàn)讀寫路徑上的零（最?。┛截悺?/p>

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

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

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

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

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

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

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

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

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

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

PFStore 設計與實現(xiàn)

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

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

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

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

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

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

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

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

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

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

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

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

與此同時，使得我們需要在 store 層實現(xiàn)空間回收（GC），而空間回收的設計對提升追加寫的存儲系統(tǒng)性能和穩(wě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 構成，通過數(shù)據(jù)的分層管理，能夠?qū)崿F(xiàn)在空間回收時將需要被回收的數(shù)據(jù)集中存放，這樣在執(zhí)行空間回收的過程搬動的數(shù)據(jù)量較少，在空間回收時對正常業(yè)務的性能影響較小。同時在執(zhí)行空間回收的過程中需要回寫的數(shù)據(jù)量較少，能夠有效的較低空間回收對 SSD 壽命的影響。

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

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

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

總結

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

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

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