FusionCache: 采用閃存的iSCSI存儲端融合緩存機制

孟祥輝, 曾學文, 陳 曉, 葉曉舟

(1.中國科學院聲學研究所 國家網絡新媒體工程技術研究中心, 北京100190； 2.中國科學院大學， 北京 100049)

FusionCache: 采用閃存的iSCSI存儲端融合緩存機制

孟祥輝1,2, 曾學文1, 陳 曉1, 葉曉舟1

(1.中國科學院聲學研究所 國家網絡新媒體工程技術研究中心, 北京100190； 2.中國科學院大學， 北京 100049)

針對原生的iSCSI目標端控制器缺乏獨立的緩存模塊問題，為了進一步提高存儲區域網的整體性能，在iSCSI target軟件中引入了一種基于閃存的融合緩存機制FusionCache. FusionCache利用閃存和DRAM組成統一的融合緩存架構，閃存充當DRAM的擴展空間，DRAM分為緩存塊元數據區和前端緩存區. 元數據區基于基數樹管理緩存塊元數據，用于加速緩存塊的查找；前端緩存區基于回歸擬合統計并預測緩存塊訪問熱度，并吸收大量寫入對閃存帶來的沖擊，只允許熱點數據進入閃存. FusionCache采用改進的LRU算法對緩存塊進行替換，并且在寫回過程中考慮iSCSI會話狀態. 實驗結果表明：FusionCache能降低對后端磁盤設備的訪問頻率，提高I/O響應的速度和吞吐. 與只采用DRAM的緩存機制以及原生iSCSI target相比，FusionCache的I/O訪問延時分別降低了33%和60%，吞吐分別提高了25%和54%；相較于Facebook提出的Flashcache機制，FusionCache的吞吐性能提高了18%，延時降低了27%；FusionCache還具有良好的讀緩存命中率；此外，FusionCache能夠減少閃存的寫入次數，提高閃存使用壽命. FusionCache提供良好的網絡存儲效率，并且降低了使用成本.

網絡存儲性能；緩存機制；iSCSI target;閃存

近年來存儲介質技術的進步和個人云存儲業務的迅速發展，使得網絡存儲系統再次成為學術界和工業界研究的熱點，存儲區域網(Storage Area Network，SAN)是解決數據密集型應用I/O性能瓶頸的重要手段,其中IP SAN采用iSCSI[1]協議. 在云計算和大數據時代，海量的網絡數據尤其是視頻流量爆炸性增長給存儲系統帶來了巨大的挑戰. 如何在大規模和高負載的應用環境下，進一步提高網絡存儲系統的性能成為亟待解決的問題.

作為網絡存儲系統的一個重要部分，緩存系統一直以來是存儲領域提高性能需要研究的關鍵課題. 文獻[2-3]利用本地磁盤緩存遠端目標設備上的數據，來降低訪問延時，減輕存儲服務器的負載. 然而，磁盤性能受限，固態硬盤(Solid State Drive, SSD)等基于閃存的設備更適合用作網絡存儲的緩存. 文獻[4-5]利用 SSD作為內存的補充來構建主機端的高速緩存架構，并在網絡存儲環境下，針對SSD緩存提出幾種不同的改進cache策略，其性能提升比磁盤緩存優勢明顯；在云架構中，文獻[6-7]利用SSD緩存提高虛擬機(Virtual Machine，VM)環境中的存儲性能.

以上研究大多是基于客戶端緩存進行研究，很少對iSCSI target(即IP SAN的存儲端)軟件進行優化. 文獻[8-9]基于iSCSI target端，從網絡設備[8]緩存和NUMA節點[9]緩存的角度進行研究，但并未利用到高速的閃存設備進行加速. 文獻[10-12]在存儲端利用閃存構建高速緩存架構，保證響應時間的同時提高閃存設備的壽命，是針對操作系統通用塊層或者文件系統級的優化，而iSCSI target控制器軟件本身依然缺乏獨立的緩存模塊. 相關工作都是從iSCSI target軟件之外的角度進行研究，很少關注iSCSI target軟件本身. 針對以上問題，為進一步提高SAN的整體性能，本文為iSCSI target控制器軟件提出獨立緩存模塊，即基于閃存的iSCSI存儲端融合緩存機制FusionCache. 與先前工作最大的不同是本文考慮iSCSI target自身的處理特征，著重研究為iSCSI target軟件引入基于閃存的緩存機制. FusionCache利用閃存和DRAM共同構成統一的塊I/O緩存空間，閃存作為DRAM的擴展，而非傳統的第二級緩存. DRAM劃分為兩個區間，分別用于快速查找緩存塊和提高閃存耐久性. 閃存的緩存空間利用改進的最近最少使用(Least Recently Used, LRU)原則組織. FusionCache能降低對后端磁盤設備的訪問頻率，提高I/O響應的速度和吞吐.

