唐英杰 王 芳 謝燕文

(武漢光電國家研究中心(華中科技大學(xué)) 武漢 430074) (信息存儲(chǔ)系統(tǒng)教育部重點(diǎn)實(shí)驗(yàn)室(華中科技大學(xué)) 武漢 430074) (深圳華中科技大學(xué)研究院 廣東深圳 518000)

隨著大數(shù)據(jù)時(shí)代的來臨，數(shù)據(jù)的爆炸式增長使得存儲(chǔ)系統(tǒng)的規(guī)模不斷增加[1-3]，但是存儲(chǔ)設(shè)備的可靠性卻一直沒有得到顯著提高.Google的研究發(fā)現(xiàn)[4]，傳統(tǒng)機(jī)械磁盤的年更換率為2%～9%，而固態(tài)盤 (solid-state drive, SSD)在4年內(nèi)的整盤更換率為4%～10%，比磁盤具有更低的更換率，但壞消息是SSD在數(shù)據(jù)局部損壞方面遠(yuǎn)遠(yuǎn)高于磁盤.這些問題給數(shù)據(jù)的持久化存儲(chǔ)帶來了巨大的挑戰(zhàn).

傳統(tǒng)的分布式存儲(chǔ)系統(tǒng)，比如GFS(Google file system)[5]和HDFS(Hadoop distributed file system)[1]采用多副本策略來保證系統(tǒng)可靠性.其中三副本策略可以容忍任意2個(gè)副本數(shù)據(jù)的丟失，在數(shù)據(jù)恢復(fù)過程中只需要從剩余可用副本拷貝數(shù)據(jù)即可，并且在并發(fā)訪問中，3個(gè)副本可以同時(shí)提供服務(wù)、分擔(dān)負(fù)載.但是隨著存儲(chǔ)規(guī)模越來越大，對每份數(shù)據(jù)維護(hù)3個(gè)副本不僅在存儲(chǔ)開銷上代價(jià)高昂，而且大大增加系統(tǒng)管理員的負(fù)擔(dān).因此大量的數(shù)據(jù)中心開始部署糾刪碼[2,6-10]，以較小的存儲(chǔ)開銷來保證足夠高的系統(tǒng)可靠性.

目前制約糾刪碼系統(tǒng)的主要因素是恢復(fù)開銷問題.糾刪碼的冗余策略是將文件分成若干數(shù)據(jù)塊，然后通過計(jì)算產(chǎn)生指定數(shù)量的校驗(yàn)塊，數(shù)據(jù)塊和校驗(yàn)塊共同形成了一個(gè)稱為條帶的結(jié)構(gòu).糾刪碼系統(tǒng)的存儲(chǔ)開銷和容錯(cuò)能力均取決于校驗(yàn)塊的數(shù)量，不過校驗(yàn)塊與副本不同，在正常情況下，校驗(yàn)塊沒有任何作用，無法分擔(dān)負(fù)載.但是當(dāng)出現(xiàn)設(shè)備故障、節(jié)點(diǎn)失效等異常情況時(shí)，就可以通過條帶上剩余可用的數(shù)據(jù)塊以及校驗(yàn)塊進(jìn)行數(shù)據(jù)恢復(fù)，不過在這個(gè)過程中，恢復(fù)1個(gè)數(shù)據(jù)塊往往需要讀取數(shù)倍的數(shù)據(jù)，產(chǎn)生大量的I/O請求以及網(wǎng)絡(luò)流量，最終導(dǎo)致高的降級(jí)讀延遲和顯著的數(shù)據(jù)重建時(shí)間.

糾刪碼系統(tǒng)的恢復(fù)開銷一般認(rèn)為來自于3個(gè)方面：編解碼運(yùn)算、存儲(chǔ)I/O以及網(wǎng)絡(luò)傳輸.但是隨著軟硬件技術(shù)的發(fā)展，通過利用CPU的新指令[11]，可以大大提高編解碼效率，因此性能瓶頸主要集中在網(wǎng)絡(luò)和存儲(chǔ)上[12-20].

在本文中，我們將優(yōu)化方向著眼于數(shù)據(jù)重建路徑，針對數(shù)據(jù)恢復(fù)過程中網(wǎng)絡(luò)流量過大的問題，利用軟件定義網(wǎng)絡(luò)(software defined networking, SDN)[21]的技術(shù)，在交換機(jī)上進(jìn)行部分計(jì)算[22]，使得數(shù)據(jù)恢復(fù)的解碼計(jì)算盡量靠近數(shù)據(jù)存儲(chǔ)節(jié)點(diǎn)，從而避免數(shù)據(jù)在網(wǎng)絡(luò)中大范圍傳輸，克服了恢復(fù)節(jié)點(diǎn)端的網(wǎng)絡(luò)瓶頸問題[18-20].因?yàn)檎麄€(gè)解碼過程中，數(shù)據(jù)流在網(wǎng)絡(luò)中聚合、計(jì)算，然后向下一個(gè)交換機(jī)傳輸，所以我們將這種基于網(wǎng)絡(luò)計(jì)算的故障重建方案稱為網(wǎng)絡(luò)流水線(in-network pipeline, INP).

本文的主要貢獻(xiàn)有4個(gè)方面：

1) 提出了INP這種基于網(wǎng)絡(luò)計(jì)算的高效故障重建方案，通過利用SDN的技術(shù)，在交換機(jī)上執(zhí)行部分解碼運(yùn)算，從而減少網(wǎng)絡(luò)流量，提高降級(jí)讀以及數(shù)據(jù)重建的性能.

2) 通過對解碼過程進(jìn)行分析，說明INP方案可以適用于多種常見的糾刪碼，比如RS碼(Reed-Solomon code)[23-24]、PC碼(product code)[25]以及LRC碼(local reconstruction code)[13]等，并且INP可以和現(xiàn)有的優(yōu)化技術(shù)[12,16,18-20]相結(jié)合，進(jìn)一步提升恢復(fù)性能.

3) 擴(kuò)展了SDN控制器的功能模塊，使其能夠根據(jù)交換機(jī)的實(shí)時(shí)負(fù)載情況，靈活地選擇出合適的交換機(jī)參與到解碼計(jì)算中.

4) 以RS碼為例，評估了INP與傳統(tǒng)糾刪碼系統(tǒng)在降級(jí)讀操作中的網(wǎng)絡(luò)流量大小.另外在不同的網(wǎng)絡(luò)帶寬下，測試了正常讀、傳統(tǒng)降級(jí)讀以及基于INP方案的降級(jí)讀這3種讀取方式的性能，結(jié)果顯示基于INP方案的降級(jí)讀方式可以在一定帶寬限制下得到和正常讀接近的性能.

1 相關(guān)工作

