云存儲(chǔ)系統(tǒng)中的預(yù)測(cè)式局部修復(fù)碼

張曉陽 許佳豪 胡燏翀,2

1(華中科技大學(xué)計(jì)算機(jī)科學(xué)與技術(shù)學(xué)院 武漢 430074)2(深圳華中科技大學(xué)研究院 廣東深圳 518000)

近幾年來，隨著社會(huì)的發(fā)展，各行業(yè)和領(lǐng)域的數(shù)據(jù)量都在呈爆炸式增長，因而不斷對(duì)存儲(chǔ)系統(tǒng)提出挑戰(zhàn)，云環(huán)境下的存儲(chǔ)系統(tǒng)已逐步成為未來數(shù)據(jù)存儲(chǔ)的發(fā)展趨勢(shì).云存儲(chǔ)系統(tǒng)的一個(gè)重要目標(biāo)就是無論系統(tǒng)發(fā)生什么樣的故障，都必須保證數(shù)據(jù)的可用性，即云存儲(chǔ)服務(wù)提供商總能夠持續(xù)不斷地向用戶提供數(shù)據(jù)訪問的服務(wù)，否則會(huì)直接影響上層應(yīng)用給用戶提供正常服務(wù).2018年，Windows Azure云存儲(chǔ)服務(wù)因故障中斷時(shí)間超過24 小時(shí)，超過40個(gè)Azure 云應(yīng)用服務(wù)因此而中斷，造成不小的經(jīng)濟(jì)損失[1].因此，對(duì)云存儲(chǔ)服務(wù)提供商和用戶來說，數(shù)據(jù)可用性至關(guān)重要.

為了提高云存儲(chǔ)的數(shù)據(jù)可用性，系統(tǒng)一般額外存儲(chǔ)大量的冗余數(shù)據(jù).冗余有2個(gè)常見的實(shí)現(xiàn)方式：復(fù)制和糾刪碼.復(fù)制是最簡(jiǎn)單的冗余方案，即一個(gè)文件擁有多個(gè)副本；而糾刪碼(一般采用Reed-Solomon碼[2])是將一個(gè)文件等分成多個(gè)數(shù)據(jù)塊，這些數(shù)據(jù)塊再編碼生成同樣大小的若干個(gè)校驗(yàn)塊，使得從所有數(shù)據(jù)塊和校驗(yàn)塊中任意下載原始文件大小的數(shù)據(jù)就可以重建出原始文件.與復(fù)制相比，糾刪碼可以大大提高數(shù)據(jù)可用性[3].可是，糾刪碼面臨的一大挑戰(zhàn)是當(dāng)發(fā)生數(shù)據(jù)塊丟失時(shí)，修復(fù)該數(shù)據(jù)塊所需要的帶寬消耗過大，即一個(gè)數(shù)據(jù)塊丟失的話，需要下載多個(gè)塊去重建出原始文件才能對(duì)單個(gè)數(shù)據(jù)塊進(jìn)行修復(fù).這會(huì)使得數(shù)據(jù)修復(fù)性能偏低，從而導(dǎo)致云存儲(chǔ)上的用戶數(shù)據(jù)訪問延遲過高，影響數(shù)據(jù)可用性.

為了降低糾刪碼的修復(fù)開銷，不少云存儲(chǔ)系統(tǒng)(Windows Azure[4], Facebook[5])開始使用一類新型的編碼方法——局部修復(fù)碼(locally repairable codes, LRC)[6].LRC設(shè)計(jì)特點(diǎn)是在Reed-Solomon碼的基礎(chǔ)上，將一個(gè)條帶的所有數(shù)據(jù)塊均分成若干個(gè)組，然后每個(gè)分組針對(duì)組內(nèi)所有的數(shù)據(jù)塊額外編碼生成一個(gè)新的校驗(yàn)塊，稱之為該組的局部校驗(yàn)塊.顯然，任意一個(gè)數(shù)據(jù)塊的丟失，都可以通過其組內(nèi)的局部校驗(yàn)塊和組內(nèi)其他數(shù)據(jù)塊來快速修復(fù)出來，而無須構(gòu)建整個(gè)原始文件來對(duì)丟失的數(shù)據(jù)塊進(jìn)行修復(fù).因此，比起Reed-Solomon碼，LRC可以大大降低修復(fù)丟失的數(shù)據(jù)塊所耗費(fèi)的帶寬，進(jìn)而降低修復(fù)時(shí)間，從而優(yōu)化云存儲(chǔ)系統(tǒng)對(duì)于用戶的訪問延遲，提高數(shù)據(jù)的可用性.

我們發(fā)現(xiàn)，LRC蘊(yùn)含了一個(gè)較強(qiáng)的假設(shè)：所有分組的長度是相同的.由于LRC修復(fù)一個(gè)數(shù)據(jù)塊需要下載它所在組的所有塊，那么這個(gè)假設(shè)就意味著修復(fù)任意一個(gè)數(shù)據(jù)塊均需要下載同樣多的塊，耗費(fèi)同樣多的帶寬.因此在這個(gè)假設(shè)下，想要LRC的修復(fù)效率得到比較好的保障，顯然只有每個(gè)塊丟失的概率較為均勻才比較公平；否則，如果塊和塊之間的丟失概率不同，但修復(fù)代價(jià)卻相同，那么這對(duì)整個(gè)系統(tǒng)的修復(fù)效率就會(huì)產(chǎn)生公平性的影響.

但是，一些研究[7-8]表明：在云存儲(chǔ)系統(tǒng)中，一些數(shù)據(jù)塊的丟失概率其實(shí)遠(yuǎn)遠(yuǎn)大于其他數(shù)據(jù)塊，這是因?yàn)檫@些數(shù)據(jù)塊所在的磁盤可被預(yù)測(cè)出來將在近期內(nèi)發(fā)生故障.實(shí)際上，磁盤是當(dāng)前云存儲(chǔ)系統(tǒng)中最主要的故障來源，磁盤故障占所有設(shè)備故障的78%[9].而磁盤故障大部分是由于諸如磨損之類的緩慢過程所導(dǎo)致的，這些過程通常會(huì)持續(xù)數(shù)月或數(shù)年，因此可以通過對(duì)磁盤歷史狀況不斷監(jiān)測(cè)而對(duì)其近期是否發(fā)生故障進(jìn)行預(yù)測(cè).這樣的話，我們可以通過機(jī)器學(xué)習(xí)等方法提前預(yù)測(cè)到某些磁盤故障的發(fā)生，即近期內(nèi)這些磁盤的故障概率遠(yuǎn)遠(yuǎn)高于其他磁盤——這意味著這些磁盤上的數(shù)據(jù)塊的丟失概率也遠(yuǎn)遠(yuǎn)高于其他數(shù)據(jù)塊.而這個(gè)現(xiàn)象和LRC碼當(dāng)前結(jié)構(gòu)所蘊(yùn)含的假設(shè)——“所有分組的長度相同，所有數(shù)據(jù)塊修復(fù)代價(jià)一樣”——是不匹配的.

