現(xiàn)代數(shù)據(jù)中心網(wǎng)絡(luò)資源管理技術(shù)分析與綜述

鄧罡，龔正虎，王宏，陳琳，劉志宏

（國防科學(xué)技術(shù)大學(xué) 計算機(jī)學(xué)院，湖南 長沙 410073）

1 引言

數(shù)據(jù)中心是互聯(lián)網(wǎng)和云計算的基礎(chǔ)支撐平臺，是信息技術(shù)發(fā)展的重要標(biāo)志。數(shù)據(jù)中心雖然由來已久，但圍繞數(shù)據(jù)中心的研究方興未艾，特別是近年來，隨著互聯(lián)網(wǎng)和云計算的不斷發(fā)展，數(shù)據(jù)中心逐漸從后臺走向前臺，得到了產(chǎn)業(yè)界和學(xué)術(shù)界的高度重視。Google、微軟、IBM、SGI、思科、惠普等國際 IT公司紛紛推出并部署了自己的數(shù)據(jù)中心，國內(nèi) IT企業(yè)也加緊搶占數(shù)據(jù)中心市場，如中國電信、中國聯(lián)通、百度、阿里巴巴等都建立了自己的大型數(shù)據(jù)中心，世紀(jì)互聯(lián)推出了“云立方”，浪潮在2011年推出了“Smart Cloud”。學(xué)術(shù)界也對數(shù)據(jù)中心給予了很高關(guān)注，SIGCOMM、INFOCOM 等重要國際會議均開辟了專門的數(shù)據(jù)中心研討專題，匯聚相關(guān)領(lǐng)域的前沿研究成果。

近年來，圍繞數(shù)據(jù)中心的研究成果大量涌現(xiàn)，為了厘清各類研究的脈絡(luò)，部分研究者已對相關(guān)研究進(jìn)行過分析綜述，文獻(xiàn)[1]分析了Internet數(shù)據(jù)中心資源管理面臨的挑戰(zhàn)，并以挑戰(zhàn)為主線對近年來國內(nèi)外在滿足SLA、降低功耗方面所取得的資源管理研究成果進(jìn)行了概括總結(jié)；文獻(xiàn)[2]重點對降低云計算數(shù)據(jù)中心能耗為目標(biāo)的資源調(diào)度方法，以提高系統(tǒng)資源利用率為目標(biāo)的資源調(diào)度方法，以及基于經(jīng)濟(jì)學(xué)模型的云資源管理方法進(jìn)行了分析比較；文獻(xiàn)[3]則主要從虛擬資源管理的角度對云數(shù)據(jù)中心資源調(diào)度模型與算法以及基于能量優(yōu)化和負(fù)載均衡的虛擬機(jī)遷移技術(shù)的研究現(xiàn)狀進(jìn)行了綜述。值得注意的是，以上對數(shù)據(jù)中心資源管理的研究，都主要是針對計算資源進(jìn)行的。其面臨的問題主要是當(dāng)前計算資源利用率低、費效比高的問題，目標(biāo)是在滿足用戶服務(wù)等級協(xié)議（SLA）的前提下，實現(xiàn)能量和計算負(fù)載的優(yōu)化。然而，由于傳輸能力的增長往往滯后于計算能力的增長，與計算資源相比，網(wǎng)絡(luò)資源更為緊缺。最近的研究表明，網(wǎng)絡(luò)性能往往成為數(shù)據(jù)中心的性能瓶頸，網(wǎng)絡(luò)配置錯誤、網(wǎng)絡(luò)擁塞、負(fù)載不均衡等將導(dǎo)致服務(wù)癱瘓、分組丟失、重傳、超時等，嚴(yán)重影響數(shù)據(jù)中心性能，進(jìn)而影響到服務(wù)質(zhì)量、用戶體驗和投資回報。網(wǎng)絡(luò)資源的管理也更為復(fù)雜，其原因在于，網(wǎng)絡(luò)資源往往是分布式的，同一網(wǎng)絡(luò)資源常常被眾多的計算節(jié)點所共享，網(wǎng)絡(luò)資源的管理，不僅牽涉到網(wǎng)絡(luò)本身拓?fù)?、配置、容量等固有屬性，還常常與計算資源、存儲資源及應(yīng)用分布等緊密相關(guān)，因此，研究網(wǎng)絡(luò)資源的管理，將面臨更大的困難和挑戰(zhàn)，也具有更加的緊迫性。

然而，隨著數(shù)據(jù)中心網(wǎng)絡(luò)的飛速發(fā)展，其組成、結(jié)構(gòu)、功能、規(guī)模及應(yīng)用模式等各方面正發(fā)生深刻的變革，傳統(tǒng)的資源靜態(tài)分配、工作負(fù)載靜態(tài)管理、應(yīng)用與基礎(chǔ)設(shè)施緊密耦合的網(wǎng)絡(luò)管理方式已經(jīng)不能適應(yīng)現(xiàn)代數(shù)據(jù)中心網(wǎng)絡(luò)的新要求，亟待研究新的技術(shù)和方法加以解決。深入研究分析現(xiàn)代數(shù)據(jù)中心網(wǎng)絡(luò)資源管理的技術(shù)和方法，對于揭示數(shù)據(jù)中心網(wǎng)絡(luò)的基本工作原理，提高數(shù)據(jù)中心網(wǎng)絡(luò)運行效率，節(jié)省成本和開銷，具有十分重要的理論和現(xiàn)實意義。地址自動配置技術(shù)、傳輸控制技術(shù)、流量管理技術(shù)以及虛擬化管理技術(shù)等是現(xiàn)代數(shù)據(jù)中心網(wǎng)絡(luò)資源管理的重要內(nèi)容，也是近年來學(xué)術(shù)界研究的重要方向，本文將結(jié)合當(dāng)前的研究現(xiàn)狀，對以上幾個方面的最新研究成果進(jìn)行分析綜述。據(jù)筆者所知，本文尚屬首次對數(shù)據(jù)中心網(wǎng)絡(luò)資源管理技術(shù)進(jìn)行綜述研究，希望本文的工作能對數(shù)據(jù)中心網(wǎng)絡(luò)資源管理的研究和系統(tǒng)設(shè)計提供拋磚引玉的借鑒作用。

2 現(xiàn)代數(shù)據(jù)中心網(wǎng)絡(luò)地址自動配置技術(shù)

網(wǎng)絡(luò)地址配置是數(shù)據(jù)中心對外提供服務(wù)的基礎(chǔ)。在數(shù)據(jù)中心網(wǎng)絡(luò)對外提供服務(wù)之前，需要首先對其節(jié)點配置正確的地址。此外，當(dāng)一個應(yīng)用從企業(yè)數(shù)據(jù)中心向云端遷移時，為了保持其原有的網(wǎng)絡(luò)布局不變，需要為其配置相同的網(wǎng)絡(luò)拓?fù)浜偷刂?。傳統(tǒng)的地址自動配置技術(shù)主要有DHCP[4]、Zeroconf[5]等。DHCP 是應(yīng)用最為廣泛的主機(jī)地址配置協(xié)議，在DHCP中，DHCP服務(wù)器保存可用的IP地址，當(dāng)主機(jī)加入子網(wǎng)時，通過廣播搜尋DHCP服務(wù)器并獲取一個未使用的IP地址作為本機(jī)地址。為了能夠接收廣播信息，主機(jī)和DHCP服務(wù)器需在同一子網(wǎng)內(nèi)。在Zeroconf協(xié)議中，需要進(jìn)行地址配置的主機(jī)隨機(jī)產(chǎn)生一個地址，并將該地址廣播到網(wǎng)絡(luò)中，如果沒有回復(fù)表明該地址被占用，則保留該地址作為本機(jī)地址，否則重復(fù)以上過程直到找到未被占用的地址，Zeroconf仍只能對同一子網(wǎng)內(nèi)的主機(jī)進(jìn)行地址配置。與傳統(tǒng)數(shù)據(jù)中心網(wǎng)絡(luò)不同的是，為了充分利用網(wǎng)絡(luò)的結(jié)構(gòu)特性以提供高效的路由，現(xiàn)代許多數(shù)據(jù)中心網(wǎng)絡(luò)地址和網(wǎng)絡(luò)位置常常是相關(guān)的，如Fat-tree[6]、Portland[7]、DCell[8]、BCube[9]等均將位置信息編碼到邏輯地址中。此外，現(xiàn)代數(shù)據(jù)中心網(wǎng)絡(luò)可達(dá)百萬節(jié)點的規(guī)模，傳統(tǒng)的地址自動配置協(xié)議如DHCP、Zeroconf等只能對同一子網(wǎng)內(nèi)的主機(jī)進(jìn)行地址配置，且需要通過廣播進(jìn)行信息交互，不僅不能適應(yīng)于大規(guī)模的網(wǎng)絡(luò)，而且隨著網(wǎng)絡(luò)規(guī)模的增大，將導(dǎo)致低效。另外，傳統(tǒng)的地址通常指的是 IP，而在現(xiàn)代數(shù)據(jù)中心網(wǎng)絡(luò)中，地址可能僅僅意味著一個邏輯標(biāo)識，既可以是傳統(tǒng)的IP地址，也可能是非IP的其他標(biāo)識，如Dcell、Bcube中的ID等。因此，傳統(tǒng)的地址自動配置技術(shù)將不適用于現(xiàn)代數(shù)據(jù)中心網(wǎng)絡(luò)。圍繞數(shù)據(jù)中心網(wǎng)絡(luò)地址自動配置，當(dāng)前的研究主要可分為2類：一類是拓?fù)湎嚓P(guān)的地址自動配置，主要是基于圖的基本理論，將地址自動配置問題轉(zhuǎn)化為圖同構(gòu)問題加以解決，另一類則是拓?fù)錈o關(guān)的配置技術(shù)，典型代表是DCZeroconf，主要是借鑒Zeroconf的思想，實現(xiàn)數(shù)據(jù)中心網(wǎng)絡(luò)地址的自動配置。前者主要解決邏輯地址與位置相關(guān)的問題，而后者主要是解決大規(guī)模的數(shù)據(jù)中心網(wǎng)絡(luò)中地址配置的動態(tài)適應(yīng)性問題。

2.1 拓?fù)湎嚓P(guān)地址自動配置

