現代數據中心網絡資源管理技術分析與綜述
2014-10-27 11:53:18鄧罡龔正虎王宏陳琳劉志宏
通信學報 2014年2期
鄧罡，龔正虎，王宏，陳琳，劉志宏
（國防科學技術大學 計算機學院，湖南 長沙 410073）
1 引言
數據中心是互聯網和云計算的基礎支撐平臺，是信息技術發展的重要標志。數據中心雖然由來已久，但圍繞數據中心的研究方興未艾，特別是近年來，隨著互聯網和云計算的不斷發展，數據中心逐漸從后臺走向前臺，得到了產業界和學術界的高度重視。Google、微軟、IBM、SGI、思科、惠普等國際 IT公司紛紛推出并部署了自己的數據中心，國內 IT企業也加緊搶占數據中心市場，如中國電信、中國聯通、百度、阿里巴巴等都建立了自己的大型數據中心，世紀互聯推出了“云立方”，浪潮在2011年推出了“Smart Cloud”。學術界也對數據中心給予了很高關注，SIGCOMM、INFOCOM 等重要國際會議均開辟了專門的數據中心研討專題，匯聚相關領域的前沿研究成果。
近年來，圍繞數據中心的研究成果大量涌現，為了厘清各類研究的脈絡，部分研究者已對相關研究進行過分析綜述，文獻[1]分析了Internet數據中心資源管理面臨的挑戰，并以挑戰為主線對近年來國內外在滿足SLA、降低功耗方面所取得的資源管理研究成果進行了概括總結；文獻[2]重點對降低云計算數據中心能耗為目標的資源調度方法，以提高系統資源利用率為目標的資源調度方法，以及基于經濟學模型的云資源管理方法進行了分析比較；文獻[3]則主要從虛擬資源管理的角度對云數據中心資源調度模型與算法以及基于能量優化和負載均衡的虛擬機遷移技術的研究現狀進行了綜述。值得注意的是，以上對數據中心資源管理的研究，都主要是針對計算資源進行的。其面臨的問題主要是當前計算資源利用率低、費效比高的問題，目標是在滿足用戶服務等級協議（SLA）的前提下，實現能量和計算負載的優化。然而，由于傳輸能力的增長往往滯后于計算能力的增長，與計算資源相比，網絡資源更為緊缺。最近的研究表明，網絡性能往往成為數據中心的性能瓶頸，網絡配置錯誤、網絡擁塞、負載不均衡等將導致服務癱瘓、分組丟失、重傳、超時等，嚴重影響數據中心性能，進而影響到服務質量、用戶體驗和投資回報。網絡資源的管理也更為復雜，其原因在于，網絡資源往往是分布式的，同一網絡資源常常被眾多的計算節點所共享，網絡資源的管理，不僅牽涉到網絡本身拓撲、配置、容量等固有屬性，還常常與計算資源、存儲資源及應用分布等緊密相關，因此，研究網絡資源的管理，將面臨更大的困難和挑戰，也具有更加的緊迫性。
然而，隨著數據中心網絡的飛速發展，其組成、結構、功能、規模及應用模式等各方面正發生深刻的變革，傳統的資源靜態分配、工作負載靜態管理、應用與基礎設施緊密耦合的網絡管理方式已經不能適應現代數據中心網絡的新要求，亟待研究新的技術和方法加以解決。深入研究分析現代數據中心網絡資源管理的技術和方法，對于揭示數據中心網絡的基本工作原理，提高數據中心網絡運行效率，節省成本和開銷，具有十分重要的理論和現實意義。地址自動配置技術、傳輸控制技術、流量管理技術以及虛擬化管理技術等是現代數據中心網絡資源管理的重要內容，也是近年來學術界研究的重要方向，本文將結合當前的研究現狀，對以上幾個方面的最新研究成果進行分析綜述。據筆者所知，本文尚屬首次對數據中心網絡資源管理技術進行綜述研究，希望本文的工作能對數據中心網絡資源管理的研究和系統設計提供拋磚引玉的借鑒作用。
2 現代數據中心網絡地址自動配置技術
網絡地址配置是數據中心對外提供服務的基礎。在數據中心網絡對外提供服務之前，需要首先對其節點配置正確的地址。此外，當一個應用從企業數據中心向云端遷移時，為了保持其原有的網絡布局不變，需要為其配置相同的網絡拓撲和地址。傳統的地址自動配置技術主要有DHCP[4]、Zeroconf[5]等。DHCP 是應用最為廣泛的主機地址配置協議，在DHCP中，DHCP服務器保存可用的IP地址，當主機加入子網時，通過廣播搜尋DHCP服務器并獲取一個未使用的IP地址作為本機地址。為了能夠接收廣播信息，主機和DHCP服務器需在同一子網內。在Zeroconf協議中，需要進行地址配置的主機隨機產生一個地址，并將該地址廣播到網絡中，如果沒有回復表明該地址被占用，則保留該地址作為本機地址，否則重復以上過程直到找到未被占用的地址，Zeroconf仍只能對同一子網內的主機進行地址配置。與傳統數據中心網絡不同的是，為了充分利用網絡的結構特性以提供高效的路由，現代許多數據中心網絡地址和網絡位置常常是相關的，如Fat-tree[6]、Portland[7]、DCell[8]、BCube[9]等均將位置信息編碼到邏輯地址中。此外，現代數據中心網絡可達百萬節點的規模，傳統的地址自動配置協議如DHCP、Zeroconf等只能對同一子網內的主機進行地址配置，且需要通過廣播進行信息交互，不僅不能適應于大規模的網絡，而且隨著網絡規模的增大，將導致低效。另外，傳統的地址通常指的是 IP，而在現代數據中心網絡中，地址可能僅僅意味著一個邏輯標識，既可以是傳統的IP地址，也可能是非IP的其他標識，如Dcell、Bcube中的ID等。因此，傳統的地址自動配置技術將不適用于現代數據中心網絡。圍繞數據中心網絡地址自動配置，當前的研究主要可分為2類：一類是拓撲相關的地址自動配置，主要是基于圖的基本理論，將地址自動配置問題轉化為圖同構問題加以解決，另一類則是拓撲無關的配置技術，典型代表是DCZeroconf，主要是借鑒Zeroconf的思想，實現數據中心網絡地址的自動配置。前者主要解決邏輯地址與位置相關的問題，而后者主要是解決大規模的數據中心網絡中地址配置的動態適應性問題。
2.1 拓撲相關地址自動配置
如前所述，最近提出的許多數據中心網絡結構均是拓撲相關的，在網絡提供服務前，需要根據設計圖配置網絡地址，或者當企業應用向云中遷移時，為了保持原有結構，需要按原有拓撲進行地址配置。一般地，拓撲相關的網絡地址自動配置問題可表述為：給定相應的設計圖（blueprint）和物理網絡圖（physical network graph），網絡地址自動配置尋找設計圖和物理網絡圖的一種同構映射，從而為每個物理節點分配相應的邏輯ID，其中，設計圖代表了網絡的邏輯拓撲，每個節點被賦予一個邏輯ID，如IP，而物理網絡圖則包含了網絡的物理連接關系及設備ID，如MAC地址。當前，拓撲相關的地址自動配置算法主要有DAC和ETAC。文獻[10]提出了一個通用數據中心網絡地址自動配置算法DAC，DAC根據設計圖及物理網絡拓撲實現邏輯ID到設備ID的映射，如圖1(a)所示。DAC問題本質上是圖同構問題，但是，針對大規模的數據中心網絡，圖同構算法復雜度極高，為此 DAC結合數據中心網絡結構特性，將問題轉化為子圖同構問題加以解決。在此過程中，DAC主要使用了3個啟發式策略，分別是通過最短路徑長度分布選擇候選者，通過軌道(orbit)過濾候選者及有選擇的撕裂（splitting）。大規模的仿真結果表明，DAC對地址自動配置問題有較高的效率，對幾萬節點的BCube網絡、幾十萬節點的 Fat-tree網絡及上百萬節點的DCell網絡能在10 s內完成配置。DAC的主要缺點是在網絡發生錯誤時，算法將無法完成配置，需要人工檢測并修復，且其錯誤檢測算法需要較長的時間，這極大地降低了網絡發生錯誤時DAC的效率。針對這一問題，Ma等人對DAC進行了補充和完善，提出了一種容錯的地址自動配置算法 ETAC[11]。ETAC包含了一個錯誤檢測模塊，當無錯誤時，則對全網進行配置，當發現網絡發生錯誤時，首先在邏輯圖和物理網絡中邏輯地移除錯誤節點，然后再對剩余的子圖進行同構映射，如圖1(b)所示，從而使得網絡在發生錯誤時，仍能部分地對網絡進行配置，提高了地址自動配置的適應性。仿真結果表明，對10000節點的網絡規模，ETAC能在300 s內完成邏輯ID到物理ID的映射。DAC與ETAC的主要缺點是需要首先輸入設計圖，對百萬節點的網絡，這是不小的規模。此外，DAC與ETAC均是在設計圖與物理網絡拓撲同構（可能存在少量故障）的前提下，對網絡地址實施同構映射，但某些情況下，可能需要根據設計圖在一個龐大的網絡中首先找出與之同構的子網（如企業應用向云遷移），且這一子網需要滿足某種限制，如占用的帶寬最少或相對集中分布等，然后再對該子網進行地址配置。這一過程本身是非常關鍵和復雜的，但當前尚未見相關研究。最后，對ETAC而言，當故障涉及核心節點時，邏輯地移除相關節點將可能使得網絡被撕裂為不同的碎片，從而無法正常提供服務，這將嚴重影響ETAC配置的效果。理想的狀態是，在節點涉及故障，而非節點本身發生故障時，仍能正常配置并提供服務。
2.2 拓撲無關地址自動配置
DAC和 ETAC適用于拓撲與地址嚴格相關的網絡，在進行地址配置時首先需要輸入設計圖，需要大量的手工輸入，當有節點動態加入和退出時，需要對全網進行重新配置，代價開銷大，對動態的網絡環境如云計算等適應性差。為此，IBM的研究人員針對拓撲無關的網絡提出了一種無需設計圖的地址自動配置方法 DCZeroconf[12]。DCZeroconf的設計目標主要是3個方面：①能夠對任意網絡拓撲的虛擬機（VM,virtual machine）或主機進行IP地址配置；②當網絡拓撲發生變化時，算法能動態適應這種變化；③能夠適應不同的網絡規模。DCZeroconf采用了一種層次式的配置思想，主要包括3步，如圖1（c）所示。首先，網絡管理員決定可用的 IP地址范圍并將其分配給地址配置集中控制器（CR），這也是DCZeroconf唯一需要人工干預的地方，隨后，CR將可用IP地址分成不同的段，并告知每一個機架地址控制器（RR）該機架可用的地址池，最后，當機架內有主機、虛擬機或交換機請求地址配置時，RR即可從地址池中任選一個未使用的地址對其進行配置。為了完成CR與RR的通信，需要在CR與RR之間構建專門的配置網絡，雖然配置網絡規模相對較小且對帶寬等要求不高，甚至可以用無線的方式構建，但這也將增加DCZeroconf的部署難度和一定的額外開銷。DCZeroconf的主要優點是實現了完全的地址配置自動化，包括無需輸入設計圖，且能適應網絡拓撲的動態變化，虛擬機的動態加入與退出等，其缺點主要是所配置的網絡地址與位置無關，且需要增加專門的地址配置網絡。
圖1 典型數據中心網絡地址自動配置算法
表1對幾種地址配置方法進行了對比，由表1可以看出，傳統的DHCP、Zeroconf等配置方法無論是在可配置設備的類型、配置規模和適用的范圍上，均不適用于大規模現代數據中心。而 DAC、ETAC與 DCZeroconf的主要區別則是在地址與位置是否嚴格相關上。對網絡節點動態加入或退出以及網絡故障引起的拓撲動態變化，除DAC和ETAC外均具有高適應性。就配置效率而言，DHCP、Zeroconf與 DCZeroconf均不受故障影響，且只對同一子網（DCZeroconf為同一機架）進行配置，效率高，但Zeroconf需要通過廣播信號在所有設備之間進行協商，因而效率較DHCP低。DAC在無故障時具有極高的配置效率，但在發生故障時需人工干預，配置效率低，ETAC部分克服了DAC的局限，但受問題復雜度的影響，在網絡規模較大時，配置效率降低。
2.3 小結
當前的數據中心網絡的地址自動配置技術主要包括拓撲相關和拓撲無關2類，前者主要根據邏輯拓撲和物理網絡圖完成邏輯 ID到設備 ID的映射，后者主要針對地址與拓撲無關的網絡實現地址的自動配置。就前者而言，當前的算法仍存在容錯性、動態適應性、配置效率等問題，且當節點涉及故障時，DAC需要人工干預才能完成配置，ETAC則可能因為移除了關鍵節點而不符合配置預期。就后者而言，地址與拓撲無關可能導致不能滿足應用拓撲相關的特殊要求，也不能有針對性地進行性能和路由等優化。此外，并非所有網絡地址均拓撲嚴格相關或無關的，某些網絡的地址與拓撲可能僅是部分相關的，如VL2[13]，某些網絡出于性能或管理的原因，僅僅需要將某一主機放置在某一機架內，對這類地址與拓撲部分相關網絡的地址配置問題，當前未見專門的研究。
表1 地址自動配置算法對比
3 現代數據中心網絡傳輸控制技術
TCP協議自誕生以來，取得了巨大的成功。然而，最近的研究表明，傳統的TCP協議應用于數據中心網絡將導致低效，這是因為TCP主要是為了滿足 Internet數據傳輸需要而設計。與數據中心網絡相比，Internet具有分布式、自組織、低帶寬、高延遲和低吞吐率的特點，而數據中心網絡則表現為集中式、高帶寬、低延遲和高吞吐率，網絡有集中統一的控制。數據中心運行著各種關鍵核心業務，如搜索引擎、Web服務、在線購物、網絡游戲等，對網絡性能有極高的要求，網絡運行效率和性能優劣將直接影響到各種服務的性能進而影響到用戶體驗。最近的研究指出，許多數據中心應用面臨某種軟實時限制（soft-real-time constraint），如搜索引擎的響應時間通常應小于300 ms，響應時間超過這一時限，將導致軟超時，影響用戶體驗進而影響到投資回報。傳統基于TCP協議的傳輸控制機制應用于數據中心將極易導致網絡性能下降、擁塞、超時、網絡利用率低等問題，為此，需要針對數據中心特殊的網絡環境，對TCP協議進行改進或重新設計，研究新的傳輸控制機制。當前的研究主要分2類：①軟超時無關的傳輸控制；②軟超時敏感的傳輸控制。
3.1 軟超時無關的傳輸控制
標準TCP協議當收到網絡擁塞通知時，即將發送速率減半，TCP對擁塞的響應與擁塞程度是不成比例的，在高帶寬、低延遲的數據中心網絡環境，將導致鏈路利用率降低和吞吐量下降。軟超時無關的傳輸控制技術主要是通過對傳統 TCP協議的擁塞控制機制進行修改，使之更適應于數據中心傳輸特性，從而提高數據中心網絡吞吐率。文獻[14]提出了一種數據中心網絡TCP協議DCTCP。DCTCP主要的設計目標是針對數據中心網絡高帶寬、低延遲的特點，提供比TCP協議更高的吞吐率、更低的延遲，并能夠適應網絡突發流。DCTCP利用交換機的顯式擁塞通知（ECN,explicit congestion notification），每條流根據擁塞標志CE被置位的數據分組所占的比例估計網絡的擁塞程度，并據此動態地調整流的發送速率，從而既能降低擁塞，又能減少隊列延遲和分組丟失。仿真結果表明，與TCP相比，DCTCP能獲得更高的吞吐率和更低的延遲。遺憾的是，DCTCP是軟超時無關的，DCTCP僅根據感知的擁塞程度，“公平地”調節流的發送速率，而不能使接近超時的流得到優先傳輸，研究表明，在高扇入、低延遲的應用中，約25%的流將發生軟超時[15]。DCTCP試圖從傳輸層的角度，設計一種通用高效的擁塞控制機制。而文獻[16]則專門針對多對一通信中的擁塞控制開展研究，提出了一種Incast擁塞避免機制ICTCP。多對一通信中接收端容易發生擁塞，引起分組丟失、重傳，導致性能下降。ICTCP在接收端根據剩余可用帶寬的大小以及流的期望吞吐量與實際測量值之間的差異率，每條流獨立地通過調整接收窗口的大小調節發送速率，達到避免擁塞的目的。簡單地說，即當差異率小于某一閾值且網卡有可用帶寬時，則增大接收窗口，反之則減小接收窗口，其他則保持不變。
3.2 軟超時敏感的傳輸控制
與軟超時無關的方法不同，軟超時敏感的傳輸控制機制的主要目標是最大限度滿足流的軟超時時限，以提高用戶體驗，同時兼顧網絡吞吐量等其他性能，典型的方法有D3、D2TCP等。微軟研究院的Wilson等人首先對軟超時問題進行了研究，提出了一種超時敏感的數據中心網絡傳輸協議D3[17]。在D3中，應用程序顯式地向傳輸層提供超時的時限和需發送流量的大小，每一個RTT(round trip time)，發送端主機根據超時時限和傳輸流量大小向路由器請求發送速率，流的傳輸路徑上的每一個路由器按照先來先服務的原則貪婪地為流分配速率以使盡可能多的流能在軟時限內完成并形成速率分配向量，反饋回發送端主機，發送端主機根據速率分配向量選擇最小的速率作為下一個 RTT的發送速率。D3開創性地提出了軟超時敏感的傳輸控制協議，但D3的缺陷也是明顯的。①需要應用程序顯式地提供軟超時信息，這可能導致惡性競爭或惡意的帶寬占用。②需要修改主機、路由器和應用程序，部署難度大。③與現有TCP協議不兼容。④D3是不公平的，當不能滿足所有流的軟超時時限時，D3保證了某些流按時傳輸完成，而另一些流則軟超時被丟棄，在需要同步的應用中，可能因為少數流被丟棄而長期等待，從而影響總的響應時間，導致性能不可預期。⑤D3按照先來先服務的策略為每條流分配帶寬，這可能導致某些稍早到達但離超時尚遠的流獲得了帶寬而某些稍晚到達但接近超時的流無法分配帶寬，從而導致優先權的反轉。如前所述，DCTCP擁塞敏感但卻軟超時無關，D3軟超時敏感卻擁塞無關，D2TCP[15]則綜合了DCTCP和D3的基本思想：發送端根據網絡的擁塞程度和流的軟超時時限動態地調整發送速率，當檢測到擁塞發生時，每條流結合網絡擁塞程度和軟超時時限動態調節發送窗口，網絡越擁塞，離軟超時越久，則發送窗口減少越多，從而既能實現擁塞控制，又使得更接近軟超時的流能得到優先傳輸。但是，D2TCP仍需應用程序顯式地提供軟超時時限。D2TCP與D3一樣不支持搶先調度，這仍然可能導致某些稍晚到達但更緊迫的流發生超時。為此，文獻[18]提出了一種分布式的流搶先調度策略PDQ。PDQ通過發送端、接收端和交換機的協作，實現了一個分布式超時敏感的搶先調度算法，算法在流有軟超時時限時，時限越小的流優先，如果流沒有軟超時時限，則完成時間小的流優先，但PDQ不僅需要上層應用顯式提供軟超時時限，而且需要對交換機進行修改以支持搶先調度，實現難度大。文獻[19]通過理論分析認為導致軟超時的原因主要是流完成時間的重尾分布，從概率意義上講，減少重尾效應就相當于減少了流軟超時的概率，而導致重尾的原因主要有3個：①分組丟失和重傳；②流優先權反轉；③負載不均衡。為此，文獻[19]提出了一種跨層的傳輸控制框架DeTail。圖2展示了DeTail的協議棧結構和跨層的信息交互。在數據鏈路層，DeTail通過端口緩沖區占用構造一個無分組丟失網絡，無分組丟失網絡只會由于硬件錯誤或失效而導致數據分組丟失，而不會因為突發擁塞而分組丟失，在現代數據中心網絡中，由于硬件錯誤極少發生，這使得分組丟失成為小概率事件，分組丟失的減少也降低了重尾的概率；在網絡層，DeTail通過端口緩沖區的占用信息執行分組級的動態負載均衡，減少了網絡擁塞的可能性；在傳輸層，由于底層網絡僅在硬件錯誤或失效時發生分組丟失，因此，無需對亂序敏感地作出反應，DeTail通過簡單地移除TCP的分組丟失重傳機制或降低對亂序的敏感度以達到抗亂序的目標；在應用層，DeTail通過允許應用定義流的優先級實現對延時敏感流的優先傳輸。DeTail首次提出了通過跨層的協作機制解決數據中心網絡擁塞控制和軟超時保證的問題，但是，DeTail仍需要應用顯式定義流的優先級，同時需要交換機及主機協議棧的支持。
圖2 DeTail的跨層網絡棧結構
3.3 小結
與 Internet相比，數據中心網絡在網絡結構、通信模式、流量特征等方面均有著不同的特點，傳統的TCP協議主要針對Internet而設計，不能充分利用數據中心網絡特性，直接運用于數據中心網絡面臨功能和性能等方面的不足，使得新型的數據中心網絡傳輸控制協議成為新的研究熱點。當前的研究主要集中在擁塞控制機制和軟超時保證 2個方面，總體而言，單純的擁塞控制機制雖然能夠提高網絡吞吐率，但由于對軟超時不敏感，可能導致部分流因未得到及時傳輸而軟超時，最終影響到應用的性能。而軟超時敏感的傳輸控制機制雖能夠根據超時時限和網絡擁塞程度進行流的優先調度，但目前的研究仍都需要上層應用顯式地提供超時信息，這容易導致帶寬資源被惡意搶占，且許多技術都需要修改網絡中間設備，這增加了部署難度。表2對幾種典型傳輸控制機制進行了綜合比較。
表2 數據中心網絡典型傳輸控制機制對比
4 現代數據中心網絡流量管理技術
流量管理是數據中心網絡資源管理中最重要也是動態性最強和最具挑戰性的內容。本節將首先對數據中心網絡流量特征進行研究分析，然后分別對2類不同的流量調度策略進行綜述，最后給出各種流量調度方法的小結比較。從網絡流級看，現代數據中心網絡普遍支持節點之間的多路徑連接，多路徑提供了更高的傳輸能力，但現有TCP協議的單路徑傳輸特性與網絡的多路徑支持之間并不相適應，如何根據數據中心網絡結構及流的特性，在不同路徑間分配和平衡流量，以最大化數據中心網絡性能是當前的研究熱點之一，可分為2種不同的研究思路。①以網絡流為中心的調度策略：通過對流的傳輸路徑的分配調度或通過虛擬機的優化布局，實現網絡流量平衡或資源利用率的最大化。②以網絡結構為中心的調度策略：從網絡結構屬性的角度研究網絡資源高效利用的支持機制，發掘現代數據中心網絡的多路徑傳輸能力。
4.1 現代數據中心網絡流量特征
網絡流量特征是進行流量管理的基本依據。最近的研究表明，數據中心網絡流量具有局部性、動態性和不平衡性等特點。文獻[20]通過對1500個服務器 2個月期間的網絡流量的測量和分析表明，相同機架內的節點更可能發生通信，一個服務器或者與同一機架內所有節點通信，或者僅與不超過25%的節點通信；或者不與機架外地其他節點通信，或者僅與1%～10%的節點通信。數據中心網絡流量分布表現出 2種不同的模型：workseeks-bandwidth 模型和 scatter-gather模型。workseeks-bandwidth模型表現為相鄰或相近的節點之間具有較大的數據通信，如相同機架或相同VLAN的節點之間具有更多的通信，這主要是因為設計者通常希望把相同的作業放在同一區域以獲得更高的帶寬。scatter-gather模型表現為一個服務器與多個服務器之間的通信，這主要是由于數據中心典型的應用模型如Map-Reduce等本質上要求數據有分發和匯聚的過程，需要在一個節點與多個節點之間傳遞數據。文獻[21]通過對10個不同類型（大學、企業和云計算）數據中心網絡流量的測量也發現，對云計算數據中心而言，80%的數據流量發生在機架之內，這表明對大部分應用而言，流的分布具有某種局部性。文獻[21]的研究還表明，隨著應用的不同，同一時刻不同數據中心網絡中流的數目存在著較大的差異，范圍從幾條到接近上萬條不等，流的到達時間也從幾毫秒到上百毫米不等，但是，絕大部分流的到達時間都不會超過100 ms。在文獻[20]的測量結果中，就整個簇而言，流的平均到達速率達105條/秒，即每毫秒有約100條到達，文獻[22]的測量結果也表明，數據中心中流的數目巨大，同時存在的跨機架的流平均可達105的數量級，平均到達時間也達5×105條/分鐘。這意味著數據中心網絡流具有極高的突發性和動態性，從資源管理的角度看，集中的流調度算法將很難奏效。最近的研究還表明，數據中心網絡流存在不平衡性，這種不平衡表現在2個方面：大小不均勻和分布不平衡。在流大小上，文獻[21]的測量結果表明，流的大小和長度表現出大象流和老鼠流的特性，80%的流大小不超過 10 KB，10%的流占據了絕大部分的數據流量。無獨有偶，文獻[8,20]也觀察到了類似的現象，文獻[8]中存在明顯的老鼠流現象，99%的流均小于100 MB，然而超過90%的字節卻包含于100 MB到1 GB的流中，這就意味著不到1%的流包含了超過90%流量。文獻[20]中持續超過200 s的流不到0.1%，80%的流持續時間都比較短，不超過10 s。在流分布上，文獻[20]的分析表明，在采用三層結構（核心層、匯聚層、邊緣層）的數據中心網絡中，各層之間的流量并不平衡，核心層通常具有較高的鏈路利用率，而邊緣層和匯聚層則相對較低。文獻[23]也觀察到類似的結論，核心層鏈路利用率高于匯聚層和邊緣層，但分組丟失率卻相反，核心層鏈路利用率是匯聚層的4倍，95%的匯聚層鏈路利用率不超過10%。這表明流的分布并不均勻，核心層相對集中且穩定，而其他層分布較少但突發性更高，從而導致分組丟失率更高。網絡流的這些特性給數據中心網絡管理帶來了嚴峻的挑戰。
4.2 以網絡流為中心的調度策略
實際的測量和理論分析表明，數據中心網絡的流量主要是服務器之間的流量，除一對一（1→1）通信外，一對多（1→N）、多對一（N→1）、多對多（N→M）等集群通信模式是數據中心網絡的主要通信模式[8,9,20]，集群通信即多節點之間的通信。大量節點之間通信容易引發網絡擁塞，導致分組丟失、重傳和性能下降。如前2.3節所述，數據中心的一些應用還面臨某種軟實時限制（soft-real-time constraint），響應時間超過一定限度（如300 ms），將影響到用戶體驗進而影響數據中心的收益。為此，需要通過網絡流的優化調度及服務器的合理布局提高網絡性能。當前，針對網絡流調度的研究主要可分為2類：一類是僅考慮主機出口帶寬的調度方法；另一種是考慮全網容量限制的調度策略。
4.2.1 主機出口帶寬限制的調度方法
由于流的突發性和動態性特征，當前，針對主機出口帶寬的流調度策略主要是將網絡流看作隨機變量，采用隨機裝箱的思想加以解決。文獻[24]研究了通過虛擬機的合并提高網絡資源利用率的問題。其問題可描述為：給定一序列元素列表L=(x1,x2,…,xn)，其中xi是規格化且互相獨立的隨機變量，則最少需要多少單位容積的箱子才能裝下所有的元素，使得元素的容積之和大于箱子容積的概率不大于某一給定常數e∈(0,1)。這里的元素就相當于每個虛擬機需要的帶寬，而箱子則相當于主機的出口帶寬，則網絡帶寬資源的分配轉化為隨機裝箱問題(SBP,stochastic bin packing)，Wang Meng等人采用啟發式策略，使得對于任意 ε>0，在滿足帶寬需求的情況下，所需服務器數量不大于最優值的(1+ε)(+1)倍；文獻[25]對Wang Meng等人的研究工作進行了改進，使得所需服務器數量進一步減少到不大于(2+ε)倍。以上解決方案僅考慮單臺服務器的出口流量，并未考慮外部網絡的傳輸能力。而實際上，網絡流的優化不僅受到主機出口帶寬的制約，同時還受到網絡拓撲及路徑容量的制約。因此，另一類的流調度策略則結合了網絡拓撲進行考慮。又可以進一步分為3種策略：①通過調度流的傳輸路徑實現流量優化；②通過虛擬機遷移，優化虛擬機的布局以改變流量的分布；③結合虛擬機遷移和路由共同優化流的傳輸。
4.2.2 全網帶寬限制的調度方法
通過調度流的傳輸路徑實現流量優化。加州大學的Mohammad Al-Fares等人提出了一種通過控制流的傳輸路徑實現流量優化的方法 Hedera[26]。Hedera首先通過網絡流量的測量并估算出每條流可能的流量需求，然后采用集中控制的算法，為流預留路徑，并更新轉發表。為了提高算法的效率，Hedera僅對大流進行調度，只有當流的持續時間及帶寬需求超過某一閾值時，才激活調度算法。Hedera在路徑改變時需要更新轉發表，將一定程度上影響流的傳輸性能。為了支持修改轉發表，Hedera采用OPenFlow[27]交換機，OPenFlow交換機雖然已有部分商業產品出現，但其性能并未得到充分檢驗，當前并未成為數據中心交換機的主流。
通過虛擬機的優化布局改變流量的分布。Hedera通過改變轉發表進而對流實施調度，但如前所述，普通商業交換機并不支持修改轉發表。現代數據中心廣泛采用虛擬化技術，可以通過對虛擬機的優化布局從而改變流的分布。為此，IBM的Meng等人將流調度問題轉化為流量感知的虛擬機的優化放置問題（TVMPP）[28]，問題的輸入是虛擬機之間的流量矩陣及主機之間的通信代價矩陣，目標是尋找一種虛擬機的放置方案，使得全網總的流量最小。文獻[28]證明了這一問題為NP完全問題，并設計了一種啟發式策略加以解決，其復雜度為O(n4)。該方法的主要缺陷是在分配虛擬機時僅考慮了網絡出口帶寬限制，并未考慮網絡容量的限制，因此，分配方案可能不滿足QoS要求。為使全網總的流量最小，意味著虛擬機應盡量集中放置，這使得配置方案擴展性較差，難以適應帶寬需求的變化，此外，算法的復雜度也較高。與此相反，文獻[29]將流量優化問題轉化為最小割率感知的虛擬機放置問題 MCRVMP，目標是虛擬機的分配不僅要滿足當前的需求，還應最大限度適應未來需求的變化，即實現網絡流量平衡。MCRVMP主要針對樹型網絡，首先根據虛擬機之間的流量矩陣及虛擬機的放置位置找出負載率最高的關鍵割，再在所有方配方案中選出關鍵割負載率最低的分配方案作為虛擬機的分配方案。MCRVMP問題仍為NP完全問題。文章提出了 2種啟發式算法。一種采用分治和遞歸思想的2PCCRS，首先將VM分成不同的簇，再對每一個小簇進行虛擬機分配，從而降低問題的規模。另一種是采用貪婪算法GH。2種方法所獲得的關鍵割的負載率均較小（小于0.5），但是2種算法的復雜度均很高，仿真結果表明，對3430個VM的網絡，在最壞情況下，2PCCRS需要超過3000 s，GH算法需要超過8000 s才能完成分配。
結合虛擬機遷移與路徑選擇的調度策略。以上2種對網絡流優化調度的方法，或者只考慮虛擬機的放置位置，或者只考慮流的路徑選擇，而實際上，網絡的性能跟虛擬機的位置與路由通常是緊密相關的，僅考慮某一維度，優化效果有限。普林斯頓大學的 Jiang等人結合虛擬機遷移和路由對網絡性能優化進行了討論，將路由選擇和虛擬機放置的聯合優化問題轉化為靜態優化問題，并基于馬爾可夫模型構造了一個優化算法VMPR[30]。但是，該模型引入了過多的參數，參數需要人工調節，因此需要專門的經驗和知識，且為了降低算法的復雜度，模型每次只允許調整一個VM的位置，在大規模的網絡中，這將對算法的優化效率產生重要影響。
4.3 以網絡結構為中心的調度策略
現代數據中心網絡的新型拓撲結構如Fat-tree、VL2、DCell等都提供節點之間的多條路徑連接。多路徑提供了更高的網絡容量，通過在多條不同的路徑之間分配和平衡流量，可以減少網絡擁塞，提高網絡資源利用率，但是，現有TCP協議的單路徑傳輸特性和數據中心網絡結構的多路徑支持之間并不適應。以網絡結構為中心的調度策略，通過發掘網絡結構固有的傳輸能力，特別是對多路徑傳輸的支持，并發地傳送流量，以到達最大化網絡傳輸性能的目的。針對如何并發利用網絡的多路徑特性，在不同的路徑之間分配和平衡流量，以提高網絡吞吐率，當前的解決方案主要有3種。
1)采用固定的轉發規則。根據源地址或目標地址將流映射到固定的路徑，如Fat-tree。在Fat-tree網絡結構中，每個終端主機有(k/2)2條到達核心層的路徑，Fat-tree根據源節點的地址，為不同源地址的流選擇不同的路徑，從而實現在不同路徑間平衡流量。
2)采用隨機負載均衡的辦法。在所有可用的等價路徑中為每條流隨機選擇一條路徑，如ECMP[31]、VLB[8]等。ECMP在多條等價路徑中為每一個數據分組隨機選擇一條路徑，而為了防止亂序，VLB則是為每條流隨機選擇路徑。
3)使用集中控制策略。根據網絡結構屬性和流量矩陣，通過全局的控制器進行路徑選擇。但是，這些方案都存在各自缺陷，固定規則的路徑選擇策略和隨機負載的方法雖然能在一定程度上分散網絡流量，但不能根據路徑的負載進行動態調度，可能導致網絡局部擁塞[32]；而集中調度算法由于需要流的全局信息，運行效率將受限。研究表明，在大規模的數據中心網絡中，網絡流的數目巨大，且絕大部分的流均為小流，持續時間極短，集中調度的算法將需要頻繁地對流進行調度。一種可行的改進是僅對大流進行調度，研究表明，在流的大小服從指數分布，到達時間間隔服從泊松分布到情況下，對大的流進行調度可以獲得較高的帶寬利用率和較小的時間開銷[26]，然而實際的測量和分析表明，數據中心網絡流并不服從這樣的分布[8]，這種方法仍需要頻繁地調度且性能接近于隨機調度[32]。基于此，文獻[32]通過理論分析認為數據中心網絡應由TCP自然演進到多路徑TCP(multipath TCP)[33]。但是，多路徑TCP當前并未得到廣泛支持。
4.4 小結
以上分析表明，數據中心網絡流數目巨大，且具有極強的突發性和動態性，對網絡流量的管理提出了嚴峻的挑戰。網絡流的調度問題往往是NP完全問題，具有極高的復雜度。以網絡流為中心的調度策略通過感知與監測網絡的負載情況及流量矩陣，實時地為每條流或主要的流選擇傳輸路徑，或通過虛擬機的遷移改變流量分布，達到流量平衡或優化的目的。但是，在流的到達速率達105條/秒且絕大部分流為短流的情況下，這樣的調度算法占用大量的資源，其有效性也難以得到保證，而且，以網絡流為中心的調度策略往往只能支持流的單路徑傳輸，不能有效利用現代數據中心網絡的多路徑特性。以網絡結構為中心的調度算法結合網絡本身固有的傳輸特性，按照一定的規則將流分配到不同的路徑上，這種方法雖然有利于發揮網絡的多路徑傳輸能力，但或者由于缺乏路徑負載信息和流量矩陣信息，可能導致局部擁塞，或者仍需要集中的控制，難以適用于大規模數據中心網絡。
5 現代數據中心網絡虛擬化管理技術
5.1 主機內部網絡虛擬化技術
服務器虛擬化技術使得網絡進入主機內部，多個虛擬機可以在同一主機內組網共存。虛擬化的這一特點使得主機內部網絡的管理與控制成為新的問題。在傳統非虛擬化條件下，物理主機作為終端計算節點而存在，內部本身不存在網絡功能，物理主機與網絡的連接通過鏈路狀態體現，主機的位置相對固定，外部網絡可以對其實施訪問控制、流量監測等監控功能，主機的狀態可以完全被網絡感知與控制。服務器虛擬化后，一個物理主機內有多個虛擬機并存，為了支持不同虛擬機之間的通信，并對其實施監控與管理，需要在主機內引入虛擬網絡功能，當前主要有3種方式。
1)采用虛擬交換（virtual switch）的方式。由宿主機操作系統或虛擬機管理系統內的軟件虛擬交換機完成虛擬機間數據交換，如開源項目Open vSwitch[34]、VMWare 的 vNetwork Distributed Switch[35]和思科的 Nexus v1000[36]等，如圖 3(a)所示。虛擬交換采用軟件的方式在主機操作系統或虛擬機管理系統（hypervisor）內部實現一個虛擬交換機，這種方式下，虛擬交換機、虛擬網卡均需要與VM競爭使用主機CPU資源，當端口的線速達到10 Gbit/s或更高時，將嚴重影響主機性能，且很難保證QoS和VM隔離。為此，文獻[37]利用多核可編程網卡的支持，提出了一種基于可編程網卡的虛擬交換技術，通過將VM的虛擬網卡遷移到可編程網卡上，避免了在高速網絡中虛擬網卡競爭使用主機資源，提高了虛擬數據中心資源利用率，同時可編程網卡為每個虛擬機提供單獨的域，提高了VM間的安全性和隔離性。但該方法仍需要借助虛擬交換機進行數據交換，且同一主機內的虛擬機間的數據需在I/O總線上傳輸2次，浪費了主機資源。總體而言，采用虛擬交換的方式存在2大問題[38]：①虛擬機之間的流量監控問題，傳統的網管系統無法深入服務器內部進行流量監控，造成安全隱患；②性能問題，虛擬機網絡流量越大，虛擬交換機就會占用越多的CPU資源進行報文轉發。
2)利用外部交換機進行數據交換。如EVB[39]，VN-tag[40]等，如圖3(b)所示。為了解決服務器虛擬化后網絡邊界模糊，虛擬機感知與控制困難等問題，IEEE標準化組織制定了 EVB（edge virtual bridging）標準（即IEEE 802.1Qbg），EVB本質上是在VM與邊緣交換機之間定義一組標準接口，使得VM的數據流量完全由外部物理交換機轉發，虛擬機接入網絡之前首先需要通過虛擬工作站接口發現協議（VDP,virtual station interface discovery protocol）發送關聯請求并與邊緣交換機建立關聯，虛擬機的遷移、銷毀也分別需要重新關聯和去關聯。通過這種方式，使得VM可以實時被外部網絡感知與控制，物理主機內部的網絡功能重新被移回主機外部，網絡邊界變得更加清晰，可以采用傳統的網絡管理的策略對VM進行流量監控、QoS監控等高級網絡特性的管理。EVB雖然解決了VM的感知與控制的問題，但在EVB中，VM的所有流量都要經外部交換機進行交換，同一主機內VM間的流量需要穿越主機網卡2次，這不僅占用主機資源、浪費主機I/O帶寬，同時也增加了外部網絡壓力。VN-tag是 Cisco的私有技術，其實現機理與EVB相似，通過在以太網幀中增加VN-TAG標記，用以標識VM連接的通道和映射到交換機的虛端口號。
圖3 3種主機內網絡虛擬化技術對比
3)利用主機網卡進行數據交換。利用增強功能的主機網卡，實現內部網絡的接入與交換，如圖3(c)所示。為了解決虛擬機與外設之間的I/O操作引起hypervisor陷入帶來的平臺資源開銷，同時保持I/O設備在多虛擬機間的共享特性，PCI-SIG聯盟提出了I/O虛擬化標準SR-IOV(single root I/O virtualization and sharing)[41]，SR-IOV允許多個虛擬機共享一個網卡。一個SR-IOV設備具有一個或多個物理功能單元(PF,physical function)，同時可以創建多個虛擬功能單元(VF,virtual function)，每一個PF是一個標準的PCIe功能部件，每個PF可與多個VF關聯，VF就像一個輕量級的PCIe功能部件，具有唯一的請求標識（RID,requester identifier）及性能攸關的關鍵資源，并共享大部分的設備資源，提供獨立的中斷、隊列及地址轉換機制，從而允許虛擬機直接對與之關聯的VF進行控制，就仿佛是獨立使用專門的網卡，部分網卡也提供板上VF間數據交換功能。文獻[42]基于 SR-IOV提出了一種跨平臺的主機內網絡虛擬化體系結構，該結構主要由 3部分組成：PF driver、VF driver和SR-IOV Manager(IOVM)。PF driver工作在物理主機操作系統或XEN的Domain0上，負責直接訪問PF及配置管理VF，VF driver工作在客戶機（VM）操作系統上，直接訪問與之對應的專門的 VF，而不需經過虛擬機管理系統VMM的干預，IOVM工作在VMM上，為每一個VF提供虛擬化的配置服務，使得客戶操作系統可以像普通設備一樣枚舉和配置 VF。該結構使得VM可以無需VMM干預直接訪問SR-IOV網卡，從而能在不同的虛擬化平臺上實現，在提高I/O性能的同時具有良好的可擴展性。但是，網卡的硬件資源總是有限的，隨著服務器性能的提高，一臺服務器內可以虛擬出幾百個虛擬機，如果為每個虛擬機均分配專門的硬件資源，網卡將不堪重負。為此，文獻[43]提出了一種折中的方案 Crossbow。Crossbow采用了硬件和軟件相結合的實現方式，當硬件資源充足時，為每一個VM分配專門的硬件虛擬網卡，而當硬件資源耗盡時，則采用軟件實現虛擬網卡。以上方案雖然無需引起VMM陷入，但主機內VM間流量仍需經網卡進行交換，將引起I/O中斷且占用網卡資源，文獻[44]提出了一種在直接訪問網卡(direct access NIC)上進行VM接入和流量交換的體系結構sNICh。為了減少對主機I/O帶寬的浪費，sNICh對主機內VM間的數據交換采用了直接內存拷貝的方法，降低數據傳輸開銷。但直接訪問網卡僅具有基本的交換機功能，不能實現企業數據中心網絡交換機所需的主要特性，也不能支持大量的VM。為此，sNICh結合了軟硬2種實現方式，采用數據平面和控制平面分離的策略，控制平面由軟件實現，數據平面采用硬件轉發，從而加快處理速度。同時由于控制功能由軟件實現，易于實現如分組過濾、安全檢查等各種控制策略。
總體而言，基于軟件的虛擬交換方式成本低，但對數據分組的處理需要占用大量的 CPU資源，開銷大、性能低。隨著對網絡性能要求的提高，利用外部硬件支持的虛擬化方式成為必然趨勢，但當前的技術發展尚不完善。利用外部交換機的方式能夠對虛擬機實施實時的監控，并進行高級的網絡管理功能，但是占用了大量的 I/O帶寬資源，同時也增加了外部網絡壓力；利用主機網卡進行交換的方式對網卡性能要求高，價格昂貴，且網卡對交換機高級特性的支持有限，削弱了對虛擬機的管理功能。
5.2 數據中心骨干網絡虛擬化技術
為了敘述方便，本文把數據中心內主機內部網絡以外的網絡統稱為數據中心骨干網，簡稱骨干網。傳統條件下，用戶與資源靜態耦合，不同用戶之間的資源互相隔離，不能共享使用，資源使用率低。現代數據中心逐漸從企業獨占向公共云服務轉變[45,46]。云計算一方面要求多個租戶共享使用數據中心網絡資源，運行不同的企業應用，資源以動態、彈性、按需的方式分配和共享使用，并按實際的資源使用情況付費[47]，同時提供各用戶間可靠的安全隔離及不同的QoS保證[48]。用戶可以定制個性化的計算環境，如服務器數量、軟件環境、網絡配置等。資源可以根據需要動態申請，也可以動態回收。如亞馬遜彈性云EC2[49]和安全存儲服務 S3[50]、IBM 藍云[51]等。另一方面又要求底層數據中心網絡基礎設施可虛擬化為統一的虛擬資源池，以便能夠根據用戶需求，靈活地分配資源。按照目標的不同，當前數據中心骨干網虛擬化技術可分為3類。
5.2.1 以資源隔離為目標的虛擬化技術
傳統的數據中心網絡使用劃分VLAN(802.1q)[52]的方式提供對資源隔離的支持，但是這種方法存在缺陷：①為了支持生成樹協議，每個VLAN只能是底層網絡的無環圖，從而限制了二分帶寬；②將所有的地址空間暴露給交換機，導致轉發表過大，不能支持大規模網絡，可擴展性差。為了支持大規模的網絡虛擬化，業界提出了很多改進方案，如QinQ(802.1ad)[53]、MinM(802.1ah)[54]等，其基本思想是將網絡劃分為不同的層次，采用嵌套封裝的方法，由每層的邊緣交換機進行封包和解包，從而極大地減少了上層網絡的地址空間，可以支持更大規模的網絡。但目前QinQ、MinM等并未得到廣泛支持，同時，生成樹協議的單路徑特性也不能充分利用網絡冗余的連通性。為了克服生成樹協議的不足，IEEE 802.1aq工作組提出了最短路徑橋接(SPB,shortest path bridging)[55]協議，SPB支持異構的網絡結構，能夠并發地利用多條最短路徑進行數據傳輸，具有更快的收斂時間和更好的可擴展性，但是SPB仍需使用QinQ或MinM方式進行虛擬網劃分。基于VLAN的虛擬網的劃分方案均是靜態的，每個用戶或每個應用運行在單獨的虛擬網之中，占用固定的資源，為了保證用戶的峰值性能，虛擬網需要預留資源，降低了網絡的效能和靈活性。
為了支持現代數據中心網絡環境下多租戶動態共享的需求，同時提供端到端的帶寬保證，文獻[56]提出了一種多用戶條件下具有帶寬保證的數據中心網絡虛擬化體系結構 SecondNet，其中每個用戶構成一個虛擬數據中心(VDC)，VDC中的每一個虛擬機對之間都有明確的帶寬需求，SecondNet將VDC的分配問題轉化為最小代價網絡流問題，采用集中控制的策略和端口交換的源路由算法，提供虛擬機之間的帶寬保證及高效的網絡資源利用率，但SecondNet需要交換機支持端口交換和高優先級流的搶先調度。通常，用戶對計算和存儲資源的需求可以明確地給出，但是卻難以提出明確的網絡資源需求，對此，文獻[57]提出了一種虛擬網絡抽象方法 Oktopus，明確定義了用戶—提供者之間的網絡資源需求接口，對無阻塞網絡和阻塞網絡，Oktopus分別利用一個二元組
為了實施靈活的虛擬化策略，需要對交換機進行精細的控制，但出于商業機密和安全的考慮，普通商業交換機開放程度限制，影響了虛擬化策略的應用。為此，斯坦福大學的研究人員提出了一種OpenFlow交換機[27]，通過定義標準接口，用戶可對OpenFlow交換機的每條流進行精確的控制，包括轉發路徑、QoS限速以及分組過濾等，通過OpenFlow技術可以很容易地實現虛擬化，并且可以靈活地利用諸如虛擬機的位置等策略進行虛擬網劃分。OpenFlow提出的初衷是為了在校園網上開發大規模的測試床供研究人員進行網絡協議測試，但是由于OpenFlow的靈活性，它也可以應用于數據中心。但就目前而言，OpenFlow還存在一些限制。①性能限制：OpenFlow的控制策略主要由集中控制器負責，在高速網絡中，將給集中控制器帶來巨大壓力，影響數據轉發性能，此外，為了實施精細的控制，如入侵檢測等，若需要執行逐包處理，將嚴重影響OpenFlow的性能。②安全問題：OpenFlow雖然增加了靈活性，但也帶來了安全隱患，由于采用集中的控制方式且用戶可以控制數據轉發策略，一旦集中控制器遭到攻擊或流表被惡意篡改，將可能導致服務中斷或癱瘓。③當前OpenFlow尚未得到主流交換機廠商的廣泛支持。盡管如此，OpenFlow仍引起了學術界和產業界的高度關注，當前已經發展成為一個頗具影響的技術流派，OpenFlow不僅可以用于數據中心網及局域網虛擬化，還可用于廣域網虛擬化，有關OpenFlow的研究已經超出了本文的范圍，在此不再贅述。
5.2.2 以資源整合為目標的虛擬化技術
資源隔離的目的是為了將同一網絡邏輯地分成不同的網絡，以供不同用戶使用。與此相反，資源整合的目標是將邏輯上分離的網絡整合為同一網絡，以增強應用部署的靈活性，如支持虛擬機的自由遷移等。典型的虛擬化方案有VL2、PortLand等。VL2采用名字和位置分離的思想，應用程序使用應用相關地址(AA,aplication-specific address)發送數據，駐留在服務器上的輕量級VL2代理將目標服務器所在ToR的位置相關地址(LA,locationspecific address)作為目的地址封裝到分組內，目的ToR解包并將數據轉發到目標服務器。為了確定目的AA所在ToR對應的LA，VL2采用一個集中的目錄系統維持AA到LA的映射，通過目錄系統可以實現訪問控制，如僅允許相同租戶的應用之間互相訪問。VL2的主要缺點是需要集中的目錄系統，集中控制器可能成為系統性能瓶頸，VL2可以實現不同租戶間的訪問控制，但是，不能實施基于租戶的性能隔離，租戶間競爭共享網絡資源，不能提供帶寬保證等QoS支持，也不支持基于租戶權重分配帶寬資源等公平性策略。PortLand的思想與VL2類似，仍采用名字和位置分離的思想，每一個終端主機都有唯一的偽MAC地址(PMAC， pseudo MAC)，PMAC是位置相關的，網絡上所有的數據轉發均基于 PMAC，集中的網絡控制器負責完成IP地址到PMAC的映射，響應ARP請求，僅在數據分組到達最后一跳時由邊緣交換機完成PMAC地址重寫，使用真實MAC地址(AMAC,actual MAC)將數據最終發送到目標服務器。VL2與PortLand均實現了一個完全的二層網絡抽象，任何應用可以被放在任何服務器上，從而支持服務器池的快速增長和收縮以及任意位置的虛擬機遷移。但是，兩者均需要集中控制器進行地址映射，存在單點失效，且兩者均不支持基于租戶的QoS策略、公平性策略等。為此，文獻[59]提出了一種數據中心網絡虛擬化體系結構NetLord，NetLord對MAC幀格式和IP報文格式進行了重定義，在IP報文的頭部顯式包含了租戶標識(Tenant_ID)，并通過一個常駐hypervisor的輕量級代理負責封包、解包和路由，虛擬機發出的數據分組經代理計算路徑，確定目的邊緣交換機地址后，在原報文的頭部添加一層MAC幀頭，將源邊緣交換機地址和目的邊緣交換機地址封裝在MAC幀中后在二層網絡上傳送，當到達邊緣交換機時，由邊緣交換機去掉幀頭，并根據封裝在分組中的IP地址確定轉發端口，將數據分組傳送到目標代理，目標代理最后將數據轉發到目的虛擬機。NetLord的虛擬化方法帶來了幾大好處：首先是通過重新封包屏蔽了虛擬機的 MAC地址，減少了核心網絡地址空間的規模，使得使用商業以太網交換機即可構建大規模多租戶網絡；其次是提供了一個完全的二層和三層網絡抽象，每一個租戶都有一個完全的二層和三層地址空間；第三，由于分組頭顯式地包含租戶標識，NetLord可以對每個租戶實施單獨的流量管理策略，如增加QoS策略、公平性策略等。但是NetLord需要修改虛擬機管理系統，且額外的分組封裝、解分組可能降低數據處理性能。
5.2.3 以公平共享為目標的虛擬化技術
隨著云計算和虛擬化技術的發展，數據中心網絡在應用模式和資源配置方式上發生了巨大變化。云計算要求數據中心網絡基礎設施作為一種服務供用戶按需申請共享使用，并按資源使用情況付費。這就要求網絡資源應該與用戶付費成比例，即資源共享應滿足某種公平性。與計算資源和存儲資源的使用可以明確的計量不同，網絡資源通常是分布式的，如何保證網絡資源的公平共享成為虛擬化的研究課題之一。文獻[22]提出了一種基于實體（entity）權重公平地共享網絡資源的方法Seawall，每個實體獲得的資源與其權重相關，這里的實體可以是進程或虛擬機。通過合理地分配權重，可以實現對網絡資源高效利用的同時實現某種公平性，但是實體的資源需求通常是動態的，不合理的權重將導致資源閑置。文獻[60]的研究進一步指出，Seawall的分配策略本質上是一種基于源的分配策略，這種策略對源節點的資源分配公平，但卻可能導致對目的節點資源分配的不公平，基于目的節點的分配策略亦如此。為此，文獻[60]總結了公平地共享帶寬資源所需的5個基本原則，如對稱性（symmetry）、獨立性（independence）等，并提出了一種基于源節點和目標節點雙邊權重的資源共享策略PES，通過調節參數，PES能夠實現帶寬保證和公平性之間的某種平衡，但需要修改交換機或虛擬機管理程序（hypervisor）。研究資源共享的公平性問題，不僅可以促進資源更加合理的分配，還可以通過定義網絡資源使用的標準接口，使得網絡資源與計算資源和存儲資源一樣，可以按照使用量進行收費，使得使用者和提供者之間能夠更加清晰地在投入和回報之間做出權衡。但當前對該問題的研究尚少，在實際系統中也未見相關的技術報告，總體而言尚處于起步階段。幾種典型數據中心骨干網虛擬化技術的對比如表3所示。
表3 數據中心骨干網虛擬化技術對比
6 結束語
數據中心網絡的深刻變化，給網絡資源管理帶來諸多挑戰，傳統的資源靜態分配、工作負載靜態管理，應用與基礎設施緊密耦合的網絡管理方式已經不能適應現代數據中心網絡的新要求，亟待研究新的技術和方法加以解決。本文從網絡資源管理的幾個重要方面，包括地址自動配置技術、傳輸控制技術、流量管理技術以及虛擬化管理技術等，對現代數據中心網絡資源管理技術的最新研究成果進行了分析綜述，以期能為數據中心網絡資源管理的研究和系統設計提供借鑒。盡管努力試圖發現各種研究、各類技術之間的關聯，努力分析其優長與特點，但由于有關現代數據中心網絡資源管理的研究正方興未艾，各種觀點、各種技術正處于百家爭鳴的態勢，以當前的認知，有些相關的研究尚難以用統一的標準加以分析比較，筆者將密切跟蹤有關的研究進展，以期能有更加全面深入的了解。就筆者的研究和分析，未來數據中心網絡資源管理將呈現以下趨勢。
1)配置自動化。隨著數據中心網絡規模的不斷擴大，傳統的人工配置方式不僅效率低，而且容易引發錯誤，據統計，50%～80%的網絡宕機都是由于人工配置錯誤引發[61,62]。特別是在云計算環境下，應用需要根據資源需求動態申請和釋放資源，如創建和銷毀虛擬機、配置虛擬網等，人工的配置方式將難以勝任，網絡管理系統將需要根據預先設定的配置策略和配置描述文件，自動完成配置操作，如根據邏輯圖完成邏輯地址到物理地址的映射。
2)管理智能化。數據中心是數據計算和存儲的中心，運行著各種關鍵核心業務，如 Web服務、Map-Reduce集群計算、在線購物等，其通信模式表現為集群通信，即大規模節點之間的通信，對網絡性能要求高，動態性強，傳統的通過VLAN的資源劃分方式導致應用與資源緊密耦合，大量資源被閑置，限制了網絡性能的發揮，資源利用率低。為了充分發揮網絡性能，提高資源利用率，網絡管理系統應具有根據網絡負載和資源使用情況，進行動態資源分配調度、流的動態路徑規劃等能力。
3)接口標準化。企業應用將逐漸向云服務轉變，數據中心網絡資源管理的功能和角色正在發生著深刻的變化。網絡資源管理的作用在于以服務的方式為數據中心網絡應用、數據中心網絡路由、數據中心監控等提供支撐。為使上層應用能在運行時動態申請管理服務，同時能在不同的云服務環境中自由遷移，網絡管理系統需要提供標準的服務接口，如配置接口、資源申請接口、流量監控接口等。
4)基礎設施虛擬化。虛擬化已經成為數據中心網絡的基本特征之一。資源管理系統應提供對虛擬化全方位的支持，如虛擬網的劃分與配置、多租戶的管理與隔離、虛擬資源的感知與控制、虛擬機創建、回收、遷移等，能夠滿足現代數據中心網絡資源動態共享，按需分配的需求。
[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.