因此，這啟發(fā)我們將基于機(jī)器學(xué)習(xí)的磁盤故障預(yù)測(cè)技術(shù)運(yùn)用到LRC中對(duì)其固定分組的假設(shè)進(jìn)行改進(jìn)，以進(jìn)一步提高LRC的修復(fù)性能.需要注意的是，已有相關(guān)研究工作將磁盤故障預(yù)測(cè)技術(shù)應(yīng)用到復(fù)制和糾刪碼技術(shù)中[8]，但LRC擁有不同于復(fù)制和糾刪碼的“條帶分組”的特點(diǎn)，因此需要我們專門針對(duì)該特點(diǎn)進(jìn)行有效的設(shè)計(jì).本文貢獻(xiàn)有3個(gè)方面：

1) 將磁盤故障預(yù)測(cè)技術(shù)的結(jié)果和LRC參數(shù)結(jié)合，構(gòu)造了一類基于預(yù)測(cè)的LRC(proactive LRC, pLRC)方案.pLRC通過磁盤故障預(yù)測(cè)方法，區(qū)分不同數(shù)據(jù)塊的丟失概率，從而動(dòng)態(tài)調(diào)整系統(tǒng)中的LRC分組大小.我們盡可能地讓近期可能丟失的數(shù)據(jù)塊所在分組的長度縮小，從而使得修復(fù)這些塊所需的帶寬降低；同時(shí)，對(duì)于近期不會(huì)丟失的數(shù)據(jù)塊所在分組的長度變長，以保證pLRC的存儲(chǔ)開銷和LRC保持一致.

2) 理論上，我們利用MTTDL建模分析對(duì)比了LRC和pLRC，結(jié)果顯示后者可以提高多達(dá)113%的可靠性.同時(shí)，我們還對(duì)pLRC的修復(fù)帶寬進(jìn)行了理論上的數(shù)值分析，結(jié)果顯示后者修復(fù)帶寬理論上可以降低48.1%.

3) 系統(tǒng)上，我們?cè)贔acebook的Hadoop HDFS RAID[10]平臺(tái)中，通過修改HDFS RAID相關(guān)代碼，實(shí)現(xiàn)了LRC和pLRC技術(shù)，并將其運(yùn)行在真實(shí)云環(huán)境下(Amazon Web Sevice[11]).實(shí)驗(yàn)結(jié)果顯示，比起LRC，pLRC的降級(jí)讀性能提高了46.8%，磁盤修復(fù)時(shí)間縮短了47.5%.

1 研究背景和動(dòng)機(jī)

1.1 云存儲(chǔ)中編碼研究現(xiàn)狀

隨著云業(yè)務(wù)大規(guī)模的落地實(shí)施，數(shù)據(jù)存儲(chǔ)已脫離于單純的存儲(chǔ)介質(zhì)，逐漸演變成一種云服務(wù)，即云存儲(chǔ).相比于傳統(tǒng)的存儲(chǔ)介質(zhì)環(huán)境，云環(huán)境中數(shù)據(jù)量大、應(yīng)用復(fù)雜，這使得云存儲(chǔ)系統(tǒng)要滿足海量的存儲(chǔ)需求和動(dòng)態(tài)的IO服務(wù)需求，因而必須提供高可用性的容錯(cuò)機(jī)制，即持續(xù)穩(wěn)定的在線運(yùn)行性能.對(duì)此，云存儲(chǔ)系統(tǒng)通常采用數(shù)據(jù)冗余技術(shù)來進(jìn)行保駕護(hù)航.傳統(tǒng)的數(shù)據(jù)冗余技術(shù)主要包括副本、RAID等.副本，即存儲(chǔ)同一份數(shù)據(jù)的多個(gè)相同拷貝；數(shù)據(jù)的副本越多、數(shù)據(jù)可靠性越高，但存儲(chǔ)空間利用率也就越低.RAID，即把多塊獨(dú)立的存儲(chǔ)磁盤按特定方式組合起來形成一個(gè)磁盤陣列；該技術(shù)提高了存儲(chǔ)空間的利用率，但傳統(tǒng)磁盤陣列存在著擴(kuò)展性較差、彈性缺乏、容錯(cuò)數(shù)較低等缺陷.因此，副本和RAID較難滿足云存儲(chǔ)的海量存儲(chǔ)和動(dòng)態(tài)變化的服務(wù)需求.

針對(duì)傳統(tǒng)數(shù)據(jù)冗余技術(shù)的不足，云存儲(chǔ)系統(tǒng)中出現(xiàn)了一種更高效的數(shù)據(jù)冗余技術(shù)——糾刪碼，其基本思想是將一份數(shù)據(jù)劃分為k個(gè)原始數(shù)據(jù)塊，基于k個(gè)數(shù)據(jù)塊編碼獲得r個(gè)校驗(yàn)塊.以上k+r個(gè)塊(即k個(gè)數(shù)據(jù)塊和r個(gè)校驗(yàn)塊，通常稱為一個(gè)條帶)中任意r塊出錯(cuò)時(shí)，系統(tǒng)均可重構(gòu)出k個(gè)原始數(shù)據(jù)塊.常用糾刪碼為Reed-Solomon編碼，通常記為(k,r) RS.與副本相比，糾刪碼可以大大提高數(shù)據(jù)可用性[3]；另外，不同于彈性缺乏、容錯(cuò)數(shù)較低的RAID，糾刪碼還具有參數(shù)配置靈活、任意容錯(cuò)的特點(diǎn)(比如可以通過調(diào)整參數(shù)k和r來改變?nèi)哂喽群腿蒎e(cuò)數(shù))，因而可以根據(jù)存儲(chǔ)服務(wù)需求的動(dòng)態(tài)變化，自適應(yīng)地來構(gòu)建糾刪碼.在學(xué)術(shù)界，已有不少工作研究基于糾刪碼的云存儲(chǔ)系統(tǒng).比如，私有云存儲(chǔ)(即企業(yè)內(nèi)部數(shù)據(jù)中心)：Facebook的f4[12]、IBM的Cleversafe[13]、Hitchhiker[14]、Giza[15]等；公有云存儲(chǔ)：Azure[4]，Hybris[16]等.在工業(yè)界，糾刪碼也逐漸成為云存儲(chǔ)產(chǎn)品的標(biāo)配之一，比如，國外云廠商Windows Azure采用(k,r)=(6,4)的糾刪碼[4]，國內(nèi)云廠商七牛云采用(k,r)=(28,4)的糾刪碼[17].

可是當(dāng)某個(gè)數(shù)據(jù)塊丟失時(shí)，糾刪碼需要下載所有k個(gè)塊去重建出原始文件才能對(duì)這個(gè)塊進(jìn)行修復(fù)，這導(dǎo)致數(shù)據(jù)修復(fù)通常需耗費(fèi)大量帶寬，而對(duì)于存儲(chǔ)集群來說，加速恢復(fù)是非常重要的[18].因此不少新型糾刪碼設(shè)計(jì)方案針對(duì)如何對(duì)修復(fù)帶寬進(jìn)行優(yōu)化，主要分為再生碼和局部修復(fù)碼2類：