如前所述，最近提出的許多數(shù)據(jù)中心網(wǎng)絡(luò)結(jié)構(gòu)均是拓?fù)湎嚓P(guān)的，在網(wǎng)絡(luò)提供服務(wù)前，需要根據(jù)設(shè)計圖配置網(wǎng)絡(luò)地址，或者當(dāng)企業(yè)應(yīng)用向云中遷移時，為了保持原有結(jié)構(gòu)，需要按原有拓?fù)溥M(jìn)行地址配置。一般地，拓?fù)湎嚓P(guān)的網(wǎng)絡(luò)地址自動配置問題可表述為：給定相應(yīng)的設(shè)計圖（blueprint）和物理網(wǎng)絡(luò)圖（physical network graph），網(wǎng)絡(luò)地址自動配置尋找設(shè)計圖和物理網(wǎng)絡(luò)圖的一種同構(gòu)映射，從而為每個物理節(jié)點分配相應(yīng)的邏輯ID，其中，設(shè)計圖代表了網(wǎng)絡(luò)的邏輯拓?fù)洌總€節(jié)點被賦予一個邏輯ID，如IP，而物理網(wǎng)絡(luò)圖則包含了網(wǎng)絡(luò)的物理連接關(guān)系及設(shè)備ID，如MAC地址。當(dāng)前，拓?fù)湎嚓P(guān)的地址自動配置算法主要有DAC和ETAC。文獻(xiàn)[10]提出了一個通用數(shù)據(jù)中心網(wǎng)絡(luò)地址自動配置算法DAC，DAC根據(jù)設(shè)計圖及物理網(wǎng)絡(luò)拓?fù)鋵崿F(xiàn)邏輯ID到設(shè)備ID的映射，如圖1(a)所示。DAC問題本質(zhì)上是圖同構(gòu)問題，但是，針對大規(guī)模的數(shù)據(jù)中心網(wǎng)絡(luò)，圖同構(gòu)算法復(fù)雜度極高，為此 DAC結(jié)合數(shù)據(jù)中心網(wǎng)絡(luò)結(jié)構(gòu)特性，將問題轉(zhuǎn)化為子圖同構(gòu)問題加以解決。在此過程中，DAC主要使用了3個啟發(fā)式策略，分別是通過最短路徑長度分布選擇候選者，通過軌道(orbit)過濾候選者及有選擇的撕裂（splitting）。大規(guī)模的仿真結(jié)果表明，DAC對地址自動配置問題有較高的效率，對幾萬節(jié)點的BCube網(wǎng)絡(luò)、幾十萬節(jié)點的 Fat-tree網(wǎng)絡(luò)及上百萬節(jié)點的DCell網(wǎng)絡(luò)能在10 s內(nèi)完成配置。DAC的主要缺點是在網(wǎng)絡(luò)發(fā)生錯誤時，算法將無法完成配置，需要人工檢測并修復(fù)，且其錯誤檢測算法需要較長的時間，這極大地降低了網(wǎng)絡(luò)發(fā)生錯誤時DAC的效率。針對這一問題，Ma等人對DAC進(jìn)行了補充和完善，提出了一種容錯的地址自動配置算法 ETAC[11]。ETAC包含了一個錯誤檢測模塊，當(dāng)無錯誤時，則對全網(wǎng)進(jìn)行配置，當(dāng)發(fā)現(xiàn)網(wǎng)絡(luò)發(fā)生錯誤時，首先在邏輯圖和物理網(wǎng)絡(luò)中邏輯地移除錯誤節(jié)點，然后再對剩余的子圖進(jìn)行同構(gòu)映射，如圖1(b)所示，從而使得網(wǎng)絡(luò)在發(fā)生錯誤時，仍能部分地對網(wǎng)絡(luò)進(jìn)行配置，提高了地址自動配置的適應(yīng)性。仿真結(jié)果表明，對10000節(jié)點的網(wǎng)絡(luò)規(guī)模，ETAC能在300 s內(nèi)完成邏輯ID到物理ID的映射。DAC與ETAC的主要缺點是需要首先輸入設(shè)計圖，對百萬節(jié)點的網(wǎng)絡(luò)，這是不小的規(guī)模。此外，DAC與ETAC均是在設(shè)計圖與物理網(wǎng)絡(luò)拓?fù)渫瑯?gòu)（可能存在少量故障）的前提下，對網(wǎng)絡(luò)地址實施同構(gòu)映射，但某些情況下，可能需要根據(jù)設(shè)計圖在一個龐大的網(wǎng)絡(luò)中首先找出與之同構(gòu)的子網(wǎng)（如企業(yè)應(yīng)用向云遷移），且這一子網(wǎng)需要滿足某種限制，如占用的帶寬最少或相對集中分布等，然后再對該子網(wǎng)進(jìn)行地址配置。這一過程本身是非常關(guān)鍵和復(fù)雜的，但當(dāng)前尚未見相關(guān)研究。最后，對ETAC而言，當(dāng)故障涉及核心節(jié)點時，邏輯地移除相關(guān)節(jié)點將可能使得網(wǎng)絡(luò)被撕裂為不同的碎片，從而無法正常提供服務(wù)，這將嚴(yán)重影響ETAC配置的效果。理想的狀態(tài)是，在節(jié)點涉及故障，而非節(jié)點本身發(fā)生故障時，仍能正常配置并提供服務(wù)。

2.2 拓?fù)錈o關(guān)地址自動配置

DAC和 ETAC適用于拓?fù)渑c地址嚴(yán)格相關(guān)的網(wǎng)絡(luò)，在進(jìn)行地址配置時首先需要輸入設(shè)計圖，需要大量的手工輸入，當(dāng)有節(jié)點動態(tài)加入和退出時，需要對全網(wǎng)進(jìn)行重新配置，代價開銷大，對動態(tài)的網(wǎng)絡(luò)環(huán)境如云計算等適應(yīng)性差。為此，IBM的研究人員針對拓?fù)錈o關(guān)的網(wǎng)絡(luò)提出了一種無需設(shè)計圖的地址自動配置方法 DCZeroconf[12]。DCZeroconf的設(shè)計目標(biāo)主要是3個方面：①能夠?qū)θ我饩W(wǎng)絡(luò)拓?fù)涞奶摂M機(jī)（VM,virtual machine）或主機(jī)進(jìn)行IP地址配置；②當(dāng)網(wǎng)絡(luò)拓?fù)浒l(fā)生變化時，算法能動態(tài)適應(yīng)這種變化；③能夠適應(yīng)不同的網(wǎng)絡(luò)規(guī)模。DCZeroconf采用了一種層次式的配置思想，主要包括3步，如圖1（c）所示。首先，網(wǎng)絡(luò)管理員決定可用的 IP地址范圍并將其分配給地址配置集中控制器（CR），這也是DCZeroconf唯一需要人工干預(yù)的地方，隨后，CR將可用IP地址分成不同的段，并告知每一個機(jī)架地址控制器（RR）該機(jī)架可用的地址池，最后，當(dāng)機(jī)架內(nèi)有主機(jī)、虛擬機(jī)或交換機(jī)請求地址配置時，RR即可從地址池中任選一個未使用的地址對其進(jìn)行配置。為了完成CR與RR的通信，需要在CR與RR之間構(gòu)建專門的配置網(wǎng)絡(luò)，雖然配置網(wǎng)絡(luò)規(guī)模相對較小且對帶寬等要求不高，甚至可以用無線的方式構(gòu)建，但這也將增加DCZeroconf的部署難度和一定的額外開銷。DCZeroconf的主要優(yōu)點是實現(xiàn)了完全的地址配置自動化，包括無需輸入設(shè)計圖，且能適應(yīng)網(wǎng)絡(luò)拓?fù)涞膭討B(tài)變化，虛擬機(jī)的動態(tài)加入與退出等，其缺點主要是所配置的網(wǎng)絡(luò)地址與位置無關(guān)，且需要增加專門的地址配置網(wǎng)絡(luò)。

圖1 典型數(shù)據(jù)中心網(wǎng)絡(luò)地址自動配置算法

表1對幾種地址配置方法進(jìn)行了對比，由表1可以看出，傳統(tǒng)的DHCP、Zeroconf等配置方法無論是在可配置設(shè)備的類型、配置規(guī)模和適用的范圍上，均不適用于大規(guī)?，F(xiàn)代數(shù)據(jù)中心。而 DAC、ETAC與 DCZeroconf的主要區(qū)別則是在地址與位置是否嚴(yán)格相關(guān)上。對網(wǎng)絡(luò)節(jié)點動態(tài)加入或退出以及網(wǎng)絡(luò)故障引起的拓?fù)鋭討B(tài)變化，除DAC和ETAC外均具有高適應(yīng)性。就配置效率而言，DHCP、Zeroconf與 DCZeroconf均不受故障影響，且只對同一子網(wǎng)（DCZeroconf為同一機(jī)架）進(jìn)行配置，效率高，但Zeroconf需要通過廣播信號在所有設(shè)備之間進(jìn)行協(xié)商，因而效率較DHCP低。DAC在無故障時具有極高的配置效率，但在發(fā)生故障時需人工干預(yù)，配置效率低，ETAC部分克服了DAC的局限，但受問題復(fù)雜度的影響，在網(wǎng)絡(luò)規(guī)模較大時，配置效率降低。

2.3 小結(jié)

當(dāng)前的數(shù)據(jù)中心網(wǎng)絡(luò)的地址自動配置技術(shù)主要包括拓?fù)湎嚓P(guān)和拓?fù)錈o關(guān)2類，前者主要根據(jù)邏輯拓?fù)浜臀锢砭W(wǎng)絡(luò)圖完成邏輯 ID到設(shè)備 ID的映射，后者主要針對地址與拓?fù)錈o關(guān)的網(wǎng)絡(luò)實現(xiàn)地址的自動配置。就前者而言，當(dāng)前的算法仍存在容錯性、動態(tài)適應(yīng)性、配置效率等問題，且當(dāng)節(jié)點涉及故障時，DAC需要人工干預(yù)才能完成配置，ETAC則可能因為移除了關(guān)鍵節(jié)點而不符合配置預(yù)期。就后者而言，地址與拓?fù)錈o關(guān)可能導(dǎo)致不能滿足應(yīng)用拓?fù)湎嚓P(guān)的特殊要求，也不能有針對性地進(jìn)行性能和路由等優(yōu)化。此外，并非所有網(wǎng)絡(luò)地址均拓?fù)鋰?yán)格相關(guān)或無關(guān)的，某些網(wǎng)絡(luò)的地址與拓?fù)淇赡軆H是部分相關(guān)的，如VL2[13]，某些網(wǎng)絡(luò)出于性能或管理的原因，僅僅需要將某一主機(jī)放置在某一機(jī)架內(nèi)，對這類地址與拓?fù)洳糠窒嚓P(guān)網(wǎng)絡(luò)的地址配置問題，當(dāng)前未見專門的研究。

表1 地址自動配置算法對比

3 現(xiàn)代數(shù)據(jù)中心網(wǎng)絡(luò)傳輸控制技術(shù)

TCP協(xié)議自誕生以來，取得了巨大的成功。然而，最近的研究表明，傳統(tǒng)的TCP協(xié)議應(yīng)用于數(shù)據(jù)中心網(wǎng)絡(luò)將導(dǎo)致低效，這是因為TCP主要是為了滿足 Internet數(shù)據(jù)傳輸需要而設(shè)計。與數(shù)據(jù)中心網(wǎng)絡(luò)相比，Internet具有分布式、自組織、低帶寬、高延遲和低吞吐率的特點，而數(shù)據(jù)中心網(wǎng)絡(luò)則表現(xiàn)為集中式、高帶寬、低延遲和高吞吐率，網(wǎng)絡(luò)有集中統(tǒng)一的控制。數(shù)據(jù)中心運行著各種關(guān)鍵核心業(yè)務(wù)，如搜索引擎、Web服務(wù)、在線購物、網(wǎng)絡(luò)游戲等，對網(wǎng)絡(luò)性能有極高的要求，網(wǎng)絡(luò)運行效率和性能優(yōu)劣將直接影響到各種服務(wù)的性能進(jìn)而影響到用戶體驗。最近的研究指出，許多數(shù)據(jù)中心應(yīng)用面臨某種軟實時限制（soft-real-time constraint），如搜索引擎的響應(yīng)時間通常應(yīng)小于300 ms，響應(yīng)時間超過這一時限，將導(dǎo)致軟超時，影響用戶體驗進(jìn)而影響到投資回報。傳統(tǒng)基于TCP協(xié)議的傳輸控制機(jī)制應(yīng)用于數(shù)據(jù)中心將極易導(dǎo)致網(wǎng)絡(luò)性能下降、擁塞、超時、網(wǎng)絡(luò)利用率低等問題，為此，需要針對數(shù)據(jù)中心特殊的網(wǎng)絡(luò)環(huán)境，對TCP協(xié)議進(jìn)行改進(jìn)或重新設(shè)計，研究新的傳輸控制機(jī)制。當(dāng)前的研究主要分2類：①軟超時無關(guān)的傳輸控制；②軟超時敏感的傳輸控制。

3.1 軟超時無關(guān)的傳輸控制

標(biāo)準(zhǔn)TCP協(xié)議當(dāng)收到網(wǎng)絡(luò)擁塞通知時，即將發(fā)送速率減半，TCP對擁塞的響應(yīng)與擁塞程度是不成比例的，在高帶寬、低延遲的數(shù)據(jù)中心網(wǎng)絡(luò)環(huán)境，將導(dǎo)致鏈路利用率降低和吞吐量下降。軟超時無關(guān)的傳輸控制技術(shù)主要是通過對傳統(tǒng) TCP協(xié)議的擁塞控制機(jī)制進(jìn)行修改，使之更適應(yīng)于數(shù)據(jù)中心傳輸特性，從而提高數(shù)據(jù)中心網(wǎng)絡(luò)吞吐率。文獻(xiàn)[14]提出了一種數(shù)據(jù)中心網(wǎng)絡(luò)TCP協(xié)議DCTCP。DCTCP主要的設(shè)計目標(biāo)是針對數(shù)據(jù)中心網(wǎng)絡(luò)高帶寬、低延遲的特點，提供比TCP協(xié)議更高的吞吐率、更低的延遲，并能夠適應(yīng)網(wǎng)絡(luò)突發(fā)流。DCTCP利用交換機(jī)的顯式擁塞通知（ECN,explicit congestion notification），每條流根據(jù)擁塞標(biāo)志CE被置位的數(shù)據(jù)分組所占的比例估計網(wǎng)絡(luò)的擁塞程度，并據(jù)此動態(tài)地調(diào)整流的發(fā)送速率，從而既能降低擁塞，又能減少隊列延遲和分組丟失。仿真結(jié)果表明，與TCP相比，DCTCP能獲得更高的吞吐率和更低的延遲。遺憾的是，DCTCP是軟超時無關(guān)的，DCTCP僅根據(jù)感知的擁塞程度，“公平地”調(diào)節(jié)流的發(fā)送速率，而不能使接近超時的流得到優(yōu)先傳輸，研究表明，在高扇入、低延遲的應(yīng)用中，約25%的流將發(fā)生軟超時[15]。DCTCP試圖從傳輸層的角度，設(shè)計一種通用高效的擁塞控制機(jī)制。而文獻(xiàn)[16]則專門針對多對一通信中的擁塞控制開展研究，提出了一種Incast擁塞避免機(jī)制ICTCP。多對一通信中接收端容易發(fā)生擁塞，引起分組丟失、重傳，導(dǎo)致性能下降。ICTCP在接收端根據(jù)剩余可用帶寬的大小以及流的期望吞吐量與實際測量值之間的差異率，每條流獨立地通過調(diào)整接收窗口的大小調(diào)節(jié)發(fā)送速率，達(dá)到避免擁塞的目的。簡單地說，即當(dāng)差異率小于某一閾值且網(wǎng)卡有可用帶寬時，則增大接收窗口，反之則減小接收窗口，其他則保持不變。

