云計算數據中心網絡設計綜述

王斌鋒　蘇金樹,2　陳　琳

1(國防科學技術大學計算機學院　長沙　410073)2　　　(國防科學技術大學并行與分布處理國防重點實驗室　長沙　410073)

?

云計算數據中心網絡設計綜述

王斌鋒1蘇金樹1,2陳琳1

1(國防科學技術大學計算機學院長沙410073)2(國防科學技術大學并行與分布處理國防重點實驗室長沙410073)

(binhai.feng@163.com)

在云計算技術趨勢的影響下，數據中心網絡正發生著深刻的變革，不僅體現在規模、帶寬、多鏈路、擴展性、靈活性的提升和成本的降低上，而且還體現在對虛擬機動態遷移的支持以及網絡虛擬化等方面.圍繞云計算數據中心網絡所面臨的主要挑戰，首先，從交換機為中心和服務器為中心的2個角度分別展開論述了云計算數據中心的網絡體系架構；其次，從網絡資源靈活部署的角度，詳細分析了云計算數據中心虛擬機動態遷移的相關協議與關鍵技術；然后，從虛擬網絡體系架構的角度分析了虛擬化技術在云計算數據中心網絡中的應用；最后預測了云計算數據中心網絡未來的發展趨勢.

數據中心網絡；云計算；網絡體系架構；移動性；虛擬化

云計算作為一種服務提供模型，可以依托網絡實現隨時隨地、按需地訪問數據中心的各種資源，包括計算資源、網絡資源、存儲資源等，且在云計算數據中心內部可以實現不同用戶間資源的動態分配和調整.目前，主要有3種服務模型，分別是IaaS，SaaS，PaaS.與傳統的IT服務模式相比，云計算自誕生以來就具有顯著的特點和巨大的優勢，體現在建設成本、擴展性、可靠性、服務質量以及遠程訪問等方面[1]，因而吸引著學術界和工業界的極大關注.數據中心作為云計算的核心基礎設施，為了更好地承載云計算相關的應用服務，更有利地響應租戶的資源訪問請求，其正經歷著前所未有的變革，帶來發展機遇的同時也帶來了前進的諸多挑戰，主要體現在以下6個方面：

1) 網絡規模日益龐大，存在多種網絡形態

為了提高海量數據的集中處理能力，數據中心網絡規模日益龐大，互連的計算節點數量能達到105以上的量級，而交換節點的數量也接近104量級，如Google在其30多個數據中心中就擁有超過100萬臺服務器，日漸擴大的網絡規模對網絡架構、傳輸協議以及網絡性能管理等都提出了新的設計要求[2].另外，由于數據中心網絡相對封閉、管理較為集中，在實際的部署過程中受不同性能需求的牽引，呈現出多種網絡形態共存的情形，如InfiniBand高速互連存儲網絡、增強以太網及用于高性能計算的專用高速網絡.

2) 流量工程難度大

數據中心網絡流量復雜，難以實現有效地預測與調度，究其原因主要體現在2方面：①由于數據中心網絡流量具有高動態及高突發的特性，如many-to-one通信模式所導致的Incast問題，且這些流量大部分耗時極短、不易檢測[3]；②由于計算密集型應用服務的發展(如MapReduce，Hadoop等應用)，以及虛擬化技術的大范圍引進(如虛擬機在線遷移VMotion等)，致使數據中心網絡“東西流量”占據了總流量的將近80%，給網絡不僅帶來了嚴重的傳輸負載，而且也增加了網絡中流量行為的復雜性.

3) 網絡縱向擴展成本高

當前數據中心所采用的網絡架構大多是單根或多根的樹形層次結構，在網絡規模不斷擴大以及“東西流量”占據總流量比例較高的情況下，為了提高網絡的對分帶寬，保證應用服務的服務質量，數據中心通常需要配置更昂貴更具專業化的轉發硬件或者負載均衡器，這種縱向擴展的模式無疑成本非常高.況且，由于樹形結構的核心鏈路存在收斂比的問題[4]，隨著節點數目的增加，縱向擴展的方式顯得不具有可持續性.

4) 網絡資源利用率低

當多個應用服務同時部署于數據中心時，通常需要對其使用的網絡資源進行相互隔離(如VLAN)，以避免它們之間相互產生干擾.然而，由于傳統通信標識IP地址不但表示了應用服務的位置信息，而且也表示了應用服務的身份信息，這就使得隔離措施很大程度地限制了資源調度的靈活性，致使網絡資源的使用率普遍較低.無論是出于提高數據中心可用網絡容量的考慮，還是為了降低投入產出比，對網絡資源利用率的提高都是很有必要的.

5) 網絡故障率呈上升趨勢

長期的實踐表明，網絡故障率會隨著系統節點數的增加而快速增長.目前，數據中心的網絡故障大體可劃分為4類：軟件故障、硬件故障、網絡配置故障及不明原因的故障[5]，各自所占的比率分別為21%，18%，38%，23%，可以看出，網絡配置故障占據的比例最多，不明原因的故障次之.隨著網絡規模的擴大，節點之間的互連關系變得越來越復雜，致使網絡配置難度增加，局部的配置失誤也可能引起網絡大范圍的失效.另外，當前云計算數據中心網絡趨向于大面積使用成本低廉的商業交換機，而商業交換機的處理能力卻十分有限，在網絡流量高度突發、行為異常復雜的情況下，容易導致原因不明的網絡故障，如交換機突然停止轉發流量.

6) 網絡運維成本高

在云計算技術趨勢的影響下，數據中心的高運維成本主要突顯在3個方面：網絡性能管理、網絡配置和能耗管理.部署于數據中心的應用大多都是在線或者需即時響應的服務，如網絡游戲、電子商務、在線視頻會議等，這些應用或對網絡延遲敏感，或對帶寬的分配敏感，或者對二者都很敏感，因而細粒度地實現對應用服務質量的保證是十分復雜的.網絡配置開銷大的原因有2方面：①由于網絡中基于不同使用需求而部署的傳輸、路由協議比較多樣；②由于當前網絡配置的自動化程度不高，而人工配置的出錯率又較大的緣故.關于數據中心的能耗，IT設備系統約占50%，空調系統約占37%[6]，這二者占據了絕大多數的能耗開支，為了節約能源，綠色數據中心的建設已經逐漸成為關注的焦點.

針對云計算數據中心發展變革所面臨的諸多挑戰，學術界和工業界都積極提出了多種不同的設計方案，并有效地推動了云計算應用服務的飛速發展.通過對這些設計方案的分析與研究，我們認為目前云計算數據中心網絡的研究主要有3方面的挑戰：1)數據中心網絡體系架構的設計；2)云計算數據中心支持虛擬機動態遷移的設計；3)云計算數據中心網絡虛擬化的設計.具體可以描述如下：

1) 高性價比數據中心網絡體系架構的廣泛探究.在云計算環境下，企業為了追求服務可靠、運行簡單、成本合理，往往將自身的數據中心移往云端，致使云計算數據中心規模越來越大.不僅如此，伴隨著應用服務的不斷繁榮發展，數據中心的東西流量比南北流量將近多出3倍，占據著數據中心的絕大多數，改變了傳統的20%～80%原則.為了保證較好的網絡性能，在數據中心網絡體系架構的設計過程中，不僅僅要求有較強的可擴展性，集裝箱式數據中心就是典型的案例[7]，而且要達到較大的網絡帶寬，點與點之間需存在多條通信鏈路.除此之外，還需要考慮建設成本的問題.在上述諸多因素的驅動下，當前云計算數據中心網絡體系架構的研究成果頗豐，依據轉發中心的不同可劃分為兩大類：以交換機為轉發中心的設計和以服務器為轉發中心的設計，各有優缺點，二者都取得了較大發展，且在不斷優化與創新.

2) 對數據中心網絡虛擬機遷移(virtual machine motion, VMotion)支撐技術的研究.快速便捷地實現網絡資源(虛擬機)的靈活部署是云計算數據中心IT管理流程自動化的重要環節.為了克服傳統數據中心網絡中資源(虛擬機)分配不能跨越3層設備的缺陷，云計算數據中心網絡采用了2種解決思路：①設計“大二層”網絡，以擴大虛擬機分配的范圍；②借助隧道技術，使虛擬機的分配能夠在“虛擬2層”中得以進行.通過這些措施，期望實現虛擬機的靈活部署，從而提高網絡資源的利用率.

3) 對數據中心網絡虛擬化技術的積極探索.為了實現云應用服務的性能隔離、靈活管理以及簡易部署等，云計算數據中心大面積多層次引入了虛擬化技術.作為云計算數據中心重要的技術支撐，虛擬化的對象不僅僅包括服務器，還包括網絡(路由器、交換機及鏈路等[8]).網絡虛擬化的發展使得數據中心的整體服務能力得以大幅提升，主要表現為：提高了網絡資源的利用率；增強了應用服務管理的靈活性；改善了應用服務部署的簡易性；可以為不同的應用服務提供流量隔離；由于可以限制網絡故障的影響區域，推動了新網絡協議的測試等.

本文圍繞云計算數據中心網絡所面臨的主要挑戰，從云計算數據中心網絡體系架構、云計算數據中心VMotion支撐和云計算數據中心網絡虛擬化3個方面，針對性地闡述了相關的研究現狀，并討論了其未來的發展趨勢.

1　云計算數據中心網絡體系架構

Fig. 1　Traditional data center network architecture.圖1　傳統數據中心網絡架構

Fig. 2　Three-stage Clos topology.圖2　Clos網絡3層結構

目前針對數據中心網絡體系架構的研究變化多樣，大體上可以劃分為兩大類：以交換機為轉發中心的體系架構和以服務器為轉發中心的體系架構.在數據中心網絡中引入無線技術的設計，從根本上講可以歸類為以交換機為轉發中心的設計類別，但是為了突出其特殊性，本文在1.1.3節專門進行詳細描述.

1.1以交換機為中心的設計方案

