孟祥輝, 曾學(xué)文, 陳 曉, 葉曉舟

(1.中國科學(xué)院聲學(xué)研究所 國家網(wǎng)絡(luò)新媒體工程技術(shù)研究中心, 北京100190； 2.中國科學(xué)院大學(xué)， 北京 100049)

FusionCache: 采用閃存的iSCSI存儲(chǔ)端融合緩存機(jī)制

孟祥輝1,2, 曾學(xué)文1, 陳 曉1, 葉曉舟1

(1.中國科學(xué)院聲學(xué)研究所 國家網(wǎng)絡(luò)新媒體工程技術(shù)研究中心, 北京100190； 2.中國科學(xué)院大學(xué)， 北京 100049)

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

網(wǎng)絡(luò)存儲(chǔ)性能；緩存機(jī)制；iSCSI target;閃存

近年來存儲(chǔ)介質(zhì)技術(shù)的進(jìn)步和個(gè)人云存儲(chǔ)業(yè)務(wù)的迅速發(fā)展，使得網(wǎng)絡(luò)存儲(chǔ)系統(tǒng)再次成為學(xué)術(shù)界和工業(yè)界研究的熱點(diǎn)，存儲(chǔ)區(qū)域網(wǎng)(Storage Area Network，SAN)是解決數(shù)據(jù)密集型應(yīng)用I/O性能瓶頸的重要手段,其中IP SAN采用iSCSI[1]協(xié)議. 在云計(jì)算和大數(shù)據(jù)時(shí)代，海量的網(wǎng)絡(luò)數(shù)據(jù)尤其是視頻流量爆炸性增長(zhǎng)給存儲(chǔ)系統(tǒng)帶來了巨大的挑戰(zhàn). 如何在大規(guī)模和高負(fù)載的應(yīng)用環(huán)境下，進(jìn)一步提高網(wǎng)絡(luò)存儲(chǔ)系統(tǒng)的性能成為亟待解決的問題.

作為網(wǎng)絡(luò)存儲(chǔ)系統(tǒng)的一個(gè)重要部分，緩存系統(tǒng)一直以來是存儲(chǔ)領(lǐng)域提高性能需要研究的關(guān)鍵課題. 文獻(xiàn)[2-3]利用本地磁盤緩存遠(yuǎn)端目標(biāo)設(shè)備上的數(shù)據(jù)，來降低訪問延時(shí)，減輕存儲(chǔ)服務(wù)器的負(fù)載. 然而，磁盤性能受限，固態(tài)硬盤(Solid State Drive, SSD)等基于閃存的設(shè)備更適合用作網(wǎng)絡(luò)存儲(chǔ)的緩存. 文獻(xiàn)[4-5]利用 SSD作為內(nèi)存的補(bǔ)充來構(gòu)建主機(jī)端的高速緩存架構(gòu)，并在網(wǎng)絡(luò)存儲(chǔ)環(huán)境下，針對(duì)SSD緩存提出幾種不同的改進(jìn)cache策略，其性能提升比磁盤緩存優(yōu)勢(shì)明顯；在云架構(gòu)中，文獻(xiàn)[6-7]利用SSD緩存提高虛擬機(jī)(Virtual Machine，VM)環(huán)境中的存儲(chǔ)性能.

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

1 緩存架構(gòu)

傳統(tǒng)使用SSD閃存的方法，一般把SSD當(dāng)作二級(jí)緩存，或者SSD與HDD構(gòu)成混合存儲(chǔ)，對(duì)DRAM不命中的請(qǐng)求再下發(fā)到SSD，但兩級(jí)緩存的請(qǐng)求訪問模式有很大不同. 本文考慮到這一點(diǎn)，在設(shè)計(jì)系統(tǒng)架構(gòu)時(shí)，把SSD當(dāng)作DRAM的擴(kuò)展空間，DRAM空間有限，還要保證對(duì)緩存命中與否的快速判斷，所以只把緩存塊(Cache Block)元數(shù)據(jù)單獨(dú)存放在DRAM，SSD存儲(chǔ)緩存塊內(nèi)容. DRAM與SSD聯(lián)合構(gòu)成完整的緩存空間，對(duì)后端設(shè)備表現(xiàn)為統(tǒng)一緩存，并對(duì)客戶端透明.

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

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

圖1 IET緩存系統(tǒng)架構(gòu)

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

2.1DRAM中的緩存設(shè)計(jì)

DRAM緩存空間包括metadata cache和front cache，前者管理緩存塊元數(shù)據(jù)，后者擔(dān)當(dāng)SSD的前端，對(duì)進(jìn)入SSD緩存的數(shù)據(jù)進(jìn)行篩選.

1) metadata數(shù)據(jù)結(jié)構(gòu)

為保證緩存算法的有效性和一致性，metadata數(shù)據(jù)結(jié)構(gòu)須至少包含以下信息，見圖2.

圖2 metadata數(shù)據(jù)結(jié)構(gòu)

元數(shù)據(jù)中每個(gè)字段代表的含義如下：