目前，分布式存儲(chǔ)系統(tǒng)的規(guī)模越來越大，故障更加頻繁，存儲(chǔ)系統(tǒng)往往通過存儲(chǔ)冗余數(shù)據(jù)以保障在故障發(fā)生時(shí)，數(shù)據(jù)不丟失，持續(xù)可用.而今，越來越多的分布式文件系統(tǒng)采用糾刪碼的冗余數(shù)據(jù)方案，而不是多副本.糾刪碼在提供足夠的可靠性同時(shí)，大大降低了存儲(chǔ)開銷，但代價(jià)是高昂的恢復(fù)開銷.這使得降級(jí)讀和數(shù)據(jù)重建的完成時(shí)間大大增加，前者會(huì)導(dǎo)致用戶感受到明顯的訪問時(shí)延，而重建窗口的擴(kuò)大則會(huì)降低系統(tǒng)的可靠性，一旦在數(shù)據(jù)重建階段再次發(fā)生節(jié)點(diǎn)故障，可能會(huì)導(dǎo)致數(shù)據(jù)無法恢復(fù).在不犧牲系統(tǒng)可靠性以及存儲(chǔ)開銷的前提下，為降低恢復(fù)開銷，我們提出了一種基于網(wǎng)絡(luò)計(jì)算的故障重建方案，利用交換機(jī)的計(jì)算能力，在網(wǎng)絡(luò)中實(shí)現(xiàn)數(shù)據(jù)合并，從而大大減少網(wǎng)絡(luò)中的數(shù)據(jù)流量，提高恢復(fù)性能.

現(xiàn)在實(shí)際生產(chǎn)系統(tǒng)中，比如Google的ColossusFS[8]、Facebook的HDFS[7]等，分別使用2種不同的RS編碼：RS(6,3)和RS(10,4).RS編碼的優(yōu)勢在于可以編碼任意k個(gè)數(shù)據(jù)塊，產(chǎn)生任意m個(gè)校驗(yàn)塊，k和m都可以完全由管理員自定義，一旦發(fā)生數(shù)據(jù)丟失，只需要任意k個(gè)塊(不管是數(shù)據(jù)塊還是校驗(yàn)塊)都能完全恢復(fù)出所有數(shù)據(jù)，即可以容忍任意m個(gè)塊的丟失.但RS編碼會(huì)導(dǎo)致比較高的恢復(fù)開銷，以RS(10,4)為例，10個(gè)數(shù)據(jù)塊編碼產(chǎn)生4個(gè)校驗(yàn)塊，存儲(chǔ)開銷是1.4倍，如果發(fā)生數(shù)據(jù)丟失，則需要從10個(gè)節(jié)點(diǎn)上讀取數(shù)據(jù)，恢復(fù)開銷是10倍，可以看到RS編碼是在存儲(chǔ)開銷和恢復(fù)開銷之間做一個(gè)權(quán)衡.但是有研究發(fā)現(xiàn)，超過98%的數(shù)據(jù)丟失都是單數(shù)據(jù)塊丟失，因此有很多針對單塊恢復(fù)的優(yōu)化工作，其中Microsoft Azure Storage[2,13]使用一種稱為LRC的編碼，它編碼12個(gè)數(shù)據(jù)塊，產(chǎn)生2個(gè)全局校驗(yàn)塊，另外每6個(gè)數(shù)據(jù)塊1組編碼產(chǎn)生2個(gè)局部校驗(yàn)塊，如果出現(xiàn)單塊丟失，只需要讀取6個(gè)塊即可進(jìn)行恢復(fù)，這種LRC(12,2,2)編碼具有1.33倍的存儲(chǔ)開銷和6倍的單塊恢復(fù)開銷，但缺點(diǎn)是犧牲了部分可靠性，不能容忍任意4個(gè)塊的丟失.

關(guān)于糾刪碼的優(yōu)化研究大致可以分為2類：1)一種新的編碼方案，比如再生碼[22]、階梯碼[14]等;2)系統(tǒng)級(jí)的優(yōu)化，比如雙糾刪碼系統(tǒng)[16]，利用負(fù)載中存在的數(shù)據(jù)訪問傾斜，對頻繁訪問的少量熱數(shù)據(jù)使用恢復(fù)開銷較小的編碼，對大量冷數(shù)據(jù)使用存儲(chǔ)開銷較小的編碼，從而獲得低的存儲(chǔ)開銷和恢復(fù)開銷.這些新型編碼或多或少都是在存儲(chǔ)性能和恢復(fù)性能上做一些權(quán)衡.另外還有針對數(shù)據(jù)重建方案的優(yōu)化[17]，傳統(tǒng)的數(shù)據(jù)重建方案如圖1所示.當(dāng)系統(tǒng)檢測到塊丟失或者節(jié)點(diǎn)故障，則會(huì)在某些可用節(jié)點(diǎn)上啟動(dòng)重建任務(wù)，以一種并行的方式恢復(fù)丟失數(shù)據(jù).圖中數(shù)據(jù)塊D1丟失，需要從其他節(jié)點(diǎn)上讀取相應(yīng)塊進(jìn)行恢復(fù)，當(dāng)數(shù)據(jù)通過網(wǎng)絡(luò)傳輸?shù)交謴?fù)節(jié)點(diǎn)時(shí)，恢復(fù)節(jié)點(diǎn)端的網(wǎng)絡(luò)帶寬將成為瓶頸，從而限制了恢復(fù)性能.

Fig. 1 The traditional erasure code data reconstruction scheme圖1 傳統(tǒng)的糾刪碼數(shù)據(jù)重建方案

Fig. 2 The erasure code data reconstruction scheme based on pipeline圖2 基于流水線的糾刪碼數(shù)據(jù)重建方案

文獻(xiàn)[17]中提出一種新的恢復(fù)方案，如圖2所示，它充分利用各個(gè)節(jié)點(diǎn)的帶寬和計(jì)算能力，采用流水線的方式，將前一個(gè)節(jié)點(diǎn)的數(shù)據(jù)傳輸?shù)较乱粋€(gè)節(jié)點(diǎn)上進(jìn)行計(jì)算，然后將計(jì)算結(jié)果繼續(xù)向后續(xù)節(jié)點(diǎn)傳輸，直到到達(dá)恢復(fù)節(jié)點(diǎn)，這種方式能比較好地解決恢復(fù)節(jié)點(diǎn)的瓶頸問題，但它并沒有減少傳輸過程中的網(wǎng)絡(luò)流量.

我們的想法得益于SDN技術(shù)的快速發(fā)展.SDN是一種新型的可編程網(wǎng)絡(luò)架構(gòu)，其最核心的概念是將網(wǎng)絡(luò)設(shè)備的控制面和數(shù)據(jù)面分離，并強(qiáng)調(diào)控制面和數(shù)據(jù)面的可編程性.其中可編程控制面技術(shù)已經(jīng)日趨成熟，現(xiàn)在已經(jīng)有大量的開源控制器實(shí)現(xiàn)方案，控制器由一系列基本網(wǎng)絡(luò)服務(wù)模塊構(gòu)成，并通過特定的接口(比如OpenFlow協(xié)議標(biāo)準(zhǔn))與交換機(jī)進(jìn)行通信，以此實(shí)現(xiàn)拓?fù)浍@取、流量統(tǒng)計(jì)、路由控制等功能.在此基礎(chǔ)上，用戶可以很容易地根據(jù)需求開發(fā)擴(kuò)展功能，并對外提供訪問接口.而關(guān)于可編程數(shù)據(jù)面的研究，目前正在逐步完善，其中P4[26]語言已經(jīng)被設(shè)計(jì)出來，旨在實(shí)現(xiàn)交換機(jī)功能的動(dòng)態(tài)配置.

