羅 萱，葉 通，金耀輝,

（1.上海交通大學(xué)網(wǎng)絡(luò)信息中心 上海200240；2.上海交通大學(xué)區(qū)域光纖通信網(wǎng)與新型光通信系統(tǒng)國(guó)家重點(diǎn)實(shí)驗(yàn)室 上海200240）

1 數(shù)據(jù)中心網(wǎng)絡(luò)需求

云計(jì)算是一種起源于互聯(lián)網(wǎng)的計(jì)算服務(wù)，可以按照需求通過網(wǎng)絡(luò)將共享的軟硬件資源和信息提供給使用者。云計(jì)算可以分為3個(gè)層面：SaaS（software as a service，軟件即服務(wù)）、PaaS（platform as a service，平臺(tái)即服務(wù)）和IaaS（infrastructure as a service，基礎(chǔ)設(shè)施即服務(wù)）。從最基本的層面，IaaS通過虛擬化技術(shù)以共享資源池的形式為用戶提供計(jì)算、存儲(chǔ)和網(wǎng)絡(luò)等IT資源，用戶可以部署、控制和運(yùn)行操作系統(tǒng)及應(yīng)用軟件，并只需按照實(shí)際使用量付費(fèi)，極大地降低了建設(shè)和運(yùn)營(yíng)成本。同時(shí)，云計(jì)算提高了IT業(yè)務(wù)的靈活性和敏捷性，能夠?qū)Υ笠?guī)模的服務(wù)器資源進(jìn)行靈活的調(diào)配，快速地支持大量的并發(fā)請(qǐng)求或作業(yè)。國(guó)外很多公司已經(jīng)將自己的業(yè)務(wù)遷移到云計(jì)算平臺(tái)之上，新興的互聯(lián)網(wǎng)公司通常選擇將業(yè)務(wù)放在Amazon或Rackspace等提供的公有云上，如NetFlix、Dropbox等；而傳統(tǒng)的大型公司如AT&T、思科等則選擇在自己的數(shù)據(jù)中心建設(shè)私有云。

云計(jì)算的快速發(fā)展，伴隨著移動(dòng)互聯(lián)網(wǎng)和大數(shù)據(jù)的發(fā)展，對(duì)數(shù)據(jù)中心網(wǎng)絡(luò)提出了更高的要求。

1.1 大規(guī)模

業(yè)務(wù)的增長(zhǎng)導(dǎo)致帶寬的需求持續(xù)增加。云計(jì)算業(yè)務(wù)、多媒體業(yè)務(wù)以及移動(dòng)設(shè)備的普及使得人們對(duì)數(shù)據(jù)的消費(fèi)加速增長(zhǎng)。舉例而言，NetFlix作為美國(guó)最大的網(wǎng)絡(luò)視頻服務(wù)提供商，其業(yè)務(wù)流量已經(jīng)達(dá)到全美國(guó)流量的30%，其用戶仍在快速增長(zhǎng)。Amazon提供的S3（simple storage server）云存儲(chǔ)服務(wù)以及Dropbox提供的云存儲(chǔ)服務(wù)在近幾年來一直維持了指數(shù)增長(zhǎng)。根據(jù)2012年6月的統(tǒng)計(jì)數(shù)字，Amazon S3已經(jīng)存儲(chǔ)了1萬億對(duì)象（每個(gè)對(duì)象的容量上限為1 TB）。這樣的增長(zhǎng)對(duì)互聯(lián)網(wǎng)的帶寬提出了很高的要求。同時(shí)，它對(duì)數(shù)據(jù)中心網(wǎng)絡(luò)的帶寬要求更為強(qiáng)烈。其原因在于數(shù)據(jù)中心中不僅要處理前端用戶對(duì)這些海量數(shù)據(jù)的訪問，也要進(jìn)行后端程序?qū)Υ祟悢?shù)據(jù)的處理、索引、同步和備份等操作。

1.2 租戶隔離

數(shù)據(jù)中心需要能夠同時(shí)支持多個(gè)租戶。出于數(shù)據(jù)隔離和隱私保障的需求，租戶申請(qǐng)的資源，包括計(jì)算、存儲(chǔ)和網(wǎng)絡(luò)，應(yīng)該與其他租戶的資源隔離開，以保護(hù)租戶的數(shù)據(jù)在任何地方都不被泄漏。在云計(jì)算環(huán)境中，租戶的隔離通常采用虛擬化技術(shù)，對(duì)應(yīng)在網(wǎng)絡(luò)中就是網(wǎng)絡(luò)虛擬化。數(shù)據(jù)中心為每個(gè)租戶或業(yè)務(wù)分配一個(gè)虛擬網(wǎng)絡(luò)，租戶在虛擬網(wǎng)絡(luò)內(nèi)可以獨(dú)享自己定制的網(wǎng)絡(luò)資源，而不關(guān)心物理網(wǎng)絡(luò)的細(xì)節(jié)。虛擬網(wǎng)絡(luò)之間的相互訪問需要通過租戶定制的策略許可。對(duì)于大型的數(shù)據(jù)中心，其服務(wù)的租戶數(shù)量也非常大，例如Amazon數(shù)據(jù)中心在全球范圍內(nèi)已擁有數(shù)十萬計(jì)的企業(yè)租戶，并且還在不斷增長(zhǎng)。根據(jù)數(shù)據(jù)中心運(yùn)營(yíng)商Digital Realty的統(tǒng)計(jì)，近幾年租用數(shù)據(jù)中心的企業(yè)數(shù)量按每年7%增長(zhǎng)，這要求網(wǎng)絡(luò)虛擬化技術(shù)具有一定的可擴(kuò)展性。