1) 再生碼(regenerating codes, RC).Dimakis等人首次提出了再生碼[19]，比起傳統(tǒng)糾刪碼降低了單節(jié)點(diǎn)修復(fù)帶寬(即修復(fù)單節(jié)點(diǎn)故障所需的傳輸數(shù)據(jù)量)，并將再生碼分成兩大類,分別為MSR碼(minimal storage regenerating codes)和MBR碼(minimal bandwidth regenerating codes).文獻(xiàn)[20]采用隨機(jī)線性編碼[21]保證了在編碼有限域足夠大的條件下，再生碼的解碼成功率無限趨近于100%.隨后的研究工作可以分成3類：1)由于隨機(jī)線性編碼很難滿足精確修復(fù)特性，即并不保證原始丟失數(shù)據(jù)的恢復(fù)，因此一些工作[22-24]針對(duì)精確修復(fù)的再生碼進(jìn)行了廣泛的研究；2)由于再生碼最初只針對(duì)單節(jié)點(diǎn)修復(fù)，后續(xù)工作致力于多節(jié)點(diǎn)修復(fù)的再生碼設(shè)計(jì)[25-26]；3)還有一些研究專注于確定性再生碼的設(shè)計(jì)[27-28].

2) 局部修復(fù)碼(LRC).LRC[4-5]通過限制數(shù)據(jù)修復(fù)時(shí)所連接的節(jié)點(diǎn)數(shù)目，即將數(shù)據(jù)修復(fù)盡可能局限在較小的節(jié)點(diǎn)集合內(nèi)，來大大降低數(shù)據(jù)傳輸和IO操作數(shù).實(shí)際上，LRC引入了額外的存儲(chǔ)消耗去達(dá)到局部修復(fù)的優(yōu)點(diǎn)，即在理論上并沒有做到存儲(chǔ)效率的最優(yōu)，但是由于其實(shí)現(xiàn)的簡(jiǎn)易性，不少云存儲(chǔ)系統(tǒng)開始部署局部修復(fù)碼，比如Azure[4]，F(xiàn)acebook[5]，Ceph[29-30]等.LRC是在參數(shù)為(k,r)的Reed-Solomon碼的基礎(chǔ)上，將一個(gè)條帶的所有k個(gè)數(shù)據(jù)塊均分成m組，每組有km個(gè)數(shù)據(jù)塊，然后每組將自己所有的km個(gè)數(shù)據(jù)塊通過異或額外生成一個(gè)新的校驗(yàn)塊，稱之為該組的局部校驗(yàn)塊.與之對(duì)應(yīng)，已有的r個(gè)校驗(yàn)塊稱之為全局校驗(yàn)塊.

圖1是(k,m,r) LRC的示例圖，其中k=6,m=2,r=2.D1～D6是6個(gè)數(shù)據(jù)塊，P1和P2是通過D1～D6編碼生成的2個(gè)全局校驗(yàn)塊.然后將所有數(shù)據(jù)塊分為2組：D1～D3，D4～D6，每組異或編碼生成一個(gè)新的局部校驗(yàn)塊：Q1和Q2.我們可以發(fā)現(xiàn)，D1～D6中無論哪一個(gè)數(shù)據(jù)塊丟失，都可以通過該塊所在組的局部校驗(yàn)塊快速修復(fù)出來.比如，假設(shè)數(shù)據(jù)塊D1丟失，如果是基于Reed-Solomon編碼，則需要下載D2～D6以及P1一共6個(gè)塊將D1修復(fù)；而如果基于LRC，則僅需要下載D2，D3以及Q1一共3個(gè)塊即可修復(fù)D1.因此，比起Reed-Solomon碼，LRC可以降低大大降低修復(fù)一個(gè)丟失塊的所需時(shí)間，從而優(yōu)化云存儲(chǔ)系統(tǒng)對(duì)于用戶的訪問性能.

Fig. 1 An illustration of (6,2,2) LRC圖1 (6,2,2) LRC的示例圖

1.2 云存儲(chǔ)中磁盤故障預(yù)測(cè)研究現(xiàn)狀

云存儲(chǔ)系統(tǒng)發(fā)生服務(wù)中斷的代價(jià)越來越高昂[31]，服務(wù)中斷最大的一個(gè)原因是磁盤設(shè)備發(fā)生故障[9,32].硬盤的故障一般分為2種：不可預(yù)測(cè)的和可預(yù)測(cè)的.前者發(fā)生幾率不高，通常不可預(yù)測(cè)，比如人為不當(dāng)操作造成的機(jī)械撞擊等；但后者比如像軸承磨損、磁介質(zhì)性能下降等都可以在幾天甚至幾周前就發(fā)現(xiàn)苗頭從而進(jìn)行規(guī)避.

SMART 技術(shù)通過在硬盤硬件內(nèi)的檢測(cè)指令對(duì)硬盤的各個(gè)硬件如磁頭、馬達(dá)、電路、盤片的運(yùn)行情況進(jìn)行監(jiān)控，并與廠商所預(yù)設(shè)的安全值進(jìn)行比較，若監(jiān)控情況將超出或已超出預(yù)設(shè)安全值的安全范圍時(shí)發(fā)出警報(bào).但該方法只能預(yù)測(cè)出不到10%的硬盤故障[33].因此，有不少研究工作在SMART數(shù)據(jù)集上建立各種預(yù)測(cè)模型，以提高硬盤的故障率預(yù)測(cè)準(zhǔn)確率.這些磁盤故障預(yù)測(cè)模型[7,34-37]通常有3個(gè)主要參數(shù)：

1) 準(zhǔn)確率(false discovery rate,FDR)，即故障磁盤中可以被準(zhǔn)確預(yù)測(cè)出的比例.

2) 誤報(bào)率(false alarm rate,FAR)，即健康磁盤中被誤報(bào)為故障磁盤的比例.

3) 提前預(yù)測(cè)時(shí)間(time in advance,TIA)，即提前多長時(shí)間預(yù)測(cè)磁盤故障.

文獻(xiàn)[33]提出了一種基于多實(shí)例學(xué)習(xí)框架和樸素貝葉斯分類器的故障預(yù)測(cè)算法，但僅使用了369個(gè)磁盤的SMART數(shù)據(jù)集.文獻(xiàn)[35]采用貝葉斯方法對(duì)磁盤故障進(jìn)行建模，數(shù)據(jù)集由1 936個(gè)磁盤組成，其中只有9個(gè)被標(biāo)記為失敗，同樣也比較小.文獻(xiàn)[36]利用統(tǒng)計(jì)檢驗(yàn)相關(guān)方法(如多變量秩和檢驗(yàn))提高FDR和降低FAR，同樣的數(shù)據(jù)集也相當(dāng)小，只有347個(gè)磁盤器(其中36個(gè)故障).文獻(xiàn)[34,37]采用人工神經(jīng)網(wǎng)絡(luò)和決策樹等學(xué)習(xí)方法，數(shù)據(jù)集規(guī)模較大，包含來自企業(yè)級(jí)模型的總共23 395個(gè)磁盤(其中433個(gè)故障).該方法最好預(yù)測(cè)性能達(dá)到0.1%以下的FAR和95%以上的FDR，且TIA至少為一周以上，從而為故障處理預(yù)留了充足時(shí)間.文獻(xiàn)[7]同樣使用了一個(gè)包含超過20 000個(gè)磁盤的大型數(shù)據(jù)集，通過選擇合適的SMART指標(biāo)并調(diào)整預(yù)測(cè)模型，使得FDR高達(dá)98%.

