王海濤 李戰(zhàn)懷 張 曉* 趙曉南
1(西北工業(yè)大學計算機學院 西安 710129)
2(西北工業(yè)大學大數(shù)據(jù)存儲與管理工業(yè)和信息化部重點實驗室 西安 710129)
3(空天地海一體化大數(shù)據(jù)應用技術國家工程實驗室 西安 710072)
目前,大數(shù)據(jù)及其分析成為了科學研究和商業(yè)運行的核心[1-5]。然而,在過去十年,互聯(lián)網平均每秒產生的數(shù)據(jù)量超過 30 TB,且增長速度持續(xù)加快[6-7],這對大數(shù)據(jù)存儲系統(tǒng)造成了巨大的壓力。為了應對該挑戰(zhàn),分布式存儲系統(tǒng)將數(shù)據(jù)平均分布在多個節(jié)點上,利用并行的數(shù)據(jù)訪問,擴展存儲系統(tǒng)的容量及性能,但數(shù)據(jù)訪問量的持續(xù)增加仍導致存儲系統(tǒng)的性能壓力越來越大。為了進一步提升分布式存儲系統(tǒng)的性能,需要減小節(jié)點間的數(shù)據(jù)傳輸開銷,提高節(jié)點上的數(shù)據(jù)存儲性能。隨著高速網絡在存儲集群中的應用,數(shù)據(jù)傳輸開銷可大幅降低,因此,提高節(jié)點上的數(shù)據(jù)存儲性能成為關鍵。
分布式存儲系統(tǒng)一般基于通用文件系統(tǒng)(如Ext4)構建存儲引擎,負責節(jié)點上的數(shù)據(jù)存儲與管理,其優(yōu)勢是能夠節(jié)約開發(fā)成本,保持較強的通用性。為了保證數(shù)據(jù)一致性,存儲引擎在進行寫入操作時,需要先將數(shù)據(jù)寫入預寫日志(Write Ahead Log,WAL)文件,并將其持久化到存儲設備層,然后再將數(shù)據(jù)更新到目標文件中。而本地文件系統(tǒng)也會利用自身的日志機制保證數(shù)據(jù)一致性,因此造成了雙重日志(Journaling of Journal)[8]的問題,引起了數(shù)據(jù)寫放大,進而降低了系統(tǒng)的寫性能。
高性能非易失性存儲器(No n-Volatile Memory,NVM)的出現(xiàn)為存儲引擎的性能優(yōu)化提供了新的機會。NVM 也被稱為存儲級內存(Storage Class Memory,SCM)或持久性內存(Persistent Memory,PM),其具有類似動態(tài)隨機存取存儲器(Dynamic Random Access Memory,DRAM)的字節(jié)尋址能力與類似閃存的數(shù)據(jù)持久性,有望彌合計算機內外存之間的性能鴻溝[9-11]。近年來,工業(yè)界和學術界對多種 NVM 進行研究,包括相變存儲器(Phase Change Memory,PCM)、磁性隨機訪問存儲器(Magnetic Random Access Memory,MRAM)、自旋傳遞扭矩MRAM(Spin Transfer Torque MRAM,STTMRAM)和電阻隨機訪問存儲器(Resistive Random Access Memory,ReRAM)等[12]。由于NVM 具有極大地提升存儲系統(tǒng)性能的潛力,因此目前有大量工作研究如何在現(xiàn)有系統(tǒng)中利用NVM 進行性能優(yōu)化,如結合 NVM 特性優(yōu)化傳統(tǒng)索引結構[13],提升物聯(lián)網終端設備的存儲性能[14];作為分布式文件系統(tǒng)的緩存擴展[15],以及配合 DRAM 和固態(tài)硬盤(Solid State Disk,SSD)構建混合存儲架構,優(yōu)化系統(tǒng)整體性能[16-18]。
在不改變現(xiàn)有系統(tǒng)的前提下,可將存儲引擎底層的存儲設備替換為 NVM,從而提高系統(tǒng)的讀寫性能。但是,對于分布式存儲系統(tǒng)而言,上層應用的數(shù)據(jù)需要經過元數(shù)據(jù)查詢、數(shù)據(jù)分發(fā)以及存儲引擎的處理才能持久化到底層存儲設備,這些軟件層次構成了系統(tǒng)整體的 I/O 軟件棧。然而,當上層數(shù)據(jù)到達存儲引擎后,需要先在存儲引擎的緩存中進行處理,然后通過文件系統(tǒng)以及塊設備接口層等軟件棧逐層傳輸和處理,最后才能到達存儲設備。數(shù)據(jù)在上述 I/O 路徑上的傳輸和處理會增加延遲,本文稱其為 I/O 軟件棧開銷。在傳統(tǒng)存儲引擎中,除 I/O 軟件棧開銷外,I/O 路徑中的數(shù)據(jù)寫放大也會限制 NVM 設備的性能發(fā)揮,因此,簡單地替換底層存儲設備并不能有效提高系統(tǒng)存儲性能。如被業(yè)界廣泛使用的大數(shù)據(jù)存儲系統(tǒng) Ceph,其存儲引擎的 I/O 軟件棧較長,且寫入流程會造成較為嚴重的數(shù)據(jù)寫放大[19-20],這會進一步增加寫操作延遲,限制存儲性能的擴展。
針對上述問題,本文以 Ceph 為平臺,對存儲引擎的主要性能問題進行分析,并提出了一種基于 NVM 的新型存儲引擎 NVMStore。NVMStore 的主要創(chuàng)新點是利用 NVM 的字節(jié)可尋址與數(shù)據(jù)持久性,通過內存直接訪問的方式讀寫 NVM 設備,并對數(shù)據(jù)讀寫流程進行改進,避免了數(shù)據(jù)在緩存中的拷貝以及小塊數(shù)據(jù)更新造成的“讀-改-寫”操作,減小了 I/O 軟件棧開銷,從而提升了存儲性能。
目前,Ceph 官方提供了 FileStore 和BlueStore 兩種成熟的存儲引擎,以及正在開發(fā)的一種新存儲引擎 SeaStore,該引擎主要面向高速的 SSD 設備以及高速網絡,尚未正式發(fā)布?,F(xiàn)有關于 Ceph 的研究工作主要是在特定場景下的集群配置參數(shù)優(yōu)化,使用 SSD 等快速存儲設備來提高集群性能[21],優(yōu)化集群的分布式鎖管理機制[22]以及故障恢復流程[23],或基于開放通道 SSD 的特性設計新型存儲引擎以提升存儲性能[24],但是尚未出現(xiàn)基于 NVM 的 Ceph 存儲引擎。對于 Ceph 存儲引擎的性能問題,相關文獻已進行較為充分的研究[19,24],本節(jié)在此基礎上作簡要分析。
對于 Ceph 的 FileStore,每次數(shù)據(jù)寫操作會轉換為一次寫日志和一次寫對象,因此,實際向磁盤寫入的數(shù)據(jù)量至少為用戶寫入數(shù)據(jù)的兩倍。加之對象數(shù)據(jù)更新引起的底層文件系統(tǒng)更新,會使實際的寫放大更嚴重,從而造成大幅度的性能退化。此外,F(xiàn)ileStore 的日志機制基于本地文件系統(tǒng)實現(xiàn),然而,本地文件系統(tǒng)也具有日志機制,這兩層日志功能存在一定程度的重合,加劇了數(shù)據(jù)寫放大。在這種情況下,F(xiàn)ileStore的數(shù)據(jù)寫放大(即實際寫入底層存儲設備的數(shù)據(jù)量與用戶寫入操作原始數(shù)據(jù)量之間的比值)可達 14.56,導致了嚴重的性能退化[19]。BlueStore可有效減小數(shù)據(jù)寫放大,在很大程度上解決FileStore 的雙重日志問題,因而成為 Ceph 的默認存儲引擎,70% 的用戶選擇在生產環(huán)境中使用BlueStore[20]。
如圖 1 所示,在用戶態(tài)下,BlueStore 使用Linux 異步 I/O 機制直接操作塊設備,避免了通用文件系統(tǒng)的復雜軟件棧帶來的延遲,利用鍵值存儲系統(tǒng) RocksDB 管理元數(shù)據(jù)和小塊數(shù)據(jù),并使用一個簡化的用戶態(tài)文件系統(tǒng) BlueFS 管理RocksDB 的數(shù)據(jù)。BlueFS 使用 Linux 直接 I/O 接口管理塊設備,只支持 RocksDB 需要的讀寫接口,去除了通用文件系統(tǒng)中的復雜功能和屬性,進一步減少了文件系統(tǒng)帶來的性能開銷。
圖1 BlueStore 架構以及寫入流程Fig. 1 The architecture and write process of BlueStore
BlueStore 針對不同存儲設備設置了不同的空間分配單元(即 bluestore_min_alloc_size 配置項),對于旋轉型存儲設備(如 HDD)默認使用64 KB 的分配單元,以發(fā)揮其順序訪問性能優(yōu)勢。對于非旋轉型存儲設備(如 SDD),則默認使用 4 KB 的分配單元,主要原因是此類設備的隨機訪問性能與順序訪問性能的差距較小,設置4 KB 的分配單元即可降低小塊數(shù)據(jù)更新時的“讀-改-寫”操作負載,進而提升存儲性能。設備上的讀寫操作通過分配單元進行切分,從而確定需要操作的數(shù)據(jù)區(qū)域。當 BlueStore 接收到用戶的寫操作請求時,首先根據(jù)目標對象的元數(shù)據(jù)定位目標區(qū)域,然后再針對各個區(qū)域進行寫入操作。在 BlueStore 中,寫操作整體上可分為兩種:
(1)新寫:當寫入數(shù)據(jù)的目標位置是新分配的空間時,直接在新空間中寫入數(shù)據(jù)(步驟②~③),然后通過 RocksDB 更新相應的元數(shù)據(jù)(步驟④),寫操作完成。由于寫操作不覆蓋已有數(shù)據(jù),因此,即使在寫入過程中發(fā)生崩潰,也不會破壞數(shù)據(jù)一致性。
(2)覆蓋寫:若寫入的數(shù)據(jù)量大于分配單元,則首先將其分割,將達到分配單元的部分按照新寫方式處理,未達到分配單元的部分則寫入RocksDB 中(步驟④),完成用戶寫操作。最后,RocksDB 通過異步 I/O 的方式把數(shù)據(jù)寫入到目標位置,并更新相應的元數(shù)據(jù)(步驟⑥~⑦),由RocksDB 的事務機制保證數(shù)據(jù)一致性。
由上述寫流程可知,BlueStore 基本解決了由 FileStore 日志造成的數(shù)據(jù)寫放大問題。首先,BlueStore 繞開了通用文件系統(tǒng),直接管理塊設備,因此,不受通用文件系統(tǒng)日志的影響。其次,新寫操作不需使用日志,只需一次數(shù)據(jù)落盤,一次元數(shù)據(jù)通過 RocksDB 事務提交落盤。最后,小塊的覆蓋寫操作可通過 RocksDB 合并到日志中進行提交,日志提交完成即可通知用戶寫完成,再將數(shù)據(jù)寫入到目標位置。經上述優(yōu)化后,BlueStore 減小了 FileStore 的數(shù)據(jù)寫放大,提高了存儲引擎層的性能。
但是,當 BlueStore 使用 RocksDB 處理小塊數(shù)據(jù)(包括元數(shù)據(jù))時,RocksDB 的日志機制造成了較為嚴重的寫放大,如進行 4 KB 的隨機寫時,寫放大最高可達 50 倍[19]。此外,BlueStore與 FileStore 都是通過 Linux 系統(tǒng)的通用塊接口來訪問存儲設備,導致了較長的 I/O 軟件棧。特別是對于字節(jié)可尋址設備(如 NVM)而言,冗長的I/O 軟件??赡軙蔀槠湫阅芷款i[25]。據(jù)英特爾在 2018 年閃存峰會上公布的測試數(shù)據(jù),當使用NVM 作為存儲設備時,軟件棧造成的延遲可達總延遲的 90%。因此,需進一步研究如何優(yōu)化存儲引擎的架構以及 I/O 軟件棧,配合底層存儲設備的特性來提升讀寫性能。
本節(jié)提出了一種基于 NVM 的新型存儲引擎NVMStore——通過內存映射而非傳統(tǒng)塊接口的方式訪問 NVM 設備,并根據(jù) NVM 的特性優(yōu)化數(shù)據(jù)讀寫流程,從而減小數(shù)據(jù)讀寫放大以及 I/O軟件棧開銷,進一步提高讀寫性能。
圖 2 為 NVMStore 的架構以及存儲結構。與使用通用塊接口的 BlueStore 相比,NVMStore具有更短的 I/O 路徑,并且通過內存直接訪問(Direct Access,DAX)的方式可繞過系統(tǒng)緩存直接讀寫 NVM 設備,利用緩存刷新指令(如clflush)將 CPU 緩存行中的數(shù)據(jù)直接持久化到NVM 中,避免數(shù)據(jù)在內存中的重復拷貝,從而減小軟件棧的開銷。DAX 的核心思想是繞過操作系統(tǒng)的頁緩存直接訪問設備,支持 DAX的文件系統(tǒng)(如 Ext4)只提供內存映射接口,具體的數(shù)據(jù)則由 DAX 接口之上的用戶程序來管理。用戶程序通過定制化的數(shù)據(jù)結構和讀寫流程來管理 NVM 的空間和數(shù)據(jù),不會由于繞過傳統(tǒng)文件系統(tǒng)而影響其功能,而且避免了傳統(tǒng)文件系統(tǒng)引入的性能開銷,可獲得一定的性能提升。
圖2 NVMStore 架構以及存儲結構Fig. 2 The architecture and storage structure of NVMStore
將 NVM 作為底層存儲設備的主要挑戰(zhàn)是原子粒度的不匹配,即 CPU 和 NVM 之間的數(shù)據(jù)傳輸粒度是 CPU 緩存行(通常為 64 字節(jié)),而NVM 設備的讀寫單元是內存數(shù)據(jù)位寬(通常為8 字節(jié))。在 NVM 上,大于 8 字節(jié)的數(shù)據(jù)寫入會被分割為多個寫入單元,因此,若在數(shù)據(jù)覆蓋寫的過程中系統(tǒng)崩潰,則可能造成只有部分新數(shù)據(jù)寫入成功,從而破壞數(shù)據(jù)一致性。針對該問題,NVMStore 構建了一個事務管理模塊,通過事務的形式進行覆蓋寫操作,當系統(tǒng)發(fā)生崩潰重啟時,通過重放日志中的有效事務記錄來恢復數(shù)據(jù)一致性(詳見第 3.3 節(jié))。
如圖 2 所示,NVMStore 將其管理的 NVM存儲空間分為超級塊(4 KB)、元數(shù)據(jù)塊(4 MB)、數(shù)據(jù)區(qū)以及日志塊(4 MB)。其中,超級塊位于空間起始位置,用于存放系統(tǒng)標簽、元數(shù)據(jù)塊地址以及日志塊地址等系統(tǒng)元數(shù)據(jù)。超級塊之后是第一個元數(shù)據(jù)塊,用于記錄系統(tǒng)中各個對象的ID 以及對應的數(shù)據(jù)區(qū)域(即數(shù)據(jù)在對象中的邏輯偏移、數(shù)據(jù)長度以及對應到存儲設備上的物理偏移等)。元數(shù)據(jù)塊以 4 MB 為單位進行分配,當一個元數(shù)據(jù)塊寫滿時,可在數(shù)據(jù)區(qū)中申請新塊,并在超級塊中進行相應的記錄。由于元數(shù)據(jù)塊的大小是固定的,因此當新增一個元數(shù)據(jù)塊時,只需在超級塊的元數(shù)據(jù)列表中新增一個 8 字節(jié)指針,指針指向新增元數(shù)據(jù)塊的起始地址,該架構利用NVM 的 8 字節(jié)原子性保證了新增元數(shù)據(jù)塊操作的原子性。日志塊以 4 MB 為單位進行分配,用于支持事務管理模塊。簡而言之,事務數(shù)據(jù)先在寫入日志塊中追加進行持久化存儲,然后再將更新的數(shù)據(jù)寫入目標空間中,從而保證系統(tǒng)的崩潰一致性。當需要新增日志塊時,先從數(shù)據(jù)區(qū)分配一塊空間,然后在超級塊的日志列表中新增一條記錄,方法與元數(shù)據(jù)塊相同。不同的是,當日志中的事務成功提交到系統(tǒng),將其數(shù)據(jù)持久化到設備后,相應的日志即可標記為廢棄(廢棄標記為 8 字節(jié),保證原子性),日志占用的空間即可回收。
NVMStore 不改變現(xiàn)有的存儲服務接口,其底層的存儲流程對用戶是透明的,不會影響上層用戶的使用,因此,不需修改用戶程序便可使用新的存儲引擎來提高存儲性能。NVMStore 是基于 Ceph 大數(shù)據(jù)存儲系統(tǒng)設計的存儲引擎,因此只支持 Ceph 存儲后端需要的功能,不提供服務給通用的文件系統(tǒng)。在實現(xiàn) Ceph 后端存儲功能的前提下,NVMStore 的設計簡單,便于實現(xiàn)和維護。
NVMStore 讀取流程與寫入流程類似,但若目標數(shù)據(jù)在 CPU 緩存中命中,則無須訪問 NVM設備。NVMStore 與 BlueStore 的寫操作流程類似,主要區(qū)別在于 NVMStore 通過內存接口訪問 NVM 設備,且利用 NVM 的字節(jié)可尋址特性對數(shù)據(jù)寫入流程進行優(yōu)化。當用戶寫操作到達NVMStore 時,NVMStore 首先根據(jù)對象元數(shù)據(jù)找到與寫入數(shù)據(jù)塊對應的存儲區(qū)域,然后按照存儲空間分配單元(默認等于內存頁面大小,即 4 KB)切分寫操作,再根據(jù)寫操作的類型執(zhí)行不同的寫入流程,總體上也可分為新寫和覆蓋寫兩大類型,具體分析如下:
(1)新寫
對于新寫的數(shù)據(jù)塊,直接在設備上分配新存儲單元并寫入數(shù)據(jù),然后利用緩存刷新指令將數(shù)據(jù)持久化到 NVM 設備,最后通過事務管理模塊更新相應的元數(shù)據(jù),完成寫操作。
BlueStore 使用傳統(tǒng)的塊接口寫入數(shù)據(jù),為了與設備上的塊單元對齊,需要進行數(shù)據(jù)補 0 操作,從而造成一定的數(shù)據(jù)寫放大。而 NVMStore利用 NVM 的字節(jié)可尋址特性,無須額外的數(shù)據(jù)補 0 操作,可直接將小塊數(shù)據(jù)寫入新空間。因此,NVMStore 的寫入流程更簡單,且減小了數(shù)據(jù)寫放大。
BlueStore 通過 RocksDB 寫入元數(shù)據(jù),而RocksDB 具有較長的 I/O 軟件棧,其數(shù)據(jù)壓縮流程會造成嚴重的寫放大。NVMStore 則使用一個簡單的事務管理模塊更新元數(shù)據(jù),通過內存接口將數(shù)據(jù)持久化到 NVM 設備,避免了 RocksDB 的多層數(shù)據(jù)壓縮,從而減小了數(shù)據(jù)寫放大,并縮短了 I/O 軟件棧。
(2)覆蓋寫
如圖 3 所示,NVMStore 在寫入對象 A 時,首先將寫操作按照分配單元進行切分,對達到分配單元的整塊覆蓋寫,將其直接寫入新分配的空間(步驟①)。對不足分配單元的新寫(稱為部分新寫),則直接分配一個新的單元并寫入(步驟②)。對不足一塊的覆蓋寫(稱為部分覆蓋寫),則先將數(shù)據(jù)寫入日志塊,并持久化到 NVM 設備(步驟③),然后將數(shù)據(jù)更新到目標區(qū)域(步驟④),最后以事務的方式更新對象 A 的元數(shù)據(jù),完成寫操作(步驟⑤)。
圖3 覆蓋寫操作示例Fig. 3 Overwrite example
與 BlueStore 的寫入流程相比,NVMStore 的寫入流程更為簡單。且由于 NVM 具有字節(jié)可尋址特性,NVMStore 將數(shù)據(jù)更新到目標區(qū)域時,不必對目標數(shù)據(jù)塊進行“讀-改-寫”操作,就可直接將數(shù)據(jù)寫入指定位置(如步驟②和④),因此,能減小數(shù)據(jù)讀寫放大,特別是小塊數(shù)據(jù)操作。由于 CPU 訪問 NVM 的粒度為緩存行,所以在讀取小塊數(shù)據(jù)時,會直接讀取數(shù)據(jù)所在的整個緩存行空間,造成一定程度的數(shù)據(jù)讀放大。但與傳統(tǒng)存儲設備上的預讀操作一樣,這種數(shù)據(jù)預讀操作可利用數(shù)據(jù)訪問的空間局部性,提高緩存命中率,減小訪問存儲設備的頻率,通常能夠有效提升用戶的數(shù)據(jù)讀取性能。為了更好地發(fā)揮緩存性能,NVMStore 為對象分配新空間時,會優(yōu)先選擇其現(xiàn)有空間附近的空閑空間,從而提高對象數(shù)據(jù)訪問的空間局部性。
綜上所述,與 BlueStore 相比,NVMStore 減小的性能開銷主要包含兩部分:一是通過 DAX的方式訪問設備,數(shù)據(jù)直接從 CPU 寫入 NVM,避免了緩存中的拷貝開銷;二是 NVMStore 通過內存接口讀寫數(shù)據(jù),當寫入小塊數(shù)據(jù)時,避免了由塊接口的“讀-改-寫”操作導致的開銷。
NVMStore 通過事務管理模塊保證系統(tǒng)中數(shù)據(jù)的崩潰一致性。對于整塊覆蓋寫或新寫(包括部分新寫)操作,NVMStore 直接分配新的空間寫入數(shù)據(jù),當數(shù)據(jù)持久化成功后,再通過事務管理模塊更新元數(shù)據(jù)。在此過程中,如果系統(tǒng)崩潰導致數(shù)據(jù)持久化失敗,那么由于原有的數(shù)據(jù)并沒有受到破壞,不影響數(shù)據(jù)一致性。如果數(shù)據(jù)持久化成功,但元數(shù)據(jù)更新失敗,那么元數(shù)據(jù)依然指向原有的數(shù)據(jù)塊(由事務管理模塊保證),也不會破壞數(shù)據(jù)一致性。
對于元數(shù)據(jù)的更新以及部分覆蓋寫操作,事務管理模塊利用日志機制保證其數(shù)據(jù)的一致性。圖 4 為事務管理模塊的寫入流程,如果寫操作的數(shù)據(jù)不大于 8 字節(jié)(如設置日志塊廢棄標記),那么可直接將其寫入目標區(qū)域(步驟①),然后將目標數(shù)據(jù)持久化到 NVM 設備(步驟⑧),利用NVM 設備本身的 8 字節(jié)原子性保證寫入操作的原子性,只需一次持久化操作。如果寫操作的數(shù)據(jù)量大于 8 字節(jié),那么 NVM 本身的硬件特性將無法保證寫操作的原子性,因此需要通過日志機制來支持數(shù)據(jù)一致性,需進行兩次持久化操作。
圖4 事務管理模塊寫入流程Fig. 4 The write process of transaction management module
當寫操作的數(shù)據(jù)量大于 8 字節(jié)時,事務管理模塊首先將寫操作編碼為特定格式的事務記錄(步驟②,編碼數(shù)據(jù)包括寫操作的目標地址、數(shù)據(jù)量、數(shù)據(jù)以及校驗碼等),然后判斷目前的日志塊是否有足夠的空閑空間寫入當前事務記錄(步驟③)。若當前日志塊中有足夠的空閑空間,則直接寫入事務記錄并將其持久化(步驟⑤~⑥);否則分配一個新的日志塊(步驟④),將事務記錄追加到日志塊中(步驟⑤),然后將其持久化(步驟⑥)。在此之后,更新目標數(shù)據(jù)并持久化(步驟⑦~⑧),完成寫入操作。其中,步驟⑥和⑧分別用于持久化目標數(shù)據(jù)和日志數(shù)據(jù),二者利用 NVM 的內存操作接口,通過緩存刷新指令(如 clflush),從 CPU 緩存中將數(shù)據(jù)直接寫入設備中。
在此過程中,若在寫入日志完成前系統(tǒng)崩潰,則認為本次操作失敗,由于原有的數(shù)據(jù)尚未更新,因此不破壞數(shù)據(jù)一致性。若寫入日志成功,但是在更新目標數(shù)據(jù)時系統(tǒng)崩潰,則在重啟時掃描最后更新的日志塊,重放其中的有效事務記錄,從而恢復數(shù)據(jù)一致性。綜上所述,NVMStore 通過事務管理模塊保證了系統(tǒng)的崩潰一致性。
本文結合英特爾開源的 N V M 開發(fā)庫PMDK①(Persistent Memory Development Kit),以及 Ceph 的對象存儲(Object Store)抽象接口實現(xiàn) NVMStore。具體實現(xiàn)過程中,Ceph 源碼是 14.2.8 版,PMDK 是 1.10 版,NVM 設備是Intel Optane DC Persistent Memory Module(簡稱“Optane”)。
Optane 為上層應用提供兩種訪問模式——內存模式(Memory Mode)和應用直接訪問模式(App Direct Mode)。在內存模式下,CPU 和操作系統(tǒng)忽略 Optane 的數(shù)據(jù)持久性,而將其視為 DRAM空間的擴展,從而提高系統(tǒng)的內存容量。在應用直接訪問模式下,CPU 和操作系統(tǒng)將 Optane 視為獨立的存儲設備,用戶可跳過 DRAM 緩存,通過內存接口直接訪問,在實現(xiàn)數(shù)據(jù)持久性存儲的同時,避免了數(shù)據(jù)在 DRAM 中的拷貝開銷。為了實現(xiàn)數(shù)據(jù)持久性存儲和減小 I/O 軟件棧的開銷,NVMStore 采用了直接訪問模式來讀寫Optane。
由于目前成熟的 Ceph 的后端存儲引擎只有FileStore 和 BlueStore,尚未發(fā)布基于 NVM 的存儲引擎,因此,本實驗對使用 NVM 作為存儲設備的 FileStore、BlueStore 和 NVMStore 的讀寫性能進行了對比。
理論上,NVM 具有遠超 HDD 的讀寫速度,特別是在小塊數(shù)據(jù)的隨機讀寫方面,因此利用 NVM 替換存儲系統(tǒng)中的 HDD,能夠提高存儲系統(tǒng)的性能。為了驗證該理論,本實驗對HDD 與 NVM 設備的讀寫性能進行比較,得出二者的性能基準。并將 NVM 替換 HDD 設備后,對 FileStore 和 BlueStore 的性能提升效果進行對比,驗證了本文優(yōu)化方法的有效性。
實驗中使用 4 臺配置相同的 Linux 服務器搭建實驗平臺。其中,3 臺搭建 Ceph 集群,每個節(jié)點配置 1 個 HDD 設備和 1 個 NVM 設備。另外 1 臺作為性能測試的客戶端,各個節(jié)點之間使用萬兆以太網連接,具體實驗配置如表 1 所示。測試工具是業(yè)界廣泛使用的 Fio,可直接對塊設備進行測試,獲得塊設備的吞吐量、IOPS以及讀寫延遲等性能指標。實驗對順序讀、順序寫、隨機讀和隨機寫這 4 種基準負載模式進行測試。每次讀寫的 I/O 塊大小分別設置為 1 KB、4 KB、16 KB、64 KB、256 KB、1 MB 和 4 MB。當讀寫測試時間達到 10 min 或數(shù)據(jù)量達到 100 GB時,測試停止,測試 5 次取性能平均值,然后進行對比分析。
表1 實驗配置Table 1 Experimental configurations
如第 2 節(jié)所述,BlueStore 對非旋轉型的存儲設備默認使用 4 KB 的分配單元,以提升存儲性能,NVM 設備也屬于非旋轉型的存儲設備,因此,為更合理地對比性能,本文在進行 NVM 性能測試時,將 BlueStore 的分配單元設置為 4 KB(通過 BlueStore 的日志可驗證),與 NVMStore上的分配單元保持一致。
本節(jié)對比了 HDD 與 Optane 作為塊設備的數(shù)據(jù)讀寫性能,為了達到塊設備的性能峰值,實驗中的 Fio 測試引擎設置為異步 I/O,隊列深度設置為 32,并繞過系統(tǒng)頁緩存和塊緩存直接對塊設備進行讀寫測試。實驗對比的性能指標為吞吐量(MB/s),HDD 的性能數(shù)據(jù)如表 2 所示,Optane的性能數(shù)據(jù)如表 3 所示,Optane 與 HDD 的性能比值如表 4 所示。
表2 HDD 吞吐量Table 2 Throughput of HDD
由實驗數(shù)據(jù)可知,Optane 設備的吞吐量遠高于 HDD,如 Optane 的 1 KB 隨機寫性能可達HDD 的 5 243.67 倍,4 MB 順序寫性能可達 HDD的 5.94 倍(見表 4)。由于 HDD 機械部件導致的延遲,其隨機性能遠低于順序性能,特別是當 I/O塊較小時,對比更為明顯。而 Optane 設備沒有機械部件,其讀寫性能主要取決于數(shù)據(jù)的分發(fā)是否能充分利用底層存儲器件的并發(fā)性。如表 3 所示,雖然 Optane 設備的讀性能高于寫性能,順序性能高于隨機性能,但是二者之間的性能差距遠小于 HDD 的性能差距。此外,Optane 的吞吐量隨著 I/O 塊的增大而提高,且當 I/O 塊大小約為64 KB 時達到峰值,這主要是由 Optane 底層存儲介質的特性及其內部存儲單元的分布決定的。
表3 Optane 吞吐量Table 3 Throughput of Optane
表4 Optane 與 HDD 的性能比值Table 4 Performance ratio of Optane to HDD
本小節(jié)對使用內存映射的方法讀寫 Optane時的性能優(yōu)勢進行驗證。由于目前 Fio 不支持Optane 的內存接口測試,因此本小節(jié)通過 PMDK提供的內存讀寫接口進行了測試,實驗結果如圖 5 所示,其中,Optane-Block 表示使用傳統(tǒng)的塊接口讀寫 Optane,Optane-Mmap 表示使用內存映射的方式讀寫 Optane。
由圖 5 可知,Optane-Mmap 的整體性能高于Optane-Block,特別是小塊數(shù)據(jù)讀寫。由圖 5(b)可知,當 I/O 塊大小為 1 KB 時,Optane-Mmap 的性能約為 Optane-Block 的 2.5 倍。原因是 Optane具有字節(jié)可尋址特性,可通過內存接口直接訪問設備,避免了塊接口較長的 I/O 軟件棧及數(shù)據(jù)在內存中的不必要拷貝,從而可獲得較高的性能。因此,與傳統(tǒng)的塊接口相比,本文提出的NVMStore 通過內存接口訪問 NVM 設備,理論上具有更優(yōu)的性能。
圖5 Optane 塊接口與內存接口性能對比Fig. 5 Performance comparison between Optane’s block and memory interface
本節(jié)通過實驗分析,當使用 Optane 設備替換 HDD 時,不同存儲引擎的 Ceph 獲得的性能提升效果。由于 Ceph 的塊接口的實際應用較為廣泛,因此,本節(jié)針對 Ceph 的 Rados 塊設備(Rados Block Device,RBD)進行測試。測試方法是,在 Ceph 集群中創(chuàng)建一個大小為 100 GB 的RBD 鏡像,然后使用 Fio 的 RBD 引擎對該鏡像進行讀寫性能測試。為更直觀地展示性能提升效果,根據(jù)存儲設備為 HDD 的 FileStore(FileStore-HDD)的吞吐量(MB/s),將性能數(shù)據(jù)進行標準化處理。最終對 Optane 的 FileStore(FileStore-Optane)和 BlueStore(BlueStore-Optane)相對于FileStore-HDD 的性能提升倍數(shù)進行對比。圖 6為性能提升效果,F(xiàn)ileStore-HDD 的性能值標準化為 1,不在圖中展示。
圖6 使用 Optane 的存儲引擎性能提升效果Fig. 6 Performance improvement of storage engine using Optane
由圖 6 可知,小塊隨機寫性能的提升最為明顯,且 BlueStore-Optane 的性能更高。當 I/O 塊小于 64 KB 時,與 FileStore-HDD 相比,F(xiàn)ileStore-Optane 和 BlueStore-Optane 的隨機寫性能提升可達 180 倍以上。與 FileStore-Optane 相比,BlueStore-Optane 的性能更高,其原因是FileStore 中的雙重日志問題造成了數(shù)據(jù)寫放大,占用了一部分 Optane 的帶寬,限制了 Optane 的性能發(fā)揮。而 BlueStore 直接管理塊設備,很大程度上減小了數(shù)據(jù)寫放大,且 BlueStore 的 I/O軟件棧較為簡單,因此,更容易發(fā)揮 Optane 的性能優(yōu)勢。
本實驗將不同存儲引擎的 Ceph 存儲系統(tǒng)的整體性能進行對比,不能簡單地將其與第 4.2 節(jié)塊設備的性能對比結果一一對應。如在第 4.2 節(jié)塊設備性能對比實驗中,當 I/O 塊為 64 KB 時,Optane 設備的順序讀性能約為 HDD 的 10 倍(詳見表 4)。但是如圖 6(b)所示,在同樣的負載模式下,Ceph 整體的順序讀性能提高了近 40 倍。其原因是 Ceph 整體上能夠將數(shù)據(jù)均勻地分布在各個存儲節(jié)點上,當進行大量數(shù)據(jù)的讀寫操作時,能夠較好地發(fā)揮各個存儲節(jié)點以及存儲設備的并發(fā)性,實現(xiàn)性能的擴展,尤其是在數(shù)據(jù)塊較大的負載模式下。
然而,直接利用 Optane 替換 HDD,并不能充分發(fā)揮 Optane 的性能優(yōu)勢。例如,Optane 的小塊隨機讀性能可達 HDD 的上千倍(詳見表 4),但是如圖 6(d)所示,將底層存儲設備換為Optane 后,Ceph 的 1 KB 隨機讀性能卻只提升了30 倍左右。該情況一方面是由于集群節(jié)點之間的數(shù)據(jù)傳輸增加了部分延遲;另一方面則是由于FileStore 與 BlueStore 底層都使用了傳統(tǒng)的塊接口和異步 I/O 機制,引入了較大的 I/O 軟件棧開銷,從而限制了 Optane 設備的性能發(fā)揮。
目前,已有開源的基于 NVM 的鍵值存儲系統(tǒng)(如 pmemkv②),但仍未有開源的可用于Ceph 后端的 NVM 存儲引擎。因此,本節(jié)對使用 Optane 設備的 NVMStore(表示為 NVMStore-Optane)與 Ceph 現(xiàn)有存儲引擎的讀寫性能進行對比。由于目前 Ceph 默認使用的存儲引擎是BlueStore,且第 4.4 節(jié)實驗已證明 BlueStore-Optane 的整體性能優(yōu)于 FileStore-Optane,因此本實驗直接對 NVMStore-Optane 與 BlueStore-Optane 的性能進行對比。實驗方法為,首先在Ceph 集群中創(chuàng)建一個 RBD 鏡像設備,然后使用Fio 的 RBD 引擎對該鏡像進行讀寫測試,獲得每秒執(zhí)行 I/O 操作的次數(shù)(Input/Output Operations Per Second,IOPS)和吞吐量性能,性能對比結果如圖 7 所示。
由圖 7 可知,NVMStore-Optane 的性能優(yōu)于 BlueStore-Optane,且讀寫負載的 I/O 塊越小,NVMStore-Optane 性能優(yōu)勢越大。如圖 7(a)所示,當 I/O 塊為 1 KB 的順序寫負載時,NVMStore-Optane 的性能約為 BlueStore-Optane的 2 倍。主要原因是,Optane 讀寫單塊數(shù)據(jù)的硬件延遲是穩(wěn)定的,但是當處理小塊(小于等于 4 KB 的數(shù)據(jù)塊)I/O 負載時,BlueStore 需要頻繁地通過塊接口訪問 Optane,導致大量的軟件棧延遲,且小塊操作造成的數(shù)據(jù)寫放大進一步增加了延遲。而 NVMStore 利用內存直接訪問 Optane,減小了軟件棧引入的延遲,且利用NVM 的字節(jié)可尋址特性減小了數(shù)據(jù)寫放大,因此性能提升較為明顯。
圖7 NVMStore 性能優(yōu)化效果Fig. 7 Performance improvement of NVMStore
為了驗證該結論,在 BlueStore 與 NVMStore的代碼中增加日志輸出,創(chuàng)建 Ceph RBD 塊設備,并針對小塊隨機寫入負載進行測試。測試方法為,使用 Fio 的 RBD 引擎進行 120 s 的 1 KB隨機寫入,統(tǒng)計 BlueStore 與 NVMStore 的 I/O 軟件棧延遲占比以及數(shù)據(jù)寫放大,測試結果如表 5所示。實驗結果表明,與 BlueStore 相比,NVMStore 的 I/O 軟件棧延遲占比更小,且能夠大幅度減小數(shù)據(jù)寫放大,因而在小塊寫入時其性能提升較為明顯。
表5 I/O 軟件棧延遲占比以及數(shù)據(jù)寫放大對比Table 5 Latency ratio of I/O software stack and data write amplification comparison
當 I/O 塊較小(不超過 64 KB 的數(shù)據(jù)塊)時,NVMStore 的性能略高于 BlueStore。主要原因是,BlueStore 通過塊接口訪問設備的頻率降低,I/O 軟件棧的開銷占總延遲的比例降低,進而縮小了與 NVMStore 的性能差距。當 I/O 塊較大時(大于 64 KB 的數(shù)據(jù)塊),NVMStore-Optane與 BlueStore-Optane 的性能相當。主要是因為,當讀寫數(shù)據(jù)量一定時,隨著 I/O 操作的粒度增大,調用 I/O 軟件棧的頻率將大幅降低,從而減小了 I/O 軟件棧引入的延遲,使得 Optane 的數(shù)據(jù)讀寫延遲占據(jù)了性能開銷的主要部分。此時,NVMStore 雖然能夠減小 I/O 軟件棧引入的延遲,但是對整體讀寫操作的影響較小,從而限制了其性能提升效果。因此,NVMStore 更適用于大量小塊數(shù)據(jù)讀寫的應用場景。目前,在Facebook 等流行的社交網絡平臺或者虛擬桌面云平臺應用場景中,小塊數(shù)據(jù)的隨機讀寫負載非常普遍[19,25-27],因此,以 NVMStore 為代表的性能優(yōu)化方向具有重要的現(xiàn)實意義。
如圖 7 所示,當 Optane 為底層存儲設備時,Ceph RBD 設備的隨機讀寫性能高于順序讀寫操作性能。主要是因為,在進行大量數(shù)據(jù)讀寫時,客戶端在 RBD 設備上的順序操作,經數(shù)據(jù)的切分與分發(fā),到達各個存儲節(jié)點后,轉化為各個存儲引擎上的隨機操作。與 HDD 等慢速設備相比,Optane 設備上的隨機操作性能與順序操作性能差異較小,因此,存儲引擎處理隨機操作不會造成嚴重的性能退化。相反,大量隨機讀寫操作更容易均勻地分布到各個存儲節(jié)點的多個對象中,有助于發(fā)揮存儲節(jié)點以及 Optane 設備底層存儲單元的并發(fā)性,最終達到更高的讀寫性能。
大數(shù)據(jù)存儲系統(tǒng)的存儲引擎對系統(tǒng)的整體性能至關重要。雖然使用高性能的 NVM 設備替換傳統(tǒng)存儲設備可以提高存儲性能,但是并不能充分發(fā)揮 NVM 設備的性能優(yōu)勢。主要原因是傳統(tǒng)的存儲引擎使用塊接口來訪問 NVM 設備,多層次的 I/O 軟件棧開銷以及數(shù)據(jù)寫放大造成的延遲,限制了 NVM 性能優(yōu)勢的發(fā)揮,進而影響了存儲引擎的性能擴展。針對該問題,本文對大數(shù)據(jù)存儲系統(tǒng) Ceph 的存儲引擎及其 I/O 軟件棧進行了分析,提出了一種基于 NVM 的存儲引擎 NVMStore,其利用內存直接映射的方式訪問NVM,并根據(jù) NVM 的特性對存儲引擎的數(shù)據(jù)讀寫流程進行優(yōu)化,減小了 I/O 軟件棧的開銷以及數(shù)據(jù)讀寫放大,進一步提升了存儲引擎的性能。最后在 NVM 設備上進行實驗,將 NVMStore 與現(xiàn)有的 Ceph 默認存儲引擎 BlueStore 的基準讀寫性能進行對比,實驗結果表明,NVMStore 能夠顯著提高存儲系統(tǒng)的小塊數(shù)據(jù)讀寫性能。在實際應用場景中,由于小塊數(shù)據(jù)讀寫負載較為普遍,因此,NVMStore 的性能優(yōu)化方向具有重要的現(xiàn)實意義。