1.3 服務(wù)保證

租戶的業(yè)務(wù)呈現(xiàn)多樣性。不同的業(yè)務(wù)對(duì)于網(wǎng)絡(luò)的服務(wù)質(zhì)量要求是不一樣的，這些需求包括分組丟失率、傳輸時(shí)延、可靠性等。例如，金融業(yè)務(wù)對(duì)實(shí)時(shí)性、可靠性要求就非常嚴(yán)格，股票交易時(shí)間搶點(diǎn)可能會(huì)導(dǎo)致租戶收益的顯著差別；相反，電子郵件業(yè)務(wù)則可忍受較高的傳輸時(shí)延和秒級(jí)以上的系統(tǒng)故障。當(dāng)租戶提出不同的需求時(shí)，網(wǎng)絡(luò)需要能夠自動(dòng)、迅速地給出資源分配方案。

此外，數(shù)據(jù)中心業(yè)務(wù)的動(dòng)態(tài)性呈現(xiàn)出急劇增長(zhǎng)。云計(jì)算的一大特性就是能夠動(dòng)態(tài)地為用戶提供彈性服務(wù)，在很短的時(shí)間內(nèi)提供大量資源。很多業(yè)務(wù)需要端到端的大容量通道進(jìn)行數(shù)據(jù)傳輸與備份，而其特殊性在于此類通道的需求具有突發(fā)性，而且并不會(huì)持續(xù)很長(zhǎng)時(shí)間。一個(gè)典型的例子是MapReduce，shuffle過程中需要的帶寬遠(yuǎn)大于其他過程中需要的帶寬，并且通常不會(huì)持續(xù)太久。移動(dòng)設(shè)備的普及也對(duì)網(wǎng)絡(luò)的動(dòng)態(tài)資源分配提出了迫切需求。在某個(gè)特定的時(shí)間與地點(diǎn)，大量的移動(dòng)用戶請(qǐng)求會(huì)產(chǎn)生巨大的網(wǎng)絡(luò)流量。例如大型體育比賽中，很多用戶會(huì)通過移動(dòng)設(shè)備獲取相關(guān)資料，也會(huì)通過文字、圖片以及音頻、視頻分享現(xiàn)場(chǎng)實(shí)況。可以預(yù)見的是，隨著視頻業(yè)務(wù)的不斷發(fā)展，在類似的情況下數(shù)據(jù)消耗總量將會(huì)出現(xiàn)巨大增長(zhǎng)，數(shù)據(jù)中心網(wǎng)絡(luò)需要能夠保證這類應(yīng)用的彈性帶寬需求。

為了滿足大量租戶巨大的帶寬需求，數(shù)據(jù)中心網(wǎng)絡(luò)在數(shù)據(jù)層面必須擁有一個(gè)可擴(kuò)展的物理網(wǎng)絡(luò)，即在不顯著增加系統(tǒng)代價(jià)（如能耗、硬件成本）的前提下，提升數(shù)據(jù)中心的帶寬供應(yīng)能力，滿足不同租戶的寬帶傳輸需求；為對(duì)多個(gè)租戶的資源定制需求做出快速響應(yīng)，在控制平面需要具有較強(qiáng)的網(wǎng)絡(luò)虛擬化管理的能力，從大量復(fù)雜的物理資源中為每個(gè)租戶虛擬出一個(gè)私有的子網(wǎng)絡(luò)；為滿足不同租戶對(duì)可靠性的要求,需要同時(shí)從兩個(gè)平面出發(fā)設(shè)計(jì)一個(gè)可感知服務(wù)質(zhì)量的可靠性機(jī)制，既能滿足可靠性需求又不會(huì)造成物理資源的過度冗余。下文將圍繞物理網(wǎng)絡(luò)、網(wǎng)絡(luò)虛擬化以及性能保證這3個(gè)方面介紹當(dāng)前的研究熱點(diǎn)。

2 物理網(wǎng)絡(luò)

對(duì)于控制層面而言，理想的數(shù)據(jù)平面應(yīng)該提供一個(gè)簡(jiǎn)單而又無阻塞的物理層網(wǎng)絡(luò)，即物理層面可以快速地為服務(wù)器之間或者虛擬機(jī)之間的業(yè)務(wù)分配一組帶寬足夠的通路。為達(dá)到這個(gè)目標(biāo)，業(yè)界相繼在交換機(jī)結(jié)構(gòu)設(shè)計(jì)、路由算法等方面提出各種不同的解決方案。