1 緩存架構

傳統使用SSD閃存的方法，一般把SSD當作二級緩存，或者SSD與HDD構成混合存儲，對DRAM不命中的請求再下發到SSD，但兩級緩存的請求訪問模式有很大不同. 本文考慮到這一點，在設計系統架構時，把SSD當作DRAM的擴展空間，DRAM空間有限，還要保證對緩存命中與否的快速判斷，所以只把緩存塊(Cache Block)元數據單獨存放在DRAM，SSD存儲緩存塊內容. DRAM與SSD聯合構成完整的緩存空間，對后端設備表現為統一緩存，并對客戶端透明.

iSCSI Enterprise Target(IET)控制器軟件分為用戶層和內核層，對數據的處理工作大部分在內核層完成. IET以block I/O(即bio)的形式對I/O請求進行處理，不經過虛擬文件系統以及Linux Page Cache，軟件本身沒有針對block I/O的緩存模塊. IET對用戶請求的封裝結構為tio(即target I/O)，因此需要在請求遞交給通用塊層之前截獲tio，并根據提出的緩存策略對請求進行處理.

基于以上考慮，在IET軟件中提出的FusionCache架構見圖1. IET軟件本身包括3個組件：NTHREAD,WTHREAD和iSCSI Response， WTHREAD負責iSCSI數據(即tio)的讀寫流程，因此FusionCache最適合嵌入在WTHREAD中. 提出的緩存架構中，tio解析模塊負責提取出目標數據的位置信息，包括目標扇區和對應的內存地址；DRAM管理模塊負責管理DRAM上的metadata cache和front cache的空間；SSD管理模塊對閃存上的緩存塊進行組織管理；LRU鏈表使用改進的LRU算法對緩存塊進行替換；bio構造模塊根據緩存策略向通用塊層發出bio請求.

圖1 IET緩存系統架構

2 設計與實現

2.1DRAM中的緩存設計

DRAM緩存空間包括metadata cache和front cache，前者管理緩存塊元數據，后者擔當SSD的前端，對進入SSD緩存的數據進行篩選.

1) metadata數據結構

為保證緩存算法的有效性和一致性，metadata數據結構須至少包含以下信息，見圖2.

圖2 metadata數據結構

元數據中每個字段代表的含義如下：

device id: 標識每一個后端磁盤設備或者LUN(Logic Unit Number)；

LBA:即Logic Block Address,代表邏輯數據塊block在一個LUN內的偏移或者編號；

cache block number: 標識SSD上一個緩存塊的位置或者編號；

dirty bits: 臟數據標記，默認情況下每個緩存塊包含16個扇區. 一個扇區在緩存中被修改而尚未同步到磁盤上時則為dirty(臟)狀態，對應的dirty位為1，反之對應的clean狀態為0. 16個扇區對應16個dirty位，只要有一個扇區為dirty，則該緩存塊也為dirty.

valid bits: 與dirty bits類似，每一個bit代表緩存塊中的一個扇區是否有效，1代表有效. 考慮到某個請求對齊到磁盤邏輯塊之后可能不滿一個block塊大小，部分扇區的讀寫則無意義，所以用valid bits標識有效數據，以免不必要的讀寫.

Sid:標識一個iSCSI會話，用于輔助write back過程；

count: 緩存塊訪問計數，用于熱度預測；

SSD:標識當前緩存塊是否在SSD上，因為在某個短暫時間內緩存塊可能在front cache中；

reserved: 預留位，方便后續擴展功能.

2) 基于radix tree的緩存查找