1.3 本文研究動(dòng)機(jī)

當(dāng)前很少有工作將云存儲(chǔ)系統(tǒng)中的編碼技術(shù)和磁盤故障預(yù)測(cè)技術(shù)聯(lián)系起來，文獻(xiàn)[8]提出了一類基于磁盤故障預(yù)測(cè)技術(shù)的糾刪碼技術(shù)Procode.Procode的技術(shù)原理是把復(fù)制和糾刪碼結(jié)合起來，將預(yù)測(cè)的故障磁盤的數(shù)據(jù)塊和校驗(yàn)塊進(jìn)行復(fù)制，使得這些塊在丟失以后無須通過糾刪碼恢復(fù)，只用通過復(fù)制恢復(fù)即可，因此降低修復(fù)這些塊所需要的時(shí)間.文獻(xiàn)[8]的作者在其工作展望中希望有工作能將Procode的策略思想和新型的編碼技術(shù)相結(jié)合起來.但是，如果直接將Procode對(duì)即將丟失的數(shù)據(jù)塊進(jìn)行簡(jiǎn)單復(fù)制的策略和新型編碼技術(shù)LRC技術(shù)結(jié)合的話，那么將會(huì)破壞LRC的單一編碼結(jié)構(gòu)而造成副本一致性維護(hù)問題，并且還會(huì)引入額外的存儲(chǔ)開銷、增加磁盤個(gè)數(shù)而加大系統(tǒng)存儲(chǔ)管理成本.

因此，這啟發(fā)我們?cè)贚RC的編碼結(jié)構(gòu)和存儲(chǔ)開銷不變的前提下，將磁盤故障預(yù)測(cè)技術(shù)結(jié)果和LRC編碼結(jié)合起來，構(gòu)造了一類基于預(yù)測(cè)的LRC編碼.pLRC算法首先通過文獻(xiàn)[34]提供的一類磁盤故障預(yù)測(cè)方法以及相應(yīng)的大型SMART數(shù)據(jù)集，區(qū)分一周的即將故障的磁盤(稱為“壞盤”)和其他健康磁盤(稱之為“好盤”)；然后僅僅調(diào)整壞盤和好盤所擁有的數(shù)據(jù)塊所在分組的大小，使得壞盤的數(shù)據(jù)塊所在分組的長度變短，而這些分組為了保持存儲(chǔ)量不變，同時(shí)將分組內(nèi)其他好盤的數(shù)據(jù)塊所在分組變長，并同步更新組內(nèi)的校驗(yàn)塊.這樣的話，pLRC的編碼結(jié)構(gòu)依然和LRC保持一致，只是部分條帶的分組組長不同；同時(shí)pLRC的存儲(chǔ)開銷和LRC也保持了一致.更重要的是，pLRC會(huì)對(duì)一周內(nèi)大概率壞掉的磁盤進(jìn)行快速修復(fù)，從而提高數(shù)據(jù)塊修復(fù)性能.

Fig. 2 An illustration of pLRC from (6,2,2) LRC圖2 (6,2,2) LRC 轉(zhuǎn)換為pLRC的示例圖

2 pLRC的設(shè)計(jì)

在本節(jié)中，我們主要對(duì)pLRC的設(shè)計(jì)算法進(jìn)行描述.

2.1 磁盤故障預(yù)測(cè)算法選擇

當(dāng)前有包括決策樹、人工神經(jīng)網(wǎng)絡(luò)等機(jī)器學(xué)習(xí)算法可用于預(yù)測(cè)磁盤，我們的目標(biāo)是在FDR和FAR之間找到一個(gè)較好的權(quán)衡.為了實(shí)現(xiàn)這一目標(biāo)，我們對(duì)當(dāng)前主流的2類分類算法：決策樹[37]和人工神經(jīng)網(wǎng)絡(luò)[34]進(jìn)行了比較.和文獻(xiàn)[34]類似，我們?cè)陂_源的SMART數(shù)據(jù)集[38]上針對(duì)12個(gè)特征(見表1)進(jìn)行采樣.SMART數(shù)據(jù)集包含23 395個(gè)磁盤(其中433個(gè)壞盤、22 962個(gè)好盤)在7天內(nèi)的SMART記錄，其中每個(gè)盤每小時(shí)都會(huì)生成一條SMART記錄，因此每個(gè)好盤有168條記錄，而壞盤記錄到自己發(fā)生故障為止.然后，我們將采樣數(shù)據(jù)集隨機(jī)拆分為訓(xùn)練數(shù)據(jù)集(占總數(shù)據(jù)集的70%)，并通過交叉驗(yàn)證測(cè)試數(shù)據(jù)集(占總數(shù)據(jù)集的30%).2個(gè)預(yù)測(cè)算法的性能如表2所示.

Table 1 Selected SMART Attributes表1 所選的SMART屬性

Table 2 Performance Comparison of Decision Tree and BP Neural Network表2 決策樹和人工神經(jīng)網(wǎng)絡(luò)的性能比較

從表2可以看出，決策樹和人工神經(jīng)網(wǎng)絡(luò)都能達(dá)到良好的預(yù)測(cè)準(zhǔn)確性；但人工神經(jīng)網(wǎng)絡(luò)的誤報(bào)率較高，會(huì)導(dǎo)致pLRC錯(cuò)把不少的好盤上所保存的數(shù)據(jù)塊也進(jìn)行分組大小調(diào)整而耗費(fèi)不小的帶寬.因此，我們選擇決策樹作為我們的預(yù)測(cè)算法.

2.2 pLRC編碼算法設(shè)計(jì)

pLRC編碼算法有2個(gè)主要的設(shè)計(jì)目標(biāo)：

1) 和LRC保持同樣的存儲(chǔ)開銷和磁盤個(gè)數(shù)；

2) 比LRC擁有更低的數(shù)據(jù)塊修復(fù)帶寬.

針對(duì)這2個(gè)設(shè)計(jì)目標(biāo)，pLRC的設(shè)計(jì)思想是對(duì)所有數(shù)據(jù)塊進(jìn)行“好”“壞”標(biāo)記；然后在磁盤故障預(yù)測(cè)算法運(yùn)行后，壞盤上的數(shù)據(jù)塊標(biāo)記為“壞塊”；最后針對(duì)每個(gè)壞塊所在的條帶，縮短該壞塊所在分組的組長，變長其他分組的組長，使得該條帶所造成的存儲(chǔ)開銷和所需磁盤個(gè)數(shù)保持不變，并且壞塊的修復(fù)所造成的帶寬消耗降低.算法細(xì)節(jié)如下：

算法1.pLRC編碼.

假設(shè)：系統(tǒng)有N個(gè)磁盤，每個(gè)磁盤擁有p個(gè)數(shù)據(jù)塊，每個(gè)條帶最多只包含一個(gè)壞塊.