在這樣的背景下，我們運(yùn)用SDN的技術(shù)，提出了基于網(wǎng)絡(luò)計(jì)算的高效故障重建方案INP，由可編程控制器面實(shí)現(xiàn)網(wǎng)絡(luò)的拓?fù)涔芾砗驼{(diào)度功能，由可編程數(shù)據(jù)面實(shí)現(xiàn)數(shù)據(jù)處理功能.如圖3所示，通過在交換機(jī)上對數(shù)據(jù)進(jìn)行合并計(jì)算，不僅能夠解決網(wǎng)絡(luò)瓶頸問題，還能大大減少網(wǎng)絡(luò)中的流量，從而提升恢復(fù)性能.

設(shè)計(jì)INP方案主要是為了實(shí)現(xiàn)3個(gè)目標(biāo)：

1) 更快的降級(jí)讀.當(dāng)客戶端訪問到不可用的數(shù)據(jù)塊時(shí)，能夠在很短的時(shí)間內(nèi)完成解碼操作，使客戶端感受不到太大的延時(shí).

2) 更短的重建時(shí)間.數(shù)據(jù)重建完成得越快，系統(tǒng)可靠性越高，在新的重建方案下，針對可能發(fā)生的多數(shù)據(jù)塊重建，如何保證高并發(fā)非常值得思考.

3) 盡可能小地影響交換機(jī)正常工作.因?yàn)榻粨Q機(jī)計(jì)算能力有限，在不影響其正常工作的前提下，如何調(diào)度交換機(jī)也是一個(gè)非常重要的工作.

2 設(shè) 計(jì)

本節(jié)首先介紹INP方案的整體結(jié)構(gòu)、包括SDN控制器、OpenFlow交換機(jī)網(wǎng)絡(luò)等；之后討論INP在降級(jí)讀過程中的I/O詳細(xì)原理；最后分析解碼計(jì)算對交換機(jī)性能的影響.

2.1 INP方案結(jié)構(gòu)

INP方案的整體結(jié)構(gòu)如圖4所示，主要由2部分組成：SDN網(wǎng)絡(luò)和Hadoop集群.其中SDN網(wǎng)絡(luò)又分為SDN控制器和OpenFlow交換機(jī)群.SDN控制器維護(hù)著整個(gè)交換機(jī)網(wǎng)絡(luò)的拓?fù)潢P(guān)系，并負(fù)責(zé)交換機(jī)的調(diào)度.交換機(jī)通過OpenFlow協(xié)議與SDN控制器通信，并在數(shù)據(jù)重建過程中執(zhí)行部分計(jì)算任務(wù).

HDFS-RAID(redundant array of independent disks)：INP方案中的Hadoop集群是基于HDFS-RAID的一個(gè)擴(kuò)展.HDFS-RAID是Facebook基于第1代Hadoop開發(fā)的支持糾刪碼的系統(tǒng)，它在HDFS的基礎(chǔ)上實(shí)現(xiàn)了一個(gè)RAID方案，HDFS-RAID將存儲(chǔ)在HDFS中的數(shù)據(jù)塊編碼產(chǎn)生若干校驗(yàn)塊，并刪除原來的副本數(shù)據(jù)塊.一旦發(fā)現(xiàn)數(shù)據(jù)丟失，就會(huì)在集群中啟動(dòng)重建任務(wù)執(zhí)行數(shù)據(jù)重建操作，如果在數(shù)據(jù)重建期間，客戶端需要訪問丟失的數(shù)據(jù)，而此時(shí)系統(tǒng)中不存在副本數(shù)據(jù)，這將導(dǎo)致正常的讀取操作拋出異常，從而開始執(zhí)行降級(jí)讀操作.降級(jí)讀本質(zhì)上也是一種數(shù)據(jù)重建操作，與一般意義上的數(shù)據(jù)重建相比，降級(jí)讀操作的主要區(qū)別在于它不會(huì)將重建的數(shù)據(jù)塊寫回相應(yīng)的節(jié)點(diǎn)，而只是將其返回給訪問的客戶端.在2.2節(jié)中，我們將主要討論降級(jí)讀操作，因?yàn)閺脑砗托阅苌蟻碚f，降級(jí)讀操作和數(shù)據(jù)重建操作是大體一致的.

1) SDN控制器.在INP方案中，我們對SDN控制器的功能進(jìn)行了擴(kuò)展，當(dāng)HDFS-RAID集群進(jìn)行降級(jí)讀或者數(shù)據(jù)重建操作時(shí)，集群中的某個(gè)節(jié)點(diǎn)會(huì)首先向SDN控制器發(fā)出請求，控制器利用自身對交換機(jī)網(wǎng)絡(luò)的全局視角，選擇出合適的交換機(jī)參與解碼計(jì)算，并將選擇結(jié)果以一種樹型的結(jié)構(gòu)返回給集群，集群憑借該結(jié)構(gòu)與相應(yīng)交換機(jī)建立連接.關(guān)于SDN控制器對交換機(jī)的選擇策略，基于交換機(jī)的性能考慮，在SDN控制器中維護(hù)了交換機(jī)的狀態(tài)信息，以此作為評估標(biāo)準(zhǔn)，避免出現(xiàn)熱點(diǎn)問題.交換機(jī)選擇策略的設(shè)計(jì)將在2.3節(jié)中詳細(xì)介紹.

2) OpenFlow交換機(jī).在INP方案中，交換機(jī)被用來作為聚合節(jié)點(diǎn)，通過在交換機(jī)上執(zhí)行一些簡單計(jì)算，將來自不同節(jié)點(diǎn)的數(shù)據(jù)流合并，然后將計(jì)算結(jié)果繼續(xù)向后轉(zhuǎn)發(fā)，從而達(dá)到減少網(wǎng)絡(luò)流量的目的.為了盡可能小地影響交換機(jī)正常工作，在整個(gè)數(shù)據(jù)重建過程中，交換機(jī)只需要進(jìn)行異或操作.具體的原理將會(huì)在2.3節(jié)中介紹.

2.2 INP中的降級(jí)讀