2.1 大容量、可擴(kuò)展的交換機(jī)

租戶數(shù)量的增加迫使數(shù)據(jù)中心不斷擴(kuò)容。2012年Amazon單個(gè)數(shù)據(jù)中心平均擁有的服務(wù)器數(shù)已超過6萬臺(tái)，Google單個(gè)數(shù)據(jù)中心的服務(wù)器數(shù)超過了4.5萬臺(tái)，微軟公司正在打造一個(gè)包含30萬臺(tái)服務(wù)器的數(shù)據(jù)中心。

把這些服務(wù)器互聯(lián)起來，需要大容量的核心交換機(jī)作為網(wǎng)絡(luò)樞紐。例如，微軟擬建成的超大型數(shù)據(jù)中心包含30萬臺(tái)服務(wù)器，按照一個(gè)邊緣交換機(jī)可以掛接50臺(tái)服務(wù)器計(jì)算，共需要約6 000個(gè)邊緣交換機(jī)。目前，單臺(tái)服務(wù)器所需要的帶寬為10 Gbit/s，在微軟的數(shù)據(jù)中心中甚至可以達(dá)到40 Gbit/s，據(jù)統(tǒng)計(jì)有20%～40%的流量會(huì)流出邊緣交換機(jī)[1]。換言之，如果按照30%的比例來算，邊緣交換機(jī)的出口流量將達(dá)到600 Gbit/s。基于業(yè)界盡量使用扁平化拓?fù)涞墓沧R(shí)，此處假設(shè)采用邊緣交換機(jī)和核心交換機(jī)全互聯(lián)的二層fat-tree拓?fù)浣Y(jié)構(gòu)，那么邊緣交換機(jī)之間的流量將全部通過核心交換機(jī)中轉(zhuǎn)。由此估算，超大型數(shù)據(jù)中心的核心層所需的吞吐量將高達(dá)3.6 Pbit/s。這個(gè)數(shù)字還是按照目前可以看到的數(shù)據(jù)中心規(guī)模和每臺(tái)服務(wù)器的通信需求計(jì)算的，如果考慮到數(shù)據(jù)業(yè)務(wù)的爆炸式增長(zhǎng)，不久的將來所需的核心交換容量將更大。目前業(yè)界最先進(jìn)的數(shù)據(jù)中心級(jí)交換平臺(tái)為思科的Nexus 7000，其容量達(dá)到15 Tbit/s，然而這一款交換機(jī)的占地面積達(dá)0.40 m2，功耗超過18 kW。如果按照簡(jiǎn)單的加法，用它來構(gòu)造核心層至少需要240臺(tái)交換機(jī)（實(shí)際情況會(huì)更多），將占地200 m2（考慮機(jī)架間距），功耗達(dá)到4.32 MW（不包括冷卻功耗）。以此算來，僅核心節(jié)點(diǎn)就要消耗掉一個(gè)大型電廠的電力輸出。

為了緩解核心層交換的功耗壓力，2011年美國(guó)的Rice大學(xué)和UCSD分別演示了C-Through[2]和Helios平臺(tái)[3]。這兩個(gè)平臺(tái)的共同特點(diǎn)是，采用電交換機(jī)和光交叉連接設(shè)備共同構(gòu)成核心交換層，以分別負(fù)責(zé)傳送不同容量或速率的數(shù)據(jù)流。據(jù)估算，這種光電混合方案可將能耗降低9倍左右。但是光交叉連接設(shè)備的重構(gòu)時(shí)間很慢。例如，Helios平臺(tái)采用光微機(jī)電系統(tǒng)（MEMS）搭建光交換矩陣，建立光路時(shí)間長(zhǎng)達(dá)96 ms。為補(bǔ)償建立光路的開銷,光路建立好之后的持續(xù)時(shí)間最好超過1 s以便能一次傳送大量數(shù)據(jù)。為此，C-Through和Helios設(shè)置了緩存量閾值。只有當(dāng)發(fā)送端緩存數(shù)據(jù)量積累超過閾值，才會(huì)通知控制平面建立光路集中發(fā)送數(shù)據(jù)。由此可見，對(duì)于通過光路傳輸?shù)臄?shù)據(jù)流來說，通信時(shí)延至少包括緩存時(shí)延和光路建立的時(shí)延。因此，如何提供時(shí)延保證的服務(wù)依然是這類光電混合核心交換平臺(tái)的一個(gè)挑戰(zhàn)。

2.2 帶寬保證的路由算法

數(shù)據(jù)中心通過出租計(jì)算、存儲(chǔ)為租戶提供服務(wù)。這些計(jì)算和存儲(chǔ)資源可以分布在不同位置，它們需要通過具有一定容量的通路連接起來協(xié)同工作。在具備大吞吐量交換機(jī)和寬帶鏈路的條件下，路由算法是給租戶提供通路的關(guān)鍵手段。好的算法不但能滿足不同租戶包括分組丟失率、時(shí)延等參數(shù)在內(nèi)的通信要求，而且具有低的計(jì)算復(fù)雜度。