在以交換機為轉發中心的網絡架構設計方案中，網絡的連接及流量的路由、轉發等功能全部是由交換機和路由器來完成的，這類設計方式最為直接、簡單，通過優化網絡連接以及路由機制，或者升級交換機的硬件和軟件就能加以實現，代表性的方案有Fat-Tree[10]、Facebook數據中心架構[11]、REWIRE[12]、SPAIN[13]等.為了方便描述，本文依據設計方案的網絡結構是否規則進行了再劃分，并就2個方面典型的設計進行了簡述.

1.1.1規則網絡結構

1) Fat-Tree

Fat-Tree是對傳統樹形層次結構的一個優化，由Al-Fares等人[10]提出，具體如圖3所示，其仍然可分為核心、匯聚和接入3個層次.與傳統樹形層次結構相比，Fat-Tree有3方面的獨特之處：①在網絡中大量采用了統一的廉價的商業交換機作為轉發設備，避免了縱向擴展所帶來的高成本；②由于各個層次都采用了經濟型的商業交換機，為了保證網絡的可靠性，所有的匯聚和接入交換機都被劃分為不同的集群Pod(其中有k2臺匯聚交換機、k2臺接入交換機)，在集群內匯聚和接入交換機之間采用了全相連的方式；③采用多路徑路由技術，為服務器之間的通信提供了較大的對分帶寬.

Fig. 3　The network architecture of Fat-Tree.圖3　Fat-Tree網絡結構

Fig. 4　Two level routing table.圖4　2級路由表

為了在服務器之間實現多路徑的通信，Al-Fares等人主要采取了2方面的措施：①制定了地址分配的具體規則；②建立了2級路由表及相應的路由機制.假設使用10.0.0.08 地址塊對網絡中的所有設備進行地址分配，則集群Pod內交換機的地址形式為10.pod.switch.1，其中pod表示集群號，switch表示交換機在集群中的位置；核心交換機的地址形式為10.k.j.i，其中j和i表示該交換機在(k2)2個核心交換機中的位置；服務器的地址形式為10.pod.switch.ID，其中ID從2開始編號.基于這樣的地址分配，作者建立了2級路由表及相應的路由機制，具體如圖4所示，左端為第1級路由表，右端為第2級路由表.對于不同Pod的終端，該結構提供有k條互不相同的傳輸路徑，主要依賴第2級路由表來完成，能夠實現Pod間流量最大可能地均勻分布于核心交換機之間；對于同一Pod的終端，其路由依賴于第1級路由表中的終結性表項，會將相應的流量從特定的端口轉發出去.

雖然Fat-Tree網絡結構為服務器與服務器之間的通信提供了多條路徑，但是如果網絡流量在多條路徑上分布不均，就會影響鏈路整體的使用效率，特別是對于多播流量.針對這一問題，文獻[4]研究了在保證鏈路收斂比O的情況下核心交換機最少應當部署的數目，并指出通過提高鏈路收斂比來降低數據中心建設成本的方法是存在局限性的，從而為如何低成本高效率地構造多播Fat-Tree結構提供了理論依據.

2) Facebook數據中心架構

對于普通的數據中心而言，網絡的“東西流量”占據著總流量的將近80%，但是，作為社交網絡巨頭的Facebook有著其自身的特殊性，其數據中心網絡的“東西流量”比“南北流量”將超出近1 000多倍[11].在這種情況下，Fat-Tree結構明顯存在較大的局限性：①縱向擴展的成本比較高；②即使部署了很多昂貴的轉發設備，也不一定能有效地支撐這種規模的網絡流量.為了解決網絡較大的對分帶寬需求，Facebook最新建立的數據中心采用了一種新型的網絡結構，具體如圖5所示:

Fig. 5　The data center network of Facebook.圖5　Facebook數據中心網絡

從圖5可以看出，該Facebook網絡結構也是在網絡中全面部署了廉價的架頂交換機，但與Fat-Tree結構不同的是其優化了服務器之間通信的路由機制.在Facebook網絡結構中，集群Pod依然是基本的劃分單位，包括48臺10 GBps帶寬的架頂交換機以及4臺光纖交換機，其中每臺架頂交換機向上以40 GBps的上行鏈路與光纖交換機相連，向下與底層服務器相連.另外，該結構還設計了4個相互獨立的Spine交換機平面(每個平面可以擴展至48臺設備).

為了實現所有服務器的互連互通，集群Pod中的每一臺光纖交換機都會與所在Spine平面的所有設備進行互連.這樣的互連結構一方面滿足了可擴展性強的實際需求，集群Pod和骨干平面Spine Plane組成了一個模塊化的網絡拓撲；另一方面，無論是Pod內的通信還是Pod間的通信，該結構都提供了較多的傳輸路徑，可以實現比較大的網絡對分帶寬，最高可擴展至幾個PB.

該結構實際是傳統樹形層次結構的進一步演化，有2點特征：①注重增大服務器與服務器之間的對分帶寬，通過巧妙的網絡連接減輕了核心交換機的瓶頸限制；②強調模塊化構造數據中心的思想，在云計算環境下數據中心的網絡規模是不斷擴張的，增加Server Pod就可實現擴張數據中心的目的，而增加Spine Plane就可實現增加服務器與服務器通信對分帶寬的目的.

1.1.2非規則網絡結構

除了類似于Fat-Tree，Facebook網絡結構等這樣有組織的、規則的網絡體系架構設計之外，研究者也對數據中心無組織的、非規則的網絡體系架構展開了大量研究，主要為了解決如何在現有數據中心網絡體系架構的基礎上進行擴展以滿足云計算應用服務的部署需求，這種設計方式既避免了對已有資源的浪費又降低了云計算數據中心的建設成本，REWIRE就是其中典型的一例.

REWIRE是針對數據中心網絡架構的設計而提出的一種框架，通過使用相應的優化算法，該框架能夠設計出一種無組織的、非規則的數據中心網絡結構：在滿足用戶自定義約束的同時實現了最大對分帶寬和最小端到端延遲的性能目標.傳統數據中心網絡架構的設計通常采用規則的方式，主要原因在于無規則、任意網絡結構的管理、運行尚存在很多未解決的問題，如路由、負載均衡等.但隨著相關路由、負載均衡等技術的發展，針對無規則、任意網絡結構的高效管理和運行也逐漸變得可行，文獻[13-14]從不同的方面探索了無規則、任意網絡結構部署應用的可行性.

REWIRE框架在進行網絡架構設計時，根據原有網絡是否需要擴展，其優化算法可以有2種不同的輸入：一種是原有的網絡結構；另一種是原有的網絡結構和一些孤立的新的交換機.如果輸入是第1種情況，則REWIRE優化算法具體可以分為4步：①暫不考慮網絡性能，確定滿足用戶自定義約束的網絡結構空間；②隨機選取一候選網絡結構作為初始值，并評估其網絡性能；③執行local search操作，通過修改前一候選網絡結構的本地屬性值，轉向另一更符合需求的候選網絡結構；④循環步驟③，直至找到近似最優的網絡結構.在整個過程中，該算法只是優化網絡結構的互連關系，并不向網絡中增加新的交換機.如果輸入是第2種情況，則首先通過任意連線使原有網絡結構和所有孤立的新的交換機之間變得連通，然后按照第1種輸入情況的處理方式進行網絡結構的設計.

通過比較驗證，基于REWIRE框架設計出的無規則網絡結構具有較優異的網絡性能，但是也存在著缺陷與不足，比如在原有網絡基礎上進行擴展設計時該方法需要一一考慮所有新增交換機的組合，導致設計效率隨著新增交換機數量的增長而變低.

1.1.3采用無線技術的網絡結構

隨著網絡規模的不斷擴大、應用服務帶寬需求的逐步提高，傳統數據中心網絡所采用的有線靜態鏈路連接方式面臨著巨大挑戰：1)網絡規模越大，每個服務器平均對應的數據鏈路就會越多，直接導致管理運營成本的增加；2)由于每個rack的實際帶寬需求難以預先估計，鏈路的分配通常只能按照等量的原則來進行，但這樣無法有效應對網絡中的突發流量；3)有線網絡鏈路的改動成本高，而無線通信技術的快速發展為這些問題的有效解決提供了新思路.將無線通信技術引入到數據中心的構建中，不僅可以減小實際布線的復雜度、降低建設與運營管理的成本，而且可大幅提高數據中心的網絡性能.目前，針對該問題的研究主要集中在2方面：一是發展無線鏈路技術，如radio-frequency[15]，3D-beamforming[16]，steered-beamforming[17]，Free-Space Optics[18]等；二是探索無線數據中心構建，如Flyway[19]、FireFly[20]、全無線數據中心等[21].以下對這2方面分別進行了描述：

1) 無線鏈路技術

文獻[22]首次提出將60 GHz無線通信技術應用到數據中心網絡中，旨在提高網絡的對分帶寬、減小鏈路發生擁塞的概率.選擇使用60 GHz射頻，主要原因有2點：①60 GHz頻段有著接近7 GHz寬的可用頻譜，使其能夠提供Gbps量級速度的多條鏈路；②60 GHz頻段擁有抗干擾、防監聽的雙重技術優勢.然而，60 GHz無線通信技術也存在先天性的不足[23]：無線信號強度會隨著距離的增加而迅速減小，覆蓋半徑極其有限；在距離較遠處，多路效應會對信號的變動產生較大影響.為了提高無線信號的傳輸強度，在實際部署過程中研究人員對60 GHz射頻的傳播進行了改進，采用了有向天線技術，該技術可以隔離不同的無線鏈接使信號浮動大幅減小.

為了優化數據中心中的無線鏈路，除了采用有向天線技術，波束成形和波束轉向等技術也得到了普遍應用，3D-beamforming就是其中典型的一例，具體如圖6所示.3D-beamforming技術比較于普通的波束成形技術，主要有2方面的改進：一是rack之間的通信路徑采用了反射的點到點形式而沒有使用直接的視線鏈路，避免了鏈路易受小障礙物阻塞的問題；二是減小了波束之間潛在的相互干擾，拓寬了每條鏈路的有效范圍.

Fig. 6　The schematic diagram of 3D-beamforming.圖6　3D-beamforming示意圖