3.2 軟超時敏感的傳輸控制

與軟超時無關(guān)的方法不同，軟超時敏感的傳輸控制機(jī)制的主要目標(biāo)是最大限度滿足流的軟超時時限，以提高用戶體驗，同時兼顧網(wǎng)絡(luò)吞吐量等其他性能，典型的方法有D3、D2TCP等。微軟研究院的Wilson等人首先對軟超時問題進(jìn)行了研究，提出了一種超時敏感的數(shù)據(jù)中心網(wǎng)絡(luò)傳輸協(xié)議D3[17]。在D3中，應(yīng)用程序顯式地向傳輸層提供超時的時限和需發(fā)送流量的大小，每一個RTT(round trip time)，發(fā)送端主機(jī)根據(jù)超時時限和傳輸流量大小向路由器請求發(fā)送速率，流的傳輸路徑上的每一個路由器按照先來先服務(wù)的原則貪婪地為流分配速率以使盡可能多的流能在軟時限內(nèi)完成并形成速率分配向量，反饋回發(fā)送端主機(jī)，發(fā)送端主機(jī)根據(jù)速率分配向量選擇最小的速率作為下一個 RTT的發(fā)送速率。D3開創(chuàng)性地提出了軟超時敏感的傳輸控制協(xié)議，但D3的缺陷也是明顯的。①需要應(yīng)用程序顯式地提供軟超時信息，這可能導(dǎo)致惡性競爭或惡意的帶寬占用。②需要修改主機(jī)、路由器和應(yīng)用程序，部署難度大。③與現(xiàn)有TCP協(xié)議不兼容。④D3是不公平的，當(dāng)不能滿足所有流的軟超時時限時，D3保證了某些流按時傳輸完成，而另一些流則軟超時被丟棄，在需要同步的應(yīng)用中，可能因為少數(shù)流被丟棄而長期等待，從而影響總的響應(yīng)時間，導(dǎo)致性能不可預(yù)期。⑤D3按照先來先服務(wù)的策略為每條流分配帶寬，這可能導(dǎo)致某些稍早到達(dá)但離超時尚遠(yuǎn)的流獲得了帶寬而某些稍晚到達(dá)但接近超時的流無法分配帶寬，從而導(dǎo)致優(yōu)先權(quán)的反轉(zhuǎn)。如前所述，DCTCP擁塞敏感但卻軟超時無關(guān)，D3軟超時敏感卻擁塞無關(guān)，D2TCP[15]則綜合了DCTCP和D3的基本思想：發(fā)送端根據(jù)網(wǎng)絡(luò)的擁塞程度和流的軟超時時限動態(tài)地調(diào)整發(fā)送速率，當(dāng)檢測到擁塞發(fā)生時，每條流結(jié)合網(wǎng)絡(luò)擁塞程度和軟超時時限動態(tài)調(diào)節(jié)發(fā)送窗口，網(wǎng)絡(luò)越擁塞，離軟超時越久，則發(fā)送窗口減少越多，從而既能實現(xiàn)擁塞控制，又使得更接近軟超時的流能得到優(yōu)先傳輸。但是，D2TCP仍需應(yīng)用程序顯式地提供軟超時時限。D2TCP與D3一樣不支持搶先調(diào)度，這仍然可能導(dǎo)致某些稍晚到達(dá)但更緊迫的流發(fā)生超時。為此，文獻(xiàn)[18]提出了一種分布式的流搶先調(diào)度策略PDQ。PDQ通過發(fā)送端、接收端和交換機(jī)的協(xié)作，實現(xiàn)了一個分布式超時敏感的搶先調(diào)度算法，算法在流有軟超時時限時，時限越小的流優(yōu)先，如果流沒有軟超時時限，則完成時間小的流優(yōu)先，但PDQ不僅需要上層應(yīng)用顯式提供軟超時時限，而且需要對交換機(jī)進(jìn)行修改以支持搶先調(diào)度，實現(xiàn)難度大。文獻(xiàn)[19]通過理論分析認(rèn)為導(dǎo)致軟超時的原因主要是流完成時間的重尾分布，從概率意義上講，減少重尾效應(yīng)就相當(dāng)于減少了流軟超時的概率，而導(dǎo)致重尾的原因主要有3個：①分組丟失和重傳；②流優(yōu)先權(quán)反轉(zhuǎn)；③負(fù)載不均衡。為此，文獻(xiàn)[19]提出了一種跨層的傳輸控制框架DeTail。圖2展示了DeTail的協(xié)議棧結(jié)構(gòu)和跨層的信息交互。在數(shù)據(jù)鏈路層，DeTail通過端口緩沖區(qū)占用構(gòu)造一個無分組丟失網(wǎng)絡(luò)，無分組丟失網(wǎng)絡(luò)只會由于硬件錯誤或失效而導(dǎo)致數(shù)據(jù)分組丟失，而不會因為突發(fā)擁塞而分組丟失，在現(xiàn)代數(shù)據(jù)中心網(wǎng)絡(luò)中，由于硬件錯誤極少發(fā)生，這使得分組丟失成為小概率事件，分組丟失的減少也降低了重尾的概率；在網(wǎng)絡(luò)層，DeTail通過端口緩沖區(qū)的占用信息執(zhí)行分組級的動態(tài)負(fù)載均衡，減少了網(wǎng)絡(luò)擁塞的可能性；在傳輸層，由于底層網(wǎng)絡(luò)僅在硬件錯誤或失效時發(fā)生分組丟失，因此，無需對亂序敏感地作出反應(yīng)，DeTail通過簡單地移除TCP的分組丟失重傳機(jī)制或降低對亂序的敏感度以達(dá)到抗亂序的目標(biāo)；在應(yīng)用層，DeTail通過允許應(yīng)用定義流的優(yōu)先級實現(xiàn)對延時敏感流的優(yōu)先傳輸。DeTail首次提出了通過跨層的協(xié)作機(jī)制解決數(shù)據(jù)中心網(wǎng)絡(luò)擁塞控制和軟超時保證的問題，但是，DeTail仍需要應(yīng)用顯式定義流的優(yōu)先級，同時需要交換機(jī)及主機(jī)協(xié)議棧的支持。

圖2 DeTail的跨層網(wǎng)絡(luò)棧結(jié)構(gòu)

3.3 小結(jié)

與 Internet相比，數(shù)據(jù)中心網(wǎng)絡(luò)在網(wǎng)絡(luò)結(jié)構(gòu)、通信模式、流量特征等方面均有著不同的特點，傳統(tǒng)的TCP協(xié)議主要針對Internet而設(shè)計，不能充分利用數(shù)據(jù)中心網(wǎng)絡(luò)特性，直接運用于數(shù)據(jù)中心網(wǎng)絡(luò)面臨功能和性能等方面的不足，使得新型的數(shù)據(jù)中心網(wǎng)絡(luò)傳輸控制協(xié)議成為新的研究熱點。當(dāng)前的研究主要集中在擁塞控制機(jī)制和軟超時保證 2個方面，總體而言，單純的擁塞控制機(jī)制雖然能夠提高網(wǎng)絡(luò)吞吐率，但由于對軟超時不敏感，可能導(dǎo)致部分流因未得到及時傳輸而軟超時，最終影響到應(yīng)用的性能。而軟超時敏感的傳輸控制機(jī)制雖能夠根據(jù)超時時限和網(wǎng)絡(luò)擁塞程度進(jìn)行流的優(yōu)先調(diào)度，但目前的研究仍都需要上層應(yīng)用顯式地提供超時信息，這容易導(dǎo)致帶寬資源被惡意搶占，且許多技術(shù)都需要修改網(wǎng)絡(luò)中間設(shè)備，這增加了部署難度。表2對幾種典型傳輸控制機(jī)制進(jìn)行了綜合比較。

表2 數(shù)據(jù)中心網(wǎng)絡(luò)典型傳輸控制機(jī)制對比

4 現(xiàn)代數(shù)據(jù)中心網(wǎng)絡(luò)流量管理技術(shù)

流量管理是數(shù)據(jù)中心網(wǎng)絡(luò)資源管理中最重要也是動態(tài)性最強和最具挑戰(zhàn)性的內(nèi)容。本節(jié)將首先對數(shù)據(jù)中心網(wǎng)絡(luò)流量特征進(jìn)行研究分析，然后分別對2類不同的流量調(diào)度策略進(jìn)行綜述，最后給出各種流量調(diào)度方法的小結(jié)比較。從網(wǎng)絡(luò)流級看，現(xiàn)代數(shù)據(jù)中心網(wǎng)絡(luò)普遍支持節(jié)點之間的多路徑連接，多路徑提供了更高的傳輸能力，但現(xiàn)有TCP協(xié)議的單路徑傳輸特性與網(wǎng)絡(luò)的多路徑支持之間并不相適應(yīng)，如何根據(jù)數(shù)據(jù)中心網(wǎng)絡(luò)結(jié)構(gòu)及流的特性，在不同路徑間分配和平衡流量，以最大化數(shù)據(jù)中心網(wǎng)絡(luò)性能是當(dāng)前的研究熱點之一，可分為2種不同的研究思路。①以網(wǎng)絡(luò)流為中心的調(diào)度策略：通過對流的傳輸路徑的分配調(diào)度或通過虛擬機(jī)的優(yōu)化布局，實現(xiàn)網(wǎng)絡(luò)流量平衡或資源利用率的最大化。②以網(wǎng)絡(luò)結(jié)構(gòu)為中心的調(diào)度策略：從網(wǎng)絡(luò)結(jié)構(gòu)屬性的角度研究網(wǎng)絡(luò)資源高效利用的支持機(jī)制，發(fā)掘現(xiàn)代數(shù)據(jù)中心網(wǎng)絡(luò)的多路徑傳輸能力。

4.1 現(xiàn)代數(shù)據(jù)中心網(wǎng)絡(luò)流量特征