考慮到hashtable存在沖突的情況，一旦沖突需要二次查找，而且hashtable的大小是固定值，不容易確定. FusionCache基于radix tree快速查找閃存中的緩存塊. 此外，radix tree支持并行查找操作，可以方便地在多核平臺上進行擴展和優化.

FusionCache根據16bits的device id和48bits的 LBA構成一個64bits的變量index,并以此index作為查詢的索引. 因此，radix tree保存了目標邏輯塊地址和緩存塊元數據的映射關系. 圖3表示一個簡化的查詢過程.

假設index的高位全為0，低18位有效，每6位一組. 樹高度為3，每個節點slot數量為64. 對于index1，高位000 000對應第一層的第0號slot，001 000對應第二層的第8號slot，低位010 000對應第三層的第10號slot，葉子節點對應一個緩存塊元數據，其index索引值即為528.

圖3 radix tree查詢過程

3) 基于回歸擬合的熱度預測

由于SSD的寫入壽命有限，需要考慮減少寫入和擦除帶來的損耗. FusionCache使用內存中的一個區間構成front cache，擔當SSD的前端來吸收大量寫入帶來的沖擊. 所有的緩存數據首先要進入front cache，當front cache填滿之后，根據metadata中的count信息統計其中緩存塊的熱度，并預測緩存塊在未來被訪問的概率. 只有熱點數據才進入SSD，冷數據直接寫入后端磁盤.

相關研究表明，存儲設備中的文件熱度與訪問情況之間符合Zipf分布[13]. 即存儲設備上的N個文件依據熱度(訪問頻率)降序排序，則第k個文件的訪問頻率為C/k1-θ,參數C為

C=1/(1+1/2+1/3+…+1/N).

此即為Zipf分布定律

(1)

式中Z(k)為第k個文件被訪問的概率. Zipf分布表明，在一段時間內，熱度越高的文件被再次訪問到的概率也越高. 文件的訪問熱度等于其所有數據塊的熱度，Zipf定律同樣適用于數據塊.

設緩存塊bi的熱度為hi(t)=mi(t)/N,其中mi為時間t之前緩存塊bi的訪問次數，N為所有緩存塊的總的請求次數.

由于訪問熱度會隨著時間動態改變，下一時刻的熱度需要根據歷史統計信息進行預測. 本文采用基于回歸擬合的方法對緩存塊的熱度進行預測，具有較高的精度，而且復雜度較低. 根據預測結果對front cache中的緩存塊進行預判，熱度低的數據不允許進入SSD.

鑒于預測精度和計算量的均衡，相關研究表明周期數L在5～10之間比較合適[13]. 由于在L=5～10之間時，訪問熱度不會大幅波動，同時為了減少回歸擬合計算的負擔，選擇二次回歸便可以實現較高的預測精度.

FusionCache的一元二次回歸模型為

服從N(0，σ2).

(2)

ε.

(3)

其系數矩陣為T

(4)

(1,(L+1),(L+1)2)·(A·Ci),

(5)

根據以上對訪問熱度的統計和預測，設定一個熱度閾值Hthreshold,對front cache緩存塊劃分兩個隊列q1,q2:

q1中的數據寫入到SSD，q2中的數據直接寫到后端磁盤.

2.2閃存中的緩存設計

2.2.1 閃存數據布局

如圖1所示，SSD可以劃分為3個區域，分別為superblock區，metadata backup區，以及存放緩存塊的cache block區. 其中，superblock是整個SSD緩存的“元數據”，保存SSD緩存的配置信息，比如緩存使用情況、緩存塊大小等. backup區是DRAM中metadata cache的備份，保證緩存數據的非易失性或者持久性，在服務器故障重啟時，憑借SSD中的metadata備份即可恢復原有的緩存數據到DRAM中，不需要從后端磁盤重新讀取重復數據. Cache block區則存放實際的緩存塊.

