基於OpenFlow交換機的OpenStack部署實踐

    譯註：本項目平臺爲美國伊利諾伊大學的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控制器在擴展性方面的缺陷。

1、簡介

    雲計算愈來愈普及，雲提供的彈性和服務的動態提供日益受人矚目。隨着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的集中控制，咱們還會演示基於控制器的虛機遷移應用。

2、實現方法

    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%。

3、擴展工做：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可能共享同一多播組。這可能致使安全和性能的問題。

4、總結

基於OpenFlow交換機部署OpenStack可充分體現SDN的優點。本項目實現了可擴展的Quantum/Neutron網絡Plugin，同時爲後續進一步基於VXLAN等新封裝協議優化改善Plugin提供了設計方向。

本文來源於SDNLAB，可點擊此閱讀原文。若是您對本文感興趣，可參與如下互動方式與做者近距離交流。

（1） 微博（http://weibo.com/sdnlab/）

（2） 微信(帳號：SDNLAB)

（3） QQ羣

SDN研究羣（214146842）

OpenDaylight研究羣（194240432）