網(wǎng)絡(luò)流量特征是進(jìn)行流量管理的基本依據(jù)。最近的研究表明，數(shù)據(jù)中心網(wǎng)絡(luò)流量具有局部性、動態(tài)性和不平衡性等特點。文獻(xiàn)[20]通過對1500個服務(wù)器 2個月期間的網(wǎng)絡(luò)流量的測量和分析表明，相同機(jī)架內(nèi)的節(jié)點更可能發(fā)生通信，一個服務(wù)器或者與同一機(jī)架內(nèi)所有節(jié)點通信，或者僅與不超過25%的節(jié)點通信；或者不與機(jī)架外地其他節(jié)點通信，或者僅與1%～10%的節(jié)點通信。數(shù)據(jù)中心網(wǎng)絡(luò)流量分布表現(xiàn)出 2種不同的模型：workseeks-bandwidth 模型和 scatter-gather模型。workseeks-bandwidth模型表現(xiàn)為相鄰或相近的節(jié)點之間具有較大的數(shù)據(jù)通信，如相同機(jī)架或相同VLAN的節(jié)點之間具有更多的通信，這主要是因為設(shè)計者通常希望把相同的作業(yè)放在同一區(qū)域以獲得更高的帶寬。scatter-gather模型表現(xiàn)為一個服務(wù)器與多個服務(wù)器之間的通信，這主要是由于數(shù)據(jù)中心典型的應(yīng)用模型如Map-Reduce等本質(zhì)上要求數(shù)據(jù)有分發(fā)和匯聚的過程，需要在一個節(jié)點與多個節(jié)點之間傳遞數(shù)據(jù)。文獻(xiàn)[21]通過對10個不同類型（大學(xué)、企業(yè)和云計算）數(shù)據(jù)中心網(wǎng)絡(luò)流量的測量也發(fā)現(xiàn)，對云計算數(shù)據(jù)中心而言，80%的數(shù)據(jù)流量發(fā)生在機(jī)架之內(nèi)，這表明對大部分應(yīng)用而言，流的分布具有某種局部性。文獻(xiàn)[21]的研究還表明，隨著應(yīng)用的不同，同一時刻不同數(shù)據(jù)中心網(wǎng)絡(luò)中流的數(shù)目存在著較大的差異，范圍從幾條到接近上萬條不等，流的到達(dá)時間也從幾毫秒到上百毫米不等，但是，絕大部分流的到達(dá)時間都不會超過100 ms。在文獻(xiàn)[20]的測量結(jié)果中，就整個簇而言，流的平均到達(dá)速率達(dá)105條/秒，即每毫秒有約100條到達(dá)，文獻(xiàn)[22]的測量結(jié)果也表明，數(shù)據(jù)中心中流的數(shù)目巨大，同時存在的跨機(jī)架的流平均可達(dá)105的數(shù)量級，平均到達(dá)時間也達(dá)5×105條/分鐘。這意味著數(shù)據(jù)中心網(wǎng)絡(luò)流具有極高的突發(fā)性和動態(tài)性，從資源管理的角度看，集中的流調(diào)度算法將很難奏效。最近的研究還表明，數(shù)據(jù)中心網(wǎng)絡(luò)流存在不平衡性，這種不平衡表現(xiàn)在2個方面：大小不均勻和分布不平衡。在流大小上，文獻(xiàn)[21]的測量結(jié)果表明，流的大小和長度表現(xiàn)出大象流和老鼠流的特性，80%的流大小不超過 10 KB，10%的流占據(jù)了絕大部分的數(shù)據(jù)流量。無獨有偶，文獻(xiàn)[8,20]也觀察到了類似的現(xiàn)象，文獻(xiàn)[8]中存在明顯的老鼠流現(xiàn)象，99%的流均小于100 MB，然而超過90%的字節(jié)卻包含于100 MB到1 GB的流中，這就意味著不到1%的流包含了超過90%流量。文獻(xiàn)[20]中持續(xù)超過200 s的流不到0.1%，80%的流持續(xù)時間都比較短，不超過10 s。在流分布上，文獻(xiàn)[20]的分析表明，在采用三層結(jié)構(gòu)（核心層、匯聚層、邊緣層）的數(shù)據(jù)中心網(wǎng)絡(luò)中，各層之間的流量并不平衡，核心層通常具有較高的鏈路利用率，而邊緣層和匯聚層則相對較低。文獻(xiàn)[23]也觀察到類似的結(jié)論，核心層鏈路利用率高于匯聚層和邊緣層，但分組丟失率卻相反，核心層鏈路利用率是匯聚層的4倍，95%的匯聚層鏈路利用率不超過10%。這表明流的分布并不均勻，核心層相對集中且穩(wěn)定，而其他層分布較少但突發(fā)性更高，從而導(dǎo)致分組丟失率更高。網(wǎng)絡(luò)流的這些特性給數(shù)據(jù)中心網(wǎng)絡(luò)管理帶來了嚴(yán)峻的挑戰(zhàn)。

4.2 以網(wǎng)絡(luò)流為中心的調(diào)度策略

實際的測量和理論分析表明，數(shù)據(jù)中心網(wǎng)絡(luò)的流量主要是服務(wù)器之間的流量，除一對一（1→1）通信外，一對多（1→N）、多對一（N→1）、多對多（N→M）等集群通信模式是數(shù)據(jù)中心網(wǎng)絡(luò)的主要通信模式[8,9,20]，集群通信即多節(jié)點之間的通信。大量節(jié)點之間通信容易引發(fā)網(wǎng)絡(luò)擁塞，導(dǎo)致分組丟失、重傳和性能下降。如前2.3節(jié)所述，數(shù)據(jù)中心的一些應(yīng)用還面臨某種軟實時限制（soft-real-time constraint），響應(yīng)時間超過一定限度（如300 ms），將影響到用戶體驗進(jìn)而影響數(shù)據(jù)中心的收益。為此，需要通過網(wǎng)絡(luò)流的優(yōu)化調(diào)度及服務(wù)器的合理布局提高網(wǎng)絡(luò)性能。當(dāng)前，針對網(wǎng)絡(luò)流調(diào)度的研究主要可分為2類：一類是僅考慮主機(jī)出口帶寬的調(diào)度方法；另一種是考慮全網(wǎng)容量限制的調(diào)度策略。

4.2.1 主機(jī)出口帶寬限制的調(diào)度方法

由于流的突發(fā)性和動態(tài)性特征，當(dāng)前，針對主機(jī)出口帶寬的流調(diào)度策略主要是將網(wǎng)絡(luò)流看作隨機(jī)變量，采用隨機(jī)裝箱的思想加以解決。文獻(xiàn)[24]研究了通過虛擬機(jī)的合并提高網(wǎng)絡(luò)資源利用率的問題。其問題可描述為：給定一序列元素列表L=(x1,x2,…,xn)，其中xi是規(guī)格化且互相獨立的隨機(jī)變量，則最少需要多少單位容積的箱子才能裝下所有的元素，使得元素的容積之和大于箱子容積的概率不大于某一給定常數(shù)e∈(0,1)。這里的元素就相當(dāng)于每個虛擬機(jī)需要的帶寬，而箱子則相當(dāng)于主機(jī)的出口帶寬，則網(wǎng)絡(luò)帶寬資源的分配轉(zhuǎn)化為隨機(jī)裝箱問題(SBP,stochastic bin packing)，Wang Meng等人采用啟發(fā)式策略，使得對于任意 ε>0，在滿足帶寬需求的情況下，所需服務(wù)器數(shù)量不大于最優(yōu)值的(1+ε)(+1)倍；文獻(xiàn)[25]對Wang Meng等人的研究工作進(jìn)行了改進(jìn)，使得所需服務(wù)器數(shù)量進(jìn)一步減少到不大于(2+ε)倍。以上解決方案僅考慮單臺服務(wù)器的出口流量，并未考慮外部網(wǎng)絡(luò)的傳輸能力。而實際上，網(wǎng)絡(luò)流的優(yōu)化不僅受到主機(jī)出口帶寬的制約，同時還受到網(wǎng)絡(luò)拓?fù)浼奥窂饺萘康闹萍s。因此，另一類的流調(diào)度策略則結(jié)合了網(wǎng)絡(luò)拓?fù)溥M(jìn)行考慮。又可以進(jìn)一步分為3種策略：①通過調(diào)度流的傳輸路徑實現(xiàn)流量優(yōu)化；②通過虛擬機(jī)遷移，優(yōu)化虛擬機(jī)的布局以改變流量的分布；③結(jié)合虛擬機(jī)遷移和路由共同優(yōu)化流的傳輸。

4.2.2 全網(wǎng)帶寬限制的調(diào)度方法

通過調(diào)度流的傳輸路徑實現(xiàn)流量優(yōu)化。加州大學(xué)的Mohammad Al-Fares等人提出了一種通過控制流的傳輸路徑實現(xiàn)流量優(yōu)化的方法 Hedera[26]。Hedera首先通過網(wǎng)絡(luò)流量的測量并估算出每條流可能的流量需求，然后采用集中控制的算法，為流預(yù)留路徑，并更新轉(zhuǎn)發(fā)表。為了提高算法的效率，Hedera僅對大流進(jìn)行調(diào)度，只有當(dāng)流的持續(xù)時間及帶寬需求超過某一閾值時，才激活調(diào)度算法。Hedera在路徑改變時需要更新轉(zhuǎn)發(fā)表，將一定程度上影響流的傳輸性能。為了支持修改轉(zhuǎn)發(fā)表，Hedera采用OPenFlow[27]交換機(jī)，OPenFlow交換機(jī)雖然已有部分商業(yè)產(chǎn)品出現(xiàn)，但其性能并未得到充分檢驗，當(dāng)前并未成為數(shù)據(jù)中心交換機(jī)的主流。

通過虛擬機(jī)的優(yōu)化布局改變流量的分布。Hedera通過改變轉(zhuǎn)發(fā)表進(jìn)而對流實施調(diào)度，但如前所述，普通商業(yè)交換機(jī)并不支持修改轉(zhuǎn)發(fā)表?，F(xiàn)代數(shù)據(jù)中心廣泛采用虛擬化技術(shù)，可以通過對虛擬機(jī)的優(yōu)化布局從而改變流的分布。為此，IBM的Meng等人將流調(diào)度問題轉(zhuǎn)化為流量感知的虛擬機(jī)的優(yōu)化放置問題（TVMPP）[28]，問題的輸入是虛擬機(jī)之間的流量矩陣及主機(jī)之間的通信代價矩陣，目標(biāo)是尋找一種虛擬機(jī)的放置方案，使得全網(wǎng)總的流量最小。文獻(xiàn)[28]證明了這一問題為NP完全問題，并設(shè)計了一種啟發(fā)式策略加以解決，其復(fù)雜度為O(n4)。該方法的主要缺陷是在分配虛擬機(jī)時僅考慮了網(wǎng)絡(luò)出口帶寬限制，并未考慮網(wǎng)絡(luò)容量的限制，因此，分配方案可能不滿足QoS要求。為使全網(wǎng)總的流量最小，意味著虛擬機(jī)應(yīng)盡量集中放置，這使得配置方案擴(kuò)展性較差，難以適應(yīng)帶寬需求的變化，此外，算法的復(fù)雜度也較高。與此相反，文獻(xiàn)[29]將流量優(yōu)化問題轉(zhuǎn)化為最小割率感知的虛擬機(jī)放置問題 MCRVMP，目標(biāo)是虛擬機(jī)的分配不僅要滿足當(dāng)前的需求，還應(yīng)最大限度適應(yīng)未來需求的變化，即實現(xiàn)網(wǎng)絡(luò)流量平衡。MCRVMP主要針對樹型網(wǎng)絡(luò)，首先根據(jù)虛擬機(jī)之間的流量矩陣及虛擬機(jī)的放置位置找出負(fù)載率最高的關(guān)鍵割，再在所有方配方案中選出關(guān)鍵割負(fù)載率最低的分配方案作為虛擬機(jī)的分配方案。MCRVMP問題仍為NP完全問題。文章提出了 2種啟發(fā)式算法。一種采用分治和遞歸思想的2PCCRS，首先將VM分成不同的簇，再對每一個小簇進(jìn)行虛擬機(jī)分配，從而降低問題的規(guī)模。另一種是采用貪婪算法GH。2種方法所獲得的關(guān)鍵割的負(fù)載率均較小（小于0.5），但是2種算法的復(fù)雜度均很高，仿真結(jié)果表明，對3430個VM的網(wǎng)絡(luò)，在最壞情況下，2PCCRS需要超過3000 s，GH算法需要超過8000 s才能完成分配。

結(jié)合虛擬機(jī)遷移與路徑選擇的調(diào)度策略。以上2種對網(wǎng)絡(luò)流優(yōu)化調(diào)度的方法，或者只考慮虛擬機(jī)的放置位置，或者只考慮流的路徑選擇，而實際上，網(wǎng)絡(luò)的性能跟虛擬機(jī)的位置與路由通常是緊密相關(guān)的，僅考慮某一維度，優(yōu)化效果有限。普林斯頓大學(xué)的 Jiang等人結(jié)合虛擬機(jī)遷移和路由對網(wǎng)絡(luò)性能優(yōu)化進(jìn)行了討論，將路由選擇和虛擬機(jī)放置的聯(lián)合優(yōu)化問題轉(zhuǎn)化為靜態(tài)優(yōu)化問題，并基于馬爾可夫模型構(gòu)造了一個優(yōu)化算法VMPR[30]。但是，該模型引入了過多的參數(shù)，參數(shù)需要人工調(diào)節(jié)，因此需要專門的經(jīng)驗和知識，且為了降低算法的復(fù)雜度，模型每次只允許調(diào)整一個VM的位置，在大規(guī)模的網(wǎng)絡(luò)中，這將對算法的優(yōu)化效率產(chǎn)生重要影響。

