數(shù)據(jù)中心網(wǎng)絡(luò)中任務(wù)感知的傳輸控制協(xié)議

,,

(中南大學(xué) 信息科學(xué)與工程學(xué)院,長沙 410083)

0 概述

近年來,隨著網(wǎng)絡(luò)帶寬的飛速提升,在線搜索、社交網(wǎng)絡(luò)、電子商務(wù)等網(wǎng)絡(luò)應(yīng)用得到了飛速發(fā)展和普及,越來越多的在線應(yīng)用系統(tǒng)被遷移到數(shù)據(jù)中心網(wǎng)絡(luò)(Data Center Network,DCN)[1],利用大規(guī)模的計算和存儲資源來為用戶提供各種服務(wù)[2]。數(shù)據(jù)中心網(wǎng)絡(luò)中的應(yīng)用任務(wù)包含一組相互獨(dú)立卻擁有共同目標(biāo)的數(shù)據(jù)流,這些數(shù)據(jù)流中拖尾流的完成時間決定整個任務(wù)的完成時間。而數(shù)據(jù)中心網(wǎng)絡(luò)中數(shù)據(jù)傳輸?shù)臅r延是影響DCN中應(yīng)用性能至關(guān)重要的一部分[2]。Facebook的日志文件表明數(shù)據(jù)傳輸占據(jù)了整個應(yīng)用處理時間的33%[3]。因此,能否提高DCN傳輸性能將極大影響用戶體驗。

為了提升DCN應(yīng)用中的網(wǎng)絡(luò)傳輸性能,國內(nèi)外學(xué)者做出了很多研究。最初的方案是基于數(shù)據(jù)流級別的延時敏感傳輸協(xié)議,這類協(xié)議以優(yōu)化流級別平均完成時間作為目標(biāo)。文獻(xiàn)[4-6]通過RTT的測量來檢測擁塞以調(diào)節(jié)擁塞窗口。這類協(xié)議需要準(zhǔn)確探知鏈路的往返時間(Round Trip Time,RTT)或者鏈路RTT的變化情況?；陲@式擁塞反饋(Explicit Congestion Notification,ECN)的協(xié)議DCTCP[7]、D2TCP[8]和 L2DCT[9]等利用ECN標(biāo)記來更準(zhǔn)確地反饋鏈路擁塞狀態(tài),從而調(diào)節(jié)發(fā)送速率[10]。然而,這些協(xié)議僅專注于流級別的數(shù)據(jù)傳輸控制,忽略了同一任務(wù)內(nèi)的數(shù)據(jù)流具有共同目標(biāo)的特性,降低了應(yīng)用任務(wù)的性能。

針對以上問題,文獻(xiàn)[11]假設(shè)已有任務(wù)的先驗信息,利用中央調(diào)度器進(jìn)行集中調(diào)度,提出最小瓶頸優(yōu)先調(diào)度算法和MADD帶寬分配算法,實現(xiàn)了近乎完美的調(diào)度系統(tǒng)。但是需要實時的網(wǎng)絡(luò)全局信息,調(diào)度開銷很大。文獻(xiàn)[12]通過分布式系統(tǒng)進(jìn)行任務(wù)調(diào)度,避免了額外的通信開銷,并且提出了FIFO-LM的調(diào)度算法,改變了傳統(tǒng)FIFO的調(diào)度模式,極大地避免了線頭阻塞。文獻(xiàn)[13]依據(jù)任務(wù)在集群中已發(fā)送的字節(jié)數(shù)更新coflow[14]在發(fā)送端的優(yōu)先級隊列,在不知道數(shù)據(jù)流先驗知識的條件下實現(xiàn)了D-CLAS[13](Discretized Coflow-aware Least-attained Service)策略。而文獻(xiàn)[15]首次提出在應(yīng)用透明的情況下,通過自動鑒別對任務(wù)進(jìn)行調(diào)度。CODA利用數(shù)據(jù)流的一些特定屬性,計算某2條數(shù)據(jù)流的屬性距離。如果小于特定的值,就認(rèn)為這2條屬于一個任務(wù),通過綁定來減小鑒別任務(wù)大小不準(zhǔn)確造成的影響。這些協(xié)議雖然通過任務(wù)感知進(jìn)行優(yōu)化,在一定程度上提升了任務(wù)級別的應(yīng)用性能,但是難以實現(xiàn)且部署代價太大。

