DN(軟件定義網(wǎng)絡)通過邏輯上集中的主控制器實現(xiàn)對底層交換機報文處理的管理，在業(yè)界也因此出現(xiàn)了多種SDN/OpenFlow的控制器比如 RYU，OpenDaylight、Floodlight等;隨著云計算技術的發(fā)展在IaaS領域涌現(xiàn)很多開源的云平臺管理工具，但是這兩個領域目前還沒有很好的融合。本項目通過為OpenStack的網(wǎng)絡實現(xiàn)一個可擴展的OpenFlow控制器Plugin，試圖解決早期OpenFlow控制器在擴展性方面的缺陷。

一、簡介

云計算越來越普及，云提供的彈性和服務的動態(tài)提供日益受人矚目。隨著OpenStack項目的出現(xiàn)，云平臺的創(chuàng)新也越來越容易。最初 OpenStack項目由instance管理項目(Nova)，object存儲項目(Swift)和image repository項目(Glance)組成，網(wǎng)路部分由Nova提供flat network配置和VLAN隔離，并沒有受到太多關注。這種簡單的網(wǎng)絡能力使得租戶很難設立多級網(wǎng)絡(flat networking模式)，同時沒有擴展性可言。

從Quantum項目開始，OpenStack在接口設備(比如vNIC)間提供“網(wǎng)絡連接即服務”。Quantum使得租戶可以輕松建立虛擬網(wǎng)絡，模塊化的架構和標準的API可方便實現(xiàn)防火墻和ACL的Plugin。在大量涌現(xiàn)的Plugin中，和網(wǎng)絡最相關的就是OpenFlow控制器RYU 的plugin，但是RYU開源的Plugin缺乏云計算最基本的特性：擴展性。本項目將為Quantum設計一個更具擴展性的openflow plugin，同時利用SDN的集中控制，我們還會演示基于控制器的虛機遷移應用。

二、實現(xiàn)方法

Floodlight是基于Java的OpenFlow控制器，來源于Stanford大學最早開發(fā)的Beacon控制器(另一個最早的控制器是 NOX)，本項目選擇Floodlight是因為它是一款相對簡單又具有較高性能的控制器，不過本項目采用的方法可同樣適用于其它控制器。

OpenFlow開源控制器RYU提供和本項目類似的Plugin，實現(xiàn)了邏輯上的集中控制和API，便于創(chuàng)建新的網(wǎng)絡管理和控制應用。RYU進行租戶的2層網(wǎng)絡隔離不是通過VLAN，而是為VM內(nèi)部通信建立單獨的流，有實驗表明這種方法在數(shù)據(jù)中心網(wǎng)絡不具有擴展性，因為它會很快耗盡交換機的內(nèi)存資源。

我們基于Floodlight為Quantum開發(fā)一款擴展性更好的OpenFlow Plugin。最初選擇Floodlight是因為它是一款高性能的企業(yè)級控制器(譯注：非常遺憾Floodlight已經(jīng)停止更新)。不過本項目的方法可以很容易應用于其他標準的OpenFlow控制器。

我們的Plugin將來自Quantum API的建立/更新/刪除網(wǎng)絡資源的請求傳遞給底層網(wǎng)絡。除了Plugin，每一個Nova VM會加載一個Agent用來處理該VM的虛擬接口的創(chuàng)建，并將它們與Quantum網(wǎng)絡對接。我們的方案利用支持OpenFlow的 OpenvSwitch(OVS)來提供Quantum所需的底層網(wǎng)絡，并通過Floodlight控制器對OVS進行配置。

1 挑戰(zhàn)

為Quantum提供OpenFlow控制器Plugin的***挑戰(zhàn)就是擴展性。RYU開源的Plugin為所有的VM間流量創(chuàng)建流，當流的數(shù)目超過OpenFlow交換機TCAM支持的***條目后擴展性就會成為問題。

本方法采用更具有擴展性的VLAN方案對租戶網(wǎng)絡進行隔離。我們知道VLAN同樣有擴展性的限制，因此，后續(xù)方案開發(fā)可以考慮新的封裝協(xié)議比如VXLAN。

2 架構