FSO(free-space optical communication)是研究者優化rack之間通信的另一項重要技術，相比于3D-beamforming，由于該技術使用可調制的可見或者紅外光束在自由空間傳輸，因而能夠在更大范圍內實現數據的高速傳輸，同時避免信號之間的相互干擾[24].

2) 無線數據中心構建

依據無線通信技術在數據中心中的普及程度，目前可將無線數據中心的構建劃分為兩大類：①在局部范圍內應用無線技術；②在全網范圍內應用無線技術.

Flyway是由美國微軟研究院提出的將無線通信技術引入數據中心的著名設計方案，旨在解決網絡中部分節點過熱的問題，主要思路是在過熱的交換機之間添加新的鏈路、分攤網絡流量、實現緩解網絡擁塞、提高數據中心整體性能的目的.如何在保證網絡性能的同時實現建設成本的降低，一直以來是數據中心設計的難點，FireFly設計方案通過引入無線技術在這方面做出了積極探索，其數據中心的構建主要有以下3個突出特征：①rack間的所有鏈路都是無線鏈路；②rack間的所有鏈路都可配置，靈活性高；③網絡中只存在架頂交換機，不存在匯聚、核心交換機.另外，通過采用自由空間光通信FSO技術以及天花板反射的相關原理[25]，FireFly單跳就可實現任意2臺rack之間的通信，極大地縮小了端到端的通信延遲，從而提高了網絡的整體性能.

除在數據中心中部分應用無線技術之外，完全采用無線連接方式在理論和邏輯上也是可行的.基于這種思想，來自美國康奈爾大學和微軟的研究團隊提出了一種全無線數據中心結構.考慮到無線鏈路有限的傳播半徑，以及為端到端提供多條冗余鏈接的需要，該結構采用了圓柱形的機架組織方式，具體如圖7所示.可以看出，環形排列的所有服務器形成了一緊密的連接網，相比于傳統有線數據中心，其端到端的平均延遲將會顯著減少，總帶寬將會更大.另外，由于無線鏈接自身的靈活性，全無線數據中心將會有更強的容錯能力.

Fig. 7　The wholly wireless data center architecture.圖7　全無線數據中心結構

1.2以服務器為中心的設計方案

除了上述以交換機為轉發中心的網絡架構設計，以服務器為轉發中心的網絡架構設計也是一個研究熱點.根據設計過程中所使用服務器的端口數目，該研究又可以被分為兩大類：以多端口的服務器為轉發中心和以雙端口的服務器為轉發中心.

1.2.1以多端口為轉發中心的網絡結構

DCell[26]、BCube[27]、雪花結構[28]、文獻[29]都是以多端口的服務器為設計出發點，分別提出了具有擴展性強、對分帶寬大等特性的不同新型網絡體系架構，滿足了云計算數據中心網絡越來越多應用服務的部署需求.

1) DCell網絡結構

考慮到樹形層次結構的缺陷與不足，DCell以一種完全不同的設計方式(以服務器為轉發中心)進行網絡結構的構造，如圖8所示為DCell1的網絡結構.

Fig. 8　The data center architecture of DCell1.圖8　DCell1網絡結構

2)BCube網絡結構

同DCell類似，BCube網絡結構也采用遞歸的定義方式，如圖9所示為Level1BCube網絡結構.

LevelkBCube網絡結構由nk個小交換機和n個Levelk-1BCube網絡結構組成，其中每個交換機與每個Levelk-1BCube都有連接，并且第i個交換機只連接每個Levelk-1BCube的第i個服務器.通過這種構造方式，BCube網絡也能夠提供較好的可擴展性以及較高的網絡對分帶寬.

Fig. 9　The data center architecture of level1 BCube.圖9　Level1 BCube網絡結構

在BCube網絡中，任意2臺服務器之間存在k+1條并行的通信路徑.BCube網絡使用k+1維行向量對所屬的服務器進行標識，如服務器A可被表示為akak-1…a0，其中ai表示A在LeveliBCube網絡結構中的坐標.基于服務器的標識方法，這k+1條并行通信鏈路可理解為由2部分組成：①只考慮通信兩端服務器標識中對應維相同的部分，計算通信路徑；②只考慮通信兩端服務器標識中對應維不相同的部分，計算通信路徑.以Level1BCube為例，假設A=00，B=30，如果只考慮ai=bi，則A到B的路徑為00→01→31→30；如果只考慮ai≠bi，則A到B的路徑為00→30，即Level1BCube為服務器A與B提供了2條通信路徑.BCube網絡中服務器之間的多路徑為網絡流量的負載均衡提供了有效的支撐機制，緩解了網絡擁塞的發生，從而保證了應用服務的性能質量.

3) 雪花結構

雪花結構同樣采用遞歸定義的方式，n級雪花結構可通過在n-1級雪花結構上添加若干個0級雪花結構來實現.0級雪花結構由一個微型交換機和k個服務器組成，k通常取為3～8，如圖10(a)所示為0級雪花結構.

Fig. 10　The snowflake architecture.圖10　雪花結構

在雪花結構的具體構造過程中，有2個比較重要的概念：虛連接和實連接.在圖10(a)的0級雪花結構中有3條服務器之間連接的虛線，這3條虛線就是所謂的虛連接，虛連接實際并不存在.相對于虛連接，實連接是真實存在的連線，當雪花結構進行擴展時，斷開虛連接并添加0級雪花結構，所形成的2條虛線都連往新添0級雪花結構的交換機，由這2條虛線所形成的網絡鏈接稱為實連接.如圖10(b)所示為由0級雪花結構擴展成的1級雪花結構，可以發現圖10(a)中有3條虛連接和0條實連接，圖10(b)中有6條虛連接和6條實連接.當雪花結構向更高等級擴展時，需斷開每一處虛連接和實連接，然后按照規則再添加0級雪花結構.

可以驗證，n級雪花結構包含的服務器數目為k×(k+1)n，即該結構服務器的數量會隨著n值的增加而呈指數次方不斷增長，滿足了云計算數據中心對大規模網絡的需求.另外，當k取3～8時，n級雪花結構任意2臺服務器之間的最短路徑將不超過2n+1跳，而且它們之間存在至少2條、至多22n條并行路徑，既保證了網絡具有較小的網絡直徑，也保證了服務器之間較大的網絡對分帶寬.

1.2.2以雙端口為轉發中心的網絡結構

雖然以多端口為轉發中心的網絡架構設計方案具有很好的網絡屬性，如可擴展性強、對分帶寬大等，但是大量多端口服務器的構造需要額外添加不少硬件，相對于雙端口服務器而言，不具有普遍性而且成本比較高.針對這些問題，研究者對基于雙端口服務器網絡架構的設計展開了積極探索，目前具有代表性的方案有DPillar[30]，HCN[31]，BCN[31]，SWCube[32]，SWKautz[32]，FiConn[33]等.

1) DPillar網絡結構

相比于傳統數據中心網絡架構的設計，DPillar網絡結構的構造有2方面的優勢：①大量采用了商用的2層交換機，容易獲取且價格相對低廉；②使用雙端口的服務器作為轉發中心，而現有的商業服務器本身就擁有2個萬兆以太網端口，因而DPillar結構以很小的部署代價就可以實現網絡的大規模擴展.

盡管使用的服務器僅僅只有2個端口，DPillar結構卻為服務器之間的通信提供了富余的鏈路，有效地支撐了帶寬密集型應用服務的部署.在DPillar網絡的構造過程中，服務器和交換機會被分別劃分為k列，并以特定的連接規則進行互連，因而使用(n,k)就可以對DPillar網絡進行唯一地標識，其中n表示交換機的端口數.

假設k列服務器分別記為H0～Hk-1，k列交換機分別記為S0～Sk-1，DPillar(n,k)網絡將k列服務器和k列交換機交替排列形成環狀結構，具體如圖11所示，其中服務器每列有(n2)k臺，交換機每列有(n2)k-1臺.對于Hi中的每一臺服務器，其一個端口連接Si列的交換機，一個端口連接S(i+k-1)%k列的交換機；對于Si列的每一臺交換機，其n2的端口連接Hi列的n2臺服務器，另外n2端口連接H(i+1)%k列的n2臺服務器.

Fig. 11　The architecture of DPillar(n,k).圖11　DPillar(n,k)網絡結構

Fig. 12　The 2D-View of the DPillar(8,2) architecture.圖12　DPillar(8,2)網絡結構的2維視圖

在DPillar(n,k)網絡中，每一臺服務器都可以使用(C,Vk-1…V0)序列進行唯一地標識，其中C表示該服務器位于Hc列，Vk-1…V0表示該服務器在Hc列的坐標位置.基于服務器的標識(C,Vk-1…V0)，DPillar網絡的具體互連關系可以進行如下描述：將Hc列和H(c+1)%k列的2(n2)k臺服務器劃分成(n2)k-1組，設服務器的標識為(C,Vk-1…Vc…V0)，在不考慮Vc位的情況下，每組n臺服務器的其他位都相同；對于劃分的每一組，其n臺服務器都連接于Sc列的同一交換機.如圖12所示為DPillar(8,2)網絡結構的2維視圖.

DPillar(n,k)網絡包含的服務器數量為k(n2)k，且對分帶寬可以達到(n2)k，以n=48，k=5為例，其支持的服務器就多達4×106多臺，表明了DPillar網絡能夠實現大規模擴展且可以提供較高的對分帶寬.除此之外，由于網絡結構的對稱性，DPillar可以為服務器之間的通信提供簡單高效的路由機制.對于任意一對服務器，假設源為(Cs,Ls)，目的為(Cd,Ld)，二者之間的通信可以被分為2個階段：helix階段和ring階段.在helix階段，數據包從源(Cs,Ls)轉發至中間節點(Ci,Ld)，之間最多有k跳；在ring階段，數據包從中間節點(Ci,Ld)轉發至目的(Cd,Ld)，之間最多有k2跳.

2) HCN和BCN網絡結構