等代價(jià)多路徑（ECMP）算法是一種RFC標(biāo)準(zhǔn)化的分組路由技術(shù)，ECMP同時(shí)使用預(yù)先計(jì)算出的多條代價(jià)相等的路徑，以增加服務(wù)器之間的傳輸帶寬。但ECMP在分配路徑時(shí)并不考慮實(shí)際的流量負(fù)載，而是根據(jù)頭部信息靜態(tài)散列到其中一條路徑上，容易造成局部擁塞。為了克服這個(gè)問題，2009年微軟研究院在其演示的VL2網(wǎng)絡(luò)架構(gòu)中提出利用ECMP技術(shù)實(shí)現(xiàn)負(fù)載均衡(VLB)機(jī)制，以處理動(dòng)態(tài)的流量負(fù)載。VL2以每個(gè)流為單位，將數(shù)據(jù)流隨機(jī)分配一組等代價(jià)路徑。盡管如此，遇到大數(shù)據(jù)流時(shí)，VLB仍然無法避免鏈路擁塞問題[4]。

2010 年UCSD提出一種集中式數(shù)據(jù)流調(diào)度器Hedera[5]。這種調(diào)度器需要實(shí)時(shí)監(jiān)測(cè)網(wǎng)絡(luò)流量從而識(shí)別出大數(shù)據(jù)流，進(jìn)而根據(jù)全局網(wǎng)絡(luò)負(fù)載信息為每個(gè)大數(shù)據(jù)流計(jì)算出優(yōu)化路徑，最后對(duì)每個(gè)大數(shù)據(jù)流進(jìn)行重路由以避免擁塞。顯然，這種全局優(yōu)化算法的擴(kuò)展性受制于活動(dòng)的大數(shù)據(jù)流數(shù)。隨著網(wǎng)絡(luò)規(guī)模的增大，實(shí)時(shí)檢測(cè)并維護(hù)整個(gè)網(wǎng)絡(luò)中的全局負(fù)載以及所有活動(dòng)的大數(shù)據(jù)流信息對(duì)集中控制器將是一個(gè)巨大的挑戰(zhàn)。

同年惠普實(shí)驗(yàn)室提出了一種智能路徑分配(SPAIN)算法[6]。SPAIN預(yù)先為每對(duì)邊緣交換機(jī)計(jì)算出多條不相交的路徑，并映射為不同的VLAN，以充分利用網(wǎng)絡(luò)的多路徑資源。但SPAIN要求每個(gè)交換機(jī)的轉(zhuǎn)發(fā)表為所有目的地地址和VLAN創(chuàng)建多個(gè)條目，比一般商用交換機(jī)復(fù)雜。

2011 年美國(guó)Wisconsin-Madison大學(xué)和IBM演示的CloudNaaS平臺(tái)考慮了區(qū)分服務(wù)質(zhì)量的路由問題。此平臺(tái)將虛擬機(jī)間的通信業(yè)務(wù)分為3個(gè)等級(jí)，并分別采用不同的算法計(jì)算路由。為了減少路由表的條目，CloudNaaS只把數(shù)據(jù)流分發(fā)到有限幾條路徑上，網(wǎng)絡(luò)鏈路利用不高，容易導(dǎo)致局部擁塞[7]。

由此可見，現(xiàn)有的算法仍然存在各種問題，要么計(jì)算復(fù)雜度高，要么會(huì)帶來擁塞無法保證服務(wù)質(zhì)量。如何找到一個(gè)既能保證帶寬又能簡(jiǎn)單高效的路由方法，仍然需要開展更多的研究。

3 網(wǎng)絡(luò)虛擬化

數(shù)據(jù)中心租戶,尤其是企業(yè)租戶，希望內(nèi)部數(shù)據(jù)局限在自己的虛擬網(wǎng)絡(luò)中而不為他人所知。網(wǎng)絡(luò)虛擬化需要做到在不同的虛擬網(wǎng)絡(luò)之間進(jìn)行隔離，以保證租戶的隱私和安全。虛擬網(wǎng)絡(luò)的隔離主要體現(xiàn)在兩方面：第一，通過有效的封裝技術(shù)區(qū)分不同的虛擬網(wǎng)絡(luò)；第二，允許每個(gè)租戶在自己的虛擬網(wǎng)絡(luò)內(nèi)自由定制地址空間。常見的網(wǎng)絡(luò)虛擬化技術(shù)主要包括VLAN、網(wǎng)絡(luò)重疊（overlay）和白名單等。

3.1 VLAN

