,,
(中南大學(xué) 信息科學(xué)與工程學(xué)院,長沙 410083)
近年來,隨著網(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ī)模的計(jì)算和存儲(chǔ)資源來為用戶提供各種服務(wù)[2]。數(shù)據(jù)中心網(wǎng)絡(luò)中的應(yīng)用任務(wù)包含一組相互獨(dú)立卻擁有共同目標(biāo)的數(shù)據(jù)流,這些數(shù)據(jù)流中拖尾流的完成時(shí)間決定整個(gè)任務(wù)的完成時(shí)間。而數(shù)據(jù)中心網(wǎng)絡(luò)中數(shù)據(jù)傳輸?shù)臅r(shí)延是影響DCN中應(yīng)用性能至關(guān)重要的一部分[2]。Facebook的日志文件表明數(shù)據(jù)傳輸占據(jù)了整個(gè)應(yīng)用處理時(shí)間的33%[3]。因此,能否提高DCN傳輸性能將極大影響用戶體驗(yàn)。
為了提升DCN應(yīng)用中的網(wǎng)絡(luò)傳輸性能,國內(nèi)外學(xué)者做出了很多研究。最初的方案是基于數(shù)據(jù)流級別的延時(shí)敏感傳輸協(xié)議,這類協(xié)議以優(yōu)化流級別平均完成時(shí)間作為目標(biāo)。文獻(xiàn)[4-6]通過RTT的測量來檢測擁塞以調(diào)節(jié)擁塞窗口。這類協(xié)議需要準(zhǔn)確探知鏈路的往返時(shí)間(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ù)的先驗(yàn)信息,利用中央調(diào)度器進(jìn)行集中調(diào)度,提出最小瓶頸優(yōu)先調(diào)度算法和MADD帶寬分配算法,實(shí)現(xiàn)了近乎完美的調(diào)度系統(tǒng)。但是需要實(shí)時(shí)的網(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)先級隊(duì)列,在不知道數(shù)據(jù)流先驗(yàn)知識(shí)的條件下實(shí)現(xiàn)了D-CLAS[13](Discretized Coflow-aware Least-attained Service)策略。而文獻(xiàn)[15]首次提出在應(yīng)用透明的情況下,通過自動(dòng)鑒別對任務(wù)進(jìn)行調(diào)度。CODA利用數(shù)據(jù)流的一些特定屬性,計(jì)算某2條數(shù)據(jù)流的屬性距離。如果小于特定的值,就認(rèn)為這2條屬于一個(gè)任務(wù),通過綁定來減小鑒別任務(wù)大小不準(zhǔn)確造成的影響。這些協(xié)議雖然通過任務(wù)感知進(jìn)行優(yōu)化,在一定程度上提升了任務(wù)級別的應(yīng)用性能,但是難以實(shí)現(xiàn)且部署代價(jià)太大。
本文提出一種對任務(wù)大小及流拖尾程度感知的TCP擁塞控制協(xié)議TLDCT。在任務(wù)內(nèi)部,減小所有數(shù)據(jù)流中拖尾流的完成時(shí)間,加速任務(wù)的完成時(shí)間。在任務(wù)之間感知任務(wù)大小,通過協(xié)議設(shè)計(jì)使得小任務(wù)優(yōu)先,旨在減少平均任務(wù)完成時(shí)間。
為了分析提升任務(wù)完成時(shí)間的關(guān)鍵因素,從DCN中應(yīng)用任務(wù)的大小感知和任務(wù)內(nèi)部流拖尾兩個(gè)方面進(jìn)行分析,探究對任務(wù)平均完成時(shí)間的影響。
在網(wǎng)絡(luò)中存在分屬于任務(wù)A和任務(wù)B的4條流,所有流同時(shí)到達(dá),如圖1(a)所示。獨(dú)占帶寬時(shí)所需要的完成時(shí)間分別是3、3、3、1個(gè)單位。圖1(b)是基于流公平共享帶寬時(shí),各數(shù)據(jù)流完成過程的時(shí)序圖。此時(shí),網(wǎng)絡(luò)中所有未完成的流獲得同樣的帶寬,流[fA1,fA2,fB1,fB2]將在[6,4,6,2]時(shí)刻完成,因此任務(wù)A和任務(wù)B都在6時(shí)刻完成。采用至少達(dá)到服務(wù)(Least Attained Service,LAS)策略[16]的時(shí)序圖如圖1(c)所示。由于LAS為最少服務(wù)流最高的服務(wù)優(yōu)先級,fA和fB也都在6時(shí)刻才完成。而采用任務(wù)大小感知策略則能有效減小平均任務(wù)完成時(shí)間。如圖1(d)所示,平均任務(wù)完成時(shí)間花費(fèi)了5個(gè)單位時(shí)間。
圖1 已發(fā)送任務(wù)大小感知?jiǎng)訖C(jī)
任務(wù)感知策略相比于公平共享策略和LAS策略降低了20%的完成時(shí)間。因此,為了最小化平均任務(wù)完成時(shí)間,當(dāng)小任務(wù)和大任務(wù)在同一個(gè)瓶頸時(shí),優(yōu)先小任務(wù)的傳輸有利于減少小任務(wù)等待的時(shí)間,從而也能減小平均任務(wù)完成時(shí)間。
由于任務(wù)由一組單獨(dú)的數(shù)據(jù)流組成,其完成時(shí)間由所有數(shù)據(jù)流中最后一條流的完成時(shí)間決定。
如圖2(a)所示,在同一個(gè)瓶頸交換機(jī)下的任務(wù)A包含2條流fA1和fA2,跟背景流fB競爭瓶頸傳輸數(shù)據(jù)。fA1、fA2和fB在獨(dú)占帶寬的情況下分別需要[1,2,3]個(gè)單位時(shí)間完成。fB和fA1在0時(shí)刻同時(shí)開始傳輸,fA2在1時(shí)刻開始傳輸。圖2(b)為采用公平共享帶寬策略時(shí),fA1和fA2分別在2.5和5.5時(shí)刻完成,所以任務(wù)完成需要5.5個(gè)單位時(shí)間。采用LAS策略的時(shí)序圖如圖2(c)所示,fA和fB分別在3和5時(shí)刻完成。如圖2(d)所示,在任務(wù)內(nèi)部流拖尾程度感知的情況下,任務(wù)內(nèi)部發(fā)送速率快的流將一部分帶寬讓給發(fā)送速率慢的流,則2條流都在4.75時(shí)刻完成。這相比于公平共享策略和LAS策略將任務(wù)完成時(shí)間降低了15%和5.2%。
圖2 拖尾流感知?jiǎng)訖C(jī)
DCN中應(yīng)用執(zhí)行的任務(wù)具有多樣性、復(fù)雜性和未知性。設(shè)計(jì)是針對DCN中未知先驗(yàn)知識(shí)的任務(wù),將從區(qū)分任務(wù)大小和感知任務(wù)內(nèi)部拖尾流程度2個(gè)部分來降低任務(wù)的平均完成時(shí)間。綜合這2個(gè)部分提出降低平均任務(wù)完成時(shí)間的傳輸控制協(xié)議TLDCT。
為了控制任務(wù)的傳輸速率,定義了一個(gè)任務(wù)傳輸速率控制因子β,其計(jì)算如式(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時(shí),β呈線性上升;當(dāng)任務(wù)已發(fā)送字節(jié)數(shù)超過最大門限taskmax時(shí),β為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)部流傳輸速率控制因子γ,其計(jì)算公式如式(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時(shí)歸一到0值。
(2)
本節(jié)詳細(xì)闡述TLDCT協(xié)議在發(fā)送端、接收端的設(shè)計(jì)部署。TLDCT協(xié)議基于DCTCP協(xié)議擴(kuò)展,利用ECN標(biāo)記動(dòng)態(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ù)包時(shí)就更新對應(yīng)任務(wù)的St值。在收到關(guān)閉連接的FIN包時(shí)就將對應(yīng)的n減1,直到n等于0時(shí)釋放存儲(chǔ)空間St和n。接收方在向發(fā)送方發(fā)送ACK時(shí),將St和n值寫入到ACK確認(rèn)包TCP頭部32 bit的選項(xiàng)字段中返回給發(fā)送方。
發(fā)送方收到當(dāng)前發(fā)送窗口內(nèi)的全部確認(rèn)包ACK之后,依據(jù)擁塞標(biāo)志位被標(biāo)記的ACK數(shù)量計(jì)算擁塞程度:
(3)
其中,cwnd是當(dāng)前發(fā)送窗口大小,m是當(dāng)前發(fā)送窗口中擁塞標(biāo)志位被標(biāo)記的ACK包數(shù)量,αn表示當(dāng)前數(shù)據(jù)包往返周期的擁塞度(α0=0),αn-1表示上一個(gè)數(shù)據(jù)包往返周期的擁塞度,g表示滑動(dòng)平均權(quán)值。接收方在收到本輪窗口最后一個(gè)數(shù)據(jù)包的ACK包后,獲得ACK中的任務(wù)已發(fā)送字節(jié)數(shù)St和任務(wù)中流條數(shù)n,利用式(1)計(jì)算得到任務(wù)大小因子。接收方在每次收到數(shù)據(jù)包的ACK時(shí)需要更新已確認(rèn)發(fā)送字節(jié)數(shù)Sf,利用式(2)求出流的拖尾因子。
發(fā)送方通過之前計(jì)算出來的α、β、γ更新當(dāng)前發(fā)送窗口cwnd:
(4)
利用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。
從區(qū)分任務(wù)大小和感知任務(wù)內(nèi)部拖尾流程度2個(gè)部分來測試協(xié)議性能。實(shí)驗(yàn)拓?fù)錇槎鄬σ荒P蚚9]。
3.1.1 區(qū)分任務(wù)大小性能對比
圖3比較了DCTCP、L2DCT、Baraat和TLDCT的大任務(wù)和小任務(wù)數(shù)據(jù)量在不同比值情況下的平均任務(wù)完成時(shí)間。實(shí)驗(yàn)包含3組比值,從圖3可見,因?yàn)門LDCT加速了小任務(wù)的發(fā)送速率,減小了小任務(wù)等待傳輸?shù)臅r(shí)間,最終降低了平均任務(wù)完成時(shí)間。其中,隨著大小任務(wù)的數(shù)據(jù)量差距增加,TLDCT的收益越明顯。例如,在大小任務(wù)數(shù)據(jù)量之比為2∶5的實(shí)驗(yàn)中,TLDCT的平均任務(wù)完成時(shí)間相比于DCTCP和L2DCT分別減少了17.5%和16.8%,僅比Baraat增多了8.7%。Baraat雖然取得了最好的性能,但其也帶來極大的分布式部署開銷。
圖3 加速小任務(wù)完成時(shí)間對比
3.1.2 感知拖尾流性能對比
圖4顯示了DCTCP、L2DCT、Baraat和TLDCT任務(wù)內(nèi)部出現(xiàn)拖尾流的平均任務(wù)完成時(shí)間。每個(gè)任務(wù)中的數(shù)據(jù)流開始發(fā)送數(shù)據(jù)的相差時(shí)間分別在20 ms、50 ms、100 ms服從均勻分布。圖4顯示,相比于DCTCP和L2DCT,TLDCT的平均任務(wù)完成時(shí)間有所降低。隨著時(shí)間間隔加大,TLDCT能提升拖尾流的發(fā)送速率,進(jìn)一步加快任務(wù)完成速度,與Baraat的差距也越來越小。
圖4 加速任務(wù)內(nèi)部拖尾流任務(wù)完成時(shí)間對比
圖5顯示了TLDCT在真實(shí)DCN流量模型下的加速效果。其中,100臺(tái)主機(jī)通過同一交換機(jī)向一臺(tái)匯聚主機(jī)共發(fā)送2 038條流。這些流組成了4類任務(wù),具體包括窄短任務(wù)、窄長任務(wù)、寬短任務(wù)和寬長任務(wù)。其中,52個(gè)窄短任務(wù)的寬度為3,流大小都是10 KB;16個(gè)窄長任務(wù)的寬度為7,流大小都是200 KB;15個(gè)寬短任務(wù)的寬度為50,流大小都是9 KB;17個(gè)寬長任務(wù)的寬度為60,流大小都是3 MB。任務(wù)的發(fā)送開始時(shí)間服從泊松到達(dá)分布,任務(wù)內(nèi)部所有流的發(fā)送時(shí)間均勻分布在100 ms內(nèi)。圖5實(shí)驗(yàn)結(jié)果顯示,TLDCT前50%、75%、95%完成任務(wù)的平均任務(wù)完成時(shí)間相比于DCTCP分別減少了47.0%、34.3%、15.1%,相比于 L2DCT減少了45.3%、29.9%、12.4%,相比于Baraat增加了17.6%、29.8%、5.2%。
圖5 綜合大規(guī)模實(shí)驗(yàn)任務(wù)完成時(shí)間對比
本文針對DCN中數(shù)據(jù)流具有的任務(wù)關(guān)聯(lián)性,提出了一種任務(wù)大小和流拖尾感知的擁塞控制協(xié)議——TLDCT。該協(xié)議從加速拖尾流和小任務(wù)出發(fā),在考慮數(shù)據(jù)中心實(shí)際環(huán)境的情況和易于部署的情況下,減少了任務(wù)的平均完成時(shí)間,提升了應(yīng)用性能。在此基礎(chǔ)上,下一步研究方向是在保證易于部署的前提下,實(shí)現(xiàn)閾值的自適應(yīng)調(diào)節(jié)方法。
[1] 李 丹,陳貴海,任豐原,等.數(shù)據(jù)中心網(wǎng)絡(luò)的研究進(jìn)展與趨勢[J].計(jì)算機(jī)學(xué)報(bào),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ì)算機(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.