本文提出一種對任務(wù)大小及流拖尾程度感知的TCP擁塞控制協(xié)議TLDCT。在任務(wù)內(nèi)部,減小所有數(shù)據(jù)流中拖尾流的完成時間,加速任務(wù)的完成時間。在任務(wù)之間感知任務(wù)大小,通過協(xié)議設(shè)計使得小任務(wù)優(yōu)先,旨在減少平均任務(wù)完成時間。

1 問題分析

為了分析提升任務(wù)完成時間的關(guān)鍵因素,從DCN中應(yīng)用任務(wù)的大小感知和任務(wù)內(nèi)部流拖尾兩個方面進(jìn)行分析,探究對任務(wù)平均完成時間的影響。

1.1 任務(wù)大小感知

在網(wǎng)絡(luò)中存在分屬于任務(wù)A和任務(wù)B的4條流,所有流同時到達(dá),如圖1(a)所示。獨(dú)占帶寬時所需要的完成時間分別是3、3、3、1個單位。圖1(b)是基于流公平共享帶寬時,各數(shù)據(jù)流完成過程的時序圖。此時,網(wǎng)絡(luò)中所有未完成的流獲得同樣的帶寬,流[fA1,fA2,fB1,fB2]將在[6,4,6,2]時刻完成,因此任務(wù)A和任務(wù)B都在6時刻完成。采用至少達(dá)到服務(wù)(Least Attained Service,LAS)策略[16]的時序圖如圖1(c)所示。由于LAS為最少服務(wù)流最高的服務(wù)優(yōu)先級,fA和fB也都在6時刻才完成。而采用任務(wù)大小感知策略則能有效減小平均任務(wù)完成時間。如圖1(d)所示,平均任務(wù)完成時間花費(fèi)了5個單位時間。

圖1 已發(fā)送任務(wù)大小感知動機(jī)

任務(wù)感知策略相比于公平共享策略和LAS策略降低了20%的完成時間。因此,為了最小化平均任務(wù)完成時間,當(dāng)小任務(wù)和大任務(wù)在同一個瓶頸時,優(yōu)先小任務(wù)的傳輸有利于減少小任務(wù)等待的時間,從而也能減小平均任務(wù)完成時間。

1.2 任務(wù)內(nèi)部流拖尾感知

由于任務(wù)由一組單獨(dú)的數(shù)據(jù)流組成,其完成時間由所有數(shù)據(jù)流中最后一條流的完成時間決定。

如圖2(a)所示,在同一個瓶頸交換機(jī)下的任務(wù)A包含2條流fA1和fA2,跟背景流fB競爭瓶頸傳輸數(shù)據(jù)。fA1、fA2和fB在獨(dú)占帶寬的情況下分別需要[1,2,3]個單位時間完成。fB和fA1在0時刻同時開始傳輸,fA2在1時刻開始傳輸。圖2(b)為采用公平共享帶寬策略時,fA1和fA2分別在2.5和5.5時刻完成,所以任務(wù)完成需要5.5個單位時間。采用LAS策略的時序圖如圖2(c)所示,fA和fB分別在3和5時刻完成。如圖2(d)所示,在任務(wù)內(nèi)部流拖尾程度感知的情況下,任務(wù)內(nèi)部發(fā)送速率快的流將一部分帶寬讓給發(fā)送速率慢的流,則2條流都在4.75時刻完成。這相比于公平共享策略和LAS策略將任務(wù)完成時間降低了15%和5.2%。

圖2 拖尾流感知動機(jī)

2 協(xié)議設(shè)計

DCN中應(yīng)用執(zhí)行的任務(wù)具有多樣性、復(fù)雜性和未知性。設(shè)計是針對DCN中未知先驗知識的任務(wù),將從區(qū)分任務(wù)大小和感知任務(wù)內(nèi)部拖尾流程度2個部分來降低任務(wù)的平均完成時間。綜合這2個部分提出降低平均任務(wù)完成時間的傳輸控制協(xié)議TLDCT。

2.1 任務(wù)大小因子和拖尾因子