HCN和BCN網絡結構以雙端口的服務器為轉發中心，二者都實現了較小的網絡直徑和較高的對分帶寬.其中，HCN網絡規則化程度高、對稱性好且可擴展性較強，適合于模塊化數據中心的設計；BCN網絡可以為節點之間的通信提供多條互不相交的路徑，具有較好的容錯能力，而且在節點度為2、網絡直徑為7的情況下，BCN是目前規模最大的網絡結構.

HCN網絡結構采用了遞歸的定義方式，即HCN(n,h)結構由多個下一級HCN(n,h-1)結構組成，其中n表示交換機的端口數目，h和h-1表示HCN結構的等級.HCN(n,0)是HCN網絡結構的基本構造單元，由1臺交換機和n臺雙端口服務器組成.對于HCN(n,h)結構的具體構建過程，可以進行如下簡單描述：由n個HCN(n,h-1)結構組成，且每個HCN(n,h-1)結構通過全相連的方式與其他n-1個同等級的結構相連，由于每個HCN(n,h-1)結構有n個可用的服務器端口，則不同HCN(n,h-1)結構互連之后所構建的HCN(n,h)網絡仍然有n個可用的服務器端口用于進一步擴展，如圖13為HCN(4,2)網絡結構.

Fig. 13　The architecture of HCN(4,2).圖13　HCN(4,2)網絡結構

Fig.14　The architecture of BCN(4,4,1,0).圖14　BCN(4,4,1,0)網絡結構

HCN網絡結構雖然具有很好的網絡屬性，但就對分帶寬而言，其仍然存在局限性.通過對HCN網絡結構的優化與改進，研究者提出了一種2維分層的BCN網絡結構，該結構同樣采用遞歸的定義方法.BCN(α,β,0)是BCN網絡結構的基本構造單元，由一臺n端口的交換機、α臺主服務器和β臺從服務器組成，其中α+β=n.BCN網絡結構分為2個維度進行擴展：第1維度使用主服務器進行擴展；第2維度使用從服務器進行擴展.第1維度的擴展與HCN結構的擴展類似，而且每一級的BCN(α,β,i)結構都存在α個可用端口用于下一級的擴展.假設第2維度擴展的基本構造單元為BCN(α,β,γ)(該結構含αγβ臺從服務器)，使用αγβ+1個BCN(α,β,γ)結構進行全相連.根據上述構造過程，可以看出BCN網絡在第1維度尚可擴展，在第2維度已經不能擴展.記2維分層的BCN網絡為BCN(α,β,h,γ)，其中h表示BCN網絡在第1維度擴展到了h級，γ表示BCN網絡在第2維度的基本構造單元為BCN(α,β,γ).如果h<γ，則需先將第1維度擴展到γ級才可進行第2維度的擴展；如果h>γ，由于BCN(α,β,h)網絡中會有αh-r個BCN(α,β,γ)結構，為了避免第2維度互連所使用的BCN(α,β,γ)成為性能瓶頸，對αh-r個BCN(α,β,γ)結構進行編號，同編號的BCN(α,β,γ)在第2維度都進行全相連.如圖14為BCN(4,4,1,0)網絡結構，其中黑色圓圈代表主服務器，白色圓圈代表從服務器.

相比于HCN網絡，BCN(α,β,h,γ)網絡在任意服務器之間都提供有α-1條并行通信鏈路，無論h大于還是小于γ，都有效地提高了網絡的對分帶寬.此外，BCN(α,β,h,γ)網絡具有較小的網絡直徑，在h<γ時最多為2γ+2h-1，其中h和γ都是很小的整數.

3) SWCube和SWKautz網絡結構

BCN和DPillar網絡結構都具有較強的可擴展能力，但是在給定條件下，如網絡直徑或者交換機的端口數目取恒定值，其所容納的服務器數量遠遠沒有達到理論的上限值[34].在給定網絡直徑長度d和交換機端口數目n的情況下，如何進行網絡架構的設計才能覆蓋更多的雙端口服務器，針對這一問題，研究者提出了2種新穎的網絡架構SWCube和SWKautz.

SWCube網絡結構的設計以Hypercube為基礎，具體的構造可描述如下：①將Hypercube結構中的節點替換成交換機；②在交換機與交換機之間插入服務器.假定記SWCube網絡結構為SWCube(r,k)，其中k表示Hypercube的維數，r表示Hyper-cube每一維的基數，如圖15所示分別為SWCube(4,1)和SWCube(4,2)網絡結構.可以證明，在網絡直徑d和交換機端口數目n確定的情況下，SWCube(r,k)網絡結構所包含的服務器數量可達到n(n(d-1)+1)d-12.當取n=16，k=8時，服務器的數量就可達52 488臺之多.

Fig. 15　The SWCube architecture.圖15　SWCube結構

SWKautz網絡結構的設計以Kautz graph為基礎，具體的構造可描述如下：①將KA(n2,k)圖中的每一個節點都替換成n端口的交換機；②去除交換機與交換機之間鏈路的方向；③在2交換機之間插入一雙端口的服務器.假定記SWKautz網絡結構為SWKautz (r,k)，其中k表示Kautz graph的維數，r表示Kautz graph節點標識的每一位取值空間的大小，如圖16為KA(2,3)和SWKautz (2,3)結構.

Fig. 16　KA(2,3) and SWKautz(2,3).圖16　KA(2,3)和SWKautz(2,3)網絡結構

可以證明，SWKautz(n2,k)網絡的網絡直徑為k+1，并且在網絡直徑為d、交換機端口數目為n的情況下，其可支持的服務器數量為(n2)d+(n2)d-1=(n2)k+(n2)k+1，如n=16，k=5時，服務器的數量多達30萬臺左右，體現了該結構具有較強的可擴展性.

綜合以上關于云計算數據中心網絡結構設計的概述，表1就多個不同指標對其進行了對比分析.可以看出，以服務器為中心的設計方案相比于以交換機為中心的設計方案，在網絡規模、帶寬、擴展性、靈活性等方面可以實現較好的性能，特別是以雙端口服務器為中心的設計方案；在布線復雜性和成本方面，無線的設計方案顯得更優，而以多端口服務器為中心的設計方案雖然布線復雜性優于以雙端口為中心的設計，但是后者在成本方面卻略勝一籌；由于以服務器為中心的設計方案不同于傳統的設計模式，地址、路由等都不同，因而配置開銷比較高.

Table1　Comparison of Data Center Network Architecture for Cloud Computing

Continued (Table1)

2　云計算數據中心VMotion的支撐

在云計算環境下，數據中心基礎設施提供商InP響應來自服務提供者SP的應用資源請求.對于InP而言，一方面需要滿足SP所請求的應用資源，另一方面需要保證自身計算資源(CPU、存儲、網絡等等)的高利用率，這就要求云計算數據中心對計算資源的調度要有足夠的靈活性，而這種靈活性很大程度上體現在虛擬機(virtual machine, VM)的動態遷移.但是，由于傳統通信實體標識IP地址同時綁定了應用服務的位置信息和身份信息，如果一臺VM發生漂移，那么對IP地址的處理將會變得很復雜.如果修改IP地址，其所代表的應用服務身份信息將會改變，需要重新對其進行識別；如果不修改IP地址，該VM在新的網段內將無法正常通信.針對如何實現VM的靈活遷移，目前的研究思路主要有2類：1)改進傳統的2層網絡，研究可以支持更大規模服務器通信的云2層網絡；2)在不改變現有2層網絡通信機制的情況下，研究如何跨越3層交換機或路由器來實現VM的遷移.

2.1“大二層”網絡體系架構

考慮到VLAN對網絡資源的隔離以及傳統通信實體標識IP地址對身份信息與位置信息的同時綁定，解決“VM遷移”最直接的思路就是擴大2層網絡.但是，無論從2層生成樹協議STP的缺陷來講，還是從2層交換機轉發表自學習不利于擴展的角度來討論，對傳統2層網絡不能僅僅是簡單地擴大即可，而需要對原有的通信體制進行優化改進，使其滿足云計算環境下的資源遷移需求.依據其所依賴的具體實現技術，“大二層”網絡可劃分為3類：1)基于位置身份相分離技術的“大二層”網絡；2)基于改進2層控制平面方法的“大二層”網絡；3)基于VPN隧道的跨數據中心“大二層”網絡.

為了實現靈活、可擴展性強的數據中心網絡，VL2[35]破除了傳統IP地址對身份和位置信息的綁定，設計了2套地址族，分別為AA(application address)和LA(locator address)，其中AA不再有拓撲含義，僅僅作為名字使用，而LA僅用于數據包的路由.在源站點處，數據包添加AA地址后被發往源架頂交換機；由源架頂交換機查詢LA，并依據LA發往目標架頂交換機；目標架頂交換機去除數據包外層的LA，基于AA最終發往目標站點.很顯然，AA-LA映射關系在數據包的傳輸過程中起著重要的樞紐作用，因而，學習、維護有效的AA-LA映射關系十分關鍵.在VL2網絡中，AA-LA間的映射關系由一可擴展的、可靠的目錄服務系統來維持，具體如圖17所示.該目錄服務系統使用了2級層次結構，第1級處理讀優先的查詢操作，包括2步：請求查詢和回復；第2級處理寫優先的更新操作，包括6步：請求更新、轉發更新請求到RSM(replicated state machine)、RSM間信息同步、RSM返回確認、DS(directory server)返回確認和DS間分發更新后的AA-LA映射關系.

Fig. 17　The VL2 directory service system.圖17　VL2目錄服務系統

不同于VL2，PortLand[36]雖然采用的依然是位置信息和身份信息相分離的設計思路，但并沒有使用2套地址族，而是將表征位置信息的地址族使用偽MAC地址PMAC進行取代.對于網絡中的每一臺主機，PortLand都會為其分配唯一的PMAC，該PMAC包含了主機在網絡中的位置信息.為了實現基于PMAC的網絡通信，主機在獲取PMAC的同時會生成MAC-IP-PMAC三者的映射關系，并將該映射關系發往網絡的集中管理器Fabric Manager(負責管理和維護全網的MAC-IP-PMAC映射).當數據包發向網絡時，源交換機通過查詢Fabric Manager，將數據包的源MAC和目的MAC改寫為源PMAC和目的PMAC，并基于PMAC進行數據包的轉發，到達目標交換機后再進行PMAC向MAC的轉換.

