云數(shù)據(jù)中心集群間網(wǎng)絡(luò)性能優(yōu)化的探討

蔣多元，陳海雄

（中國石化石油勘探開發(fā)研究院 北京100083）

1 引言

出于容錯備份、業(yè)務(wù)隔離、可擴(kuò)展性等需求，現(xiàn)代的大規(guī)模云計算任務(wù)往往被劃分到多個集群進(jìn)行處理。例如，規(guī)劃專用于計算的集群和專用于存儲的集群已經(jīng)成為一種常見的部署模式。在這種模式下，由于任務(wù)的完成需要多個集群協(xié)作完成，因此，規(guī)劃連接集群的網(wǎng)絡(luò)且保證網(wǎng)絡(luò)的性能具有重要意義。

由于集群間網(wǎng)絡(luò)一般用來承載數(shù)據(jù)備份、文件傳輸?shù)刃枰笕萘烤W(wǎng)絡(luò)的情況，對帶寬的要求很高；另一方面，由于集群一般會跨地域部署，鏈路時延一般相對較高。這兩個特性導(dǎo)致了經(jīng)常需要針對網(wǎng)絡(luò)實(shí)際承載業(yè)務(wù)的特性來對集群間網(wǎng)絡(luò)進(jìn)行有針對性的優(yōu)化。本文首先介紹了一次集群間網(wǎng)絡(luò)的性能問題的真實(shí)案例。這個案例來源于一個用于大規(guī)模實(shí)時數(shù)據(jù)處理的數(shù)據(jù)中心，在一次大規(guī)模并發(fā)任務(wù)中發(fā)現(xiàn)在帶寬并未完全使用的情況下發(fā)生了嚴(yán)重的分組丟失現(xiàn)象。其后，基于對拓?fù)浣Y(jié)構(gòu)的分析，介紹了對性能瓶頸的定位過程。接著，通過搭建測試環(huán)境并進(jìn)行實(shí)際測試，對性能瓶頸的來源進(jìn)行了發(fā)掘。最后，基于一個簡單的模型，分析了各個要素對于性能的影響，并基于分析結(jié)果設(shè)計了最終的解決方案。

2 相關(guān)研究工作

出于容災(zāi)、提高訪問速度等目的，現(xiàn)在很多大型的公司或組織在不同的地理位置建設(shè)了云服務(wù)集群。這些數(shù)據(jù)中心間一般通過專用的私有網(wǎng)絡(luò)或者從網(wǎng)絡(luò)運(yùn)營商租借的鏈路進(jìn)行連接。這類網(wǎng)絡(luò)一般用來承載跨數(shù)據(jù)中心的大數(shù)據(jù)量傳輸?shù)娜蝿?wù)。

由于這類網(wǎng)絡(luò)一般有較高的建設(shè)和運(yùn)維成本，其建立者會尋求充分利用這種網(wǎng)絡(luò)的能力。為此，當(dāng)前集群（或者數(shù)據(jù)中心）間的網(wǎng)絡(luò)性能優(yōu)化是一個熱門的學(xué)術(shù)問題，具體介紹如下。

· Google[1]和 Microsoft[2]研究了如何基于 SDN[3]技術(shù)來提高集群間網(wǎng)絡(luò)的利用率。提高網(wǎng)絡(luò)的利用率有助于降低其平均成本，但是由于散列不均衡等因素的影響，簡單地采用負(fù)載均衡技術(shù)并不能有效利用數(shù)據(jù)中心間的鏈路帶寬。此外，缺乏全局視圖的調(diào)度反而可能造成擁塞惡化。SDN恰好能解決這些問題，一方面，SDN能夠采用更加細(xì)粒度的分流技術(shù)，使得鏈路能夠被充分利用，避免不均衡的情況；另一方面，SDN可以基于全局視圖規(guī)劃流量，避免本地最優(yōu)導(dǎo)致的全局惡化現(xiàn)象。