VLAN是最早用來實(shí)現(xiàn)網(wǎng)絡(luò)虛擬化的技術(shù)。在計(jì)算機(jī)網(wǎng)絡(luò)中，一個(gè)二層網(wǎng)絡(luò)可以被劃分為多個(gè)不同的廣播域，這些廣播域是相互隔離的，每個(gè)廣播域就是一個(gè)VLAN。根據(jù)IEEE 802.1q協(xié)議，VLAN僅有12 bit用于區(qū)分不同子網(wǎng)，因此租戶數(shù)不能超過4 096個(gè)；另外，VLAN隧道需要手工配置，基于最小生成樹的路由協(xié)議限制了網(wǎng)絡(luò)規(guī)模的擴(kuò)展。

2010 年，Bell Labs提出將物理網(wǎng)絡(luò)劃分成核心區(qū)域和邊緣區(qū)域，每個(gè)邊緣區(qū)域用若干轉(zhuǎn)發(fā)元素與核心區(qū)域連通，只用VLAN區(qū)分一個(gè)邊緣區(qū)域內(nèi)的不同租戶，在一定程度上改善了租戶數(shù)量的可擴(kuò)展性。但同一邊緣區(qū)域的租戶數(shù)仍然不能超過4 096個(gè)；每個(gè)發(fā)往不同邊緣區(qū)域的數(shù)據(jù)分組都增加了一個(gè)外部MAC地址，因此需要交換機(jī)支持超大以太網(wǎng)幀[8]。

3.2 網(wǎng)絡(luò)重疊

網(wǎng)絡(luò)重疊是工業(yè)界采用的網(wǎng)絡(luò)虛擬化主流技術(shù)。IETF成立了網(wǎng)絡(luò)虛擬覆蓋（NVO3）技術(shù)工作組，討論各種重疊隧道技術(shù)標(biāo)準(zhǔn)用于支持網(wǎng)絡(luò)虛擬化，比如思科等提出的VXLAN（virtual extensible LAN）、微軟等 提出的NVGRE（network virtualization using generic routing encapsulation）和Nicira等提出的STT（stateless transport tunneling）等。網(wǎng)絡(luò)重疊通過建立端到端的隧道，在三層網(wǎng)絡(luò)上保證了二層虛擬網(wǎng)絡(luò)的全網(wǎng)可達(dá)性，具體技術(shù)見表1。

VXLAN采用一種類似于VLAN的封裝技術(shù)，把基于MAC的二層以太網(wǎng)幀封裝到三層UDP分組中。每一個(gè)VXLAN劃分是通過24 bit的VNI（VXLAN identifier）來標(biāo)識(shí)的。VXLAN通過多播來實(shí)現(xiàn)地址學(xué)習(xí)，這不僅要求物理設(shè)備支持多播，還會(huì)因?yàn)槎嗖浼夹g(shù)的限制導(dǎo)致VXLAN的可擴(kuò)展性受到影響。

NVGRE與VXLAN類似，兩者實(shí)際都使用封裝策略創(chuàng)建大量的VLAN子網(wǎng)，NVGRE使用通用路由封裝創(chuàng)建一個(gè)獨(dú)立的虛擬二層網(wǎng)絡(luò)。NVGRE與VXLAN不同的是地址學(xué)習(xí)是通過控制平面實(shí)現(xiàn)的，但是，目前NVGRE還沒有地址學(xué)習(xí)的具體方案。NVGRE相對(duì)VXLAN在負(fù)載均衡方面有天生的缺陷。對(duì)于傳統(tǒng)的三層網(wǎng)絡(luò)設(shè)備，基本都可以實(shí)現(xiàn)基于四層端口的負(fù)載均衡，但是卻無法基于GRE key實(shí)現(xiàn)負(fù)載均衡。此外，由于建立的是端到端的隧道，因此隧道的數(shù)量隨終端數(shù)量增加以平方速率上升，導(dǎo)致維持隧道的開銷增大。

STT、VXLAN及NVGRE使用了類似的封裝技術(shù)，區(qū)別是把數(shù)據(jù)幀先進(jìn)行分割再封裝，充分利用了網(wǎng)卡的硬件加速功能提高效率。由于STT技術(shù)將原STT分組偽裝成了TCP/IP分組，而在TCP分組頭中又沒有維護(hù)TCP狀態(tài)信息，如果IP分組在傳輸過程中發(fā)生了分組丟失，STT終端不會(huì)進(jìn)行重傳，這使得建立的隧道是不可靠通信信道。

3.3 白名單

白名單技術(shù)利用類似防火墻的機(jī)制來實(shí)現(xiàn)虛擬網(wǎng)絡(luò)間的隔離。白名單通常由用戶自定義，維護(hù)在網(wǎng)絡(luò)邊緣側(cè)（例如Hypervisor或者虛擬機(jī)）。所有收到的數(shù)據(jù)分組要先經(jīng)過白名單檢驗(yàn)，符合白名單中的規(guī)則才允許虛擬機(jī)之間的通信。白名單技術(shù)主要由做安全出身的互聯(lián)網(wǎng)公司在推動(dòng)，如M2Mi。相對(duì)于VLAN和網(wǎng)絡(luò)重疊，白名單可以提供更好的靈活性，并且不依賴于底層的網(wǎng)絡(luò)技術(shù)。其局限性也很明顯，當(dāng)虛擬網(wǎng)絡(luò)規(guī)模很大時(shí)，白名單的規(guī)模會(huì)迅速增長(zhǎng)；每一次虛擬網(wǎng)絡(luò)成員以及規(guī)則的變化都會(huì)導(dǎo)致白名單的更新，維護(hù)開銷可能成為制約其擴(kuò)展性的瓶頸。