Quantum的Plugin用來處理網(wǎng)絡建立請求，它將來自Quantum的網(wǎng)絡ID轉(zhuǎn)換為VLAN并將這個轉(zhuǎn)換關系維護在數(shù)據(jù)庫中。 Plugin負責OVS Bridge的創(chuàng)建，記錄邏輯網(wǎng)路模型。Agent和Plugin同時紀錄進入網(wǎng)絡的端口，通知Floodlight有新的流量進入網(wǎng)絡?；诰W(wǎng)絡端口的分配情況和端口的源MAC地址，流量被控制器加上VLAN ID標簽。一旦加上標簽后，網(wǎng)絡流量就基于傳統(tǒng)的learning switch進行轉(zhuǎn)發(fā)。因此，通過VLAN標簽和OpenFlow的控制我們就可以基于租戶進行VM流量的隔離。

上圖所示為Plugin的架構。租戶通過nova-client將指令傳遞給Quantum管理單元，管理單元再將這些Call傳遞給真正執(zhí)行創(chuàng)建 /讀取/更新/刪除(CRUD)功能的控制器Plugin。Plugin通過在每個租戶的網(wǎng)絡ID和VLAN ID間建立映射關系實現(xiàn)上述功能。每當有新的端口加載于Quantum網(wǎng)絡，Plugin就會相應地添加端口到OVS-bridge，保存端口和VLAN ID間的映射關系。***，以Daemon形式運行于每個Hypervisor之上的Quantum agent不斷輪詢數(shù)據(jù)庫和OVS Bridge，當有變化發(fā)生時就通知Floodlight Client，Client采用RESTful API告知Floodlight控制器模塊。這樣控制器就獲取了端口、網(wǎng)絡ID和VLAN ID的映射關系。當?shù)竭_OVS的新報文沒有任何entry時，報文會送到控制器做決策。然后控制器會推送一條規(guī)則到OVS告知其采用哪個VLAN ID來標記報文以及封裝報文所用的物理主機地址。另外，控制器還會為物理交換機增加一條規(guī)則，動作為按照普通報文處理流程處理報文，所以報文的轉(zhuǎn)發(fā)將會按照基本的Leaning Switch方式。通過這個方法每個物理交換機所需的TCAM條目數(shù)與通過交換機的VLAN數(shù)目成正比。

#p#

3 分析對比

本節(jié)分析對比上述方法與RYU方法在流表數(shù)目上對交換機的需求。假定每個服務器有20個VM，每個VM有10條并發(fā)流(出入各5條)。在這樣的設定下，如果采用RYU的方法VM-VM間的流不具有擴展性。上圖所示為兩種方法的對比圖。假定RYU的匹配規(guī)則基于VM的源和目的地址，因此ToR交換機需要在TCAM中存儲20 servers/rack x 20 VMs/server x 10并發(fā)流/VM = 4000條流表。然而在我們的方案中基于每個報文的VLAN標簽可對流表進行聚合，即使在物理交換機上每個VM都有一條匹配規(guī)則(這里假定最壞情況即服務器上的每個VM都屬于不同的租戶)，需要存儲在交換機TCAM中的流表條目數(shù)也只有400條，可以下降十倍以上。

4 管理應用示例：VM遷移

OpenFlow和我們的OpenStack Plugin實現(xiàn)網(wǎng)絡的全局視角以及對轉(zhuǎn)發(fā)行為的直接控制，因而可以簡化操作管理。接下來我們提供一個應用案例：VM遷移。

高速無縫的VM遷移是數(shù)據(jù)中心實現(xiàn)負載均衡、配置管理、能耗節(jié)約等提升資源利用率的重要手段。但是VM遷移需要更新網(wǎng)絡狀態(tài)，可能導致沖突、業(yè)務中斷、環(huán)路以及SLA不達標等一系列問題，因此VM遷移對服務提供商來講始終是一個挑戰(zhàn)。SDN為解決這些棘手問題提供一個強有力的手段：在邏輯上集中的控制器位置運行算法和可精確控制交換機轉(zhuǎn)發(fā)層面的能力有助于在兩個狀態(tài)間切換網(wǎng)絡。

本方法特別解決以下問題：對于分別由帶有特定轉(zhuǎn)發(fā)規(guī)則的交換機組成的起始網(wǎng)絡和目標網(wǎng)絡，我們是否可以設計出一套OpenFlow指令將起始網(wǎng)絡狀態(tài)轉(zhuǎn)換到目標網(wǎng)絡，同時保持某些狀態(tài)比如路徑無環(huán)以及保證帶寬。這個問題可以分解為兩個小問題：確定VM遷移的順序或者規(guī)劃排序;對于每一個要遷移的 VM，確定要執(zhí)行或者丟棄的OpenFlow指令的順序。