本節(jié)討論INP方案中完整的數(shù)據(jù)讀取流程.如圖5所示.1)首先用戶通過HDFS客戶端向HDFS中的數(shù)據(jù)塊D1發(fā)出讀取請求.2)但此時(shí)數(shù)據(jù)塊D1因?yàn)槟承┕收夏Ｊ綄?dǎo)致數(shù)據(jù)丟失，而系統(tǒng)可能尚未發(fā)現(xiàn)該故障或者正處于數(shù)據(jù)重建過程中，所以訪問的最終結(jié)果是拋出異常.3)HDFS客戶端捕獲到讀取異常，了解到數(shù)據(jù)塊丟失，從而啟動(dòng)降級(jí)讀操作.在后文的后續(xù)說明中，均采用的是RS(3,2)編碼，即3個(gè)數(shù)據(jù)塊通過編碼產(chǎn)生2個(gè)校驗(yàn)塊，在這種編碼模式下，如果1個(gè)塊丟失，則需要從剩余4個(gè)可用塊中任意選出3個(gè)塊進(jìn)行數(shù)據(jù)重建，在圖5中，當(dāng)數(shù)據(jù)塊D1丟失時(shí)，選擇從數(shù)據(jù)塊D3以及校驗(yàn)塊P1和P2中讀取數(shù)據(jù)用于數(shù)據(jù)重建.而在INP架構(gòu)中，從指定塊讀取數(shù)據(jù)之前，HDFS客戶端會(huì)向SDN 控制器發(fā)出請求，在請求消息中，HDFS 客戶端告知SDN控制器需要參與到降級(jí)讀操作當(dāng)中的數(shù)據(jù)塊和校驗(yàn)塊所在節(jié)點(diǎn)位置，SDN控制器不僅維護(hù)著整個(gè)OpenFlow交換機(jī)網(wǎng)絡(luò)的拓?fù)湫畔ⅲ€掌握著邊緣設(shè)備(Hadoop集群節(jié)點(diǎn))與交換機(jī)的連接關(guān)系，當(dāng)SDN控制器收到HDFS客戶端的請求后，它根據(jù)交換機(jī)拓?fù)湫畔⒑凸?jié)點(diǎn)位置選擇出合適的交換機(jī)用于計(jì)算.4)SDN控制器將交換機(jī)和節(jié)點(diǎn)的連接關(guān)系通過一種樹型結(jié)構(gòu)返回給HDFS客戶端，我們將這種樹型結(jié)構(gòu)命名為重建樹，如圖6(a)所示.5)HDFS客戶端收到重建樹后，嘗試進(jìn)行初始化，與各交換機(jī)和節(jié)點(diǎn)建立連接，在圖5中HDFS客戶端向交換機(jī)SW1發(fā)出建立連接請求并等待響應(yīng)，SW1收到請求后按照重建樹結(jié)構(gòu)向交換機(jī)SW2和節(jié)點(diǎn)D3發(fā)出連接請求并等待響應(yīng)，以此類推.當(dāng)各節(jié)點(diǎn)確認(rèn)自身狀態(tài)，同意建立連接，就會(huì)向上一級(jí)交換機(jī)發(fā)出確認(rèn)信號(hào)，當(dāng)HDFS客戶端收到所有的確認(rèn)信號(hào)，就表示連接建立成功，從而可以開始讀取數(shù)據(jù)，進(jìn)行解碼運(yùn)算.

Fig. 6 Structure of reconstruction tree圖6 重建樹結(jié)構(gòu)

2.3 交換機(jī)性能分析

在INP方案中，交換機(jī)在整個(gè)數(shù)據(jù)重建操作中具有至關(guān)重要的作用，它是使得網(wǎng)絡(luò)流量減少的關(guān)鍵設(shè)備，在本節(jié)中將重點(diǎn)討論針對交換機(jī)性能設(shè)計(jì)的調(diào)度策略以及交換機(jī)在解碼運(yùn)算中的工作原理.

1) 交換機(jī)調(diào)度策略.在實(shí)際應(yīng)用場景中，多用戶并發(fā)訪問或者多數(shù)據(jù)塊重建是非常常見的.以用戶訪問為例，當(dāng)不同用戶同時(shí)引發(fā)降級(jí)讀時(shí)，SDN控制器會(huì)根據(jù)網(wǎng)絡(luò)拓?fù)溥x擇出合適的交換機(jī)進(jìn)行解碼運(yùn)算，這時(shí)可能會(huì)出現(xiàn)某臺(tái)交換機(jī)被多個(gè)降級(jí)讀所共享的情況.為了避免出現(xiàn)交換機(jī)熱點(diǎn)問題，對SDN控制器功能進(jìn)行擴(kuò)展，實(shí)現(xiàn)了3步調(diào)度策略：①如圖7所示，首先選擇出各節(jié)點(diǎn)到HDFS客戶端的最短路徑，各路徑交點(diǎn)為解碼交換機(jī)，從而得到如圖6(a)所示的重建樹結(jié)構(gòu)；②如果選擇出的交換機(jī)的連接數(shù)(參與降級(jí)讀的數(shù)量)超過某個(gè)閾值，則進(jìn)行向上調(diào)度，即從當(dāng)前交換機(jī)沿?cái)?shù)據(jù)流方向(圖7中箭頭所指方向)選擇出空閑交換機(jī)用于解碼，所得重建樹如圖6(b)所示；③如果最短路徑上所有交換機(jī)均不符合，則放棄最短路徑，直接從高層交換機(jī)中選擇出空閑交換機(jī).

Fig. 7 Shortest-path strategy圖7 最短路徑策略

2) RS解碼運(yùn)算的分解.在2.2節(jié)的討論中，已經(jīng)提到了基于網(wǎng)絡(luò)計(jì)算的重建方案的核心思想，即在交換機(jī)上進(jìn)行部分計(jì)算，使得網(wǎng)絡(luò)中傳輸?shù)牧髁繙p少.考慮到交換機(jī)本身的計(jì)算能力，為了盡量小地影響其基本的路由轉(zhuǎn)發(fā)功能，在重建方案的設(shè)計(jì)中，在交換機(jī)上只需要進(jìn)行非常簡單的異或運(yùn)算.具體的工作原理可通過式(1)來解釋.

(1)

RS碼的解碼過程可以表示為2個(gè)矩陣相乘，其中a1，a2，a3組成了系數(shù)矩陣，D3，P1，P2是用于解碼的數(shù)據(jù)塊和校驗(yàn)塊.將式(1)左邊的矩陣運(yùn)算展開，得到式(1)右邊的表達(dá)式，可以看到解碼操作的實(shí)質(zhì)就是若干系數(shù)各自乘上對應(yīng)的塊，然后將結(jié)果累加.需要注意的是，式(1)中的乘法和加法運(yùn)算都是伽羅華域中的運(yùn)算，伽羅華域中的乘法運(yùn)算非常復(fù)雜，涉及到查表等操作，而加法運(yùn)算非常簡單，就是異或操作，因此在INP的設(shè)計(jì)中，當(dāng)從各節(jié)點(diǎn)讀取數(shù)據(jù)時(shí)，首先在各節(jié)點(diǎn)上對原始數(shù)據(jù)D3，P1，P2執(zhí)行乘法運(yùn)算，即式(1)中的乘法項(xiàng)a1×D3，a2×P1，a3×P2，然后將計(jì)算結(jié)果發(fā)送給對應(yīng)的交換機(jī)，在交換機(jī)上只需要將來自不同節(jié)點(diǎn)的數(shù)據(jù)進(jìn)行異或合并即可.另外通過式(1)也可以分析出降級(jí)讀過程中的流量變化，假設(shè)需要降級(jí)讀取1 GB的數(shù)據(jù)，按照傳統(tǒng)的數(shù)據(jù)重建方案，HDFS客戶端所在的網(wǎng)絡(luò)將接收到3 GB的數(shù)據(jù)，而INP方案中，交換機(jī)將來自不同節(jié)點(diǎn)的數(shù)據(jù)進(jìn)行異或合并，大大減少了向后傳輸?shù)木W(wǎng)絡(luò)流量，理論上HDFS客戶端收到的數(shù)據(jù)量應(yīng)該為1 GB，從而解決數(shù)據(jù)恢復(fù)中的瓶頸問題.