VL2和PortLand都是依賴于集中式方法來管理身份信息和位置信息之間的映射關系，在網絡規模逐漸擴大的情況下，這種方式使用十分受限.LISP[37]同樣是基于位置身份分離技術來研究“大二層”網絡的，其2類地址信息可描述為：表明位置的路由標識符RLOCs(routing locators)和表明身份的節點標識符EIDs(endpoint identifiers).為了在新地址機制下完成通信，LISP為網絡中的每一個站點都分配有獨立的EID，并引入了2種新的網元：ITR(ingress tunnel router)和ETR(egress tunnel router)，二者部署在LISP網絡的邊界.站點數據包的轉發采取的是Map-and-Encap機制，并由ITRETR完成EID與RLOCs映射關系的轉換.為了在大規模網絡環境下高效地實現EID與RLOCs之間的映射，LISP引入了LISP-ALT(LISP alternative topology)概念，即架構于基礎網絡之上的LISP覆蓋網.該覆蓋網包含網絡中所有的ITR和ETR，并通過在這些節點之間運行BGP協議，實現EID可達信息的交換，最終建立全網的EID-RLOCs映射關系表，該方式較VL2和PortLand的集中管理方式更具可擴展性.

2.1.2改進2層控制平面

針對2層網絡的廣播風暴、網絡環路以及交換機緩存小等傳統問題，研究者將3層路由技術引入2層網絡，期望通過改進控制平面實現2層網絡的多鏈路負載均衡、快速收斂及高可擴展性等特點，并最終達到擴張的目的.

Monsoon[38]網絡架構為了避免內部服務器資源被分離以及鏈路存在收斂比等情況，將網絡中的所有服務器連接于同一個2層域中.Monsoon強化了控制平面的作用，在禁用ARP、自學習算法的基礎上，建立了維護IP-MAC映射關系的目錄服務系統.初始情況下，Monsoon由每臺架頂交換機維護著其自身所連主機的IP-MAC映射關系；隨后，通過運行鏈路狀態協議LSA實現所有架頂交換機IP-MAC映射信息相互之間的交換，從而建立起全局的IP-MAC映射目錄服務系統.Victor[39]體系架構同樣采用此種設計思路實現了VM在不同網絡之間的靈活遷移.Monsoon架構通過優化IP-MAC的學習方式，可以實現更大規模的2層網絡，但是由于網絡設備的MAC地址無規律可循，導致運行鏈路狀態協議所學到的路徑并非最優，而且將其調整成最優的代價很大.

FabricPath[40]是Cisco針對“大二層”環境所設計的一個技術方案，與Monsoon相比，其主要的改進表現在新定義了全新的地址空間：switch ID.對于FabricPath網絡中的每一臺設備，其在初始接入時都會被分配唯一的switch ID，用于網絡設備身份的標識，也作為數據包路由尋址的依據.當數據包發送到FabricPath網關時，原數據幀會被添加新的幀頭，該新幀頭除包括源、目的switch ID外，還包括TTL值.TTL字段類似于IP包頭的TTL，其作用是為了防止數據幀在網絡中被無限次的轉發.如圖18所示為FabricPath的組網圖.類似于Monsoon不依賴于MAC地址進行尋址，FabricPath網絡也通過運行鏈路狀態協議(IS-IS協議)，為網絡設備建立全網拓撲圖，以計算最優路徑來進行數據包的轉發.此處，IS-IS協議使用的路由地址為switch ID，其比MAC地址更有規律性，從而降低了節點之間最優路徑選擇的復雜度.新的地址空間加上IS-IS協議，FabricPath為2層網絡建立起了擁有更多功能特征的控制平面，可以有效地實現多鏈路負載均衡和較強的可擴展性.雖然維護簡單且性能優越，但由于FabricPath定義了新的地址空間和幀頭，而傳統設備并不支持這些功能，因此為了部署Fabric-Path就需要額外購置新的硬件設備，成本較高.

Fig. 18　The FabricPath network.圖18　FabricPath組網

同Monsoon，FabricPath一樣，SPB[41](shortest path bridging)也是瞄準未來2層網絡發展而研發的新技術.在控制平面，SPB依然采用IS-IS協議來保證節點之間數據傳輸的最優路徑.但是，在數據平面SPB并沒有設計新的幀頭結構，而是采用了復用現有以太網技術的2種轉發策略：基于VID的最短橋接路徑(shortest path bridging VID, SPBV)和基于MAC的最短橋接路徑(shortest path bridging MAC, SPBM)，這樣就無需破壞現有以太網幀結構，對于網絡設備而言，理論上只需升級軟件即可，部署成本較低.

2.1.3跨數據中心的“大二層”互連

在云計算環境下，資源的靈活分配不僅僅局限于數據中心內部，在數據中心之間也存在這種需求，這就要求2層網絡能夠跨廣域網進行延伸.

虛擬私有網絡服務(virtual private LAN service, VPLS)[42]搭建于MPLS核心網之上，并基于隧道技術實現了2層網絡的跨域延伸.在VPLS網絡中，主要包含有3類設備：CE(customer edge)設備、PE(provider edge)設備和P(provider)設備，其中PE設備為核心，一方面要負責MPLS隧道的建立，另一方面又要負責MAC地址學習.VPLS網絡的基礎為MPLS的Full Mesh連接，因為數據包的轉發依賴于MPLS所提供的交換能力.在Full Mesh之上，VPLS利用偽連接PW(pseudo wire)建立起了PE之間的鄰接關系，從而形成了覆蓋所有PE的VPN網絡.為了實現2層數據的轉發，每個PE都保存著一個VPLS實例，該實例記錄了同屬于一個局域網的所有PE節點，并維護了相對應的所有MAC地址信息.正是PE設備對PW鄰居關系的維護以及整個局域網MAC地址的記錄，使VPLS得以為不同地理位置的節點提供跨廣域網的2層互連.但是，VPLS只考慮了以太網的擴張，并沒有對廣播風暴、網絡環路等傳統以太網問題進行優化，這將會造成廣域網鏈路資源的極大浪費.

上層傳輸虛擬化(overlay transport virtuali-zation, OTV)[43]針對VPLS缺乏對以太網進行優化的不足，通過進一步強化2層網絡的“控制平面”，同時減弱對“數據平面”的要求，在優化以太網、增加靈活性的基礎上實現了2層網絡的擴張.在數據平面，OTV簡化了數據幀對傳輸鏈路的要求，即由本地發往廣域網的數據幀只進行UDP封裝即可，從而使其應用范圍更加廣泛.在控制平面，OTV基于IS-IS協議對MAC進行尋址，避免了使用ARP所造成的廣播風暴等，另外，依據廣域網是否支持組播，OTV將控制平面的報文交互機制設置為2種：基于組播的信息同步和無組播環境下基于鄰接服務器的信息同步，以提高MAC地址表同步的效率.

VPLS和OTV都實現了2層網絡的跨域延伸，且OTV對延伸后的2層網絡進行了優化，但考慮到廣域網的流量負載均衡、技術的開放性和成熟程度以及運維管理的成本等，跨數據中心的2層互連還值得進一步研究.

2.2跨越3層的網絡體系架構

在云計算環境下，為了實現如“VM遷移”等網絡資源的靈活分配，除了針對扁平化的“大二層”網絡進行研究外，探索跨越3層的資源遷移方式也是另一種思路，典型的代表有VXLAN[44]，NVGRE[45]等.

VXLAN有2個設計目標：一是破除虛擬化部署對廣泛2層網絡的要求；二是克服VLAN缺陷，并對2層標簽技術進行徹底改革，為此，其主要有3方面的改進工作：

1) VXLAN的數據平面

為了跨越3層網絡，VXLAN采用了隧道機制，在現有網絡之上搭建了一疊加網絡.在這種機制下，數據包的轉發過程可以描述為：首先，VXLAN在網絡中定義了VTEP(VXLAN tunnel end point)實體；其次，由該實體對虛擬機產生的數據包添加VXLAN包頭(UDP包頭)；在疊加網中，數據包依據VXLAN包頭進行轉發，不再依賴虛擬機本身的MAC地址和VLAN信息.基于隧道機制有2點好處：一是減小了對現網的改動，只需在需要通信的鏈路兩端部署一對封裝設備即可，不需要改動中間設備；二是能夠支持網絡的快速變更，隧道在建立和拆除時都不會對其他網絡鏈路造成影響.

2) 定義了新的包頭

VXLAN包頭如圖19所示，從外到內依次包括了兩端通信實體VTEP的MAC地址、IP地址以及VXLAN標簽.VXLAN標簽的功能類似于VLAN標簽，只不過VXLAN可以表示更多網段，其使用24 b的VNI(VXLAN network identifier)來標識網段，只有具有相同VNI的虛擬機才可以互相通信.

Fig. 19　The structure of VXLAN frame.圖19　VXLAN幀結構

3) VXLAN的控制平面

由于采用了隧道機制，VXLAN控制平面的一項主要工作是記錄虛擬機、VNI以及VTEP的對應關系.通過這些對應關系，到達VTEP的數據包就能夠準確地找到虛擬機的位置.對于不認識的MAC地址，VXLAN控制平面依靠類似廣播的行為來獲取路徑信息，所謂類似廣播的行為是VXLAN對傳統廣播行為的一個改進，具體描述為：VXLAN選擇使用IP組播來承載2層的廣播流量，所有的VTEP都會被加入到一個特定的IGMP組播組，這樣ARP請求等廣播報文就會被局限在組播范圍內，并不會影響到其他不相關的網絡設備，從而提高了鏈路的使用效率，避免了網絡擁塞的發生.

NVGRE是Microsoft提出的研究方案，與VXLAN實現了類似的功能，與其不同之處在于NVGRE采用了GRE技術來搭建隧道，由于許多交換機芯片都支持GRE隧道功能，這就很便于NVGRE的普及.但NVGRE未在添加的NVGRE包頭中包含原始2層幀頭的Hash結果，就沒有能夠同VXLAN一樣提供多條路徑上的負載均衡.