4 性能保證

云計(jì)算環(huán)境中給租戶提供性能可保證的資源是很大的挑戰(zhàn)。本質(zhì)在于云計(jì)算是建立在共享資源池上的復(fù)用技術(shù)，租戶之間的資源競(jìng)爭(zhēng)導(dǎo)致了云計(jì)算服務(wù)提供商很難為租戶提供性能可保證的云計(jì)算服務(wù)。

微軟研究院根據(jù)多篇公開測(cè)量報(bào)道對(duì)以Amazon云主機(jī)服務(wù)EC2為主的云計(jì)算環(huán)境下的CPU、磁盤特別是網(wǎng)絡(luò)性能做了分析比較[9]，圖1顯示了云計(jì)算環(huán)境下虛擬機(jī)間的網(wǎng)絡(luò)帶寬測(cè)量百分位統(tǒng)計(jì)（1%-25%-50%-75%-100%）。從圖中可以看出，虛機(jī)間網(wǎng)絡(luò)帶寬變化非常大，差異達(dá)到5倍甚至更高。

表1 網(wǎng)絡(luò)重疊技術(shù)

圖1 過去研究工作對(duì)云計(jì)算環(huán)境下虛擬機(jī)間網(wǎng)絡(luò)帶寬性能的測(cè)量百分位統(tǒng)計(jì)[9]

云計(jì)算環(huán)境網(wǎng)絡(luò)性能無法保證或者無法預(yù)見，將給租戶和云計(jì)算提供商帶來很多負(fù)面影響。

首先，限制了云計(jì)算的應(yīng)用領(lǐng)域。例如，2～3年前，能否在公有云上實(shí)現(xiàn)Top 500的高性能計(jì)算（HPC）虛擬集群是很熱的話題，但大量研究表明，如果不能解決虛擬機(jī)及虛擬網(wǎng)絡(luò)的性能劣化和變化問題，HPC應(yīng)用很難在IaaS公有云上運(yùn)行。

其次，增加了云計(jì)算的使用風(fēng)險(xiǎn)。USENIX HotCloud 2012組織了一個(gè)專題討論云計(jì)算風(fēng)險(xiǎn)，云計(jì)算環(huán)境中由于多租戶相互干擾，同一租戶的虛擬機(jī)間網(wǎng)絡(luò)性能不穩(wěn)定、變化大，造成了應(yīng)用性能無法預(yù)知，用戶體驗(yàn)下降，租戶不敢將他們的應(yīng)用向云計(jì)算環(huán)境遷移。無論是對(duì)于面向事務(wù)處理的電子商務(wù)Web應(yīng)用還是MapReduce型的數(shù)據(jù)密集型應(yīng)用都存在這個(gè)問題。

最后，增加了云計(jì)算的租用成本。因?yàn)樵朴?jì)算按照租戶占用虛擬機(jī)的時(shí)間以及網(wǎng)絡(luò)流量收費(fèi)，而任務(wù)完成的時(shí)間受網(wǎng)絡(luò)性能影響很大，租戶無法估計(jì)任務(wù)結(jié)束時(shí)間，分組丟失造成的重傳會(huì)增加網(wǎng)絡(luò)流量，租戶將潛在支出額外的費(fèi)用。

Amazon為了支持網(wǎng)絡(luò)性能可保證的高端應(yīng)用，采用了萬兆專有網(wǎng)絡(luò)且無超額認(rèn)購(gòu)（over subscription）的高代價(jià)方案。因此，云計(jì)算環(huán)境中更加有效的虛擬數(shù)據(jù)中心（VDC）需求被提出：VDC的定義是一個(gè)用戶可以自主定義IP地址并具有完整業(yè)務(wù)等級(jí)規(guī)約（SLA）的虛擬機(jī)集群，SLA不僅包括計(jì)算和存儲(chǔ)的需求，也包括虛擬機(jī)間通信網(wǎng)絡(luò)即虛擬網(wǎng)絡(luò)的帶寬需求[10]。對(duì)于租戶來說，VDC在使用上應(yīng)該與專有數(shù)據(jù)中心沒有差別，因此要求虛擬網(wǎng)絡(luò)具有良好的隔離性；同時(shí)VDC比專有數(shù)據(jù)中心具有更大的吸引力是由于其具有彈性，即可以根據(jù)租戶的需求動(dòng)態(tài)調(diào)整容量。