2.4 編碼擴(kuò)展性分析

2.3節(jié)中已經(jīng)詳細(xì)說明了RS碼在INP方案下的解碼過程，可以發(fā)現(xiàn)INP方案的有效性依賴于交換機(jī)上的數(shù)據(jù)合并過程.在本節(jié)中我們將分析一些常見糾刪碼的解碼過程，從而證明INP方案可以運(yùn)用在多種糾刪碼系統(tǒng)中.

1) LRC碼.LRC(12,2,2)的編碼結(jié)構(gòu)如圖8所示，12個(gè)數(shù)據(jù)塊使用RS編碼的算法產(chǎn)生2個(gè)全局校驗(yàn)塊，另外每6個(gè)數(shù)據(jù)塊通過異或產(chǎn)生1個(gè)局部校驗(yàn)塊.在解碼過程中，如果出現(xiàn)單塊故障，則只需要通過式(2)進(jìn)行異或計(jì)算即可，顯然可以在交換機(jī)上進(jìn)行數(shù)據(jù)合并減少網(wǎng)絡(luò)流量；如果出現(xiàn)多塊故障，則需要用到全局校驗(yàn)塊，該解碼過程和RS完全一致.

d4=d1+d2+d3+d5+d6+L1.

(2)

Fig. 8 LRC code圖8 LRC編碼結(jié)構(gòu)

2) PC碼.PC(2,5)的編碼結(jié)構(gòu)如圖9所示，每行5個(gè)數(shù)據(jù)塊通過異或產(chǎn)生1個(gè)局部校驗(yàn)塊，每列2個(gè)數(shù)據(jù)塊通過異或產(chǎn)生1個(gè)局部校驗(yàn)塊，所有的數(shù)據(jù)塊異或產(chǎn)生1個(gè)全局校驗(yàn)塊.其解碼過程類似于LRC的單塊恢復(fù)，每塊數(shù)據(jù)的恢復(fù)都涉及單次異或運(yùn)算，因此PC碼也可以部署在INP方案中.

Fig. 9 PC code圖9 PC編碼結(jié)構(gòu)

3) SD(sector-disk)碼[15].SD碼是一種可以修復(fù)扇區(qū)錯(cuò)誤的糾刪碼，其結(jié)構(gòu)如圖10所示.與傳統(tǒng)糾刪碼相比，SD碼將扇區(qū)作為最小編碼單元，每行采用RS編碼算法產(chǎn)生2個(gè)局部校驗(yàn)塊，所有扇區(qū)經(jīng)過編碼產(chǎn)生2個(gè)全局校驗(yàn)塊，其解碼過程與RS碼相同，區(qū)別只在于SD碼重建粒度更小，所以INP方案也可以兼容用于扇區(qū)修復(fù)的糾刪碼.

Fig. 10 SD code圖10 SD編碼結(jié)構(gòu)

3 實(shí) 現(xiàn)

3.1 傳統(tǒng)糾刪碼系統(tǒng)

HDFS-RAID中實(shí)現(xiàn)糾刪碼功能的核心模塊主要是DRFS(distributed raid file system)和RaidNode，其中DRFS是在HDFS基礎(chǔ)上實(shí)現(xiàn)的RAID方案，而RaidNode進(jìn)程主要負(fù)責(zé)數(shù)據(jù)編碼以及數(shù)據(jù)重建工作.RaidNode進(jìn)程會(huì)周期性地查詢NameNode，來獲取需要編碼和需要進(jìn)行重建的文件條目.

DRFS客戶端是在HDFS客戶端的基礎(chǔ)上進(jìn)行封裝，它的大部分功能其實(shí)都是由下層的HDFS客戶端實(shí)現(xiàn)的，在讀取數(shù)據(jù)時(shí)，如果出現(xiàn)塊丟失等異常情況，DRFS客戶端將會(huì)捕獲到這些異常，并且定位到異常發(fā)生的位置，進(jìn)而檢索同一條帶上的可用塊用于解碼操作，得到請求的數(shù)據(jù)，這就是傳統(tǒng)的降級(jí)讀操作.

3.2 基于網(wǎng)絡(luò)計(jì)算的糾刪碼系統(tǒng)

在INP方案中， 當(dāng)客戶端讀取到某個(gè)丟失塊時(shí)，客戶端同樣會(huì)捕獲異常，與傳統(tǒng)降級(jí)讀不同的是客戶端之后會(huì)采取的措施，即開始執(zhí)行2.2節(jié)所描述的降級(jí)讀操作.在整個(gè)INP方案的實(shí)現(xiàn)中，SDN控制器選擇的是基于Java語言的Floodlight，OpenFlow交換機(jī)則采用Open vSwitch虛擬交換機(jī).在客戶端捕獲到讀取異常之后，首先向條帶上的其余數(shù)據(jù)塊和校驗(yàn)塊發(fā)起訪問，確定有足夠多的可用塊，并獲取這些塊所在節(jié)點(diǎn)的IP地址.因?yàn)镕loodlight采用REST(representational state transfer)風(fēng)格的編程接口對外提供服務(wù)，所以客戶端將節(jié)點(diǎn)的IP地址通過HTTP請求的方式發(fā)送給Floodlight，F(xiàn)loodlight收到請求后，根據(jù)維護(hù)的交換機(jī)負(fù)載信息，對交換機(jī)進(jìn)行調(diào)度.當(dāng)成功選擇出合適的交換機(jī)后，更新交換機(jī)負(fù)載信息，并將交換機(jī)和節(jié)點(diǎn)的連接方式以重建樹的結(jié)構(gòu)發(fā)送回客戶端.然后客戶端開始計(jì)算式(1)中的系數(shù)矩陣，也稱為解碼矩陣，在與交換機(jī)以及各節(jié)點(diǎn)建立連接的過程中，將系數(shù)矩陣以及文件偏移等信息發(fā)送到對應(yīng)節(jié)點(diǎn).當(dāng)節(jié)點(diǎn)接收到客戶端的連接請求之后，它會(huì)去打開指定文件，根據(jù)文件偏移定位數(shù)據(jù)，如果在這個(gè)過程中發(fā)生異常，會(huì)向客戶端發(fā)送一個(gè)值為false的確認(rèn)，只要有1個(gè)節(jié)點(diǎn)不能正常連接，客戶端收到的確認(rèn)就是false，只有當(dāng)所有的節(jié)點(diǎn)以及交換機(jī)都做好數(shù)據(jù)傳輸準(zhǔn)備，客戶端才會(huì)收到值為true的確認(rèn).