① 所有數(shù)據(jù)塊都標(biāo)為“好塊”；

② 執(zhí)行(k,m,r) LRC；

③ 運(yùn)行Decision Tree算法，輸出壞盤H1,H2,…,Hb；

⑥ fori=1 tobp

⑦Si所有分組記為Gi,1,Gi,2,…Gi,m；

⑩Gi,1,Gi,2,…,Gi,m更新校驗(yàn)塊；

算法1在初始狀態(tài)時(shí)，所有數(shù)據(jù)塊都標(biāo)記為“好塊”，然后執(zhí)行LRC編碼(行①②).在決策樹預(yù)測(cè)算法過后，預(yù)測(cè)為壞盤所保存的數(shù)據(jù)塊標(biāo)記為“壞塊”，然后找到所有壞塊所在的條帶(行③～⑤).最后對(duì)所有這些bp個(gè)條帶進(jìn)行分組大小調(diào)整：含有壞塊的分組長度縮短為3(即原分組縮小為僅包含2個(gè)數(shù)據(jù)塊和1個(gè)校驗(yàn)塊的分組)，即該分組為簡(jiǎn)單的(2,1) RS編碼；然后該分組的其他塊隨機(jī)轉(zhuǎn)移到其他分組，最后更新分組的校驗(yàn)塊.

Fig. 3 Illustrations of pLRC圖3 pLRC的算法示例圖

2.3 pLRC算法優(yōu)化

當(dāng)所有壞塊被修復(fù)以后，pLRC應(yīng)該回歸LRC以等待下一次磁盤故障預(yù)測(cè)算法的執(zhí)行.基于算法1的編碼策略，我們可以發(fā)現(xiàn)需要對(duì)大量的局部校驗(yàn)塊進(jìn)行更新，將造成較大的傳輸開銷.因此，我們對(duì)pLRC算法進(jìn)行進(jìn)一步的優(yōu)化，優(yōu)化思想是通過盡可能地減少局部校驗(yàn)塊的更新個(gè)數(shù)來降低其更新所帶來的開銷.算法細(xì)節(jié)如下：

算法2.pLRC編碼(優(yōu)化).

①～⑧和算法1相同；

⑨Gi,1分組保留di和任意一個(gè)數(shù)據(jù)塊，將其他數(shù)據(jù)塊全部轉(zhuǎn)移到Gi,2;

⑩Gi,1和Gi,2更新校驗(yàn)塊;

算法2將壞塊所在分組需要轉(zhuǎn)移的數(shù)據(jù)塊全部放在另外一個(gè)分組內(nèi)，使得需要更新的校驗(yàn)塊永遠(yuǎn)只有2個(gè).因此，在從pLRC回歸到LRC時(shí)，只需要對(duì)2個(gè)校驗(yàn)塊進(jìn)行更新，這樣可以將2個(gè)校驗(yàn)塊的更新操作協(xié)同起來，從而降低傳輸開銷.

3 理論量化分析

在本節(jié)中，我們主要在理論上對(duì)pLRC的可靠性以及修復(fù)過程中消耗的帶寬進(jìn)行分析，并與LRC進(jìn)行比較.

3.1 可靠性分析

可靠性是分布式系統(tǒng)中最重要的性質(zhì)之一，下面對(duì)pLRC的可靠性進(jìn)行分析.與之前的很多工作類似[4-5,39-42]，我們使用馬爾可夫模型來對(duì)平均無數(shù)據(jù)丟失時(shí)間(mean-time-to-data-loss, MTTDL)進(jìn)行分析.與文獻(xiàn)[4]相同，我們對(duì)一般化馬爾可夫模型進(jìn)行簡(jiǎn)單的擴(kuò)展使其可以捕捉到LRC以及pLRC中的特殊狀態(tài)變換.雖然基于馬爾可夫的可靠性分析的有效性值得商榷[43]，但我們認(rèn)為它足以為本工作提供可靠性的初步見解.

1) 模型.將參數(shù)固定為k=6,m=2,r=2.圖4為LRC和pLRC參數(shù)(k,m,r)=(6,2,2)的馬爾可夫模型.假定我們將多個(gè)條帶上的數(shù)據(jù)分布于k+m+r個(gè)節(jié)點(diǎn)上，每種狀態(tài)代表可用節(jié)點(diǎn)的數(shù)量.比如狀態(tài)10表示全部節(jié)點(diǎn)都是健康節(jié)點(diǎn)，而狀態(tài)5則表示有數(shù)據(jù)丟失.在本文中，我們僅考慮獨(dú)立故障，將單節(jié)點(diǎn)的故障率記為λ.因此，從狀態(tài)i到狀態(tài)i-1，1≤i≤n的狀態(tài)轉(zhuǎn)換率為iλ.

Fig. 4 Markov reliability model圖4 馬爾可夫可靠性模型

馬爾可夫模型中增加的擴(kuò)展部分位于狀態(tài)7，其可轉(zhuǎn)換為2個(gè)擁有6個(gè)健康節(jié)點(diǎn)的狀態(tài).狀態(tài)6代表了有4個(gè)可修復(fù)的故障，而狀態(tài)6F則表示了有4個(gè)不可修復(fù)的故障.我們將在4個(gè)故障情形中可修復(fù)故障的比例記為pd,則從狀態(tài)7到狀態(tài)6的轉(zhuǎn)換率為7λpd，而從狀態(tài)7到狀態(tài)6F的轉(zhuǎn)換率為7λ(1-pd).

在反方向的修復(fù)模型上，我們將從狀態(tài)i到狀態(tài)i+1進(jìn)行修復(fù)的修復(fù)率記為μ，其中在狀態(tài)轉(zhuǎn)換中使用LRC修復(fù)的修復(fù)率記為μ1，而對(duì)于pLRC從狀態(tài)9到狀態(tài)10的過程中使用(2,1) RS碼的修復(fù)率記為μ2.在pLRC中，對(duì)于使用磁盤預(yù)測(cè)技術(shù)預(yù)測(cè)出的故障磁盤，我們將采用(2,1) RS碼進(jìn)行局部修復(fù)；對(duì)于未能預(yù)測(cè)出的故障磁盤，將仍使用LRC來進(jìn)行修復(fù).因此，pLRC中從狀態(tài)9到狀態(tài)10的修復(fù)率μ=(1-FDR)×μ1+FDR×μ2.

我們可以按如下方式配置參數(shù)：對(duì)于λ，我們假定一個(gè)節(jié)點(diǎn)的平均無故障時(shí)間(mean-time-to-failure, MTTF)為4年[5](也就是說，1λ=4年).我們把節(jié)點(diǎn)間的可用帶寬記為γ，集群中的節(jié)點(diǎn)數(shù)為M，單節(jié)點(diǎn)上的存儲(chǔ)量記為S，修復(fù)每一單元數(shù)據(jù)所需要的修復(fù)開銷記為C.例如，在(k,m,r)=(6,2,2)時(shí)，對(duì)于LRC來說，C=(3×8+6×2)10=185，pd=86%[4]，因此μ1=γ(M-1)(18S5)；而對(duì)于pLRC來說，C=(2×8+6×2)10=145，因此μ2=γ(M-1)(14S5).