性能可保證、可預(yù)見的虛擬網(wǎng)絡(luò)是VDC技術(shù)的關(guān)鍵，可以把這個(gè)問題和電信網(wǎng)絡(luò)中流量工程做一個(gè)類比，可以采用帶寬預(yù)留和呼叫允許控制機(jī)制。但是在云計(jì)算環(huán)境中，性能可預(yù)見、可保證的虛擬網(wǎng)絡(luò)面臨的挑戰(zhàn)更多。首先，可擴(kuò)展性要求更高，帶寬預(yù)留的機(jī)制應(yīng)該能夠擴(kuò)展到超大規(guī)模云計(jì)算環(huán)境的百萬臺(tái)虛擬機(jī)規(guī)模；其次，實(shí)現(xiàn)開銷要求更小，電信網(wǎng)絡(luò)中采用的多協(xié)議標(biāo)簽交換（MPLS）并不適用于云計(jì)算環(huán)境，云計(jì)算中引入了虛擬化，網(wǎng)絡(luò)的邊界從接入交換機(jī)推到了服務(wù)器的虛擬交換機(jī)，虛擬交換機(jī)實(shí)現(xiàn)MPLS開銷太大，一般采用三層到二層的協(xié)議封裝技術(shù)；最后，云計(jì)算具有高動(dòng)態(tài)特點(diǎn)，工作負(fù)載彈性可變，盡管工作負(fù)載遷移可以緩解網(wǎng)絡(luò)擁塞，頻繁調(diào)整工作負(fù)載可能給整個(gè)云計(jì)算環(huán)境的穩(wěn)定帶來災(zāi)難性影響。

為解決云計(jì)算環(huán)境中虛擬網(wǎng)絡(luò)性能可預(yù)見、可保證問題，學(xué)術(shù)界提出了以下幾種思路。

（1）通過預(yù)約帶寬，保證用戶請(qǐng)求的網(wǎng)絡(luò)服務(wù)質(zhì)量

[10]提出了一種能提供端到端帶寬保證的數(shù)據(jù)中心網(wǎng)絡(luò)架構(gòu)。首先，這個(gè)方案需要全網(wǎng)交換設(shè)備支持新協(xié)議的尋址功能，且布線工作量遠(yuǎn)高于目前的樹型拓?fù)浣Y(jié)構(gòu)，實(shí)際部署較難；其次，端到端的帶寬保證帶來了可擴(kuò)展性的問題，當(dāng)虛擬機(jī)數(shù)量和租戶數(shù)量增加時(shí)，其對(duì)應(yīng)的管理復(fù)雜度將大為提升。再次，在傳輸流量前，虛擬機(jī)需要顯式地預(yù)約流量，這種靜態(tài)的流量預(yù)約方式不適合高動(dòng)態(tài)的數(shù)據(jù)中心業(yè)務(wù)。參考文獻(xiàn)[9]在不改變物理拓?fù)涞那疤嵯?，使用虛擬拓?fù)溆成錁?gòu)建了一些具有服務(wù)質(zhì)量保證的虛擬子網(wǎng)，但還是無法滿足高動(dòng)態(tài)網(wǎng)絡(luò)負(fù)載的需求。

（2）動(dòng)態(tài)調(diào)節(jié)虛擬網(wǎng)絡(luò)的帶寬限制或者路由

參考文獻(xiàn)[11]提出了一種改進(jìn)的時(shí)間交織的虛擬集群（TIVC）模型來抽象網(wǎng)絡(luò)帶寬需求隨時(shí)間變化的特性。與固定帶寬模型相比，TIVC模型盡管提高了整個(gè)數(shù)據(jù)中心的效率，但依然不能應(yīng)對(duì)云計(jì)算突發(fā)業(yè)務(wù)的實(shí)時(shí)需求。另外一種思路是大象流被認(rèn)為是數(shù)據(jù)中心網(wǎng)絡(luò)中影響性能的關(guān)鍵流量，因此可以只調(diào)整部分大象流的路由來解決可擴(kuò)展問題[12]。

（3）引入反饋控制機(jī)制

參考文獻(xiàn)[13]通過虛擬交換機(jī)的動(dòng)態(tài)流量限制，確保了虛擬機(jī)在邊界的接入帶寬可控。參考文獻(xiàn)[14]在每對(duì)虛擬機(jī)宿主（Hypervisor）間增加了一條擁塞控制的端到端的邏輯隧道。然而，反饋控制方式的時(shí)滯較大，簡(jiǎn)單的域值控制還可能導(dǎo)致整個(gè)系統(tǒng)的震蕩不穩(wěn)定。另外，單純的邊界控制保證虛擬機(jī)端到端帶寬的能力有限，還應(yīng)當(dāng)結(jié)合核心交換網(wǎng)絡(luò)來避免擁塞出現(xiàn)。