連接成功建立之后，客戶端會(huì)采用流水線的方式向節(jié)點(diǎn)發(fā)出讀取請求.為了提升讀取效率，客戶端上建立了雙緩沖區(qū)，在連接建立后客戶端啟動(dòng)1個(gè)子線程向緩沖區(qū)中寫數(shù)據(jù)，寫線程會(huì)一直循環(huán)檢查2個(gè)緩沖區(qū)，一旦發(fā)現(xiàn)某個(gè)緩沖區(qū)為空，就會(huì)向服務(wù)器發(fā)出讀取數(shù)據(jù)請求.采用雙緩沖區(qū)這樣的方式，是為了讀線程在讀某個(gè)緩沖區(qū)時(shí)，寫線程可以去填滿另一個(gè)緩沖區(qū)，當(dāng)讀線程讀完前一個(gè)緩沖區(qū)時(shí)，可以無等待地切換到另一個(gè)緩沖區(qū)，而同時(shí)寫線程會(huì)去填滿之前被讀完的緩沖區(qū).

當(dāng)寫線程讀取到1個(gè)塊的塊尾時(shí)，表示已經(jīng)成功讀取1個(gè)丟失的塊，這時(shí)客戶端就應(yīng)該與交換機(jī)以及各節(jié)點(diǎn)斷開連接，在這個(gè)過程中客戶端會(huì)向Floodlight發(fā)送一個(gè)斷開連接的信號(hào)，收到此信號(hào)的控制器就會(huì)更新交換機(jī)的負(fù)載信息.如果客戶端還需要讀取文件的下一個(gè)塊，且該數(shù)據(jù)塊也發(fā)生丟失，則需要重新建立連接，重復(fù)整個(gè)流程.因?yàn)榧词故俏募羞B續(xù)的2個(gè)塊，也可能編碼在不同的條帶上.

4 測 試

4.1 測試環(huán)境

如圖11所示，在1臺(tái)配置有2TB磁盤、12 GB內(nèi)存以及2個(gè)4核2.4 GHz Intel Xeon E5620 CPU的物理機(jī)上構(gòu)建了1個(gè)由11個(gè)Docker容器和1臺(tái)虛擬交換機(jī)組成的小集群，其中8個(gè)容器作為DataNode服務(wù)器節(jié)點(diǎn)，另外3個(gè)容器分別作為NameNode、HDFS客戶端以及交換機(jī)的計(jì)算節(jié)點(diǎn).容器內(nèi)運(yùn)行Ubuntu 14.04.2操作系統(tǒng)，Docker版本為1.7.1，SDN控制器是Floodlight-0.90，交換機(jī)使用Open vSwitch 2.0.2來模擬.

Fig. 11 Experimental cluster圖11 測試集群

因?yàn)樘摂M交換機(jī)本身并不具備數(shù)據(jù)解碼中的計(jì)算功能，而修改其源代碼代價(jià)太大.因此我們?yōu)槊總€(gè)虛擬交換機(jī)綁定1個(gè)計(jì)算節(jié)點(diǎn)，如圖11所示，當(dāng)交換機(jī)接收到服務(wù)器節(jié)點(diǎn)傳來的數(shù)據(jù)時(shí)，首先將數(shù)據(jù)轉(zhuǎn)發(fā)給對應(yīng)的計(jì)算節(jié)點(diǎn)，在計(jì)算節(jié)點(diǎn)上完成異或合并運(yùn)算，然后再發(fā)送回交換機(jī)，并繼續(xù)向后傳輸.但是采用這種方式，會(huì)給測試引入不必要的開銷，在4.3節(jié)我們將分析這種方式對測試結(jié)果造成的影響，并合理估計(jì)這部分額外開銷.

另外關(guān)于糾刪碼的設(shè)置，我們采用的編碼是RS(3,2)，即每3個(gè)數(shù)據(jù)塊編碼產(chǎn)生2個(gè)校驗(yàn)塊，5個(gè)塊一起構(gòu)成1個(gè)條帶，基于這種編碼，每次降級(jí)讀取1個(gè)塊需要連接另外3個(gè)可用塊.另外設(shè)置HDFS塊大小為128 MB，使用HDFS-RAID默認(rèn)的塊分布方案將編碼后的數(shù)據(jù)塊和校驗(yàn)塊平均分布在集群中，確保同一糾刪碼條帶上的任意2個(gè)塊不在同一節(jié)點(diǎn)上.

在4.2～4.4節(jié)中，我們將分別從網(wǎng)絡(luò)流量、降級(jí)讀延遲以及帶寬競爭力這3個(gè)方面說明INP方案的有效性.

4.2 流量測試

通過第2節(jié)分析可知，影響降級(jí)讀性能的一個(gè)重要因素是網(wǎng)絡(luò)流量，在我們的測試集群中，網(wǎng)絡(luò)瓶頸主要出現(xiàn)在交換機(jī)與客戶端相連的鏈路上.因?yàn)闇y試過程中客戶端降級(jí)讀取1 GB的數(shù)據(jù)，而編碼方案采用的是RS(3,2)編碼，即每次需要讀取3倍的數(shù)據(jù)用于解碼操作，所以理論上客戶端的降級(jí)讀會(huì)從服務(wù)器上獲取3 GB的數(shù)據(jù)，傳統(tǒng)降級(jí)讀方式中3 GB的數(shù)據(jù)將全部流經(jīng)交換機(jī)到達(dá)客戶端，在客戶端上進(jìn)行解碼得到丟失的數(shù)據(jù).而基于網(wǎng)絡(luò)計(jì)算的降級(jí)讀方式因?yàn)樵诮粨Q機(jī)上已經(jīng)完成了計(jì)算，因此理論上只需要向客戶端傳輸1 GB數(shù)據(jù).我們通過調(diào)用Floodlight控制器的接口可以獲取到交換機(jī)各端口的輸入輸出流量，經(jīng)過簡單處理后的結(jié)果如圖12所示，其中HDFS-RAID表示傳統(tǒng)降級(jí)讀，INP表示基于網(wǎng)絡(luò)計(jì)算的降級(jí)讀.

Fig. 12 Comparison of network traffic圖12 網(wǎng)絡(luò)流量對比

第1組數(shù)據(jù)測的是交換機(jī)從各服務(wù)器節(jié)點(diǎn)讀取的數(shù)據(jù)量，可以看到在傳統(tǒng)降級(jí)讀過程中，需要從集群中讀取2.98 GB的數(shù)據(jù)，與理論分析值3 GB基本相符，另外INP方案中的降級(jí)讀從服務(wù)器獲取了2.91 GB的數(shù)據(jù)，略少于傳統(tǒng)降級(jí)讀，但認(rèn)為是在測試誤差范圍內(nèi).

我們比較關(guān)注的是第2組數(shù)據(jù)：交換機(jī)轉(zhuǎn)發(fā)給客戶端的數(shù)據(jù)量.圖12中數(shù)據(jù)顯示INP方案中交換機(jī)轉(zhuǎn)發(fā)給客戶端的數(shù)據(jù)量與傳統(tǒng)降級(jí)讀的比例為1:3，基本與理論值相符.

后面2組數(shù)據(jù)測試的是交換機(jī)的總的接收數(shù)據(jù)量和發(fā)送數(shù)據(jù)量，統(tǒng)計(jì)這2組數(shù)據(jù)主要是為了說明在降級(jí)讀中，交換機(jī)接收的流量幾乎都來自服務(wù)器，而轉(zhuǎn)發(fā)的流量都是送往客戶端.