2) 分析.我們現(xiàn)在對(duì)LRC和pLRC策略下的MTTDL進(jìn)行分析.采用2.1節(jié)所使用的SMART數(shù)據(jù)集，其中23 395個(gè)磁盤約30%作為測(cè)試集(M=7 019)，使用一組經(jīng)典的參數(shù)(S=16 TB，網(wǎng)絡(luò)帶寬利用率為0.1)[5]來對(duì)不同網(wǎng)絡(luò)帶寬下的兩者的可靠性進(jìn)行計(jì)算.結(jié)果如表3所示：

Table 3 MTTDLs of LRC and pLRC for Different Values of Bandwidth表3 不同帶寬下LRC和pLRC的MTTDL a

從表3中數(shù)據(jù)我們得到，在不同的網(wǎng)絡(luò)帶寬下，pLRC的MTTDL最多比LRC提高113%.主要的原因是pLRC提前預(yù)測(cè)了磁盤故障，并使用修復(fù)效率較高的(2,1) RS碼進(jìn)行局部修復(fù)，提升了系統(tǒng)的可靠性.我們還能看到，網(wǎng)絡(luò)帶寬越高，兩者的MTTDL均越高.這是由于網(wǎng)絡(luò)帶寬越高，其余參數(shù)不變的情況下，修復(fù)率μ也越高，從而提升了可靠性.

3.2 修復(fù)帶寬分析

對(duì)于(k,m,r) LRC和(k,m,r) pLRC，我們將LRC中修復(fù)每一單元所需的修復(fù)帶寬記為CLRC，將pLRC中修復(fù)每一單元所需的修復(fù)帶寬記為CpLRC.我們假定每個(gè)條帶中最多含有一個(gè)壞盤上的塊，通過對(duì)LRC進(jìn)行分析得到：

(1)

注意:pLRC將預(yù)測(cè)將要壞掉的數(shù)據(jù)塊使用(2,1)RS進(jìn)行恢復(fù)，而未被預(yù)測(cè)中的塊則仍使用原來的(k,m,r) LRC進(jìn)行修復(fù).同時(shí)，壞盤中的全局編碼塊也仍使用(k,m,r) LRC進(jìn)行修復(fù).因此，我們得到：

(2)

Fig. 5 Numerical results of recovery bandwidth for LRC and pLRC圖5 LRC和pLRC修復(fù)帶寬的理論分析結(jié)果

通過計(jì)算式(1)、式(2)兩個(gè)等式的差可以得到pLRC相對(duì)于LRC減少的修復(fù)帶寬：

(3)

由式(3)可以得出，km越大以及FDR越大，則CLRC-CpLRC越大，也就是pLRC相對(duì)于LRC來說，修復(fù)帶寬減少得越多，修復(fù)帶寬越小.

如2.1節(jié)所示，根據(jù)基于決策樹的磁盤預(yù)測(cè)算法的結(jié)果FDR≈93%，我們對(duì)(6,2,2) pLRC和(12,2,2) pLRC的修復(fù)帶寬分別進(jìn)行計(jì)算，并和相應(yīng)的LRC進(jìn)行比較，具體結(jié)果如圖5所示:

從圖5可以看出，對(duì)于(6,2,2) LRC和(6,2,2) pLRC，CLRC=3.6，CpLRC=2.86，且CLRC-CpLRC=0.74.也就是說，修復(fù)一個(gè)單元的數(shù)據(jù)，LRC需要3.6個(gè)單元的數(shù)據(jù)來進(jìn)行修復(fù)，而pLRC僅需要2.86個(gè)單元即可修復(fù)，此時(shí)pLRC相對(duì)LRC的修復(fù)帶寬下降了大約20.6%.同樣地，在(k,m,r)=(12,2,2)時(shí)，pLRC相對(duì)LRC的修復(fù)帶寬下降了大約48.1%.

我們發(fā)現(xiàn)，(12,2,2) pLRC對(duì)(6,2,2)pLRC的修復(fù)開銷下降得更多，這是因?yàn)樵贔DR相同的情況下，(12,2,2) pLRC的km=6大于(6,2,2) pLRC 的km=3，由式(3)可知，前者的修復(fù)帶寬下降更多.這說明條帶越長，我們的算法效果越好，這符合實(shí)際云存儲(chǔ)廠商為了降低存儲(chǔ)成本采用大條帶的事實(shí)[16].

3.3 pLRC更新開銷分析

pLRC的更新開銷包括2個(gè)部分：LRC重組成pLRC和pLRC回歸為LRC時(shí)，算法2與算法1更新操作所造成的傳輸.下面我們對(duì)(k,m,r) pLRC的這2個(gè)算法在重組與回歸過程中的更新造成的傳輸開銷進(jìn)行分析.

1) 對(duì)算法1的更新方式的傳輸開銷進(jìn)行分析.在重組過程中，其將一個(gè)分組中的km個(gè)塊除去壞塊以及任意一個(gè)塊，也就是將剩余的km-2個(gè)塊隨機(jī)均勻轉(zhuǎn)移到其余m-1組中去.算法1需要對(duì)這m-1個(gè)組中的編碼塊進(jìn)行更新，同時(shí)也需要傳輸2個(gè)塊(壞塊以及任意一個(gè)塊)來對(duì)第1個(gè)分組中的編碼塊進(jìn)行更新，因而在重組過程中一共需要傳輸km個(gè)塊.在回歸過程中，算法1需要將之前重組出去的km-2個(gè)塊收集至第1個(gè)分組中以對(duì)第1個(gè)分組的編碼塊進(jìn)行更新，并且這km-2個(gè)塊需要對(duì)重組過程中更新的m-1個(gè)組的編碼塊進(jìn)行更新.在回歸過程中一共需要傳輸2(km-2)個(gè)塊.因此，我們可以得到算法1的更新方式的傳輸開銷為

(4)

2) 對(duì)算法2的更新方式的傳輸開銷進(jìn)行分析.在重組過程中，其將一個(gè)分組中剩余的km-2個(gè)塊均轉(zhuǎn)移至第2個(gè)分組中，這樣算法2可以先將2個(gè)塊(壞塊以及任意一個(gè)塊)傳至第1個(gè)分組中的編碼塊，以生成新的編碼塊.然后算法2利用第1個(gè)分組中舊的編碼塊與這2個(gè)塊生成一個(gè)異或塊，并將其傳至第2個(gè)分組的編碼塊上對(duì)編碼塊進(jìn)行更新.因而在重組過程中算法2一共需要傳輸3個(gè)塊.在回歸過程中，算法2需要將之前重組出去的km-2個(gè)塊收集至第1個(gè)分組中以對(duì)第1個(gè)分組的編碼塊進(jìn)行更新，同時(shí)，算法2利用收集的這km-2個(gè)塊生成一個(gè)更新塊.然后算法2將這個(gè)更新塊傳至第2個(gè)分組的編碼塊上以對(duì)其進(jìn)行更新.這樣，在回歸過程中一共需要傳輸km-2+1=km-1個(gè)塊.因此，我們可以得到算法2的更新方式的傳輸開銷為