緩存操作的基本單位是cache block，如果設置太小，則緩存塊元數據會占據太多空間；如果block太大，則算法精度會降低，算法會失真. 不同的應用場景，I/O訪問模式不同，即便是同樣的數據庫應用，I/O大小也會變化. 因此緩存塊大小的設定沒有普適性的值. Flashcache和dm-cache的默認緩存塊大小為4K，SQL Server和Oracle默認的塊大小都是8KB. 本文默認使用8K大小的緩存塊，占用兩個內存page，有利于數據預讀和減小元數據所占空間. 當然，也可以根據特定應用場景的I/O訪問模式自定義緩存塊大小并保存到superblock中.

2.2.2 改進的LRU算法

SSD緩存根據數據訪問的時間局部性原則，不僅考慮緩存塊上一次訪問的時間，同時結合前文所述的訪問熱度進行緩存替換.

進入SSD的緩存根據熱度分為3個級別：hot(熱點數據)，warm(暖數據)和cold(冷數據)，算法分別使用3個不同級別的LRU隊列(Qhot,Qwarm,Qcold)管理對應的cache數據，見圖4.

圖4 改進的LRU

熱度高的隊列中cache 比熱度低的隊列cache 塊生存時間更久，Qwarm和Qcold隊列中的 cache塊被命中時，則分別將其升級到更高一級隊列中，Qhot和Qwarm隊列中cache塊在一段時間內沒有被命中則會降級到更低一級的隊列中. 當SSD緩存空間用盡發生替換時，只在Qcold中進行，不需要DRAM的cache信息進行判斷. 所以，cache塊的訪問頻率能夠在不同級別的 LRU隊列得到體現.

2.2.3 write-back過程

iSCSI協議允許initiator和target之間建立多個會話，每個會話允許使用多個連接. 所以，SSD緩存塊的寫回過程應該考慮會話狀態.

SSD緩存空間較大，發生寫回的頻率較低，cold數據可能較長時間停留在SSD緩存，尤其是一個會話結束以后，相應的緩存塊應該被寫回到磁盤上. 因此，write-back策略根據metadata中的sid判斷緩存塊是否屬于一個結束的會話，然后把屬于已經結束的會話的全部緩存塊都寫回到磁盤. 若緩存已滿，需要發生替換時，首先需要檢查被替換的緩存塊的dirty bits，對于dirty的緩存塊應立即寫回磁盤再替換，而clean狀態的緩存塊可以立即替換.

2.3讀寫流程

圖5展示了讀請求的處理流程，寫過程與讀相似. 需要注意的兩點：一是無論對SSD緩存命中與否，都需要構造bio請求，因為對SSD和HDD磁盤的訪問都屬于塊請求；二是無論是讀還是寫過程，都需要圖5左下角的寫前端緩存區過程，右半部分虛線框內為寫前端緩存區子過程.

圖5 緩存讀流程圖

當一個讀請求到達target端，FusionCache首先檢查是否命中緩存，若命中則存在兩種可能：命中的緩存在front cache，則cache block將立即返回；命中的緩存在SSD中，則需要構造到SSD的bio請求，然后返回相應的cache block. 若未命中，則需要構造到HDD的bio請求，然后缺失的cache block會從HDD拷貝到front cache，即寫前端緩存區過程：首先分配一個新的cache block并填充相關數據，若front cache此時未滿則此次請求處理結束，繼續處理其他請求；若front cache已滿，則啟動上述基于回歸擬合的熱度預測算法. 根據算法結果，熱數據移動到SSD，冷數據直接進入HDD. 之后檢測SSD狀態，若SSD未滿則此子過程返回；若SSD已滿，則利用改進的LRU替換策略驅逐Qcold中的cache block. 在驅逐cache block時，FusionCache同時考慮dirty位狀態和iSCSI會話狀態. 若dirty位被置1，被驅逐的cache block須先同步到HDD；若檢測到某個會話已經logout，那么所有屬于該會話的cache block將會被寫回到HDD.

3 實驗與分析

使用IOMeter測試FusionCache性能，作為對比，測試原生的以及只使用內存DRAM作為緩存的iSCSI target，同時對比Facebook開源的Flashcache在iSCSI target端的表現. 此外，使用兩種實際應用場景負載記錄(workload trace)進行測試，I/O trace分別為Websearch[14]和Ads[15]. 測試環境見表1.

表1 測試環境配置