4.3 以網(wǎng)絡(luò)結(jié)構(gòu)為中心的調(diào)度策略

現(xiàn)代數(shù)據(jù)中心網(wǎng)絡(luò)的新型拓?fù)浣Y(jié)構(gòu)如Fat-tree、VL2、DCell等都提供節(jié)點之間的多條路徑連接。多路徑提供了更高的網(wǎng)絡(luò)容量，通過在多條不同的路徑之間分配和平衡流量，可以減少網(wǎng)絡(luò)擁塞，提高網(wǎng)絡(luò)資源利用率，但是，現(xiàn)有TCP協(xié)議的單路徑傳輸特性和數(shù)據(jù)中心網(wǎng)絡(luò)結(jié)構(gòu)的多路徑支持之間并不適應(yīng)。以網(wǎng)絡(luò)結(jié)構(gòu)為中心的調(diào)度策略，通過發(fā)掘網(wǎng)絡(luò)結(jié)構(gòu)固有的傳輸能力，特別是對多路徑傳輸?shù)闹С?，并發(fā)地傳送流量，以到達(dá)最大化網(wǎng)絡(luò)傳輸性能的目的。針對如何并發(fā)利用網(wǎng)絡(luò)的多路徑特性，在不同的路徑之間分配和平衡流量，以提高網(wǎng)絡(luò)吞吐率，當(dāng)前的解決方案主要有3種。

1)采用固定的轉(zhuǎn)發(fā)規(guī)則。根據(jù)源地址或目標(biāo)地址將流映射到固定的路徑，如Fat-tree。在Fat-tree網(wǎng)絡(luò)結(jié)構(gòu)中，每個終端主機(jī)有(k/2)2條到達(dá)核心層的路徑，F(xiàn)at-tree根據(jù)源節(jié)點的地址，為不同源地址的流選擇不同的路徑，從而實現(xiàn)在不同路徑間平衡流量。

2)采用隨機(jī)負(fù)載均衡的辦法。在所有可用的等價路徑中為每條流隨機(jī)選擇一條路徑，如ECMP[31]、VLB[8]等。ECMP在多條等價路徑中為每一個數(shù)據(jù)分組隨機(jī)選擇一條路徑，而為了防止亂序，VLB則是為每條流隨機(jī)選擇路徑。

3)使用集中控制策略。根據(jù)網(wǎng)絡(luò)結(jié)構(gòu)屬性和流量矩陣，通過全局的控制器進(jìn)行路徑選擇。但是，這些方案都存在各自缺陷，固定規(guī)則的路徑選擇策略和隨機(jī)負(fù)載的方法雖然能在一定程度上分散網(wǎng)絡(luò)流量，但不能根據(jù)路徑的負(fù)載進(jìn)行動態(tài)調(diào)度，可能導(dǎo)致網(wǎng)絡(luò)局部擁塞[32]；而集中調(diào)度算法由于需要流的全局信息，運行效率將受限。研究表明，在大規(guī)模的數(shù)據(jù)中心網(wǎng)絡(luò)中，網(wǎng)絡(luò)流的數(shù)目巨大，且絕大部分的流均為小流，持續(xù)時間極短，集中調(diào)度的算法將需要頻繁地對流進(jìn)行調(diào)度。一種可行的改進(jìn)是僅對大流進(jìn)行調(diào)度，研究表明，在流的大小服從指數(shù)分布，到達(dá)時間間隔服從泊松分布到情況下，對大的流進(jìn)行調(diào)度可以獲得較高的帶寬利用率和較小的時間開銷[26]，然而實際的測量和分析表明，數(shù)據(jù)中心網(wǎng)絡(luò)流并不服從這樣的分布[8]，這種方法仍需要頻繁地調(diào)度且性能接近于隨機(jī)調(diào)度[32]?；诖?，文獻(xiàn)[32]通過理論分析認(rèn)為數(shù)據(jù)中心網(wǎng)絡(luò)應(yīng)由TCP自然演進(jìn)到多路徑TCP(multipath TCP)[33]。但是，多路徑TCP當(dāng)前并未得到廣泛支持。

4.4 小結(jié)

以上分析表明，數(shù)據(jù)中心網(wǎng)絡(luò)流數(shù)目巨大，且具有極強的突發(fā)性和動態(tài)性，對網(wǎng)絡(luò)流量的管理提出了嚴(yán)峻的挑戰(zhàn)。網(wǎng)絡(luò)流的調(diào)度問題往往是NP完全問題，具有極高的復(fù)雜度。以網(wǎng)絡(luò)流為中心的調(diào)度策略通過感知與監(jiān)測網(wǎng)絡(luò)的負(fù)載情況及流量矩陣，實時地為每條流或主要的流選擇傳輸路徑，或通過虛擬機(jī)的遷移改變流量分布，達(dá)到流量平衡或優(yōu)化的目的。但是，在流的到達(dá)速率達(dá)105條/秒且絕大部分流為短流的情況下，這樣的調(diào)度算法占用大量的資源，其有效性也難以得到保證，而且，以網(wǎng)絡(luò)流為中心的調(diào)度策略往往只能支持流的單路徑傳輸，不能有效利用現(xiàn)代數(shù)據(jù)中心網(wǎng)絡(luò)的多路徑特性。以網(wǎng)絡(luò)結(jié)構(gòu)為中心的調(diào)度算法結(jié)合網(wǎng)絡(luò)本身固有的傳輸特性，按照一定的規(guī)則將流分配到不同的路徑上，這種方法雖然有利于發(fā)揮網(wǎng)絡(luò)的多路徑傳輸能力，但或者由于缺乏路徑負(fù)載信息和流量矩陣信息，可能導(dǎo)致局部擁塞，或者仍需要集中的控制，難以適用于大規(guī)模數(shù)據(jù)中心網(wǎng)絡(luò)。

5 現(xiàn)代數(shù)據(jù)中心網(wǎng)絡(luò)虛擬化管理技術(shù)

5.1 主機(jī)內(nèi)部網(wǎng)絡(luò)虛擬化技術(shù)

服務(wù)器虛擬化技術(shù)使得網(wǎng)絡(luò)進(jìn)入主機(jī)內(nèi)部，多個虛擬機(jī)可以在同一主機(jī)內(nèi)組網(wǎng)共存。虛擬化的這一特點使得主機(jī)內(nèi)部網(wǎng)絡(luò)的管理與控制成為新的問題。在傳統(tǒng)非虛擬化條件下，物理主機(jī)作為終端計算節(jié)點而存在，內(nèi)部本身不存在網(wǎng)絡(luò)功能，物理主機(jī)與網(wǎng)絡(luò)的連接通過鏈路狀態(tài)體現(xiàn)，主機(jī)的位置相對固定，外部網(wǎng)絡(luò)可以對其實施訪問控制、流量監(jiān)測等監(jiān)控功能，主機(jī)的狀態(tài)可以完全被網(wǎng)絡(luò)感知與控制。服務(wù)器虛擬化后，一個物理主機(jī)內(nèi)有多個虛擬機(jī)并存，為了支持不同虛擬機(jī)之間的通信，并對其實施監(jiān)控與管理，需要在主機(jī)內(nèi)引入虛擬網(wǎng)絡(luò)功能，當(dāng)前主要有3種方式。

1)采用虛擬交換（virtual switch）的方式。由宿主機(jī)操作系統(tǒng)或虛擬機(jī)管理系統(tǒng)內(nèi)的軟件虛擬交換機(jī)完成虛擬機(jī)間數(shù)據(jù)交換，如開源項目Open vSwitch[34]、VMWare 的 vNetwork Distributed Switch[35]和思科的 Nexus v1000[36]等，如圖 3(a)所示。虛擬交換采用軟件的方式在主機(jī)操作系統(tǒng)或虛擬機(jī)管理系統(tǒng)（hypervisor）內(nèi)部實現(xiàn)一個虛擬交換機(jī)，這種方式下，虛擬交換機(jī)、虛擬網(wǎng)卡均需要與VM競爭使用主機(jī)CPU資源，當(dāng)端口的線速達(dá)到10 Gbit/s或更高時，將嚴(yán)重影響主機(jī)性能，且很難保證QoS和VM隔離。為此，文獻(xiàn)[37]利用多核可編程網(wǎng)卡的支持，提出了一種基于可編程網(wǎng)卡的虛擬交換技術(shù)，通過將VM的虛擬網(wǎng)卡遷移到可編程網(wǎng)卡上，避免了在高速網(wǎng)絡(luò)中虛擬網(wǎng)卡競爭使用主機(jī)資源，提高了虛擬數(shù)據(jù)中心資源利用率，同時可編程網(wǎng)卡為每個虛擬機(jī)提供單獨的域，提高了VM間的安全性和隔離性。但該方法仍需要借助虛擬交換機(jī)進(jìn)行數(shù)據(jù)交換，且同一主機(jī)內(nèi)的虛擬機(jī)間的數(shù)據(jù)需在I/O總線上傳輸2次，浪費了主機(jī)資源?？傮w而言，采用虛擬交換的方式存在2大問題[38]：①虛擬機(jī)之間的流量監(jiān)控問題，傳統(tǒng)的網(wǎng)管系統(tǒng)無法深入服務(wù)器內(nèi)部進(jìn)行流量監(jiān)控，造成安全隱患；②性能問題，虛擬機(jī)網(wǎng)絡(luò)流量越大，虛擬交換機(jī)就會占用越多的CPU資源進(jìn)行報文轉(zhuǎn)發(fā)。

2)利用外部交換機(jī)進(jìn)行數(shù)據(jù)交換。如EVB[39]，VN-tag[40]等，如圖3(b)所示。為了解決服務(wù)器虛擬化后網(wǎng)絡(luò)邊界模糊，虛擬機(jī)感知與控制困難等問題，IEEE標(biāo)準(zhǔn)化組織制定了 EVB（edge virtual bridging）標(biāo)準(zhǔn)（即IEEE 802.1Qbg），EVB本質(zhì)上是在VM與邊緣交換機(jī)之間定義一組標(biāo)準(zhǔn)接口，使得VM的數(shù)據(jù)流量完全由外部物理交換機(jī)轉(zhuǎn)發(fā)，虛擬機(jī)接入網(wǎng)絡(luò)之前首先需要通過虛擬工作站接口發(fā)現(xiàn)協(xié)議（VDP,virtual station interface discovery protocol）發(fā)送關(guān)聯(lián)請求并與邊緣交換機(jī)建立關(guān)聯(lián)，虛擬機(jī)的遷移、銷毀也分別需要重新關(guān)聯(lián)和去關(guān)聯(lián)。通過這種方式，使得VM可以實時被外部網(wǎng)絡(luò)感知與控制，物理主機(jī)內(nèi)部的網(wǎng)絡(luò)功能重新被移回主機(jī)外部，網(wǎng)絡(luò)邊界變得更加清晰，可以采用傳統(tǒng)的網(wǎng)絡(luò)管理的策略對VM進(jìn)行流量監(jiān)控、QoS監(jiān)控等高級網(wǎng)絡(luò)特性的管理。EVB雖然解決了VM的感知與控制的問題，但在EVB中，VM的所有流量都要經(jīng)外部交換機(jī)進(jìn)行交換，同一主機(jī)內(nèi)VM間的流量需要穿越主機(jī)網(wǎng)卡2次，這不僅占用主機(jī)資源、浪費主機(jī)I/O帶寬，同時也增加了外部網(wǎng)絡(luò)壓力。VN-tag是 Cisco的私有技術(shù)，其實現(xiàn)機(jī)理與EVB相似，通過在以太網(wǎng)幀中增加VN-TAG標(biāo)記，用以標(biāo)識VM連接的通道和映射到交換機(jī)的虛端口號。

圖3 3種主機(jī)內(nèi)網(wǎng)絡(luò)虛擬化技術(shù)對比