為了控制任務(wù)的傳輸速率,定義了一個任務(wù)傳輸速率控制因子β,其計算如式(1)。其中,St表示任務(wù)已發(fā)送字節(jié)數(shù),taskmin和taskmax是任務(wù)已發(fā)送字節(jié)數(shù)的最大最小門限值。任務(wù)傳輸速率控制因子β隨著任務(wù)已發(fā)送字節(jié)數(shù)變化。β初始值為0.5;當(dāng)任務(wù)已發(fā)送字節(jié)數(shù)超過taskmin時,β呈線性上升;當(dāng)任務(wù)已發(fā)送字節(jié)數(shù)超過最大門限taskmax時,β為1.5。文獻(xiàn)[17]分析了Web搜索應(yīng)用的任務(wù)流量模型。其中約82%任務(wù)大小都分布在47 KB左右,而大約15%的任務(wù)遠(yuǎn)大于100 KB。在這種流量模型下,將taskmin和taskmax分別設(shè)置為47 KB和100 KB。

(1)

另一方面,為了控制任務(wù)內(nèi)部的流傳輸速率,定義了任務(wù)內(nèi)部流傳輸速率控制因子γ,其計算公式如式(2)。其中,Sf表示流已發(fā)送字節(jié)數(shù),St表示任務(wù)已發(fā)送字節(jié)數(shù),n表示任務(wù)內(nèi)部的流數(shù)目。任務(wù)內(nèi)部流傳輸速率控制因子γ由該流已發(fā)送字節(jié)數(shù)和它所屬任務(wù)的平均每條流已發(fā)送字節(jié)數(shù)的差值除以該流已發(fā)送字節(jié)數(shù)決定,在數(shù)值小于0時歸一到0值。

(2)

2.2 詳細(xì)設(shè)計

本節(jié)詳細(xì)闡述TLDCT協(xié)議在發(fā)送端、接收端的設(shè)計部署。TLDCT協(xié)議基于DCTCP協(xié)議擴(kuò)展,利用ECN標(biāo)記動態(tài)反饋鏈路擁塞狀況。

接收方收到發(fā)送方的握手包,獲取握手包中所攜帶的任務(wù)id號,并查詢是否已經(jīng)接收過同一id號的任務(wù)子流。若已接收過,就將該任務(wù)子流數(shù)目n加1。若初次收到該任務(wù),初始化變量St和n,記錄已發(fā)送字節(jié)數(shù)和任務(wù)子流數(shù)目n,令St=0,n=1。接收方收到數(shù)據(jù)包時就更新對應(yīng)任務(wù)的St值。在收到關(guān)閉連接的FIN包時就將對應(yīng)的n減1,直到n等于0時釋放存儲空間St和n。接收方在向發(fā)送方發(fā)送ACK時,將St和n值寫入到ACK確認(rèn)包TCP頭部32 bit的選項字段中返回給發(fā)送方。

發(fā)送方收到當(dāng)前發(fā)送窗口內(nèi)的全部確認(rèn)包ACK之后,依據(jù)擁塞標(biāo)志位被標(biāo)記的ACK數(shù)量計算擁塞程度:

(3)

其中,cwnd是當(dāng)前發(fā)送窗口大小,m是當(dāng)前發(fā)送窗口中擁塞標(biāo)志位被標(biāo)記的ACK包數(shù)量,αn表示當(dāng)前數(shù)據(jù)包往返周期的擁塞度(α0=0),αn-1表示上一個數(shù)據(jù)包往返周期的擁塞度,g表示滑動平均權(quán)值。接收方在收到本輪窗口最后一個數(shù)據(jù)包的ACK包后,獲得ACK中的任務(wù)已發(fā)送字節(jié)數(shù)St和任務(wù)中流條數(shù)n,利用式(1)計算得到任務(wù)大小因子。接收方在每次收到數(shù)據(jù)包的ACK時需要更新已確認(rèn)發(fā)送字節(jié)數(shù)Sf,利用式(2)求出流的拖尾因子。

發(fā)送方通過之前計算出來的α、β、γ更新當(dāng)前發(fā)送窗口cwnd:

(4)

3 性能評估