對云計算數據中心VMotion支撐技術的研究，極大地促進了網絡資源的靈活部署，使得對底層物理網絡的利用變得更加充分.

表2對VMotion相關支撐技術的優缺點進行了比較分析，表明“大二層”網絡并非虛擬化軟件部署的必要條件，同時也顯示了VMotion支撐技術的發展有強化控制平面功能、保留或弱化數據平面功能的趨勢.

Table 2　Comparison of the Supporting Technologies Concerning VMotion of Data Center for Cloud Computing

3　云計算數據中心網絡虛擬化

“虛擬化”是云計算數據中心的一大重要特征，通過引入虛擬化，可以極大提高數據中心的資源利用率，并確保更多用戶獲取質量更優的應用服務.在云計算環境下，虛擬化的對象不僅僅局限于服務器，交換機、路由器、網絡鏈路等網絡元素都屬于可虛擬化的范疇.從不同的角度講，云計算數據中心網絡虛擬化往往實現著不同的目標[46-54]，云租戶期望實現對其所部署應用服務質量的保證；而云基礎設施提供商期望能夠提高物理數據中心的承載比，即同一底層物理網絡承載更多的虛擬數據中心，從而增加經濟收益，具體如圖20所示.為了在有限的物理基礎設施之上承載更多的VDC，并高可靠地滿足應用服務對網絡性能的多種需求，對云計算數據中心網絡虛擬化的研究具有十分重要的意義.

Fig. 20　The virtual data center.圖20　虛擬數據中心

圍繞云計算數據中心網絡虛擬化，目前研究者已經提出了多種虛擬網絡體系架構的解決方案，根據所解決問題側重的不同，可以將其分為兩大類：可擴展型虛擬網絡體系架構，主要解決虛擬數據中心的可擴展性問題；性能保證型虛擬網絡體系架構，主要解決應用服務性能質量的保證問題，如帶寬、容錯等.

3.1可擴展型虛擬網絡體系架構

可擴展型虛擬數據中心網絡體系架構旨在突破現有物理網絡設備的性能瓶頸，通過采用恰當的設計方式，實現對更大規模虛擬數據中心的支持.

文獻[55]提出了一種虛擬網絡體系架構SecondNet，其能夠部署于任意的物理網絡拓撲結構之上，具有很強的適用性.SecondNet虛擬網絡體系架構如圖21所示，其主要有3方面的特征：

1) hypervisor取代交換機進行路徑轉發信息的維護，通常情況下，為了滿足云租戶的性能需求，需要對VM-Pairs路徑的相關狀態信息(如預留的帶寬等)進行保存和維護，SecondNet為了避免信息維護給中間交換機帶來巨大的處理負擔，選擇使用hypervisor來進行狀態信息的維護，由于服務器上駐守的VM數量有限，因而該方法切實高效可行；

2) 使用基于端口的源路由，數據中心網絡存在單一管理實體，因而全網拓撲是可以獲取的，基于這樣的事實，為了實現部署的任意性和靈活性，SecondNet采用了類似源路由的數據包轉發方式，但不同于源路由，數據報文中并沒有攜帶所有下一跳的MAC地址或者IP地址，而是攜帶所有下一跳的輸出端口；

3) 建立健壯可靠的信息傳輸樹，為了保證網絡管理控制信息的暢通傳輸，SecondNet建立了一個以VDC Manager為根的帶內通信生成樹，保證了VDC Manager和節點之間控制信息的可靠傳輸.

正是由于這3點特征，使得SecondNet具有較強的可擴展性.但是，源路由的應用需要交換機支持端口交換和基于流的優先級的搶先調度.

NetLord[56]虛擬網絡體系架構通過虛擬云租戶的2層和3層地址空間，即允許云租戶根據實際需要設計部署自己的地址空間，從而實現了對更多云租戶的支持.如圖22所示為NetLord虛擬網絡體系架構，其數據包的發送過程涉及6個實體：源虛擬機VM-S、源NetLord代理NLA-S、入口交換機ES-S、出口交換機ES-D、目的NetLord代理NLA-D、目的虛擬機VM-D.NetLord數據包的發送過程可描述如下：VM-S為數據包指定2層地址(源虛擬機的MAC和目的虛擬機的MAC)，并發往NLA-S；部署于物理服務器上的NLA-S為數據包增加2層包頭和3層包頭，2層包頭的地址分別為ES-S和ES-D的MAC地址，3層包頭的源IP為云租戶MAC地址空間的ID，3層包頭的目的IP為ES-D出端口和云租戶ID的組合；通過2層網絡，該數據包被傳送到了ES-D，去掉外層的2層包頭，并依據目的IP數據包到達NLA-D；數據包到達NLA-D后，依據云租戶ID和VM-D的MAC就能到達目的虛擬機.

Fig. 21　The virtual network architecture of SecondNet.圖21　SecondNet虛擬網絡體系架構

Fig. 22　The virtual network architecture of NetLord.圖22　NetLord虛擬網絡體系架構

通過在服務器部署NetLord代理，將租戶虛擬機的MAC地址封裝起來，使其并不暴露于網絡中，這樣不但節約了交換機的轉發表空間，而且允許不同云租戶MAC地址空間的重疊，具有較好的擴展性.但是NetLord額外的封裝會增加數據包的長度，造成分片或者丟包.另外，NetLord使用SPAIN在2層網絡上進行多路徑轉發，但由于SPAIN的轉發操作是基于數據流的，這一定程度上限制了NetLord的可擴展性.

不同SecondNet使用源路由、NetLord使用代理來增強虛擬數據中心網絡體系結構的可擴展性，文獻[57]提出了一虛擬網絡向底層物理網絡映射的再優化機制.因為各個物理節點(邊)在底層網絡中所起的重要程度互不相同，所以應該有所區別地進行對待，如果不加以區別，就可能將虛擬節點(邊)過多地映射到關鍵節點(邊)上，從而影響更多虛擬網絡的進一步映射.該文通過檢測、定位映射過程中的關鍵節點和瓶頸鏈路并對其進行重新映射，從而提高了底層物理網絡對虛擬網絡的承載比率，增強了虛擬網絡體系結構的可擴展性.

3.2性能保證型虛擬網絡體系架構

性能保證型虛擬網絡體系架構旨在更大程度地保證云租戶應用服務的服務質量，如帶寬、容錯等，從而使云租戶有更好的用戶體驗，減小其經濟損失.

Oktopus[58]就是性能保證型虛擬網絡體系架構的一例，其為了更清晰地描述云租戶應用服務的資源需求，提出了2種網絡抽象的實現，分別是virtual cluster和virtual oversubscribed cluster.圖23(a)所示為virtual cluster，即由不具有鏈路收斂屬性的虛擬交換機連接所有VM，主要針對于數據密集型的應用，如MapReduce；圖23(b)所示為virtual over-subscribed cluster，即通過多個virtual cluster形成一個具有鏈路收斂比屬性的雙層交換集群，主要針對于本地通信集中的應用.基于這2個網絡抽象的定義，云租戶可以根據自身應用服務的通信特點，選擇恰當的網絡抽象方法以及鏈路收斂比，如〈N,B〉或者〈N,S,B,O〉，從而提高ISP實際所提供資源與云租戶資源申請的匹配程度.虛擬網絡體系架構Oktopus通過采取一系列措施為云應用服務的正常運行提供了帶寬保證，但與此同時卻犧牲了網絡鏈路的高利用率，Gatekeeper[59]針對這一問題，為每一對VM-Pair都定義了最低保證速率和最高允許速率，使得VM-Pair帶寬在保證最低需求的基礎上有著靈活的變動空間，從而一定程度上提高了鏈路的利用率.而虛擬網絡體系架構NetShare[60]，SeaWall[61]則采用了不同的設計思路，提出基于權值的帶寬分配策略，在不同應用服務間實現了相對公平的帶寬共享，但并不提供固定的帶寬保證，從而更進一步提高了鏈路的利用率.

Fig. 23　The network abstractions in Oktopus.圖23　Oktopus的網絡抽象

但是TIVC[62]發現云應用服務在整個運行過程中，只有30%～60%的執行時間才會產生大量數據流量，如果在云應用服務初始運行時就分配固定的帶寬資源，勢必會造成數據中心資源的過度浪費.為了合理地利用數據中心的帶寬資源，TIVC提出根據云應用服務的流量模型[63]，隨時間動態地為其分配帶寬資源.

TIVC模型具體如圖24所示，為了清晰地描述如何隨時間動態調整帶寬資源，文獻[62]以云計算數據中心典型的應用服務為例，歸納分析了常見的流量模型，共分為4類：Type 1(單一峰值)；Type 2(重復固定寬度峰值)；Type 3(變寬度峰值)；Type 4(變寬度變高度峰值).基于這4類，帶寬有規律地調整，從而實現了數據中心網絡資源高效利用.

然而，為支撐云應用服務的高效部署和管理，虛擬網絡體系架構所面臨的問題不僅僅限于如何進行VM分組、預留帶寬等，還包括應用服務地址空間的定義、如何進行網絡廣播等問題，而目前的虛擬網絡體系架構往往只能解決其中的部分問題.旨在全面地解決虛擬網絡體系架構所面臨的問題，Cloud-NaaS[64]提供了一組原語，用于定義云應用服務的部署需求，這些原語包括應用服務地址空間的定義、網絡廣播、VM分組、預留帶寬等.為了實現上述目標，CloudNaaS利用OpenFlow技術，將部署云應用服務的過程分為以下3步：①云租戶使用原語描述網絡的資源需求，并發送給云控制器；②云控制器將網絡資源需求的描述轉化為通信矩陣；③云控制器確定VM到物理機的映射機制，并生成對應的交換機規則.在第③步中，CloudNaaS針對如何實現VM到物理機的映射和如何降低交換機轉發條目的數量等問題，提出了具體可行的方法.此外，CloudNaaS可以通過重新規劃虛擬數據中心VDC來在線支持網絡策略的失效或者改變，但是，由于其對網絡流傳輸路徑的數目進行了限制，CloudNaaS可能存在易導致網絡擁塞或資源利用率偏低等問題.