客戶端上IOMeter測試結果見圖6. 圖6(a)展示幾種機制在不同I/O請求塊大小的吞吐性能，原生的IET默認塊大小4K，所以在請求大小為4K時性能最高，只使用DRAM做緩存和使用FusionCache的IET默認塊大小都是8K，所以請求大小在8K左右性能最高，繼續增大塊大小不會提高性能. FusionCache相對原生IET和只使用DRAM的緩存提升分別為54%和25%左右,比Flashcache提高18%左右. 由于SSD空間遠大于DRAM，所以Flashcache的平均性能要稍好于FusionCache架構中只使用DRAM的情況.

圖6(b)顯示，隨著請求塊大小成倍增大，I/O平均響應時間整體呈指數上升. 集成緩存模塊的IET，允許I/O請求在緩存中獲得請求數據而無須到磁盤請求，所以響應時間大大縮短；但是DRAM空間不大，緩存的數據量有限，而SSD緩存的空間增大幾十倍甚至上百倍，進一步減少了請求磁盤的次數. FusionCache相對原生IET和只使用DRAM的緩存帶來的延時減少分別為60%和33%左右，比Flashcache減少27%左右.

(a)吞吐量

(b)延時

此外，以4 K，8 K，16 K請求大小對存儲系統連續寫入1小時(順序)，并統計對SSD的寫入次數，以驗證對SSD壽命的影響. 結果見圖7，front cache減少了30%左右的SSD寫入次數，因此可以提高SSD使用壽命，能夠降低成本.

圖7 SSD寫入次數

為了測試穩定狀態下Websearch和Ads兩種traces負載下的緩存命中率和I/O吞吐，先使兩個traces各自運行一小時再記錄數據，以跳過緩存的熱身(warm up)階段，結果見圖8. 圖8(a)顯示， 在兩種trace下，FusionCache的讀緩存命中率比只使用DRAM的分別提高30%和35%左右.

圖8(b)顯示，FusionCache的I/O吞吐在Websearch trace下，比原生IET和只用DRAM的方法分別提高60%和23%左右；在Ads trace下，FusionCache比另外兩種方法分別提高54%和21%左右.

(a)緩存命中率

(b)I/O吞吐

4 結 論

本文針對IET控制器軟件缺少獨立緩存模塊的問題，提出一種采用閃存的融合緩存機制FusionCache. FusionCache利用閃存和內存(DRAM)組成統一的融合緩存架構，閃存充當DRAM的擴展空間. 基于基數樹(radix tree)管理緩存塊元數據，用于加速緩存塊的查找；基于回歸擬合統計并預測緩存塊訪問熱度，只允許熱點數據進入閃存. 閃存采用改進的LRU算法對緩存塊進行替換，并且在寫回過程中考慮iSCSI會話狀態. 實驗結果表明，與其他方法相比，無論是采用IOMeter還是實際應用場景負載測試，其性能都要更好.

[1] SATRAN J, METH K, SAPUNTZAKIS C, et al. Internet Small Computer Systems Interface (iSCSI) [EB/OL]. (2004-04-27). https://www.ietf.org/rfc/rfc3720.txt.

[2] HENSBERGEN E V, ZHAO Ming. Dynamic policy disk caching for storage networking: IBM Research Report RC24123 [R].USA:IBM,2006.

[3] 尹洋, 劉振軍,許魯. 一種基于磁盤介質的網絡存儲系統緩存 [J]. 軟件學報, 2009,20(10): 2752-2765.

YIN Yang, LIU Zhenjun, XU Lu. Cache system based on disk media for network storage[J].Chinese Journal of Software, 2009,20(10): 2752-2765.

[4] BYAN S, LENTINI J, MADAN A, et al. Mercury: Host-side flash caching for the data center [C]// IEEE Symposium on Mass Storage Systems and Technologies. Pacific Grove, CA: IEEE Publisher,2012: 1-12.

[5] KOLLER R, MARMOL L, RANGASWAMI R, et al. Write policies for host-side flash caches [C]// USENIX Conference on File and Storage Technologies. San Jose, CA: USENIX Publisher,2013: 45-58.

[6] ARTEAGA D,ZHAO Ming. Client-side flash caching for cloud systems [C]// Proceedings of International Conference on Systems and Storage. Haifa, Israel:ACM Publisher, 2014:1-11.