利用NS2模擬器對TLDCT協(xié)議以及DCTCP協(xié)議、L2DCT協(xié)議和Baraat進(jìn)行基礎(chǔ)性能對比測試。然后針對大規(guī)模場景,評估TLDCT協(xié)議。根據(jù)數(shù)據(jù)中心網(wǎng)絡(luò)中的應(yīng)用任務(wù)大小分布情況[17],約82%任務(wù)大小都分布在47 KB左右,而剩下約18%的任務(wù)都遠(yuǎn)大于100 KB。因此,將式(1)中的taskmin和taskmax分別設(shè)置為47 KB和100 KB。

3.1 基礎(chǔ)性能測試

從區(qū)分任務(wù)大小和感知任務(wù)內(nèi)部拖尾流程度2個部分來測試協(xié)議性能。實驗拓?fù)錇槎鄬σ荒Ｐ蚚9]。

3.1.1 區(qū)分任務(wù)大小性能對比

圖3比較了DCTCP、L2DCT、Baraat和TLDCT的大任務(wù)和小任務(wù)數(shù)據(jù)量在不同比值情況下的平均任務(wù)完成時間。實驗包含3組比值,從圖3可見,因為TLDCT加速了小任務(wù)的發(fā)送速率,減小了小任務(wù)等待傳輸?shù)臅r間,最終降低了平均任務(wù)完成時間。其中,隨著大小任務(wù)的數(shù)據(jù)量差距增加,TLDCT的收益越明顯。例如,在大小任務(wù)數(shù)據(jù)量之比為2∶5的實驗中,TLDCT的平均任務(wù)完成時間相比于DCTCP和L2DCT分別減少了17.5%和16.8%,僅比Baraat增多了8.7%。Baraat雖然取得了最好的性能,但其也帶來極大的分布式部署開銷。

圖3 加速小任務(wù)完成時間對比

3.1.2 感知拖尾流性能對比

圖4顯示了DCTCP、L2DCT、Baraat和TLDCT任務(wù)內(nèi)部出現(xiàn)拖尾流的平均任務(wù)完成時間。每個任務(wù)中的數(shù)據(jù)流開始發(fā)送數(shù)據(jù)的相差時間分別在20 ms、50 ms、100 ms服從均勻分布。圖4顯示,相比于DCTCP和L2DCT,TLDCT的平均任務(wù)完成時間有所降低。隨著時間間隔加大,TLDCT能提升拖尾流的發(fā)送速率,進(jìn)一步加快任務(wù)完成速度,與Baraat的差距也越來越小。

圖4 加速任務(wù)內(nèi)部拖尾流任務(wù)完成時間對比

3.2 協(xié)議性能測試

圖5顯示了TLDCT在真實DCN流量模型下的加速效果。其中,100臺主機(jī)通過同一交換機(jī)向一臺匯聚主機(jī)共發(fā)送2 038條流。這些流組成了4類任務(wù),具體包括窄短任務(wù)、窄長任務(wù)、寬短任務(wù)和寬長任務(wù)。其中,52個窄短任務(wù)的寬度為3,流大小都是10 KB;16個窄長任務(wù)的寬度為7,流大小都是200 KB;15個寬短任務(wù)的寬度為50,流大小都是9 KB;17個寬長任務(wù)的寬度為60,流大小都是3 MB。任務(wù)的發(fā)送開始時間服從泊松到達(dá)分布,任務(wù)內(nèi)部所有流的發(fā)送時間均勻分布在100 ms內(nèi)。圖5實驗結(jié)果顯示,TLDCT前50%、75%、95%完成任務(wù)的平均任務(wù)完成時間相比于DCTCP分別減少了47.0%、34.3%、15.1%,相比于 L2DCT減少了45.3%、29.9%、12.4%,相比于Baraat增加了17.6%、29.8%、5.2%。

圖5 綜合大規(guī)模實驗任務(wù)完成時間對比

4 結(jié)束語

本文針對DCN中數(shù)據(jù)流具有的任務(wù)關(guān)聯(lián)性,提出了一種任務(wù)大小和流拖尾感知的擁塞控制協(xié)議——TLDCT。該協(xié)議從加速拖尾流和小任務(wù)出發(fā),在考慮數(shù)據(jù)中心實際環(huán)境的情況和易于部署的情況下,減少了任務(wù)的平均完成時間,提升了應(yīng)用性能。在此基礎(chǔ)上,下一步研究方向是在保證易于部署的前提下,實現(xiàn)閾值的自適應(yīng)調(diào)節(jié)方法。