為了在有正確性保證的情況下進行遷移，我們測試了***算法(用來從所有可能的遷移順序組合中確定導致最少沖突的排序)的性能。算法可以計算出VM遷移的排序以及一系列的轉(zhuǎn)發(fā)狀態(tài)改變。 算法運行在SDN控制器之上所以可以編排整個網(wǎng)絡的改變。為了評估設計的性能，我們在真實的數(shù)據(jù)中心用虛擬的網(wǎng)絡拓撲仿真性能。對于各種負載情況，算法可以大幅提高遷移的隨機排序性能(80%以上)。

在共享的物理數(shù)據(jù)中心分配虛擬網(wǎng)絡已經(jīng)有很多研究，本項目借用這些工作中物理底層網(wǎng)絡和VN的拓撲和設置。另外，對于底層拓撲，我們測試了用于隨機圖、樹、胖樹、D-Cell和B-Cube的算法。對于VN，我們采用Web服務應用常見的星形、樹和3-tier圖。在遷移前最初分配VN時，我們使用了SecondNet的算法。

我們隨機選擇虛擬節(jié)點來進行遷移，從有空余資源的底層節(jié)點任意選擇目的網(wǎng)絡。在其他場景下當需要不同的節(jié)點或目標選取策略時或許會影響算法的性能，基于本算法可以繼續(xù)進行研究。

遷移平臺基于Intel的Core i7-2600K，16GB內(nèi)存。圖3實驗為200個節(jié)點的樹，鏈接帶寬為500MB，VN為9節(jié)點樹，鏈路帶寬為10MB。如圖所示，采用***算法后沖突比例保持在30%以下，而某些隨機排序下則接近100%。

三、擴展工作：VXLAN

隨著VXLAN等新的協(xié)議出現(xiàn)，擴展多租戶云網(wǎng)絡的其他方法也可以被應用于Plugin的通信底層機制。

VLAN(IEEE802.1q)傳統(tǒng)上常被用于為云中的不同租戶和組織提供隔離機制。雖然VLAN通過將網(wǎng)絡分隔為獨立的廣播域解決了2層網(wǎng)絡的問題，但是它無法提供敏捷的服務，可支持的host數(shù)目有限。因此，服務需要擴展時不得不適配不同的VLAN，導致服務的分隔。另外，在手工配置的情況下，VLAN配置很容易出錯，難于管理。雖然可以借助于VLAN管理策略服務器(VMPS)和VLAN trunking協(xié)議(VTP)自動化地配置access端口和trunk端口，但是網(wǎng)絡管理員很少采用VTP，因為在這種情況下，管理員必須將交換機分為不同VTP域，域中的每一個交換機必須加入域中所有的VLAN，造成不必要的負擔。再加上VLAN頭只提供12位的VLAN ID，網(wǎng)絡中最多有4096個VLAN?？紤]到VLAN廣泛的用途，這個數(shù)目難堪重任。數(shù)據(jù)中心虛擬化后進一步增大對VLAN的需求。虛擬可擴展 VLAN(VXLAN)是IETF推出的標準，試圖通過引入24位的VLAN網(wǎng)絡標識符(VNI)來消除VLAN的限制，也就是說VXLAN可在網(wǎng)絡中創(chuàng)建16M個VLAN。VXLAN主要利用hypervisor中軟交換(或者硬件接入交換機)的虛擬隧道端點(VTEP)并將與VM相關的VNI和報文進行封裝。VTEP基于IGMP協(xié)議加入多播組，這有助于消除未知的單播flood。

限制：VXLAN中16M個VLAN將超過多播組的***數(shù)目，所以屬于不同VNI的多個VLAN可能共享同一多播組。這可能導致安全和性能的問題。

四、總結

基于OpenFlow交換機部署OpenStack可充分體現(xiàn)SDN的優(yōu)勢。本項目實現(xiàn)了可擴展的Quantum/Neutron網(wǎng)絡Plugin，同時為后續(xù)進一步基于VXLAN等新封裝協(xié)議優(yōu)化改善Plugin提供了設計方向。