本項目平臺為美國伊利諾伊大學的 OCEAN，由176臺服務器+16臺Pica8公司OpenFlow交換機組成，提供從底層物理網絡到應用的完整環境，支撐的項目包括獲得HotSDN 2012最佳論文獎的VeriFlow，Jellyfish數據中心架構以及LIME虛擬網絡遷移系統。項目2011年啟動時OpenStack的網絡仍為Quantum，方案設計可應用于后續版本Neutron。
摘要： SDN（軟件定義網絡）通過邏輯上集中的主控制器實現對底層交換機報文處理的管理，在業界也因此出現了多種SDN/OpenFlow的控制器比如RYU，OpenDaylight、Floodlight等；隨著云計算技術的發展在IaaS領域涌現很多開源的云平臺管理工具，但是這兩個領域目前還沒有很好的融合。本項目通過為OpenStack的網絡實現一個可擴展的OpenFlow控制器Plugin，試圖解決早期OpenFlow控制器在擴展性方面的缺陷。
一、簡介
云計算越來越普及，云提供的彈性和服務的動態提供日益受人矚目。隨著 OpenStack項目的出現，云平臺的創新也越來越容易。最初OpenStack項目由instance管理項目（Nova），object存儲項目（Swift）和image repository項目（Glance）組成，網路部分由Nova提供flat network配置和VLAN隔離，并沒有受到太多關注。這種簡單的網絡能力使得租戶很難設立多級網絡（flat networking模式），同時沒有擴展性可言。
從 Quantum項目開始，OpenStack在接口設備（比如vNIC）間提供“網絡連接即服務”。Quantum使得租戶可以輕松建立虛擬網絡，模塊化的架構和標準的API可方便實現防火墻和ACL的Plugin。在大量涌現的Plugin中，和網絡最相關的就是OpenFlow控制器RYU的plugin，但是RYU開源的Plugin缺乏云計算最基本的特性：擴展性。本項目將為Quantum設計一個更具擴展性的openflow plugin，同時利用SDN的集中控制，我們還會演示基于控制器的虛機遷移應用。
二、實現方法
Floodlight 是基于Java的OpenFlow控制器，來源于Stanford大學最早開發的Beacon控制器(另一個最早的控制器是NOX)，本項目選擇Floodlight是因為它是一款相對簡單又具有較高性能的控制器，不過本項目采用的方法可同樣適用于其它控制器。
OpenFlow 開源控制器RYU提供和本項目類似的Plugin，實現了邏輯上的集中控制和API，便于創建新的網絡管理和控制應用。RYU進行租戶的2層網絡隔離不是通過VLAN，而是為VM內部通信建立單獨的流，有實驗表明這種方法在數據中心網絡不具有擴展性，因為它會很快耗盡交換機的內存資源。
我們基于 Floodlight為Quantum開發一款擴展性更好的OpenFlow Plugin。最初選擇Floodlight是因為它是一款高性能的企業級控制器（譯注：非常遺憾Floodlight已經停止更新）。不過本項目的方法可以很容易應用于其他標準的OpenFlow控制器。
我們的 Plugin將來自Quantum API的建立/更新/刪除網絡資源的請求傳遞給底層網絡。除了Plugin，每一個Nova VM會加載一個Agent用來處理該VM的虛擬接口的創建，并將它們與Quantum網絡對接。我們的方案利用支持OpenFlow的OpenvSwitch（OVS）來提供Quantum所需的底層網絡，并通過Floodlight控制器對OVS進行配置。
1 挑戰
為 Quantum提供OpenFlow控制器Plugin的最大挑戰就是擴展性。RYU開源的Plugin為所有的VM間流量創建流，當流的數目超過OpenFlow交換機TCAM支持的最大條目后擴展性就會成為問題。
本方法采用更具有擴展性的 VLAN方案對租戶網絡進行隔離。我們知道VLAN同樣有擴展性的限制，因此，后續方案開發可以考慮新的封裝協議比如VXLAN。
2 架構
Quantum 的Plugin用來處理網絡建立請求，它將來自Quantum的網絡ID轉換為VLAN并將這個轉換關系維護在數據庫中。Plugin負責OVS Bridge的創建，記錄邏輯網路模型。Agent和Plugin同時紀錄進入網絡的端口，通知Floodlight有新的流量進入網絡。基于網絡端口的分配情況和端口的源MAC地址，流量被控制器加上VLAN ID標簽。一旦加上標簽后，網絡流量就基于傳統的learning switch進行轉發。因此，通過VLAN標簽和OpenFlow的控制我們就可以基于租戶進行VM流量的隔離。
上圖所示為 Plugin的架構。租戶通過nova-client將指令傳遞給Quantum管理單元，管理單元再將這些Call傳遞給真正執行創建/讀取/更新/刪除（CRUD）功能的控制器Plugin。Plugin通過在每個租戶的網絡ID和VLAN ID間建立映射關系實現上述功能。每當有新的端口加載于Quantum網絡，Plugin就會相應地添加端口到OVS-bridge，保存端口和VLAN ID間的映射關系。最后，以Daemon形式運行于每個Hypervisor之上的Quantum agent不斷輪詢數據庫和OVS Bridge，當有變化發生時就通知Floodlight Client，Client采用RESTful API告知Floodlight控制器模塊。這樣控制器就獲取了端口、網絡ID和VLAN ID的映射關系。當到達OVS的新報文沒有任何entry時，報文會送到控制器做決策。然后控制器會推送一條規則到OVS告知其采用哪個VLAN ID來標記報文以及封裝報文所用的物理主機地址。另外，控制器還會為物理交換機增加一條規則，動作為按照普通報文處理流程處理報文，所以報文的轉發將會按照基本的Leaning Switch方式。通過這個方法每個物理交換機所需的TCAM條目數與通過交換機的VLAN數目成正比。
3 分析對比
本節分析對比上述方法與 RYU方法在流表數目上對交換機的需求。假定每個服務器有20個VM，每個VM有10條并發流（出入各5條）。在這樣的設定下，如果采用RYU的方法VM-VM間的流不具有擴展性。上圖所示為兩種方法的對比圖。假定RYU的匹配規則基于VM的源和目的地址，因此ToR交換機需要在TCAM中存儲20 servers/rack x 20 VMs/server x 10并發流/VM = 4000條流表。然而在我們的方案中基于每個報文的VLAN標簽可對流表進行聚合，即使在物理交換機上每個VM都有一條匹配規則（這里假定最壞情況即服務器上的每個VM都屬于不同的租戶），需要存儲在交換機TCAM中的流表條目數也只有400條，可以下降十倍以上。
4 管理應用示例：VM遷移
OpenFlow 和我們的OpenStack Plugin實現網絡的全局視角以及對轉發行為的直接控制，因而可以簡化操作管理。接下來我們提供一個應用案例：VM遷移。
高速無縫的 VM遷移是數據中心實現負載均衡、配置管理、能耗節約等提升資源利用率的重要手段。但是VM遷移需要更新網絡狀態，可能導致沖突、業務中斷、環路以及SLA不達標等一系列問題，因此VM遷移對服務提供商來講始終是一個挑戰。SDN為解決這些棘手問題提供一個強有力的手段：在邏輯上集中的控制器位置運行算法和可精確控制交換機轉發層面的能力有助于在兩個狀態間切換網絡。
本方法特別解決以下問題：對于分別由帶有特定轉發規則的交換機組成的起始網絡和目標網絡，我們是否可以設計出一套 OpenFlow指令將起始網絡狀態轉換到目標網絡，同時保持某些狀態比如路徑無環以及保證帶寬。這個問題可以分解為兩個小問題：確定VM遷移的順序或者規劃排序；對于每一個要遷移的VM，確定要執行或者丟棄的OpenFlow指令的順序。
為了在有正確性保證的情況下進行遷移，我們測試了最佳算法（用來從所有可能的遷移順序組合中確定導致最少沖突的排序）的性能。算法可以計算出 VM遷移的排序以及一系列的轉發狀態改變。 算法運行在SDN控制器之上所以可以編排整個網絡的改變。為了評估設計的性能，我們在真實的數據中心用虛擬的網絡拓撲仿真性能。對于各種負載情況，算法可以大幅提高遷移的隨機排序性能（80%以上）。
在共享的物理數據中心分配虛擬網絡已經有很多研究，本項目借用這些工作中物理底層網絡和 VN的拓撲和設置。另外，對于底層拓撲，我們測試了用于隨機圖、樹、胖樹、D-Cell和B-Cube的算法。對于VN，我們采用Web服務應用常見的星形、樹和3-tier圖。在遷移前最初分配VN時，我們使用了SecondNet的算法。
我們隨機選擇虛擬節點來進行遷移，從有空余資源的底層節點任意選擇目的網絡。在其他場景下當需要不同的節點或目標選取策略時或許會影響算法的性能，基于本算法可以繼續進行研究。
遷移平臺基于 Intel的Core i7-2600K，16GB內存。圖3實驗為200個節點的樹，鏈接帶寬為500MB，VN為9節點樹，鏈路帶寬為10MB。如圖所示，采用最佳算法后沖突比例保持在30%以下，而某些隨機排序下則接近100%。
三、擴展工作： VXLAN
隨著 VXLAN等新的協議出現，擴展多租戶云網絡的其他方法也可以被應用于Plugin的通信底層機制。
VLAN （IEEE802.1q）傳統上常被用于為云中的不同租戶和組織提供隔離機制。雖然VLAN通過將網絡分隔為獨立的廣播域解決了2層網絡的問題，但是它無法提供敏捷的服務，可支持的host數目有限。因此，服務需要擴展時不得不適配不同的VLAN，導致服務的分隔。另外，在手工配置的情況下，VLAN配置很容易出錯，難于管理。雖然可以借助于VLAN管理策略服務器（VMPS）和VLAN trunking協議（VTP）自動化地配置access端口和trunk端口，但是網絡管理員很少采用VTP，因為在這種情況下，管理員必須將交換機分為不同VTP域，域中的每一個交換機必須加入域中所有的VLAN，造成不必要的負擔。再加上VLAN頭只提供12位的VLAN ID，網絡中最多有4096個VLAN。考慮到VLAN廣泛的用途，這個數目難堪重任。數據中心虛擬化后進一步增大對VLAN的需求。虛擬可擴展VLAN（VXLAN）是IETF推出的標準，試圖通過引入24位的VLAN網絡標識符（VNI）來消除VLAN的限制，也就是說VXLAN可在網絡中創建16M個VLAN。VXLAN主要利用hypervisor中軟交換（或者硬件接入交換機）的虛擬隧道端點（VTEP）并將與VM相關的VNI和報文進行封裝。VTEP基于IGMP協議加入多播組，這有助于消除未知的單播flood。
限制： VXLAN中16M個VLAN將超過多播組的最大數目，所以屬于不同VNI的多個VLAN可能共享同一多播組。這可能導致安全和性能的問題。
四、總結
基于 OpenFlow交換機部署OpenStack可充分體現SDN的優勢。本項目實現了可擴展的Quantum/Neutron網絡Plugin，同時為后續進一步基于VXLAN等新封裝協議優化改善Plugin提供了設計方向。
京公網安備 11010502049343號