[7] KOLLER R, MASHTIZADEH A J, RANGASWAMI R. Centaur: Host-side SSD caching for storage performance control[C]// IEEE International Conference on Autonomic Computing.Grenoble:IEEE Publisher,2015: 51-60.

[8] WANG Jun, YAO Xiaoyu, MITCHELL C, et al. A new hierarchical data cache architecture for iSCSI storage server[J]. IEEE Transactions on Computers, 2009,58(4): 433-447.

[9] REN Y, LI T, YU D, et al. Design, implementation, and evaluation of a NUMA-aware cache for iSCSI storage servers[J]. IEEE Transactions on Parallel and Distributed Systems, 2015,26(2): 413-422.

[10]SUEI P L, YEH M Y, KUO T W. Endurance-aware flash-cache management for storage servers[J].IEEE Transactions on Computers, 2014,63(10): 2416-2430.

[11]HUO Zhisheng, XIAO Limin, ZHONG Qiaoling, et al. A metadata cooperative caching architecture based on SSD and DRAM for file systems[C]//International Conference on Algorithms and Architectures for Parallel Processing. Zhangjiajie: Springer Publisher, 2015: 31-51.

[12]LIU Yi, GE Xiongzi, DU D H, et al. SSD as a cloud cache? carefully design about it[J].Taiwan Journal of Computers,2016,27(1): 26-37.

[13]SHANG Qiuli, ZHANG Wu, GUO Xiuyan, et al. An energy-saving scheduling scheme for streaming media storage systems[J].High Technology Letters, 2015,21(3): 347-357.

[14]MCNUTT B, BATES K. Umass trace repository: search engine I/O[EB/OL]. (2007-06-01). http://traces.cs.umass.edu/index.php/Storage/Storage.

[15]KAVALANEKAR S,WORTHINGTON B,ZHANG Qi, et al. Characterization of storage workload traces from production Windows servers[C]//IEEE International Symposium on Workload Characterization. Seattle:IEEE Publisher, 2008:119-128.

FusionCache:AFusionCacheMechanismforiSCSITargetBasedonFlashMemory

MENG Xianghui1,2, ZENG Xuewen1, CHEN Xiao1, YE Xiaozhou1

(1.National Network New Media Engineering Research Center, Institute of Acoustics, Chinese Academy of Sciences, Beijing 100190, China; 2.University of Chinese Academy of Sciences, Beijing 100049, China)

Focusing on the problem of lack of independent cache module of original iSCSI target controller, we introduce a fusion cache mechanism based on flash memory called FusionCache into the iSCSI target software to further improve the overall performance of the storage area network. FusionCache uses flash memory and DRAM to form a unified fusion cache architecture. The flash memory acts as DRAM’s expansion space, and DRAM is divided into cache block metadata area (metadata cache) and front-end buffer area (front cache). The metadata cache manages cache block metadata based on radix tree in order to accelerate the cache block searching; the front cache tallies and predicts the access popularity of the cache block based on regressing fitting model, and absorbs the impact of massive writes on flash memory to ensure that only the hot data is allowed to enter the flash memory. FusionCache uses the improved LRU algorithm to do cache replacement. Besides, it takes iSCSI session’s state into account during write-back. The experimental results show that: FusionCache is able to reduce access to backend disk devices, and improve I/O response speed. FusionCache reduces I/O access latency by 33% and 60%, and improves throughput by 25% and 54%, compared to cache mechanism with only DRAM and original iSCSI target, respectively. Compared with Flashcache proposed by Facebook, FusionCache improves throughput by 18% and reduces latency by 27%. FusionCache also has a good read cache hit rate. Besides, FusionCache reduces write amount of flash memory, thus extends its life. FusionCache provides good efficiency of network storage and reduces cost.

network storage performance; cache mechanism; iSCSI target; flash memory

10.11918/j.issn.0367-6234.201701022

TP393

A

0367-6234(2017)11-0066-07

2017-01-05

中國科學院戰略性先導科技專項課題(XDA06010302)，中科院創新研究院前瞻項目(Y555021601)

孟祥輝(1990—)，男，博士

葉曉舟，yexz@dsp.ac.cn

(編輯苗秀芝)