[1] 李 丹,陳貴海,任豐原,等.數(shù)據(jù)中心網(wǎng)絡(luò)的研究進(jìn)展與趨勢[J].計算機(jī)學(xué)報,2014,37(2):259-274.

[2] MEISNER D,SADLER C M,BARROSO L A,et al.Power management of online data-intensive services[C]// Proceedings of the 38th Annual International Symposium on Computer Architecture.New York,USA:ACM Press,2011:319-330.

[3] CHOWDHURY M,ZAHARIA M,MA J,et al.Managing data transfers in computer clusters with orchestra[C]//Proceedings of ACM SIGCOMM Conference.New York,USA:ACM Press,2011:98-109.

[4] MITTAL R,LAM V T,DUKKIPATI N,et al.TIMELY:RTT-based congestion control for the datacenter[C]//Proceedings of ACM Conference on Special Interest Group on Data Communication.New York,USA:ACM Press,2015:537-550.

[5] LEE C,PARK C,JANG K,et al.Accurate latency-based congestion feedback for datacenters[C]//Proceedings of USENIX Technical Conference.Daejeon,Korea:[s.n.],2015:403-415.

[6] WU Haitao,FENG Zhenqian,GUO Chuanxiong,et al.ICTCP:incast congestion control for TCP in data center networks[J].IEEE/ACM Transactions on Networking,2010,21(2):345-358.

[7] ALIZADEH M,GREENBERG A,MALTZ D A,et al.DCTCP:efficient packet transport for the commoditized data center[C]//Proceedings of ACM SIGCOMM’2010.New York,USA:ACM Press,2010:1-15.

[8] VAMANAN B,HASAN J,VIJAYKUMAR T N,et al.Deadline-aware datadcenter TCP(D2TCP)[EB/OL].[2017-02-01].http://www.raincent.com/content-84-162-1.html.

[9] MUNIR A,QAZI I,UZMI Z,et al.Minimizing flow completion times in data centers[C]//Proceedings of INFOCOM’2013.Washington D.C.,USA:IEEE Press,2013:2157-2165.

[10] 蘇凡軍,牛詠梅,邵 清.數(shù)據(jù)中心網(wǎng)絡(luò)快速反饋傳輸控制協(xié)議[J].計算機(jī)工程,2015,41(4):107-111.

[11] CHOWDHURY M,ZHONG Yuan,STOICA I.Efficient coflow scheduling with varys[C]//Proceedings of ACM Conference on SIGCOMM.New York,USA:ACM Press,2014:443-454.

[12] DOGAR F R,KARAGIANNIS T,BALLANI H,et al.Decentralized task-aware scheduling for data center networks[C]//Proceedings of ACM Conference on SIGCOMM.New York,USA:ACM Press,2014:431-442.

[13] CHOWDHURY M,STOICA I.Efficient coflow scheduling without prior knowledge[C]//Proceedings of ACM Conference on Special Interest Group on Data Communication.New York,USA:ACM Press,2015:393-406.

[14] CHOWDHURY M,STOICA I.Coflow:an application layer abstraction for cluster networking[EB/OL].[2017-03-10].http://www2.eecs.berkeley.edu/Pubs/TechRpts/2012/EECS-2012-184.pdf.

[15] ZHANG Hong,CHEN Li,YI Bairen,et al.CODA:toward automatically identifying and scheduling coflows in the dark[C]//Proceedings of ACM Sigcomm Conference.New York,USA:ACM Press,2016:160-173.

[16] RAI I A,URVOY-KELLER G,BIERSACK E W.Analysis of LAS scheduling for job size distributions with high variance[J].ACM SIGMETRICS Perfor-mance Evaluation Review,2003,31(1):218-228.

[17] JALAPARTI V,BODIK P,KANDULA S,et al.Speeding up distributed request-response workflows[C]//Pro-ceedings of ACM SIGCOMM Conference.New York,USA:ACM Press,2013:219-230.