(5)

現(xiàn)在通過計(jì)算式(4)、式(5)兩個(gè)等式的差來得到算法2相對(duì)于算法1減少的傳輸開銷：

(6)

在LRC的算法中，分組中至少有3個(gè)塊(2個(gè)數(shù)據(jù)塊、1個(gè)編碼塊)，因此km≥3.通過式(6)我們發(fā)現(xiàn)算法2的更新方式的傳輸開銷要小于等于算法1的開銷,且km越大，算法2的傳輸開銷相對(duì)于算法1來說越有優(yōu)勢(shì).

根據(jù)式(4)(5)，我們計(jì)算出不同分組內(nèi)塊數(shù)量下的算法傳輸開銷，如圖6所示:

Fig. 6 Transfer cost of algorithm 1 and algorithm 2圖6 算法1和算法2更新方式的傳輸開銷

從圖6中我們可以看到，算法1的開銷要大于算法2的開銷，且2種算法的開銷之差也隨著分組內(nèi)塊的數(shù)量的增多而不斷增加.

4 實(shí)驗(yàn)與結(jié)果

在本節(jié)中，我們?cè)谠粕线\(yùn)行了實(shí)驗(yàn)，測(cè)試了pLRC的降級(jí)讀性能以及修復(fù)性能，并將其與LRC進(jìn)行對(duì)比.

4.1 實(shí)驗(yàn)部署環(huán)境

我們將pLRC部署在Facebook的HDFS[10]中，其通過整合HDFS-RAID[44]以在Hadoop Distributed File System (HDFS)[45]中支持糾刪碼.下面我們先對(duì)HDFS如何實(shí)現(xiàn)糾刪碼進(jìn)行概述，然后介紹我們?nèi)绾卧贖DFS中部署pLRC.

4.1.1 HDFS簡(jiǎn)概

HDFS是學(xué)術(shù)界和工業(yè)界部署應(yīng)用最為廣泛的分布式存儲(chǔ)系統(tǒng)之一.它由2種類型的節(jié)點(diǎn)組成：一個(gè)執(zhí)行管理操作并包含各種元數(shù)據(jù)的NameNode，以及多個(gè)包含數(shù)據(jù)的DataNode.HDFS將數(shù)據(jù)分為固定大小的塊，這些塊作為基本單元來進(jìn)行讀、寫以及編碼等操作.

HDFS-RAID引入了一個(gè)RaidNode來處理糾刪碼的相關(guān)操作如編碼、修復(fù)等.RaidNode首先將數(shù)據(jù)存儲(chǔ)為多個(gè)副本，并將這些副本分布在不同節(jié)點(diǎn)上.一段時(shí)間后，RaidNode通過使用MapReduce[46]來將這些塊轉(zhuǎn)換為編碼過的塊.具體來說，為了構(gòu)建參數(shù)為(k,r)的糾刪碼，MapReduce作業(yè)中的map任務(wù)從不同的DataNode上收集k個(gè)編碼塊，然后將它們編碼為r個(gè)校驗(yàn)塊，并將這k+r個(gè)塊分布至k+r個(gè)DataNode上.此外，RaidNode還會(huì)定期檢查是否存在故障塊，并觸發(fā)修復(fù)操作來修復(fù)故障塊.

4.1.2 pLRC部署

下面我們將解釋如何擴(kuò)展Facebook的HDFS以對(duì)pLRC進(jìn)行支持.具體架構(gòu)如圖7所示:

Fig. 7 Architecture of pLRC圖7 pLRC架構(gòu)圖

1) LRC和pLRC編碼模塊.我們?cè)贖DFS上增加了LRC編碼，并實(shí)現(xiàn)了在預(yù)測(cè)到磁盤將要發(fā)生故障時(shí)將LRC編碼轉(zhuǎn)變?yōu)閜LRC編碼的相關(guān)模塊.我們主要實(shí)現(xiàn)了LRC以及pLRC這2種編碼的編解碼以及修復(fù)操作.對(duì)于LRC，我們主要是增加了分組，計(jì)算出分組內(nèi)的局部校驗(yàn)塊，并通過Placement Manager模塊指定其所有塊的放置位置. LRC的分組信息、分組內(nèi)局部校驗(yàn)塊的信息以及塊放置信息均存儲(chǔ)于RaidNode上，以備修復(fù)過程及轉(zhuǎn)換至pLRC時(shí)使用.對(duì)于pLRC, 我們首先在模塊中增加getPredictingInfo API，通過此API從磁盤故障預(yù)測(cè)算法中獲取預(yù)測(cè)的結(jié)果即壞盤；然后從NameNode獲取壞盤中所有壞塊相關(guān)的條帶信息，從RaidNode獲取分組、校驗(yàn)塊信息以及塊放置信息；最后通過傳輸塊對(duì)分組校驗(yàn)塊進(jìn)行更新，使得壞塊所在的條帶從LRC編碼轉(zhuǎn)變?yōu)閜LRC編碼.

對(duì)于修復(fù)操作，我們主要關(guān)注單節(jié)點(diǎn)的故障修復(fù).現(xiàn)在支持2類修復(fù)操作：①節(jié)點(diǎn)修復(fù).指的是某個(gè)節(jié)點(diǎn)發(fā)生故障時(shí)，對(duì)其上所有丟失的數(shù)據(jù)塊進(jìn)行修復(fù).由于每個(gè)丟失的數(shù)據(jù)塊位于不同的條帶中，因此利用條帶中的其余數(shù)據(jù)對(duì)其進(jìn)行修復(fù).當(dāng)RaidNode檢測(cè)到節(jié)點(diǎn)故障時(shí)，RaidNode會(huì)調(diào)用pLRC的修復(fù)函數(shù)來進(jìn)行節(jié)點(diǎn)修復(fù)，其先從NameNode獲取相關(guān)所有條帶信息.對(duì)每一個(gè)條帶，pLRC從RaidNode上獲取相關(guān)的分組信息及放置信息，然后利用這些信息調(diào)用相關(guān)的DataNode傳輸修復(fù)所需的塊至新節(jié)點(diǎn)上以進(jìn)行修復(fù)操作.②降級(jí)讀.指的是修復(fù)某個(gè)當(dāng)前不可用的數(shù)據(jù)塊.我們對(duì)文件系統(tǒng)客戶端進(jìn)行了修改，當(dāng)客戶端讀取數(shù)據(jù)發(fā)現(xiàn)不能獲取某個(gè)塊時(shí)，會(huì)觸發(fā)塊丟失故障異常.此時(shí)客戶端將調(diào)用RaidNode上的pLRC從相關(guān)DataNode上讀取分組中的相關(guān)塊來對(duì)丟失塊進(jìn)行修復(fù)，并將修復(fù)出的塊傳給客戶端，從而完成降級(jí)讀操作.