測試中我們采用的是一種恢復(fù)開銷相對較小的編碼，每次恢復(fù)1個(gè)數(shù)據(jù)塊只需要讀取3倍的數(shù)據(jù)量.而在Google ColossusFS中使用的是RS(6,3)，F(xiàn)acebook HDFS-RAID使用的是RS(10,4)，如果在INP方案中部署這2種編碼，能夠減少的網(wǎng)絡(luò)流量會(huì)更多.

4.3 降級(jí)讀延時(shí)

在本節(jié)中，我們將分別在不同網(wǎng)絡(luò)帶寬下對正常讀、傳統(tǒng)降級(jí)讀和INP方案中的降級(jí)讀的時(shí)間進(jìn)行比較.測試結(jié)果如表1和圖13所示，其中HDFS表示正常讀.

關(guān)于網(wǎng)絡(luò)帶寬的設(shè)置，采用的辦法是在交換機(jī)到客戶端的出口端口上創(chuàng)建1個(gè)QoS(quality of service)隊(duì)列，并設(shè)置最大最小速度，以此來限制網(wǎng)絡(luò)帶寬.需要注意的是所有的網(wǎng)絡(luò)限制都是針對交換機(jī)到客戶端的出口帶寬，其余鏈路不做限制，以此來分析網(wǎng)絡(luò)流量所引起的瓶頸問題，同時(shí)說明INP方案的有效性.

Table 1 Time Required to Read 1 GB Data at DifferentNetwork Bandwidths

Note: The value in parentheses is the correction data, because the simulation method used in our experiments has a large impact on the result at 10 000 Mbps.

Fig. 13 Time required to read 1 GB data at different network bandwidths圖13 不同帶寬下讀取1 GB數(shù)據(jù)所需時(shí)間對比

在整個(gè)測試部分，我們以正常讀取1 GB數(shù)據(jù)的時(shí)間作為基準(zhǔn)來分析傳統(tǒng)降級(jí)讀和基于INP方案的降級(jí)讀的性能.在10 000 Mbps下，測得客戶端正常讀取1 GB的數(shù)據(jù)需要1.65 s，基于流水線原理，讀取時(shí)間取決于瓶頸帶寬和瓶頸鏈路上的網(wǎng)絡(luò)流量，在傳統(tǒng)降級(jí)讀中，客戶端所在鏈路需要傳輸3倍于正常讀的流量，因此理論上傳統(tǒng)降級(jí)讀讀取1 GB的數(shù)據(jù)需要3倍的正常讀時(shí)間，而實(shí)際測試結(jié)果是8.79 s.這主要是因?yàn)榻导?jí)讀除了網(wǎng)絡(luò)傳輸開銷，還存在存儲(chǔ)I/O以及解碼計(jì)算開銷.

再觀察10 000 Mbps下INP方案的測試結(jié)果.因?yàn)?.2節(jié)實(shí)際測得交換機(jī)最后轉(zhuǎn)發(fā)到客戶端的流量和正常讀是一致的，即INP方案中瓶頸鏈路帶寬以及瓶頸鏈路傳輸?shù)木W(wǎng)絡(luò)流量均與正常讀相同，所以INP方案中的網(wǎng)絡(luò)傳輸時(shí)間理論上也應(yīng)該與正常讀一致，不過根據(jù)4.1節(jié)所述，因?yàn)橛布O(shè)備受限，所以在仿真測試中為交換機(jī)綁定1個(gè)計(jì)算節(jié)點(diǎn)，按照這種方式，在10 000 Mbps下，雖然消除了客戶端的網(wǎng)絡(luò)瓶頸，但是計(jì)算節(jié)點(diǎn)處的鏈路反而成為了瓶頸，而且交換機(jī)轉(zhuǎn)發(fā)給計(jì)算節(jié)點(diǎn)的數(shù)據(jù)和計(jì)算節(jié)點(diǎn)回送給交換機(jī)的計(jì)算結(jié)果均在同一鏈路上傳輸，所以該段鏈路上的網(wǎng)絡(luò)流量是正常讀的4倍，為了消除這部分開銷，我們測試了3 GB數(shù)據(jù)在萬兆鏈路下的網(wǎng)絡(luò)傳輸時(shí)間，以此來近似估計(jì)交換機(jī)與計(jì)算節(jié)點(diǎn)之間的額外開銷，如表1所示，我們列出了INP方案的原始測試結(jié)果和修正之后的結(jié)果，消除開銷之后INP方案讀取時(shí)間為9.82 s.但即使是修正之后的數(shù)據(jù)，也遠(yuǎn)遠(yuǎn)大于正常讀，甚至要比傳統(tǒng)降級(jí)讀時(shí)間略長，不僅沒有減少恢復(fù)開銷，反而增大.分析INP方案的額外時(shí)間開銷，不僅包括存儲(chǔ)I/O和解碼計(jì)算，另外在INP方案中，客戶端在讀取數(shù)據(jù)之前還需要訪問SDN控制器，并等待控制器返回重建樹信息，之后還要與交換機(jī)、服務(wù)器建立連接，這些操作都存在一定的時(shí)間開銷.而且由于客戶端鏈路的網(wǎng)絡(luò)帶寬達(dá)到10 000 Mbps，數(shù)據(jù)傳輸速度較快，導(dǎo)致網(wǎng)絡(luò)開銷并不是影響恢復(fù)性能的主導(dǎo)因素.這就使得INP方案性能反而沒有傳統(tǒng)降級(jí)讀性能好.由于集群規(guī)模的限制，我們在測試中只能采用條帶較短的編碼方案，但是考慮到實(shí)際系統(tǒng)中往往會(huì)部署恢復(fù)開銷更大的編碼，這時(shí)網(wǎng)絡(luò)流量將會(huì)成倍增加，這些都將有利于INP方案的性能發(fā)揮.

當(dāng)我們將帶寬設(shè)置為2 000 Mbps時(shí)，交換機(jī)與計(jì)算節(jié)點(diǎn)之間的鏈路不再是網(wǎng)絡(luò)瓶頸，因此不用對測試結(jié)果進(jìn)行修正.測試結(jié)果顯示INP方案性能優(yōu)于傳統(tǒng)降級(jí)讀，且隨著帶寬資源越來越緊張，INP方案的優(yōu)勢也越來越明顯，甚至接近正常讀時(shí)間.如圖13所示，在1 000 Mbps下，INP方案可以減少50%的降級(jí)讀開銷；而在200 Mbps下，INP方案已經(jīng)達(dá)到正常讀的性能.這主要是因?yàn)殡S著帶寬降低，降級(jí)讀的恢復(fù)開銷主要取決于網(wǎng)絡(luò)傳輸時(shí)間，而INP方案大大減少了網(wǎng)絡(luò)流量，因此可以獲得非常大的性能提升.而且目前用于測試的INP方案只是一個(gè)簡單原型，在性能優(yōu)化上還有一些工作有待完成.

4.4 網(wǎng)絡(luò)競爭力