文獻[65]就虛擬網絡體系架構中的容錯問題進行了研究，由于一條物理鏈路可能承載著多個虛擬網絡的多條虛擬鏈路，一旦底層物理網絡發生故障，就可能影響到多個虛擬網絡的正常運行，作者提出了一種Hybrid啟發式策略，并結合節點遷移策略，可有效處置底層網絡的多鏈路失效和單節點失效問題.

虛擬網絡體系架構設計的合理性直接影響著云應用服務性能質量的保證，雖然有許多方案相繼提出，但是其仍面臨不少的問題，特別是隨著云應用服務的繁榮快速發展，目前該領域仍是學術界和工業界的關注焦點.

Fig. 24　TIVC models.圖24　TIVC模型

4　未來發展趨勢

在云計算技術趨勢的影響下，目前，數據中心領域正發生著前所未有的深刻變革，本文圍繞云計算數據中心網絡所面臨的主要挑戰，將當前相關的研究工作從云計算數據中心網絡體系架構、云計算數據中心VMotion支撐和云計算數據中心網絡虛擬化3個方面進行了深入分析，可以看出，盡管數據中心已經獲得了很大發展，但是仍尚未足夠進化以滿足新技術條件下具體應用服務的部署和使用需求，以下3個方面在未來仍值得繼續探索與研究.

1) 新穎云計算數據中心網絡架構的研究.在目前數據中心的網絡架構研究方案中，有線形式的研究已漸漸受到較少的關注，相反，為了追求更低廉的建設成本、降低網絡布線的復雜性，無線形式的數據中心網絡架構逐漸受到熱捧，隨著無線通信技術的不斷發展，可以預期在這方面將產生不少的新成果.另外，關于數據中心之間的互連拓撲也有較大的研究空間，通過數據中心之間的高效協同，可進一步推動云計算實際應用的大力發展.

2) “大二層”網絡技術的深化與創新.為了實現數據中心網絡資源的靈活調度與部署，深化與創新“大二層”網絡技術迫在眉睫，因為跨越3層的網絡資源調度方式不夠靈活且本身存在巨大的開銷.“大二層”網絡技術具有較大的研究空間，體現在以下2方面：①為了避免對現有網絡設備的巨大改動，“大二層”網絡技術需要更多地依托于現有網絡設備(交換機)所支持的多種功能，而并非僅限于新設計的網絡設備才可以支持；②發展跨數據中心的“大二層”網絡技術，隨著云計算的發展，數據中心之間的交互逐漸變得頻繁，如何實現跨數據中心的資源調度又盡可能地節約寶貴的廣域網資源、降低運維管理的復雜度，是值得探索的一個方向.

3) 云計算數據中心虛擬化的進一步發展.虛擬化雖然已經在云計算數據中心環境中得到大量應用，但就其發展而言，仍有較大的研究空間，體現在3方面：①虛擬化的對象不僅僅局限于服務器、鏈路，還包括路由器、交換機、存儲設備及安全系統等，擴大虛擬化對象的范圍將有助于網絡資源的進一步高效利用.②虛擬網絡在向物理網絡映射時，除了保證帶寬外，對于別的因素的考慮也很重要，比如如何動態地映射以實現節能的目的、如何將虛擬網絡映射到跨自治域的底層物理網絡[66]等.③在虛擬化的過程中也面臨著不少新的安全問題，需要去研究解決，如不同虛擬網絡對安全有著不同程度的要求，需要設計高效且可擴展的監控機制；虛擬網絡之間的安全策略可能會互相影響，如何避免這種復雜性等.