3)利用主機(jī)網(wǎng)卡進(jìn)行數(shù)據(jù)交換。利用增強功能的主機(jī)網(wǎng)卡，實現(xiàn)內(nèi)部網(wǎng)絡(luò)的接入與交換，如圖3(c)所示。為了解決虛擬機(jī)與外設(shè)之間的I/O操作引起hypervisor陷入帶來的平臺資源開銷，同時保持I/O設(shè)備在多虛擬機(jī)間的共享特性，PCI-SIG聯(lián)盟提出了I/O虛擬化標(biāo)準(zhǔn)SR-IOV(single root I/O virtualization and sharing)[41]，SR-IOV允許多個虛擬機(jī)共享一個網(wǎng)卡。一個SR-IOV設(shè)備具有一個或多個物理功能單元(PF,physical function)，同時可以創(chuàng)建多個虛擬功能單元(VF,virtual function)，每一個PF是一個標(biāo)準(zhǔn)的PCIe功能部件，每個PF可與多個VF關(guān)聯(lián)，VF就像一個輕量級的PCIe功能部件，具有唯一的請求標(biāo)識（RID,requester identifier）及性能攸關(guān)的關(guān)鍵資源，并共享大部分的設(shè)備資源，提供獨立的中斷、隊列及地址轉(zhuǎn)換機(jī)制，從而允許虛擬機(jī)直接對與之關(guān)聯(lián)的VF進(jìn)行控制，就仿佛是獨立使用專門的網(wǎng)卡，部分網(wǎng)卡也提供板上VF間數(shù)據(jù)交換功能。文獻(xiàn)[42]基于 SR-IOV提出了一種跨平臺的主機(jī)內(nèi)網(wǎng)絡(luò)虛擬化體系結(jié)構(gòu)，該結(jié)構(gòu)主要由 3部分組成：PF driver、VF driver和SR-IOV Manager(IOVM)。PF driver工作在物理主機(jī)操作系統(tǒng)或XEN的Domain0上，負(fù)責(zé)直接訪問PF及配置管理VF，VF driver工作在客戶機(jī)（VM）操作系統(tǒng)上，直接訪問與之對應(yīng)的專門的 VF，而不需經(jīng)過虛擬機(jī)管理系統(tǒng)VMM的干預(yù)，IOVM工作在VMM上，為每一個VF提供虛擬化的配置服務(wù)，使得客戶操作系統(tǒng)可以像普通設(shè)備一樣枚舉和配置 VF。該結(jié)構(gòu)使得VM可以無需VMM干預(yù)直接訪問SR-IOV網(wǎng)卡，從而能在不同的虛擬化平臺上實現(xiàn)，在提高I/O性能的同時具有良好的可擴(kuò)展性。但是，網(wǎng)卡的硬件資源總是有限的，隨著服務(wù)器性能的提高，一臺服務(wù)器內(nèi)可以虛擬出幾百個虛擬機(jī)，如果為每個虛擬機(jī)均分配專門的硬件資源，網(wǎng)卡將不堪重負(fù)。為此，文獻(xiàn)[43]提出了一種折中的方案 Crossbow。Crossbow采用了硬件和軟件相結(jié)合的實現(xiàn)方式，當(dāng)硬件資源充足時，為每一個VM分配專門的硬件虛擬網(wǎng)卡，而當(dāng)硬件資源耗盡時，則采用軟件實現(xiàn)虛擬網(wǎng)卡。以上方案雖然無需引起VMM陷入，但主機(jī)內(nèi)VM間流量仍需經(jīng)網(wǎng)卡進(jìn)行交換，將引起I/O中斷且占用網(wǎng)卡資源，文獻(xiàn)[44]提出了一種在直接訪問網(wǎng)卡(direct access NIC)上進(jìn)行VM接入和流量交換的體系結(jié)構(gòu)sNICh。為了減少對主機(jī)I/O帶寬的浪費，sNICh對主機(jī)內(nèi)VM間的數(shù)據(jù)交換采用了直接內(nèi)存拷貝的方法，降低數(shù)據(jù)傳輸開銷。但直接訪問網(wǎng)卡僅具有基本的交換機(jī)功能，不能實現(xiàn)企業(yè)數(shù)據(jù)中心網(wǎng)絡(luò)交換機(jī)所需的主要特性，也不能支持大量的VM。為此，sNICh結(jié)合了軟硬2種實現(xiàn)方式，采用數(shù)據(jù)平面和控制平面分離的策略，控制平面由軟件實現(xiàn)，數(shù)據(jù)平面采用硬件轉(zhuǎn)發(fā)，從而加快處理速度。同時由于控制功能由軟件實現(xiàn)，易于實現(xiàn)如分組過濾、安全檢查等各種控制策略。

總體而言，基于軟件的虛擬交換方式成本低，但對數(shù)據(jù)分組的處理需要占用大量的 CPU資源，開銷大、性能低。隨著對網(wǎng)絡(luò)性能要求的提高，利用外部硬件支持的虛擬化方式成為必然趨勢，但當(dāng)前的技術(shù)發(fā)展尚不完善。利用外部交換機(jī)的方式能夠?qū)μ摂M機(jī)實施實時的監(jiān)控，并進(jìn)行高級的網(wǎng)絡(luò)管理功能，但是占用了大量的 I/O帶寬資源，同時也增加了外部網(wǎng)絡(luò)壓力；利用主機(jī)網(wǎng)卡進(jìn)行交換的方式對網(wǎng)卡性能要求高，價格昂貴，且網(wǎng)卡對交換機(jī)高級特性的支持有限，削弱了對虛擬機(jī)的管理功能。

5.2 數(shù)據(jù)中心骨干網(wǎng)絡(luò)虛擬化技術(shù)

為了敘述方便，本文把數(shù)據(jù)中心內(nèi)主機(jī)內(nèi)部網(wǎng)絡(luò)以外的網(wǎng)絡(luò)統(tǒng)稱為數(shù)據(jù)中心骨干網(wǎng)，簡稱骨干網(wǎng)。傳統(tǒng)條件下，用戶與資源靜態(tài)耦合，不同用戶之間的資源互相隔離，不能共享使用，資源使用率低?，F(xiàn)代數(shù)據(jù)中心逐漸從企業(yè)獨占向公共云服務(wù)轉(zhuǎn)變[45,46]。云計算一方面要求多個租戶共享使用數(shù)據(jù)中心網(wǎng)絡(luò)資源，運行不同的企業(yè)應(yīng)用，資源以動態(tài)、彈性、按需的方式分配和共享使用，并按實際的資源使用情況付費[47]，同時提供各用戶間可靠的安全隔離及不同的QoS保證[48]。用戶可以定制個性化的計算環(huán)境，如服務(wù)器數(shù)量、軟件環(huán)境、網(wǎng)絡(luò)配置等。資源可以根據(jù)需要動態(tài)申請，也可以動態(tài)回收。如亞馬遜彈性云EC2[49]和安全存儲服務(wù) S3[50]、IBM 藍(lán)云[51]等。另一方面又要求底層數(shù)據(jù)中心網(wǎng)絡(luò)基礎(chǔ)設(shè)施可虛擬化為統(tǒng)一的虛擬資源池，以便能夠根據(jù)用戶需求，靈活地分配資源。按照目標(biāo)的不同，當(dāng)前數(shù)據(jù)中心骨干網(wǎng)虛擬化技術(shù)可分為3類。

5.2.1 以資源隔離為目標(biāo)的虛擬化技術(shù)

傳統(tǒng)的數(shù)據(jù)中心網(wǎng)絡(luò)使用劃分VLAN(802.1q)[52]的方式提供對資源隔離的支持，但是這種方法存在缺陷：①為了支持生成樹協(xié)議，每個VLAN只能是底層網(wǎng)絡(luò)的無環(huán)圖，從而限制了二分帶寬；②將所有的地址空間暴露給交換機(jī)，導(dǎo)致轉(zhuǎn)發(fā)表過大，不能支持大規(guī)模網(wǎng)絡(luò)，可擴(kuò)展性差。為了支持大規(guī)模的網(wǎng)絡(luò)虛擬化，業(yè)界提出了很多改進(jìn)方案，如QinQ(802.1ad)[53]、MinM(802.1ah)[54]等，其基本思想是將網(wǎng)絡(luò)劃分為不同的層次，采用嵌套封裝的方法，由每層的邊緣交換機(jī)進(jìn)行封包和解包，從而極大地減少了上層網(wǎng)絡(luò)的地址空間，可以支持更大規(guī)模的網(wǎng)絡(luò)。但目前QinQ、MinM等并未得到廣泛支持，同時，生成樹協(xié)議的單路徑特性也不能充分利用網(wǎng)絡(luò)冗余的連通性。為了克服生成樹協(xié)議的不足，IEEE 802.1aq工作組提出了最短路徑橋接(SPB,shortest path bridging)[55]協(xié)議，SPB支持異構(gòu)的網(wǎng)絡(luò)結(jié)構(gòu)，能夠并發(fā)地利用多條最短路徑進(jìn)行數(shù)據(jù)傳輸，具有更快的收斂時間和更好的可擴(kuò)展性，但是SPB仍需使用QinQ或MinM方式進(jìn)行虛擬網(wǎng)劃分?；赩LAN的虛擬網(wǎng)的劃分方案均是靜態(tài)的，每個用戶或每個應(yīng)用運行在單獨的虛擬網(wǎng)之中，占用固定的資源，為了保證用戶的峰值性能，虛擬網(wǎng)需要預(yù)留資源，降低了網(wǎng)絡(luò)的效能和靈活性。

為了支持現(xiàn)代數(shù)據(jù)中心網(wǎng)絡(luò)環(huán)境下多租戶動態(tài)共享的需求，同時提供端到端的帶寬保證，文獻(xiàn)[56]提出了一種多用戶條件下具有帶寬保證的數(shù)據(jù)中心網(wǎng)絡(luò)虛擬化體系結(jié)構(gòu) SecondNet，其中每個用戶構(gòu)成一個虛擬數(shù)據(jù)中心(VDC)，VDC中的每一個虛擬機(jī)對之間都有明確的帶寬需求，SecondNet將VDC的分配問題轉(zhuǎn)化為最小代價網(wǎng)絡(luò)流問題，采用集中控制的策略和端口交換的源路由算法，提供虛擬機(jī)之間的帶寬保證及高效的網(wǎng)絡(luò)資源利用率，但SecondNet需要交換機(jī)支持端口交換和高優(yōu)先級流的搶先調(diào)度。通常，用戶對計算和存儲資源的需求可以明確地給出，但是卻難以提出明確的網(wǎng)絡(luò)資源需求，對此，文獻(xiàn)[57]提出了一種虛擬網(wǎng)絡(luò)抽象方法 Oktopus，明確定義了用戶—提供者之間的網(wǎng)絡(luò)資源需求接口，對無阻塞網(wǎng)絡(luò)和阻塞網(wǎng)絡(luò)，Oktopus分別利用一個二元組和四元組代表一個租戶的需求，其中，N代表VM數(shù)，B代表每一個VM的帶寬需求，對阻塞網(wǎng)絡(luò)，VM被劃分為不同的組，S代表每組中的VM數(shù)，O為阻塞因子。Oktopus根據(jù)租戶需求為每個租戶分配符合要求的虛擬網(wǎng)絡(luò)，從而使得網(wǎng)絡(luò)提供者可以像出租計算資源、存儲資源一樣，對出租的網(wǎng)絡(luò)資源按帶寬進(jìn)行收費，雙方能夠在網(wǎng)絡(luò)性能保障、開銷和收益之間作出權(quán)衡。但由于VM流量需求的突發(fā)性和不均衡性，通常難以用統(tǒng)一的標(biāo)準(zhǔn)描述VM的流量需求，此外，Oktopus基于終端主機(jī)的速率限制機(jī)制，需要對VM增加一個增強模塊。文獻(xiàn)[58]從安全的角度，提出了一種居于身份映射的多租戶隔離機(jī)制，形式化定義了隔離的概念，在此基礎(chǔ)上，以系統(tǒng)開銷和資源利用率建立目標(biāo)函數(shù)并給出了解決算法。