·Netstitcher[4]研究了跨數(shù)據(jù)中心的大規(guī)模數(shù)據(jù)傳輸問題，提出利用存儲—轉(zhuǎn)發(fā)的方法和不同數(shù)據(jù)中心的可用帶寬的時間差，將數(shù)據(jù)中心間的帶寬在時間上“縫合”起來，從而滿足數(shù)據(jù)傳輸?shù)膸捫枨螅粎⒖嘉墨I(xiàn)[5]研究了一種數(shù)據(jù)中心間數(shù)據(jù)傳輸?shù)陌葱璧膸捁┙o方案，采用按需供給的方式滿足數(shù)據(jù)傳輸?shù)膸捫枨蟆?/p>

·由于數(shù)據(jù)中心間的鏈路往往是基于峰值進(jìn)行計費(fèi)的，參考文獻(xiàn)[6]研究了如何基于對大規(guī)模數(shù)據(jù)傳輸?shù)恼{(diào)度來平抑峰值，降低數(shù)據(jù)中心間數(shù)據(jù)傳輸?shù)恼{(diào)度開銷。

· 基于網(wǎng)絡(luò)的調(diào)度往往是被動的、基于當(dāng)前的，這導(dǎo)致無法取得主動、平穩(wěn)的調(diào)度結(jié)果；Microsoft最新的研究[7]表明，如果對大文件傳輸任務(wù)在時間域上進(jìn)行一個合理的規(guī)劃，將會更加有利于任務(wù)在時間期限前完成。

現(xiàn)有研究主要關(guān)注的是如何提高帶寬利用率來滿足帶寬敏感的業(yè)務(wù)的帶寬需求，而本文的研究主要關(guān)注的業(yè)務(wù)場景是不同的：除了對帶寬的需求，網(wǎng)絡(luò)同樣需要滿足時延和分組丟失率的要求，以滿足實(shí)時性業(yè)務(wù)的特征。據(jù)筆者所知，這是一個現(xiàn)有研究并未涉及的領(lǐng)域。和關(guān)注數(shù)據(jù)中心內(nèi)部數(shù)據(jù)傳輸時延的研究[8～11]不同的是，本文的研究關(guān)注的是跨數(shù)據(jù)中心的業(yè)務(wù)。

3 集群間網(wǎng)絡(luò)性能優(yōu)化案例場景

某云數(shù)據(jù)中心規(guī)劃的結(jié)構(gòu)如圖1所示。其中計算集群A和計算集群B執(zhí)行實(shí)時性較高的計算任務(wù)，在完成計算之后，需要將數(shù)據(jù)及時寫入存儲集群。計算集群A和計算集群B都需要處理大量的并發(fā)任務(wù)。但計算集群A經(jīng)常出現(xiàn)報文重傳或者任務(wù)失敗的現(xiàn)象，導(dǎo)致數(shù)據(jù)無法正常寫入存儲集群，而計算集群B沒有出現(xiàn)類似問題。

圖1 集群間網(wǎng)絡(luò)性能優(yōu)化案例場景

4 性能瓶頸定位

在故障追查中，首先考慮的是帶寬不足導(dǎo)致的問題，即路由器C和存儲集群之間的鏈路成為了瓶頸。但是，由于計算集群B到存儲集群并未出現(xiàn)網(wǎng)絡(luò)問題，這就否定了這段鏈路出現(xiàn)擁塞的可能性。而對實(shí)際數(shù)據(jù)的分析也發(fā)現(xiàn)，這段鏈路的利用率不足50%。由于這段鏈路沒有出現(xiàn)帶寬不足的問題，計算集群A到存儲集群的整個路徑上也不應(yīng)該出現(xiàn)帶寬問題。

在排除帶寬問題和路由器B、C的問題之后，將問題定位在交換機(jī)A上。初步推測是交換機(jī)A的某些配置不足造成的性能問題。

5 測試與結(jié)果

盡管初步估計是交換機(jī)A造成的性能低下，但是由于現(xiàn)網(wǎng)環(huán)境復(fù)雜，難以確定是什么原因造成了性能不足。為了進(jìn)一步追查問題，對交換機(jī)A展開了測試。測試環(huán)境如圖2所示。所有鏈路、接口帶寬都為10 Gbit/s。

圖2 測試場景

用qperf（qperf是測量網(wǎng)絡(luò)帶寬和時延的常用工具）測試從服務(wù)器A到其他服務(wù)器的時延情況。時延均為鏈路滿負(fù)荷時的時延。消息的大小范圍是1～1 024 KB。實(shí)驗結(jié)果見表 1。

作為對比，用qperf測試從服務(wù)器C到其他服務(wù)器的時延情況。消息的大小范圍同樣是1～1 024 KB。實(shí)驗結(jié)果見表 2。

表1 服務(wù)器A到達(dá)其他服務(wù)器的時延

表2 服務(wù)器C到達(dá)其他服務(wù)器的時延

為了方便比較，將時延和消息大小的關(guān)系畫在一張圖中，如圖3所示。

圖3 時延和消息大小的關(guān)系

由圖3可以明顯發(fā)現(xiàn)兩個問題。

（1）即便在默認(rèn)的分組長度下，交換機(jī)A造成的時延也顯著大于路由器C的時延，甚至可能高于服務(wù)器的網(wǎng)卡時延。這說明交換機(jī)A的轉(zhuǎn)發(fā)速率并不高。

（2）當(dāng)報文的大小超過一個閾值（8 KB左右）時，交換機(jī)A造成的時延將會急劇增加。由于這種報文長度大于鏈路層MTU，所以會被分片。時延的急劇增加說明交換機(jī)A可能丟棄數(shù)據(jù)幀的概率較高，這導(dǎo)致分片的重傳，進(jìn)而增加時延。而交換機(jī)A丟棄數(shù)據(jù)幀的可能原因是緩存隊列已經(jīng)滿了，無法進(jìn)一步存儲報文。

這兩個問題共同說明交換機(jī)A的處理能力和緩存可能構(gòu)成了瓶頸。

6 問題分析與解決

為了解決交換機(jī)A的問題，筆者首先建立了一個簡單的模型描述這個問題。

對于現(xiàn)代的交換機(jī)而言，其處理能力只與幀的到達(dá)速率有關(guān)，和幀大小的關(guān)系很小，為此，記交換機(jī)的處理能力是幀/秒（f/s）。緩存大小是Mbyte，鏈路帶寬是Bbyte，幀的大小是Fbyte。

如果交換機(jī)的處理能力是網(wǎng)絡(luò)的瓶頸，即：

在20 Gbit/s的鏈路中，采用默認(rèn)的以太網(wǎng)幀大小1 500 byte，相應(yīng)的交換機(jī)處理能力應(yīng)該達(dá)到1.71×106f/s。如果僅有這個能力的一半 （如10 Gbit/s網(wǎng)絡(luò)設(shè)計的交換機(jī)），交換機(jī)A的緩存僅有40 MB，這時緩存將在0.03 s內(nèi)被耗盡，進(jìn)而出現(xiàn)分組丟失現(xiàn)象。

提高網(wǎng)絡(luò)對峰值流量容忍能力的最直接方法是提高交換機(jī)的處理能力。圖4說明了提高交換機(jī)處理能力和可容忍峰值時間之間的關(guān)系。不過可以明顯看到的是，除非交換機(jī)處理能力非常接近或者高于峰值的幀速率，否則依然很難在流量達(dá)到峰值時正常工作。

圖4 在M=40 MB、B=20 Gbit/s時，能夠容忍的峰值時間和交換機(jī)處理能力間的關(guān)系

另外一個方法是增加交換機(jī)緩存。不過，如圖5所示，增加緩存取得的效果是線性的，而且即便將緩存增大到400 MB，容忍時間依然不夠長。

圖5 通過增加緩存的大小來提高對網(wǎng)絡(luò)峰值流量的容忍能力

相比之下，提高幀的大小是一個更加有效的方法，如采用巨幀（jumbo frame）技術(shù)[12]?，F(xiàn)在大多數(shù)交換機(jī)都已經(jīng)支持巨幀技術(shù)[13]。如圖6所示，如果把幀的大小從默認(rèn)的以太網(wǎng)上限1500 byte提高到2 600 byte左右，就可以對峰值流量的容忍時間更長。相比之下，改變幀的大小是相當(dāng)靈活的，比提高交換機(jī)的能力成本更低，適應(yīng)性更好。通過在網(wǎng)絡(luò)中開啟巨幀，最終解決了交換機(jī)A導(dǎo)致的重傳和寫入失敗問題。

圖6 通過增加幀的大小來提高對網(wǎng)絡(luò)峰值流量的容忍能力

7 結(jié)束語

當(dāng)前針對云計算集群間網(wǎng)絡(luò)的研究主要的關(guān)注點(diǎn)在于提高網(wǎng)絡(luò)的利用率，以滿足對帶寬需求高的應(yīng)用（如數(shù)據(jù)備份）。本文主要討論了另外一種場景：在集群間網(wǎng)絡(luò)支持實(shí)時性要求較高的應(yīng)用時，如何滿足這類應(yīng)用對于低時延和低分組丟失率的需求。本文通過實(shí)驗和分析發(fā)現(xiàn)，交換機(jī)的幀處理能力可能成為網(wǎng)絡(luò)的瓶頸，進(jìn)而導(dǎo)致時延增加和分組丟失。通過分析發(fā)現(xiàn)，增加幀的大小可以有效避免交換機(jī)處理能力不足導(dǎo)致的分組丟失，并通過巨幀技術(shù)解決了這一問題。本文是對當(dāng)前研究的一個重要補(bǔ)充。當(dāng)前對大規(guī)模數(shù)據(jù)處理的性能和實(shí)時性要求不斷增加，筆者認(rèn)為，在跨集群網(wǎng)絡(luò)上支持高度實(shí)時的應(yīng)用將成為一個廣泛的需求。特別地，如何在提高網(wǎng)絡(luò)利用率的情況下依然為實(shí)時性要求較高的應(yīng)用提供傳輸質(zhì)量保證，將是一個值得深入研究的問題。

1 Jain S,Kumar A,Mandal S,et al.B4:experience with a globally-deployed software defined WAN.Proceedings of the ACM SIGCOMM 2013 Conference on SIGCOMM,Hong Kong,China,2013

2 Hong C Y,Kandula S,Mahajan R,et al.Achieving high utilization with software-driven WAN.Proceedings of the ACM SIGCOMM 2013 Conference on SIGCOMM,Hong Kong,China,2013

3 McKeown N,Anderson T,Balakrishnan H,et al.OpenFlow:enabling innovation in campus networks.SIGCOMM Computer Commununication Review,2008,38(4):69～74

4 Laoutaris N,Sirivianos M,Yang X,et al.Inter-datacenter bulk transfers with netstitcher.Proceedings of the ACM SIGCOMM 2011 Conference,Toronto,Ontario,Canada,2011

5 Mahimkar A,Chiu A,Doverspike R,et al.Bandwidth on demand for inter-data center communication.Proceedings of the 10th ACM Workshop on Hot Topics in Networks,Cambridge,Massachusetts,2011

6 Nandagopal T,Puttaswamy K P N.Lowering inter-datacenter bandwidth costs via bulk data scheduling.Proceedings of the 12th IEEE/ACM International Symposium on Cluster,Cloud and Grid Computing(CCGrid 2012),Ottawa,Canada,2012

7 Kandula S,Menache I,Schwartz R,et al.Calendaring for wide area networks.Proceedings of the 2014 ACM Conference on SIGCOMM,Chicago,Illinois,USA,2014

8 Wilson C,Ballani H,Karagiannis T,et al.Better never than late:meeting deadlines in datacenter networks.Proceedings of the ACM SIGCOMM 2011 Conference,Toronto,Ontario,Canada,2011

9 Vamanan B,Hasan J,Vijaykumar T N.Deadline-aware datacenter TCP (D2TCP).ProceedingsoftheACM SIGCOMM 2012 Conference on Applications,Technologies,Architectures,and Protocols for Computer Communication,Helsinki,Finland,2012

10 Lee C,Jang K,Moon S.Reviving delay-based TCP for data centers.Proceedings of the ACM SIGCOMM 2012 Conference on Applications,Technologies,Architectures,and Protocols for Computer Communication,Helsinki,Finland,2012

11 Liu Y J,Gao P X,Wong B,et al.Quartz:a new design element for low-latency DCNs.Proceedings of the 2014 ACM Conference on SIGCOMM,Chicago,Illinois,USA,2014

12 Murray D,Koziniec T,Lee K,et al.Large MTUs and internet performance.Proceedings of IEEE the 13th International Conference on High Performance Switching and Routing(HPSR),Belgrade,Serbia,2012

13 Hogg S.Jumbo frames.http://www.networkworld.com/article/2224722/cisco-subnet/jumbo-frames.html,2013