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

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

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

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

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

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

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

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

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

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

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

1 緩存架構(gòu)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2) 基于radix tree的緩存查找

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

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

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

圖3 radix tree查詢過程

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

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

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

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

此即為Zipf分布定律

(1)

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

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

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

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

FusionCache的一元二次回歸模型為

服從N(0，σ2).

(2)

ε.

(3)

其系數(shù)矩陣為T

(4)

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

(5)

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

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

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

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

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

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

2.2.2 改進的LRU算法

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

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

圖4 改進的LRU

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

2.2.3 write-back過程

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

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

2.3讀寫流程

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

圖5 緩存讀流程圖

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

3 實驗與分析

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

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

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

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

(a)吞吐量

(b)延時

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

圖7 SSD寫入次數(shù)

為了測試穩(wěn)定狀態(tài)下Websearch和Ads兩種traces負載下的緩存命中率和I/O吞吐，先使兩個traces各自運行一小時再記錄數(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é) 論

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

[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ò)存儲系統(tǒng)緩存 [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

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

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

葉曉舟，yexz@dsp.ac.cn

(編輯苗秀芝)