2) ISA-L計(jì)算模塊.以上的2種編碼我們均通過使用Intel的ISA-L[47]硬件加速庫來實(shí)現(xiàn)快速編解碼.我們通過Java Native Interface (JNI)來將具體的編解碼操作與Hadoop連接起來，從而極大地加速了編解碼操作.我們主要使用2個(gè)ISA-L的API：用來指定編碼系數(shù)的ec_init_tables以及用來具體執(zhí)行編解碼操作的ec_encode_data.這些ISA_L的API將基于硬件配置來自動(dòng)對(duì)計(jì)算過程進(jìn)行優(yōu)化.

3) 數(shù)據(jù)布局.LRC及pLRC編碼在編解碼完成后需要考慮將數(shù)據(jù)塊如何在集群中進(jìn)行放置.因此我們將數(shù)據(jù)布局增添到HDFS中，通過對(duì)RaidNode中的數(shù)據(jù)布局管理模塊進(jìn)行更改，以此來指定條帶中的數(shù)據(jù)具體是如何放置的.即如何把編碼后的同一條帶中的數(shù)據(jù)塊與編碼塊隨機(jī)地放置到集群中的不同節(jié)點(diǎn)上或是將解碼后的數(shù)據(jù)塊放置到特定的節(jié)點(diǎn)上.

4.2 實(shí)驗(yàn)配置與方法

1) 實(shí)驗(yàn)環(huán)境配置.我們的實(shí)驗(yàn)部署在Amazon EC2[11]上.使用位于美國東部(弗吉尼亞北部)區(qū)域的17個(gè)m4.4xlarge實(shí)例來進(jìn)行實(shí)驗(yàn)，其中有1個(gè)實(shí)例用作管理節(jié)點(diǎn)NameNode及編解碼節(jié)點(diǎn)RaidNode，其余16個(gè)實(shí)例用作數(shù)據(jù)節(jié)點(diǎn)DataNode.這些實(shí)例均基于Ubuntu 14.04的Linux平臺(tái)，具體硬件配置為16核CPU、64 GB內(nèi)存、2 TB SSD.

2) 實(shí)驗(yàn)方法.我們測(cè)試了4種不同參數(shù)下pLRC的降級(jí)讀延遲以及單節(jié)點(diǎn)修復(fù)時(shí)間，并與LRC進(jìn)行對(duì)比.這4組參數(shù)分別是：微軟Azure[4]中采用的(6,2,2),(12,2,2)，F(xiàn)aceook集群[5]中采用的(10,2,4)，以及理論最優(yōu)LRC[48]中采用的(6,2,3).

對(duì)于(6,2,2) pLRC，我們使用了總量為6 TB的數(shù)據(jù)來進(jìn)行編碼，生成4 TB的編碼數(shù)據(jù); 對(duì)于(12,2,2) pLRC我們使用了總量為12 TB的數(shù)據(jù)來進(jìn)行編碼，生成4 TB的編碼數(shù)據(jù); 對(duì)于(10,2,4) pLRC我們使用了總量為10 TB的數(shù)據(jù)來進(jìn)行編碼，生成6 TB的編碼數(shù)據(jù); 對(duì)于(6,2,3) pLRC我們使用了總量為6 TB的數(shù)據(jù)來進(jìn)行編碼，生成5 TB的編碼數(shù)據(jù).我們將這些數(shù)據(jù)分別均勻分布在10，16，16及11個(gè)數(shù)據(jù)節(jié)點(diǎn)上，每個(gè)數(shù)據(jù)節(jié)點(diǎn)存放1 T數(shù)據(jù)，取每個(gè)實(shí)驗(yàn)的5次平均運(yùn)行結(jié)果.

4.3 實(shí)驗(yàn)結(jié)果

1) 數(shù)據(jù)塊降級(jí)讀性能.我們測(cè)試了當(dāng)文件系統(tǒng)客戶端讀取一個(gè)不可用數(shù)據(jù)塊的降級(jí)讀性能.在系統(tǒng)中隨機(jī)擦除掉一個(gè)數(shù)據(jù)塊，然后讓文件系統(tǒng)客戶端通過降級(jí)讀的方式來獲取該數(shù)據(jù)塊.降級(jí)讀性能的測(cè)試結(jié)果如圖8所示:

Fig. 8 Degraded read performance for LRC and pLRC圖8 LRC和pLRC的降級(jí)讀性能

在圖8中可以看到，在(k,m,r)=(12,2,2) 時(shí)，LRC的降級(jí)讀時(shí)延為42.25 ms，pLRC的降級(jí)讀時(shí)延為22.49 ms.pLRC相對(duì)于LRC來說減少了降級(jí)讀的時(shí)延，降級(jí)讀性能提升了大約46.8%.這主要是由于pLRC通過對(duì)預(yù)測(cè)到的壞盤使用(2,1) RS編碼，大大減少了降級(jí)讀時(shí)的修復(fù)開銷，從而使得降級(jí)讀性能得以提升.

我們還發(fā)現(xiàn)pLRC相對(duì)LRC來說，其在(k,m,r)=(12,2,2)情況下的降級(jí)讀性能提升要比(k,m,r)=(6,2,2)大.和3.2節(jié)理論分析結(jié)果較為一致.

2) 節(jié)點(diǎn)修復(fù)性能.我們還測(cè)試了節(jié)點(diǎn)修復(fù)性能，即當(dāng)某個(gè)節(jié)點(diǎn)發(fā)生故障時(shí)，系統(tǒng)對(duì)該節(jié)點(diǎn)上的多個(gè)數(shù)據(jù)塊進(jìn)行修復(fù)所消耗的時(shí)間.隨機(jī)選取一個(gè)節(jié)點(diǎn)，擦除掉上面的所有塊，然后分別使用pLRC和LRC來修復(fù)該節(jié)點(diǎn)上被擦除的所有塊.節(jié)點(diǎn)修復(fù)性能的測(cè)試結(jié)果如圖9所示:

Fig. 9 Node repair performance for LRC and pLRC圖9 LRC和pLRC的節(jié)點(diǎn)修復(fù)性能

在圖9中我們可以看到，在(k,m,r)=(12,2,2) 時(shí)，pLRC的節(jié)點(diǎn)修復(fù)時(shí)間為1.99×103s，LRC的節(jié)點(diǎn)修復(fù)時(shí)間為3.79×103s.pLRC相對(duì)于LRC修復(fù)時(shí)間下降了大約47.5%.在其余參數(shù)下情況類似.我們注意到(k,m,r)=(10,2,4)時(shí)，pLRC的節(jié)點(diǎn)修復(fù)時(shí)間相對(duì)LRC下降較少，主要是由于這種情況有較多的全局編碼塊，需要使用大量數(shù)據(jù)塊來進(jìn)行修復(fù).

5 總 結(jié)

本文通過將基于機(jī)器學(xué)習(xí)的磁盤故障預(yù)測(cè)技術(shù)運(yùn)用到LRC中以對(duì)其固定分組大小的假設(shè)進(jìn)行改進(jìn)，提出了一類基于預(yù)測(cè)的LRC編碼方案pLRC，該方案通過動(dòng)態(tài)調(diào)整系統(tǒng)中LRC的分組大小從而降低了修復(fù)帶寬，并提升了系統(tǒng)的可靠性.