device id: 標(biāo)識(shí)每一個(gè)后端磁盤設(shè)備或者LUN(Logic Unit Number)；

LBA:即Logic Block Address,代表邏輯數(shù)據(jù)塊block在一個(gè)LUN內(nèi)的偏移或者編號(hào)；

cache block number: 標(biāo)識(shí)SSD上一個(gè)緩存塊的位置或者編號(hào)；

dirty bits: 臟數(shù)據(jù)標(biāo)記，默認(rèn)情況下每個(gè)緩存塊包含16個(gè)扇區(qū). 一個(gè)扇區(qū)在緩存中被修改而尚未同步到磁盤上時(shí)則為dirty(臟)狀態(tài)，對(duì)應(yīng)的dirty位為1，反之對(duì)應(yīng)的clean狀態(tài)為0. 16個(gè)扇區(qū)對(duì)應(yīng)16個(gè)dirty位，只要有一個(gè)扇區(qū)為dirty，則該緩存塊也為dirty.

valid bits: 與dirty bits類似，每一個(gè)bit代表緩存塊中的一個(gè)扇區(qū)是否有效，1代表有效. 考慮到某個(gè)請(qǐng)求對(duì)齊到磁盤邏輯塊之后可能不滿一個(gè)block塊大小，部分扇區(qū)的讀寫則無意義，所以用valid bits標(biāo)識(shí)有效數(shù)據(jù)，以免不必要的讀寫.

Sid:標(biāo)識(shí)一個(gè)iSCSI會(huì)話，用于輔助write back過程；

count: 緩存塊訪問計(jì)數(shù)，用于熱度預(yù)測(cè)；

SSD:標(biāo)識(shí)當(dāng)前緩存塊是否在SSD上，因?yàn)樵谀硞€(gè)短暫時(shí)間內(nèi)緩存塊可能在front cache中；

reserved: 預(yù)留位，方便后續(xù)擴(kuò)展功能.

2) 基于radix tree的緩存查找

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

FusionCache根據(jù)16bits的device id和48bits的 LBA構(gòu)成一個(gè)64bits的變量index,并以此index作為查詢的索引. 因此，radix tree保存了目標(biāo)邏輯塊地址和緩存塊元數(shù)據(jù)的映射關(guān)系. 圖3表示一個(gè)簡(jiǎn)化的查詢過程.

假設(shè)index的高位全為0，低18位有效，每6位一組. 樹高度為3，每個(gè)節(jié)點(diǎn)slot數(shù)量為64. 對(duì)于index1，高位000 000對(duì)應(yīng)第一層的第0號(hào)slot，001 000對(duì)應(yīng)第二層的第8號(hào)slot，低位010 000對(duì)應(yīng)第三層的第10號(hào)slot，葉子節(jié)點(diǎn)對(duì)應(yīng)一個(gè)緩存塊元數(shù)據(jù)，其index索引值即為528.

圖3 radix tree查詢過程

3) 基于回歸擬合的熱度預(yù)測(cè)

由于SSD的寫入壽命有限，需要考慮減少寫入和擦除帶來的損耗. FusionCache使用內(nèi)存中的一個(gè)區(qū)間構(gòu)成front cache，擔(dān)當(dāng)SSD的前端來吸收大量寫入帶來的沖擊. 所有的緩存數(shù)據(jù)首先要進(jìn)入front cache，當(dāng)front cache填滿之后，根據(jù)metadata中的count信息統(tǒng)計(jì)其中緩存塊的熱度，并預(yù)測(cè)緩存塊在未來被訪問的概率. 只有熱點(diǎn)數(shù)據(jù)才進(jìn)入SSD，冷數(shù)據(jù)直接寫入后端磁盤.

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

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

此即為Zipf分布定律

(1)

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

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

由于訪問熱度會(huì)隨著時(shí)間動(dòng)態(tài)改變，下一時(shí)刻的熱度需要根據(jù)歷史統(tǒng)計(jì)信息進(jìn)行預(yù)測(cè). 本文采用基于回歸擬合的方法對(duì)緩存塊的熱度進(jìn)行預(yù)測(cè)，具有較高的精度，而且復(fù)雜度較低. 根據(jù)預(yù)測(cè)結(jié)果對(duì)front cache中的緩存塊進(jìn)行預(yù)判，熱度低的數(shù)據(jù)不允許進(jìn)入SSD.

鑒于預(yù)測(cè)精度和計(jì)算量的均衡，相關(guān)研究表明周期數(shù)L在5～10之間比較合適[13]. 由于在L=5～10之間時(shí)，訪問熱度不會(huì)大幅波動(dòng)，同時(shí)為了減少回歸擬合計(jì)算的負(fù)擔(dān)，選擇二次回歸便可以實(shí)現(xiàn)較高的預(yù)測(cè)精度.

FusionCache的一元二次回歸模型為

服從N(0，σ2).

(2)

ε.

(3)

其系數(shù)矩陣為T

(4)

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

(5)

根據(jù)以上對(duì)訪問熱度的統(tǒng)計(jì)和預(yù)測(cè)，設(shè)定一個(gè)熱度閾值Hthreshold,對(duì)front cache緩存塊劃分兩個(gè)隊(duì)列q1,q2:

q1中的數(shù)據(jù)寫入到SSD，q2中的數(shù)據(jù)直接寫到后端磁盤.

2.2閃存中的緩存設(shè)計(jì)

2.2.1 閃存數(shù)據(jù)布局

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

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

2.2.2 改進(jìn)的LRU算法

SSD緩存根據(jù)數(shù)據(jù)訪問的時(shí)間局部性原則，不僅考慮緩存塊上一次訪問的時(shí)間，同時(shí)結(jié)合前文所述的訪問熱度進(jìn)行緩存替換.

進(jìn)入SSD的緩存根據(jù)熱度分為3個(gè)級(jí)別：hot(熱點(diǎn)數(shù)據(jù))，warm(暖數(shù)據(jù))和cold(冷數(shù)據(jù))，算法分別使用3個(gè)不同級(jí)別的LRU隊(duì)列(Qhot,Qwarm,Qcold)管理對(duì)應(yīng)的cache數(shù)據(jù)，見圖4.

圖4 改進(jìn)的LRU

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

2.2.3 write-back過程

iSCSI協(xié)議允許initiator和target之間建立多個(gè)會(huì)話，每個(gè)會(huì)話允許使用多個(gè)連接. 所以，SSD緩存塊的寫回過程應(yīng)該考慮會(huì)話狀態(tài).

SSD緩存空間較大，發(fā)生寫回的頻率較低，cold數(shù)據(jù)可能較長(zhǎng)時(shí)間停留在SSD緩存，尤其是一個(gè)會(huì)話結(jié)束以后，相應(yīng)的緩存塊應(yīng)該被寫回到磁盤上. 因此，write-back策略根據(jù)metadata中的sid判斷緩存塊是否屬于一個(gè)結(jié)束的會(huì)話，然后把屬于已經(jīng)結(jié)束的會(huì)話的全部緩存塊都寫回到磁盤. 若緩存已滿，需要發(fā)生替換時(shí)，首先需要檢查被替換的緩存塊的dirty bits，對(duì)于dirty的緩存塊應(yīng)立即寫回磁盤再替換，而clean狀態(tài)的緩存塊可以立即替換.

2.3讀寫流程

圖5展示了讀請(qǐng)求的處理流程，寫過程與讀相似. 需要注意的兩點(diǎn)：一是無論對(duì)SSD緩存命中與否，都需要構(gòu)造bio請(qǐng)求，因?yàn)閷?duì)SSD和HDD磁盤的訪問都屬于塊請(qǐng)求；二是無論是讀還是寫過程，都需要圖5左下角的寫前端緩存區(qū)過程，右半部分虛線框內(nèi)為寫前端緩存區(qū)子過程.

圖5 緩存讀流程圖

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

3 實(shí)驗(yàn)與分析

使用IOMeter測(cè)試FusionCache性能，作為對(duì)比，測(cè)試原生的以及只使用內(nèi)存DRAM作為緩存的iSCSI target，同時(shí)對(duì)比Facebook開源的Flashcache在iSCSI target端的表現(xiàn). 此外，使用兩種實(shí)際應(yīng)用場(chǎng)景負(fù)載記錄(workload trace)進(jìn)行測(cè)試，I/O trace分別為Websearch[14]和Ads[15]. 測(cè)試環(huán)境見表1.

表1 測(cè)試環(huán)境配置

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

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

(a)吞吐量

(b)延時(shí)

此外，以4 K，8 K，16 K請(qǐng)求大小對(duì)存儲(chǔ)系統(tǒng)連續(xù)寫入1小時(shí)(順序)，并統(tǒng)計(jì)對(duì)SSD的寫入次數(shù)，以驗(yàn)證對(duì)SSD壽命的影響. 結(jié)果見圖7，front cache減少了30%左右的SSD寫入次數(shù)，因此可以提高SSD使用壽命，能夠降低成本.

圖7 SSD寫入次數(shù)

為了測(cè)試穩(wěn)定狀態(tài)下Websearch和Ads兩種traces負(fù)載下的緩存命中率和I/O吞吐，先使兩個(gè)traces各自運(yùn)行一小時(shí)再記錄數(shù)據(jù)，以跳過緩存的熱身(warm up)階段，結(jié)果見圖8. 圖8(a)顯示， 在兩種trace下，F(xiàn)usionCache的讀緩存命中率比只使用DRAM的分別提高30%和35%左右.

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

(a)緩存命中率

(b)I/O吞吐

4 結(jié) 論

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

[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] 尹洋, 劉振軍,許魯. 一種基于磁盤介質(zhì)的網(wǎng)絡(luò)存儲(chǔ)系統(tǒng)緩存 [J]. 軟件學(xué)報(bào), 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

中國科學(xué)院戰(zhàn)略性先導(dǎo)科技專項(xiàng)課題(XDA06010302)，中科院創(chuàng)新研究院前瞻項(xiàng)目(Y555021601)

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

葉曉舟，yexz@dsp.ac.cn

(編輯苗秀芝)