在4.3節(jié)的測試中，評估的都是某種讀取方式獨(dú)享整個(gè)網(wǎng)絡(luò)帶寬時(shí)的性能.而在真實(shí)應(yīng)用場景里，往往是既有正常讀，也有降級(jí)讀，2種讀取方式并行執(zhí)行.在這部分，將考量正常讀+正常讀、正常讀+傳統(tǒng)降級(jí)讀、正常讀+INP降級(jí)讀這3種共享讀取模式下各讀取方式的性能表現(xiàn).設(shè)置這組測試的目的主要是為了評估降級(jí)讀與正常讀產(chǎn)生的數(shù)據(jù)流在網(wǎng)絡(luò)中的競爭力表現(xiàn).

如圖14所示，在1 000 Mbps下，第1組數(shù)據(jù)顯示的是獨(dú)占模式下各讀取方式的性能，即4.3節(jié)中測得的數(shù)據(jù).第2組數(shù)據(jù)表示的是當(dāng)網(wǎng)絡(luò)中存在2個(gè)客戶端同時(shí)讀取數(shù)據(jù)時(shí)正常讀的性能表現(xiàn).結(jié)果符合預(yù)期，當(dāng)網(wǎng)絡(luò)中流量成倍增加時(shí)，正常讀性能成倍降低，圖14中顯示2個(gè)正常讀操作的時(shí)間都是原來獨(dú)占網(wǎng)絡(luò)帶寬時(shí)的2倍.再觀察第3組數(shù)據(jù)，當(dāng)網(wǎng)絡(luò)中同時(shí)存在正常讀和傳統(tǒng)降級(jí)讀時(shí)，正常讀的完成時(shí)間接近于獨(dú)占網(wǎng)絡(luò)帶寬時(shí)的3倍，這是因?yàn)楫?dāng)網(wǎng)絡(luò)中存在降級(jí)讀時(shí)，網(wǎng)絡(luò)流量大大增加，嚴(yán)重占用了網(wǎng)絡(luò)帶寬，實(shí)驗(yàn)結(jié)果顯示在這種共享模式下，正常讀分配有1/3的帶寬，傳統(tǒng)降級(jí)讀占用了剩下的2/3，但是考慮到傳統(tǒng)降級(jí)讀的流量是正常讀的3倍，所以說明正常讀的網(wǎng)絡(luò)競爭力會(huì)略強(qiáng)于傳統(tǒng)降級(jí)讀.第4組數(shù)據(jù)測的是正常讀和INP降級(jí)讀的共享模式，其中正常讀的時(shí)間相比于獨(dú)占帶寬增加了1倍，即正常讀在混合模式下占用了一半的帶寬，這與第2組數(shù)據(jù)情況相同，因此可以認(rèn)為INP方案在網(wǎng)絡(luò)競爭力方面與正常讀表現(xiàn)一致.

Fig. 14 Shared read mode in 1 000 Mbps圖14 1 000 Mbps下的共享讀取模式

另外我們還分別在500 Mbps下和100 Mbps下對3種混合讀取模式進(jìn)行了測試，如圖15和圖16所示.在這2種帶寬下，正常讀和INP降級(jí)讀的混合模式中，正常讀均占有一半的帶寬，與1 000 Mbps下表現(xiàn)一致.特別是100 Mbps下的測試結(jié)果，非常直觀地顯示了INP降級(jí)讀具有和正常讀一樣的網(wǎng)絡(luò)競爭力.如圖16所示，因?yàn)樵谠搸捪?，INP降級(jí)讀已經(jīng)具有接近正常讀的時(shí)間開銷，所以圖16中第4組數(shù)據(jù)和第2組數(shù)據(jù)表現(xiàn)完全吻合，這也說明了可以將INP降級(jí)讀等價(jià)于正常讀來看待.

Fig. 15 Shared read mode in 500 Mbps圖15 500 Mbps下的共享讀取模式

Fig. 16 Shared read mode in 100 Mbps圖16 100 Mbps下的共享讀取模式

4.5 未來工作

在本次測試過程中，我們從網(wǎng)絡(luò)流量、降級(jí)讀延遲以及網(wǎng)絡(luò)競爭力說明了INP方案的有效性，它能夠大大減少降級(jí)讀過程中的網(wǎng)絡(luò)流量，從而提升恢復(fù)性能，甚至可以在一定帶寬下接近正常讀水平，而且我們可以預(yù)見到，在恢復(fù)開銷更大的編碼系統(tǒng)上，我們的方案會(huì)獲得進(jìn)一步的性能提升.

但是我們在測試環(huán)境上還存在一些不足，比如單機(jī)性能有限，在單機(jī)上模擬集群，對于集群的很多特性無法表現(xiàn)出來，比如存儲(chǔ)I/O操作，這也是一個(gè)影響恢復(fù)性能的重要因素；另外一個(gè)不足是目前沒有在實(shí)際的OpenFlow交換機(jī)上去實(shí)現(xiàn)我們的功能，這也導(dǎo)致實(shí)驗(yàn)過程中引入了一些額外開銷，雖然我們在測試中修正了這部分開銷，但還是不能完全代表真實(shí)場景.關(guān)于測試部分，在代碼實(shí)現(xiàn)上還存在不少優(yōu)化空間，可以進(jìn)一步提升INP方案的性能，另外目前INP方案尚未與更多編碼方案進(jìn)行對比測試.這些問題都將作為我們未來的研究方向.

5 總 結(jié)

本文提出一種新型的基于網(wǎng)絡(luò)計(jì)算的高效故障重建方案INP來解決糾刪碼系統(tǒng)中恢復(fù)開銷太大的問題，考慮到影響恢復(fù)開銷的3個(gè)因素：較高的網(wǎng)絡(luò)傳輸開銷、解碼計(jì)算復(fù)雜以及大量的磁盤讀寫.INP方案選擇從網(wǎng)絡(luò)傳輸量這個(gè)主要因素上進(jìn)行優(yōu)化.

通過分析傳統(tǒng)糾刪碼系統(tǒng)恢復(fù)數(shù)據(jù)時(shí)的網(wǎng)絡(luò)情況，可以發(fā)現(xiàn)客戶端所在鏈路經(jīng)常需要傳輸大量的數(shù)據(jù)，這是由RS碼的解碼算法決定的，傳統(tǒng)糾刪碼系統(tǒng)在解碼時(shí)總是把所有需要的數(shù)據(jù)都傳輸?shù)?個(gè)節(jié)點(diǎn)上進(jìn)行計(jì)算，這就使得該節(jié)點(diǎn)所在鏈路成了整個(gè)網(wǎng)絡(luò)的瓶頸，從而導(dǎo)致恢復(fù)開銷增大.

因此我們利用SDN，設(shè)計(jì)出一種可以在交換機(jī)上進(jìn)行聚合計(jì)算的數(shù)據(jù)重建方案，以此來減少向后傳輸?shù)木W(wǎng)絡(luò)流量，最終解決客戶端處的網(wǎng)絡(luò)瓶頸問題.

實(shí)驗(yàn)結(jié)果顯示INP方案能夠大大減少降級(jí)讀過程中的網(wǎng)絡(luò)流量，從而提升恢復(fù)性能，在1 000 Mbps下能夠降低50%的降級(jí)讀開銷，而且隨著帶寬資源緊缺，INP方案中的降級(jí)讀可以接近正常讀水平.