綜上，一個(gè)更加合理的思路是采用預(yù)測(cè)控制的方法，對(duì)于云計(jì)算環(huán)境中的業(yè)務(wù)流量、工作負(fù)載和鏈路帶寬等進(jìn)行觀測(cè)和分析，得出一定的預(yù)測(cè)規(guī)律，從而實(shí)現(xiàn)穩(wěn)定的實(shí)時(shí)控制，為租戶提供性能可預(yù)見的虛擬網(wǎng)絡(luò)。與性能可保證相比，性能可預(yù)見在滿足租戶SLA的同時(shí)，進(jìn)一步提高了網(wǎng)絡(luò)資源利用率。

事實(shí)上，已經(jīng)有一些針對(duì)數(shù)據(jù)中心資源預(yù)測(cè)的相關(guān)研究，這些研究針對(duì)數(shù)據(jù)中心虛擬化的CPU資源使用情況進(jìn)行了預(yù)測(cè)和控制，使得各虛擬機(jī)實(shí)際所得的CPU資源可以根據(jù)工作負(fù)載的變化而動(dòng)態(tài)分配。另外，也有研究者使用了預(yù)測(cè)模型進(jìn)行云計(jì)算環(huán)境中工作負(fù)載自動(dòng)擴(kuò)展的控制。這些預(yù)測(cè)大都著重計(jì)算和存儲(chǔ)資源的使用和分配問題，而與CPU、內(nèi)存、硬盤等資源不同，網(wǎng)絡(luò)資源并非從屬于某個(gè)虛擬設(shè)備，而是連接虛擬設(shè)備之間的資源，網(wǎng)絡(luò)流量的分析更為復(fù)雜。在數(shù)據(jù)中心網(wǎng)絡(luò)的流量測(cè)量和分析方面已經(jīng)有一些研究工作[15]，但基本都是基于網(wǎng)絡(luò)蹤跡（network trace）的離線分析，預(yù)測(cè)控制需要基于實(shí)時(shí)或準(zhǔn)實(shí)時(shí)的網(wǎng)絡(luò)流量分析。

由上可見，在云計(jì)算環(huán)境中實(shí)現(xiàn)性能可預(yù)見、可保證的虛擬網(wǎng)絡(luò)，提供虛擬數(shù)據(jù)中心業(yè)務(wù)，具有廣泛的應(yīng)用前景。目前對(duì)它的研究尚處于起步階段，在擴(kuò)展性、穩(wěn)定性、實(shí)現(xiàn)及部署的低開銷和實(shí)時(shí)響應(yīng)等方面還有大量的問題有待解決。

參考文獻(xiàn)

1 Benson T,Anand A,Akella A,et al.Understanding data center traffic characteristics.SIGCOMM Computer Communication Review,2010,40(1):92～99

2 Wang G,Andersen D G,Kaminsky M,et al.C-through:part-time optics in data centers.Proceedings of ACM SIGCOMM 2010,New Delhi,India,2010:327～338

3 Farrington N,Porter G,Radhakrishnan S,et al.Helios:a hybrid electrical/optical switch architecture for modular data centers.Proceedings of ACM SIGCOMM 2010,New Delhi,India,2010:339～350

4 Chen K,Hu C,Zhang X,et al.Survey on routing in data centers:insights and future directions.IEEE Network,2011,25(4):6～10

5 Mohammad A F,Radhakrishnan S,Raghavan B,et al.Hedera:dynamic flow scheduling for data center networks.Proceedings of NSDI 2010,San Jose,USA,2010

6 Mudigonda J,Yalagandula P,Al-Fares M,et al.SPAIN:COTS data-center ethernet for multipathing over arbitrary topologies.Proceedings of ACM USENIX NSDI 2010,San Jose,USA,2010

7 Bari M,Boutaba R,Esteves R,et al.Data center network virtualization:a survey.IEEE Communications Surveys and Tutorials,2012(2)

8 Hao F,Lakshman T,Mukherjee S,et al.Secure cloud computing with a virtualized network infrastructure.Proceedings of USENIX HotCloud 2010,Boston,USA,2010

9 Hitesh B,Costaet P,Karagiannis T,et al.Towards predictable datacenter networks.Proceedings of ACM SIGCOMM 2011,Toronto,Canada,2011

10 Guo C X,Lu G,Wang H J,et al.Secondnet:a data center network virtualization architecture with bandwidth guarantees.Proceedings of ACM Co-Next 2010,Philadelphia,USA,2010

11 Xie D,Ding N,Hu Y C.The only constant is change:incorporating time-varying network reservations in data centers.ACM SIGCOMM Computer Communication Review,2012,42(4):199～210

12 Curtis A R,Mogul J C,Tourrilhes J.DevoFlow:scaling flow management for high-performance networks.SIGCOMM-Computer Communication Review,2011,41(4)

13 Rodrigues H,Santoset J R.Gatekeeper:supporting bandwidth guarantees for multi-tenant datacenter networks.Proceedings of USENIX WIOV’11,Portland,2011

14 Alan S,Kandula S,Greenberg A.Sharing the data center network.Proceedings of USENIX NSDI 2011,Boston,USA,2011

15 Benson T,Akella A,Maltz D A.Network traffic characteristics of data centers in the wild.Proceedings of IMC 2010,Melbourne,Australia,2010