為了實施靈活的虛擬化策略，需要對交換機(jī)進(jìn)行精細(xì)的控制，但出于商業(yè)機(jī)密和安全的考慮，普通商業(yè)交換機(jī)開放程度限制，影響了虛擬化策略的應(yīng)用。為此，斯坦福大學(xué)的研究人員提出了一種OpenFlow交換機(jī)[27]，通過定義標(biāo)準(zhǔn)接口，用戶可對OpenFlow交換機(jī)的每條流進(jìn)行精確的控制，包括轉(zhuǎn)發(fā)路徑、QoS限速以及分組過濾等，通過OpenFlow技術(shù)可以很容易地實現(xiàn)虛擬化，并且可以靈活地利用諸如虛擬機(jī)的位置等策略進(jìn)行虛擬網(wǎng)劃分。OpenFlow提出的初衷是為了在校園網(wǎng)上開發(fā)大規(guī)模的測試床供研究人員進(jìn)行網(wǎng)絡(luò)協(xié)議測試，但是由于OpenFlow的靈活性，它也可以應(yīng)用于數(shù)據(jù)中心。但就目前而言，OpenFlow還存在一些限制。①性能限制：OpenFlow的控制策略主要由集中控制器負(fù)責(zé)，在高速網(wǎng)絡(luò)中，將給集中控制器帶來巨大壓力，影響數(shù)據(jù)轉(zhuǎn)發(fā)性能，此外，為了實施精細(xì)的控制，如入侵檢測等，若需要執(zhí)行逐包處理，將嚴(yán)重影響OpenFlow的性能。②安全問題：OpenFlow雖然增加了靈活性，但也帶來了安全隱患，由于采用集中的控制方式且用戶可以控制數(shù)據(jù)轉(zhuǎn)發(fā)策略，一旦集中控制器遭到攻擊或流表被惡意篡改，將可能導(dǎo)致服務(wù)中斷或癱瘓。③當(dāng)前OpenFlow尚未得到主流交換機(jī)廠商的廣泛支持。盡管如此，OpenFlow仍引起了學(xué)術(shù)界和產(chǎn)業(yè)界的高度關(guān)注，當(dāng)前已經(jīng)發(fā)展成為一個頗具影響的技術(shù)流派，OpenFlow不僅可以用于數(shù)據(jù)中心網(wǎng)及局域網(wǎng)虛擬化，還可用于廣域網(wǎng)虛擬化，有關(guān)OpenFlow的研究已經(jīng)超出了本文的范圍，在此不再贅述。

5.2.2 以資源整合為目標(biāo)的虛擬化技術(shù)

資源隔離的目的是為了將同一網(wǎng)絡(luò)邏輯地分成不同的網(wǎng)絡(luò)，以供不同用戶使用。與此相反，資源整合的目標(biāo)是將邏輯上分離的網(wǎng)絡(luò)整合為同一網(wǎng)絡(luò)，以增強應(yīng)用部署的靈活性，如支持虛擬機(jī)的自由遷移等。典型的虛擬化方案有VL2、PortLand等。VL2采用名字和位置分離的思想，應(yīng)用程序使用應(yīng)用相關(guān)地址(AA,aplication-specific address)發(fā)送數(shù)據(jù)，駐留在服務(wù)器上的輕量級VL2代理將目標(biāo)服務(wù)器所在ToR的位置相關(guān)地址(LA,locationspecific address)作為目的地址封裝到分組內(nèi)，目的ToR解包并將數(shù)據(jù)轉(zhuǎn)發(fā)到目標(biāo)服務(wù)器。為了確定目的AA所在ToR對應(yīng)的LA，VL2采用一個集中的目錄系統(tǒng)維持AA到LA的映射，通過目錄系統(tǒng)可以實現(xiàn)訪問控制，如僅允許相同租戶的應(yīng)用之間互相訪問。VL2的主要缺點是需要集中的目錄系統(tǒng)，集中控制器可能成為系統(tǒng)性能瓶頸，VL2可以實現(xiàn)不同租戶間的訪問控制，但是，不能實施基于租戶的性能隔離，租戶間競爭共享網(wǎng)絡(luò)資源，不能提供帶寬保證等QoS支持，也不支持基于租戶權(quán)重分配帶寬資源等公平性策略。PortLand的思想與VL2類似，仍采用名字和位置分離的思想，每一個終端主機(jī)都有唯一的偽MAC地址(PMAC， pseudo MAC)，PMAC是位置相關(guān)的，網(wǎng)絡(luò)上所有的數(shù)據(jù)轉(zhuǎn)發(fā)均基于 PMAC，集中的網(wǎng)絡(luò)控制器負(fù)責(zé)完成IP地址到PMAC的映射，響應(yīng)ARP請求，僅在數(shù)據(jù)分組到達(dá)最后一跳時由邊緣交換機(jī)完成PMAC地址重寫，使用真實MAC地址(AMAC,actual MAC)將數(shù)據(jù)最終發(fā)送到目標(biāo)服務(wù)器。VL2與PortLand均實現(xiàn)了一個完全的二層網(wǎng)絡(luò)抽象，任何應(yīng)用可以被放在任何服務(wù)器上，從而支持服務(wù)器池的快速增長和收縮以及任意位置的虛擬機(jī)遷移。但是，兩者均需要集中控制器進(jìn)行地址映射，存在單點失效，且兩者均不支持基于租戶的QoS策略、公平性策略等。為此，文獻(xiàn)[59]提出了一種數(shù)據(jù)中心網(wǎng)絡(luò)虛擬化體系結(jié)構(gòu)NetLord，NetLord對MAC幀格式和IP報文格式進(jìn)行了重定義，在IP報文的頭部顯式包含了租戶標(biāo)識(Tenant_ID)，并通過一個常駐hypervisor的輕量級代理負(fù)責(zé)封包、解包和路由，虛擬機(jī)發(fā)出的數(shù)據(jù)分組經(jīng)代理計算路徑，確定目的邊緣交換機(jī)地址后，在原報文的頭部添加一層MAC幀頭，將源邊緣交換機(jī)地址和目的邊緣交換機(jī)地址封裝在MAC幀中后在二層網(wǎng)絡(luò)上傳送，當(dāng)?shù)竭_(dá)邊緣交換機(jī)時，由邊緣交換機(jī)去掉幀頭，并根據(jù)封裝在分組中的IP地址確定轉(zhuǎn)發(fā)端口，將數(shù)據(jù)分組傳送到目標(biāo)代理，目標(biāo)代理最后將數(shù)據(jù)轉(zhuǎn)發(fā)到目的虛擬機(jī)。NetLord的虛擬化方法帶來了幾大好處：首先是通過重新封包屏蔽了虛擬機(jī)的 MAC地址，減少了核心網(wǎng)絡(luò)地址空間的規(guī)模，使得使用商業(yè)以太網(wǎng)交換機(jī)即可構(gòu)建大規(guī)模多租戶網(wǎng)絡(luò)；其次是提供了一個完全的二層和三層網(wǎng)絡(luò)抽象，每一個租戶都有一個完全的二層和三層地址空間；第三，由于分組頭顯式地包含租戶標(biāo)識，NetLord可以對每個租戶實施單獨的流量管理策略，如增加QoS策略、公平性策略等。但是NetLord需要修改虛擬機(jī)管理系統(tǒng)，且額外的分組封裝、解分組可能降低數(shù)據(jù)處理性能。

5.2.3 以公平共享為目標(biāo)的虛擬化技術(shù)

隨著云計算和虛擬化技術(shù)的發(fā)展，數(shù)據(jù)中心網(wǎng)絡(luò)在應(yīng)用模式和資源配置方式上發(fā)生了巨大變化。云計算要求數(shù)據(jù)中心網(wǎng)絡(luò)基礎(chǔ)設(shè)施作為一種服務(wù)供用戶按需申請共享使用，并按資源使用情況付費。這就要求網(wǎng)絡(luò)資源應(yīng)該與用戶付費成比例，即資源共享應(yīng)滿足某種公平性。與計算資源和存儲資源的使用可以明確的計量不同，網(wǎng)絡(luò)資源通常是分布式的，如何保證網(wǎng)絡(luò)資源的公平共享成為虛擬化的研究課題之一。文獻(xiàn)[22]提出了一種基于實體（entity）權(quán)重公平地共享網(wǎng)絡(luò)資源的方法Seawall，每個實體獲得的資源與其權(quán)重相關(guān)，這里的實體可以是進(jìn)程或虛擬機(jī)。通過合理地分配權(quán)重，可以實現(xiàn)對網(wǎng)絡(luò)資源高效利用的同時實現(xiàn)某種公平性，但是實體的資源需求通常是動態(tài)的，不合理的權(quán)重將導(dǎo)致資源閑置。文獻(xiàn)[60]的研究進(jìn)一步指出，Seawall的分配策略本質(zhì)上是一種基于源的分配策略，這種策略對源節(jié)點的資源分配公平，但卻可能導(dǎo)致對目的節(jié)點資源分配的不公平，基于目的節(jié)點的分配策略亦如此。為此，文獻(xiàn)[60]總結(jié)了公平地共享帶寬資源所需的5個基本原則，如對稱性（symmetry）、獨立性（independence）等，并提出了一種基于源節(jié)點和目標(biāo)節(jié)點雙邊權(quán)重的資源共享策略PES，通過調(diào)節(jié)參數(shù)，PES能夠?qū)崿F(xiàn)帶寬保證和公平性之間的某種平衡，但需要修改交換機(jī)或虛擬機(jī)管理程序（hypervisor）。研究資源共享的公平性問題，不僅可以促進(jìn)資源更加合理的分配，還可以通過定義網(wǎng)絡(luò)資源使用的標(biāo)準(zhǔn)接口，使得網(wǎng)絡(luò)資源與計算資源和存儲資源一樣，可以按照使用量進(jìn)行收費，使得使用者和提供者之間能夠更加清晰地在投入和回報之間做出權(quán)衡。但當(dāng)前對該問題的研究尚少，在實際系統(tǒng)中也未見相關(guān)的技術(shù)報告，總體而言尚處于起步階段。幾種典型數(shù)據(jù)中心骨干網(wǎng)虛擬化技術(shù)的對比如表3所示。

表3 數(shù)據(jù)中心骨干網(wǎng)虛擬化技術(shù)對比

6 結(jié)束語

數(shù)據(jù)中心網(wǎng)絡(luò)的深刻變化，給網(wǎng)絡(luò)資源管理帶來諸多挑戰(zhàn)，傳統(tǒng)的資源靜態(tài)分配、工作負(fù)載靜態(tài)管理，應(yīng)用與基礎(chǔ)設(shè)施緊密耦合的網(wǎng)絡(luò)管理方式已經(jīng)不能適應(yīng)現(xiàn)代數(shù)據(jù)中心網(wǎng)絡(luò)的新要求，亟待研究新的技術(shù)和方法加以解決。本文從網(wǎng)絡(luò)資源管理的幾個重要方面，包括地址自動配置技術(shù)、傳輸控制技術(shù)、流量管理技術(shù)以及虛擬化管理技術(shù)等，對現(xiàn)代數(shù)據(jù)中心網(wǎng)絡(luò)資源管理技術(shù)的最新研究成果進(jìn)行了分析綜述，以期能為數(shù)據(jù)中心網(wǎng)絡(luò)資源管理的研究和系統(tǒng)設(shè)計提供借鑒。盡管努力試圖發(fā)現(xiàn)各種研究、各類技術(shù)之間的關(guān)聯(lián)，努力分析其優(yōu)長與特點，但由于有關(guān)現(xiàn)代數(shù)據(jù)中心網(wǎng)絡(luò)資源管理的研究正方興未艾，各種觀點、各種技術(shù)正處于百家爭鳴的態(tài)勢，以當(dāng)前的認(rèn)知，有些相關(guān)的研究尚難以用統(tǒng)一的標(biāo)準(zhǔn)加以分析比較，筆者將密切跟蹤有關(guān)的研究進(jìn)展，以期能有更加全面深入的了解。就筆者的研究和分析，未來數(shù)據(jù)中心網(wǎng)絡(luò)資源管理將呈現(xiàn)以下趨勢。

1)配置自動化。隨著數(shù)據(jù)中心網(wǎng)絡(luò)規(guī)模的不斷擴(kuò)大，傳統(tǒng)的人工配置方式不僅效率低，而且容易引發(fā)錯誤，據(jù)統(tǒng)計，50%～80%的網(wǎng)絡(luò)宕機(jī)都是由于人工配置錯誤引發(fā)[61,62]。特別是在云計算環(huán)境下，應(yīng)用需要根據(jù)資源需求動態(tài)申請和釋放資源，如創(chuàng)建和銷毀虛擬機(jī)、配置虛擬網(wǎng)等，人工的配置方式將難以勝任，網(wǎng)絡(luò)管理系統(tǒng)將需要根據(jù)預(yù)先設(shè)定的配置策略和配置描述文件，自動完成配置操作，如根據(jù)邏輯圖完成邏輯地址到物理地址的映射。

2)管理智能化。數(shù)據(jù)中心是數(shù)據(jù)計算和存儲的中心，運行著各種關(guān)鍵核心業(yè)務(wù)，如 Web服務(wù)、Map-Reduce集群計算、在線購物等，其通信模式表現(xiàn)為集群通信，即大規(guī)模節(jié)點之間的通信，對網(wǎng)絡(luò)性能要求高，動態(tài)性強，傳統(tǒng)的通過VLAN的資源劃分方式導(dǎo)致應(yīng)用與資源緊密耦合，大量資源被閑置，限制了網(wǎng)絡(luò)性能的發(fā)揮，資源利用率低。為了充分發(fā)揮網(wǎng)絡(luò)性能，提高資源利用率，網(wǎng)絡(luò)管理系統(tǒng)應(yīng)具有根據(jù)網(wǎng)絡(luò)負(fù)載和資源使用情況，進(jìn)行動態(tài)資源分配調(diào)度、流的動態(tài)路徑規(guī)劃等能力。