[1]Xu Libing. Tengyun: the Exploration of Network Technologies in the Era of Cloud Computing and Big Data[M]. Beijing: Posts & Telecom Press, 2013 (in Chinese)(徐立冰. 騰云: 云計算和大數據時代網絡技術揭秘[M]. 北京: 人民郵電出版社, 2013)[2]Vamanan B, Hasan J, Vijaykumar T N. Deadline-aware datacenter TCP(D2TCP)[J]. ACM SIGCOMM Computer Communication Review, 2012, 42(4): 115-126[3]Rasley J, Stephens B, Dixon C, et al. Planck: Millisecond-scale monitoring and control for commodity networks[C]Proc of the 2014 ACM Conf on SIGCOMM. New York: ACM, 2014: 407-418[4]Guo Z, Yang Y. Multicast fat-tree data center networks with bounded link oversubscription[C]Proc of IEEE INFOCOM’13. Piscataway, NJ: IEEE, 2013: 350-354[5]Wu X, Turner D, Chen C C, et al. Netpilot: Automating datacenter network failure mitigation[J]. ACM SIGCOMM Computer Communication Review, 2012, 42(4): 419-430[6]China Electronics Standardization Institute. Status and prospects of green data center[R]. San Francisco, CA: Sino-America Energy Efficiency Forum, 2011[7]Farrington N, Porter G, Radhakrishnan S, et al. Helios: A hybrid electricaloptical switch architecture for modular data centers[J]. ACM SIGCOMM Computer Communication Review, 2011, 41(4): 339-350[8]Bari M F, Boutaba R, Esteves R, et al. Data center network virtualization: A survey[J]. Communications Surveys & Tutorials, 2013, 15(2): 909-928[9]Dally W J, Towles B P. Principles and Practices of Interconnection Networks[M]. Amsterdam: Elsevier, 2004[10]Al-Fares M, Loukissas A, Vahdat A. A scalable, commodity data center network architecture[J]. ACM SIGCOMM Computer Communication Review, 2008, 38(4): 63-74[11]Gary B. Facebook fabric networking deconstructed[EBOL]. 2014[2015-02-15]. http:firstclassfunc.comfacebook-fabric-networking[12]Curtis A R, Carpenter T, Elsheikh M, et al. Rewire: An optimization-based framework for unstructured data center network design[C]Proc of IEEE INFOCOM’12. Piscataway, NJ: IEEE, 2012: 1116-1124[13]Mudigonda J, Yalagandula P, Al-Fares M, et al. SPAIN: COTS data-center Ethernet for multipathing over arbitrary topologies[C]Proc of NSDI’10. Berkeley, CA: USENIX Association, 2010: 265-280[14]Chen K, Guo C, Wu H, et al. Generic and automatic address configuration for data center networks[J]. ACM SIGCOMM Computer Communication Review, 2011, 41(4): 39-50[15]Halperin D, Kandula S, Padhye J, et al. Augmenting data center networks with multi-gigabit wireless links[C]Proc of the 2011 ACM Conf on SIGCOMM. New York: ACM, 2011: 38-49[16]Zhang W, Zhou X, Yang L, et al. 3D beaming for wireless data centers[C]Proc of the 10th ACM Workshop on Hot Topics in Networks. New York: ACM, 2011: 1-6[17]Katayama Y, Takano K, Kohda Y, et al. Wireless data center networking with steered-beam mmwave links[C]Proc of the IEEE Wireless Communications and Networking Conf. Piscataway, NJ: IEEE, 2011: 2179-2184[18]Hamedazimi N, Gupta H, Sekar V, et al. Patch panels in the sky: A case for free-space optics in data centers[C]Proc of the 12th ACM Workshop on Hot Topics in Networks. New York: ACM, 2013: 1-7[19]Kandula S, Padhye J, Bahl P. Flyways to de-congest data center networks[C]Proc of the ACM Workshop. New York: ACM, 2009: 32-41[20]Hamedazimi N, Qazi Z, Gupta H, et al. FireFly: A reconfigurable wireless data center fabric using free-space optics[C]Proc of the 2014 ACM Conf on SIGCOMM. New York: ACM, 2014: 319-330[21]Shin J Y, Sirer E G, Weatherspoon H, et al. On the feasibility of completely wireless data centers[J]. IEEEACM Trans on Networking, 2013, 21(5): 1666-1679[22]Ramachandran K, Kokku R, Mahindra R, et al. 60 GHz data-center networking: Wireless=>worry less?[R]. Princeton, NJ: NEC Laboratories America, 2008 [23]Wei Wei, Wei Xuanzhong, Chen Guihai. Wireless technology for data center networks[J]. ZTE Technology Journal, 2012, 18(4): 1-6 (in Chinese)(魏煒, 魏晅中, 陳貴海. 數據中心網絡中的無線通信技術[J].中興通訊技術, 2012, 18(4): 1-6)[24]Kedar D, Arnon S. Urban optical wireless communication networks: The main challenges and possible solutions[J]. IEEE Communications Magazine, 2004, 42(5): 2-7[25]Zhou X, Zhang Z, Zhu Y, et al. Mirror mirror on the ceiling: Flexible wireless links for data centers[J]. ACM SIGCOMM Computer Communication Review, 2012, 42(4): 443-454[26]Guo C, Wu H, Tan K, et al. DCell: A scalable and fault-tolerant network structure for data centers[J]. ACM SIGCOMM Computer Communication Review, 2008, 38(4): 75-86[27]Guo C, Lu G, Li D, et al. BCube: A high performance, server-centric network architecture for modular data centers[J]. ACM SIGCOMM Computer Communication Review, 2009, 39(4): 63-74[28]Liu Xiaoqian, Yang Shoubao, Guo Liangmin, et al. Snowflake: A new-type network structure of data center[J]. Chinese Journal of Computers, 2011, 34(1): 76-86 (in Chinese)(劉曉茜, 楊壽保, 郭良敏, 等.雪花結構: 一種新型數據中心網絡結構[J].計算機學報, 2011, 34(1): 76-86 )[29]Zhu Guiming, Xie Xianghui, Guo Deke, et al. High performance expandable data center networking structure[J]. Journal of Software, 2014, 25(6): 1339-1351 (in Chinese)(朱桂明, 謝向輝, 郭得科, 等.一種高吞吐量、高可擴展數據中心網絡結構[J].軟件學報, 2014, 25(6): 1339-1351)[30]Liao Y, Yin D, Gao L. DPillar: Scalable dual-port server interconnection for data center networks[C]Proc of the 19th Int Conf on Computer Communications and Networks. Piscataway, NJ: IEEE, 2010: 1-6[31]Guo D, Chen T, Li D, et al. Expandable and cost-effective network structures for data centers using dual-port servers[J]. IEEE Trans on Computers, 2013, 62(7): 1303-1317[32]Li D, Wu J. On the design and analysis of data center network architectures for interconnecting dual-port servers[C]Proc of IEEE INFOCOM’14. Piscataway, NJ: IEEE, 2014: 1851-1859 [33]Li D, Guo C, Wu H, et al. FiConn: Using backup port for server interconnection in data centers[C]Proc of IEEE INFOCOM’09. Piscataway, NJ: IEEE, 2009: 2276-2285[34]Biggs N. Algebraic Graph Theory[M]. Cambridge, UK: Cambridge University Press, 1993[35]Greenberg A, Hamilton J R, Jain N, et al. VL2: A scalable and flexible data center network[J]. ACM SIGCOMM Computer Communication Review, 2009, 39(4): 51-62[36]Niranjan M R, Pamboris A, Farrington N, et al. PortLand: A scalable fault-tolerant layer 2 data center network fabric[J]. ACM SIGCOMM Computer Communication Review, 2009, 39(4): 39-50[37]Farinacci D, Fuller V, Meyer D, et al. The LocatorID Separation Protocol (LISP)[SOL]. IETF, 2013[2016-03-10]. https:tools.ietf.orghtmlrfc6830[38]Greenberg A, Lahiri P, Maltz D A, et al. Towards a next generation data center architecture: Scalability and commoditization[C]Proc of ACM Workshop on Programmable Routers for Extensible Services of Tomorrow. New York: ACM, 2008: 57-62[39]Hao F, Lakshman T V, Mukherjee S, et al. Enhancing dynamic cloud-based services using network virtualization[C]Proc of the 1st ACM Workshop on Virtualized Infrastructure Systems and Architectures. New York: ACM, 2009: 37-44[40]Hooda S K, Kapadia S, Krishnan P. Using TRILL, FabricPath, and VXLAN: Designing Massively Scalable Data Centers (MSDC) with Overlays[M]. Indianapolis, IN: Cisco Press, 2014[41]Peter A. Shortest path bridging IEEE 802.1aq tutorial and demo[R]. Huawei: NANOG 50, 2010[42]Wang P C, Chan C T, Lin P Y. MAC address translation for enabling scalable virtual private LAN services[C]Proc of IEEE AINAW’07. Piscataway, NJ: IEEE, 2007: 870-875[43]Cisco. Layer 2 everywhere: Overcoming overlay transport virtualization (OTV) site limitations within and between data centers[EBOL]. 2012 [2015-05-15].http:www.cisco.comcenussolutionscollateraldata-center-virtualizationoverlay-transport-virtualization-otvwhite_paper_c11-702185.html[44]Sridhar T, Kreeger L, Dutt D, et al. VXLAN: A Framework for Overlaying Virtualized Layer 2 Networks Over Layer 3 Networks[SOL]. IETF, 2014[2016-03-10]. https:tools.ietf.orghtmlrfc7348[45]Mahalingam M, Duda K, Ganga I, et al. NVGRE: Network Virtualization Using Generic Routing Encapsulation[SOL]. IETF, 2011[2016-03-10]. https:tools.ietf.orghtmldraft-sridharan-virtualization-nvgre-00[46]Jing L, Jonathan T. Efficient mapping of virtual networks onto a shared substrate[R]. Saint Louis, Missouri: Washington University, School of Engineering & Applied Science, 2006[47]Li X, Wang H, Ding B, et al. SPGM: An efficient algorithm for mapping MapReduce-like data-intensive applications in data centre network[J]. Int Journal of Web and Grid Services, 2013, 9(2): 172-192[48]Li X, Wang H, Ding B, et al. Resource allocation with dynamic substrate network in data centre networks[J]. Communications, 2013, 10(9): 130-142[49]Cheng X, Su S, Zhang Z, et al. Virtual network embedding through topology awareness and optimization[J]. Computer Networks, 2012, 56(6): 1797-1813[50]Yu M, Yi Y, Rexford J, et al. Rethinking virtual network embedding: Substrate support for path splitting and migration[J]. ACM SIGCOMM Computer Communication Review, 2008, 38(2): 17-29[51]Bienkowski M, Feldmann A, Jurca D, et al. Competitive analysis for service migration in VNets[C]Proc of the 2nd ACM SIGCOMM Workshop on Virtualized Infrastructure Systems and Architectures. New York: ACM, 2010: 17-24[52]Chowdhury N M, Rahman M R, Boutaba R. Virtual network embedding with coordinated node and link mapping[C]Proc of IEEE INFOCOM’09. Piscataway, NJ: IEEE, 2009: 783-791[53]Cheng X, Su S, Zhang Z, et al. Virtual network embedding through topology awareness and optimization[J]. Computer Networks, 2012, 56(6): 1797-1813[54]Sun G, Yu H, Anand V, et al. A cost efficient framework and algorithm for embedding dynamic virtual network requests[J]. Future Generation Computer Systems, 2013, 29(5): 1265-1277[55]Guo C, Lu G, Wang H J, et al. SecondNet: A data center network virtualization architecture with bandwidth guarantees[C]Proc of the 6th Int CoNEXT. New York: ACM, 2010: 195-207[56]Mudigonda J, Yalagandula P, Mogul J, et al. NetLord: A scalable multi-tenant network architecture for virtualized datacenters[J]. ACM SIGCOMM Computer Communication Review, 2011, 41(4): 62-73[57]Butt N F, Chowdhury M, Boutaba R. Topology-awareness and Reoptimization Mechanism for Virtual Network Embedding[M]. Berlin: Springer, 2010[58]Ballani H, Costa P, Karagiannis T, et al. Towards predictable datacenter networks[J]. ACM SIGCOMM Computer Communication Review, 2011, 41(4): 242-253[59]Rodrigues H, Santos J R, Turner Y, et al. Gatekeeper: Supporting bandwidth guarantees for multi-tenant datacenter networks[C]Proc of the 3rd Conf on IO Virtualization. Berkeley, CA: USENIX Association, 2011: 73-85[60]Lam T, Radhakrishnan S, Vahdat A, et al. NetShare: Virtualizing Data Center Networks across Services[M]. San Diego, CA: University of California, 2010[61]Shieh A, Kandula S, Greenberg A G, et al. Sharing the data center network[C]Proc of the 8th USENIX Conf on Networked Systems Design and Implementation. Berkeley, CA: USENIX Association, 2011: 309-322[62]Xie D, Ding N, Hu Y C, et al. The only constant is change: Incorporating time-varying network reservations in data centers[J]. ACM SIGCOMM Computer Communication Review, 2012, 42(4): 199-210[63]Kandula S, Sengupta S, Greenberg A, et al. The nature of data center traffic: Measurements & analysis[C]Proc of the 2009 ACM Conf on SIGCOMM. New York: ACM, 2009: 202-208[64]Benson T, Akella A, Shaikh A, et al. CloudNaaS: A cloud networking platform for enterprise applications[C]Proc of

the 2nd ACM Symp on Cloud Computing. New York: ACM, 2011: 53-64[65]Rahman M R, Aib I, Boutaba R. Survivable Virtual Network Embedding[M]. Berlin: Springer, 2010[66]Chowdhury M, Samuel F, Boutaba R. PolyViNE: Policy-based virtual network embedding across multiple domains[C]Proc of the 2nd ACM SIGCOMM Workshop. New York: ACM, 2010: 49-56

Wang Binfeng, born in 1989. Received his BSc degree in computer science from China University of Petroleum in 2011 and his MSc degree in computer science from National University of Defense Technology in 2013. PhD candidate at the College of Computer, National University of Defense Technology. His main research interests include network management, data center network and cloud computing.

Su Jinshu, born in 1962. Received his MSc and PhD degrees in computer science from National University of Defense Technology in 1989 and 1999 respectively. Professor and PhD supervisor at the College of Computer, National University of Defense Technology. Member of the ACM and IEEE. His main research interests include high-performance routers, Internet routing, high-performance computing, cloud computing, wireless networks, and information security (sjs@nudt.edu.cn).

Chen Lin, born in 1976. Received her PhD degree in computer science from National University of Defense Technology in 2005. Associate professor at the College of Computer, National University of Defense Technology. Her main research interests include network management and data center network resource management (chenlin@nudt.edu.cn).

Review of the Design of Data Center Network for Cloud Computing

Wang Binfeng1, Su Jinshu1,2, and Chen Lin1

1(CollegeofComputer,NationalUniversityofDefenseTechnology,Changsha410073)2(ScienceandTechnologyonParallelandDistributedProcessingLaboratory,NationalUniversityofDefenseTechnology,Changsha410073)

Under the influence of the development of cloud computing, the data center network is going through tremendous changes, which are reflected not only in the improvement of network size, bandwidth, abundant links, scalability, agility and the cutting down of the cost, but also in other aspects, such as the support for the VMotion dynamically, the network virtualization etc. On the basis of the main challenges of data center network for cloud computing, the paper firstly describes the network architecture of data center for cloud computing in two different aspects, which regards switches and servers as the forwarding center respectively. Next, from the perspective of the flexible deployment of network resources, the paper deeply analyzes the related proposals and key technologies concerning the VMotion dynamically in data center for cloud computing. Further, in order to summarize the application of the network virtualization in data center for cloud computing in detail, the paper mainly analyzes a variety of designs for the virtual network architecture, which includes two different types: the scalability type and the performance guaranteed type. Finally, taking the rapid development of advanced technologies into account, the paper puts forward several points of future prediction in terms of the development of data center network for cloud computing.

data center network; cloud computing; network architecture; mobility; virtualization

2015-11-09；

2016-03-22

國家“九七三”重點基礎研究發展計劃基金項目(2012CB315906)；國家自然科學基金項目(61303264)

TP391

This work was supported by the National Basic Research Program of China (973 Program) (2012CB315906) and the National Natural Science Foundation of China (61303264).