3)接口標(biāo)準(zhǔn)化。企業(yè)應(yīng)用將逐漸向云服務(wù)轉(zhuǎn)變，數(shù)據(jù)中心網(wǎng)絡(luò)資源管理的功能和角色正在發(fā)生著深刻的變化。網(wǎng)絡(luò)資源管理的作用在于以服務(wù)的方式為數(shù)據(jù)中心網(wǎng)絡(luò)應(yīng)用、數(shù)據(jù)中心網(wǎng)絡(luò)路由、數(shù)據(jù)中心監(jiān)控等提供支撐。為使上層應(yīng)用能在運行時動態(tài)申請管理服務(wù)，同時能在不同的云服務(wù)環(huán)境中自由遷移，網(wǎng)絡(luò)管理系統(tǒng)需要提供標(biāo)準(zhǔn)的服務(wù)接口，如配置接口、資源申請接口、流量監(jiān)控接口等。

4)基礎(chǔ)設(shè)施虛擬化。虛擬化已經(jīng)成為數(shù)據(jù)中心網(wǎng)絡(luò)的基本特征之一。資源管理系統(tǒng)應(yīng)提供對虛擬化全方位的支持，如虛擬網(wǎng)的劃分與配置、多租戶的管理與隔離、虛擬資源的感知與控制、虛擬機(jī)創(chuàng)建、回收、遷移等，能夠滿足現(xiàn)代數(shù)據(jù)中心網(wǎng)絡(luò)資源動態(tài)共享，按需分配的需求。

[1]ZHANG W,SONG Y,RUAN L,et al. Resource management in internet-oriented data centers[J]. Journal of Software,2012,23(2):179-199.

[2]LIN W,QID. Survey of resource scheduling in cloud computing[J].Computer Science,2012,39(10):1-6.

[3]QIAN Q,LI C,ZHANG X,et al. Survey of virtual resource management in cloud data center[J]. Application Research of Computers,2012,29(7): 2411-2415.

[4]Dynamic Host Configuration Protocol[S]. RFC2131,1997.

[5]Dynamic Configuration of IPv4 Link-Local Addresses[S]. RFC3927,2005.

[6]AL-FARES M,LOUKISSAS A,VAHDAT A. A scalable,commodity data center network architecture[A]. Proc of SIGCOMM '08[C]. Seattle,WA,USA,2008.63-74.

[7]MYSORE R N,PAMBORIS A,FARRINGTON N,et al. PortLand: a scalable fault-tolerant layer 2 data center network fabric[A]. Proc of SIGCOMM ’09[C]. Barcelona,Spain.2009.

[8]GUO C,WU H,TAN K,et al. Dcell: a scalable and fault-tolerant network structure for data centers[A]. Proc of SIGCOMM’08[C]. Seattle,WA,USA,2008.75-86.

[9]GUO C,LU G,LID,et al. Bcube: a high performance,server-centric network architecture for modular data centers[A]. Proc of SIGCOMM’09[C]. Barcelona,Spain,2009.

[10]CHEN K,GUO C,WU H,et al. Generic and automatic address configuration for data center networks[A]. Proc of SIGCOMM’10[C].New Delhi,India,2010.39-50.

[11]MA X,HU C,CHEN K,et al. Error tolerant address configuration for data center networks with malfunctioning devices[A]. Proc of INFOCOM’12[C]. Florida,USA,2012.

[12]HU C,YANG M,ZHENG K,et al. Automatically configuring the network layer of data centers for cloud computing[J]. IBM Journal of Research and Development,2011,55(6):1-10.

[13]GREENBERG A,HAMILTON J R,JAIN N,et al. VL2: a scalable and flexible data center network[A]. Proc of SIGCOMM’09[C]. Barcelona,Spain,2009.51-62.

[14]ALIZADEH M,GREENBERG A,MALTZ D A,et al. Data center TCP (DCTCP)[A]. Proc of SIGCOMM’10[C]. New Delhi,India,2010.

[15]VAMANAN B,HASAN J,VIJAYKUMAR T N. Deadline-aware datacenter TCP (D2TCP)[A]. Proc SIGCOMM’12[C]. Helsinki,Finland,2012.

[16]WU H,FENG Z,GUO C,et al. ICTCP: incast congestion control for TCP in data center networks[A]. ACM CoNEXT’10[C]. Philadelphia,USA,2010.

[17]WILSON C,BALLANI H,KARAGIANNIS T,et al. Better never than late: meeting deadlines in datacenter networks[A]. Proc SIGCOMM’11[C]. Toronto,Ontario,Canada,2011.

[18]HONG C,CAESAR M,GODFREY P B. Finishing flows quickly with preemptive scheduling[A]. Proc of SIGCOMM’12[C]. Helsinki,Finland,2012.

[19]ZATS D,DAS T,MOHAN P,et al. DeTail: reducing the flow completion time tail in datacenter networks[A]. Proc of SIGCOMM’12[C].Helsinki,Finland,2012.

[20]KANDULA S,SENGUPTA S,GREENBERG A,et al. The nature of data center traffic: measurements and analysis[A]. Proc of IMC’09[C].Chicago,Illinois,USA,2009.202-208.

[21]BENSON T,AKELLA A,MALTZ D A. Network traffic characteristics of data centers in the wild[A]. Proc of IMC’10[C]. Melbourne,Australia,2010.267-280.

[22]SHIEH A,KANDULA S,GREENBERG A,et al. Sharing the data center network[A]. Proc of Usenix NSDI’11[C]. Berkeley,CA,USA,2011.

[23]BENSON T,ANAND A,AKELLA A,et al. Understanding data center traffic characteristics[A]. Proc of SIGCOMM’09[C]. Barcelona,Spain,2009. 92-99.

[24]WANG M,MENG X,ZHANG L. Consolidating virtual machines with dynamic bandwidth demand in data centers[A]. Proc of INFOCOM’11[C].Shanghai,China,2011.

[25]EPSTEIN A,BREITGAND D. Improving consolidation of virtual machines with risk-aware bandwidth oversubscription in compute clouds[A].Proc of INFOCOM’12[C]. Florida,USA,2012.

[26]AL-FARES M,RADHAKRISHNAN S,RAGHAVAN B,et al. Hedera:dynamic flow scheduling for data center networks[A]. Proc of Usenix NSDI’10[C]. California,USA,2010.

[27]MCKEOWN N,ANDERSON T,BALAKRISHNAN H,et al. Open-Flow: enabling innovation in campus networks[J].Computer Communication Review.2008,38(2):69-74.

[28]MENG X,PAPPAS V,ZHANG L. Improving the scalability of data center networks with traffic-aware virtual machine placement[A]. Proc of INFOCOM'10[C]. San,Diego,CA,USA,2010.

[29]BIRAN O,CORRADI A,FANELLI M,et al. A stable network-aware vm placement for cloud systems[A]. Proc of 12th IEEE/ACM International Symposium on Cluster,Cloud and Grid Computing[C]. Ottawa,Canada,2012.

[30]JIANG J,LAN T,HA S,et al. Joint VM placement and routing for data center traffic engineering[A]. Proc of INFOCOM’12[C]. Florida,USA,2012.

[31]HOPPS C. Analysis of an Equal-Cost Multi-Path Algorithm[S]. RFC 2992,IETF,2000.

[32]RAICIUC,PLUNTKE C,BARRE S,et al. Data center networking with multipath TCP[A]. Proc of HOTNETS ’10[C]. Monterey,CA,USA,2010.

[33]FORD A,RAICIU C,HANDLEY M,et al. TCP Extensions for Multipath Operation with Multiple Addresses[S]. Internet-draft,IETF,2012.

[34]Open vswitch project[EB/OL]. http://www.vswitch.org.

[35]VMWare vSphere: vnetwork distributed switch[EB/OL]. http://www.vmware.com/products/vnetworkdistributedswitch.

[36]Cisco nexus 1000V series switches[EB/OL]. http://www.cisco.com/en/US/products/ps9902.

[37]LUO Y,MURRAY E,FICARRA T L. Accelerated virtual switching with programmable NICs for scalable data center networking[A].VISA’10[C]. New York,NY,USA,2010.

[38]XU L,ZHANG Y,WU J,et al. Network technology research under cloud computing environment[J]. Journal on Communications,2012,33(Z1): 16-221.

[39]802.1Qbg-edge Virtual Bridging[EB/OL]. http://www.ieee802.org/1/pages/802.1bg.html.

[40]802.1Qbh-bridge port extension[EB/OL]. http://www.ieee802.org/1/pages/802.1bh.html.

[41]PCI-SIG. Single root I/O virtualization and sharing specication[EB/OL]. http://www.pcisig.com/specifications/iov/single_root/.

[42]DONG Y,YANG X,LI J,et al. High performance network virtualization with SR-IOV[J]. Journal of Parallel and Distributed Computing,2012,(72):1471-1482.

[43]TRIPATHI S,DROUX N,SRINIVASAN T. Crossbow: from hardware virtualized NICs to virtualized networks[A]. Proc of VISA’09[C].Barcelona,Spain,2009.

[44]RAMK K,MUDIGONDA J,COX L A. sNICh: efficient last hop networking in the data center[A]. Proc of ANCS '10[C]. San Diego,CA,USA,2010.

[45]NAHIR A,ORDA A,RAZ D. Workload factoring with the cloud: a game-theoretic perspective[A]. Proc of INFOCOM’12[C]. Florida,USA,2012.

[46]HAYES B. Cloud computing[J]. Commun,ACM,2008,51(7):9-11.

[47]LUO J,JIN J,SONG A,et al. Cloud computing: architecture and key technologies[J]. Journal on Communications,2011,32(7):3-21.

[48]FEHLING C,LEYMANN F,MIETZNER R. A framework for optimized distribution of tenants in cloud applications[A]. Proc of 3rd International Conference on Cloud Computing’10[C]. Miami,FL,USA,2010.

[49]Amazon elastic compute cloud[EB/OL]. http://aws.amazon.com/ec2.

[50]Amazon simple storage service[EB/OL]. http://aws.amazon.com/s3.

[51]IBM blue cloud project[EB/OL].http://www-03.ibm.com/press/ us/en/pressrelease/ -22613.wss.

[52]802.1Q-virtual LANs[EB/OL]. http://www.ieee802.org/1/pages/802.1Q.html.

[53]802.1ad-provider bridges[EB/OL]. http://www.ieee802.org/1/pages/802.1ad.html.

[54]802.1ah-provider backbone bridges[EB/OL]. http://www.ieee802.org/1/pages/802.1ah.html.

[55]802.1aq-shortest path bridging[EB/OL]. http://www.ieee802.org/1/ pages/802.1aq.html

[56]GUO C,LU G,WANGH J,et al. SecondNet: a data center network virtualization architecture with bandwidth guarantees[A]. Proc of Philadelphia[C]. New York,USA,ACM,2010.

[57]BALLANI H,COSTA P,KARAGIANNIS T,et al. Towards predictable datacenter networks[A]. Proc of SIGCOMM’11[C]. New York,ACM,2011.242-253.

[58]QIN A,YU H. Research on the multi-tenant isolation mechanism based on indentity mapping[J]. Chinese High Technology Letters,2011,21(10):1007-1013.

[59]MUDIGONDA J,STIEKES B,YALAGANDULA P,et al. NetLord: a scalable multi-tenant network architecture for virtualized datacenters[A].Proc of SIGCOMM’11[C]. Toronto,Canada,2011.

[60]POPA L,KRISHNAMURTHY A,RATNASAMY S,et al. FairCloud:sharing the network in cloud computing[A]. Proc of HOTNETS’11[C].Cambridge,MA,USA,2010.

[61]KERRAVALA Z. As the value of enterprise networks escalates,so does the need for configuration management[EB/OL]. http://www.cs.princeton.edu/courses/archive/spr12/cos461/papers/Yankee04.pdf.

[62]What’s behind network downtime?[EB/OL]. http://f.netline. junipermarketing.com/netline000s/?msg=msg.htm.txt&_m=26.11dk.1.ua06p 11znd.3to.