軟件定義網絡(SDN)是一種新型的網絡架構，它使用一個集中控制器來控制數據層面的數據流。這種新方案使網絡管理更容易，并能夠節約成本。云計算技術的進步促進了云管理工具的發展，OpenStack就是云管理工具的代表。它使用網絡組件Neutron(原來是Quantum)提供網絡虛擬化服務，允許租戶創建和管理虛擬網絡，并且提供標準化的插件架構，便于連接SDN控制器。但是Neutron的擴展性不好，不能滿足虛擬化環境的動態特性，并且對網絡資源的控制是有限的。SDN可以為Neutron提供附加功能，如集中控制、無縫網絡、多租戶和網絡可伸縮性。
在本文中，我們將測試SDN控制器和OpenStack集成的功能和可用性;調查分析業界對SDN與OpenStack集成的看法;利用商業調查結果和測試用例來突出SDN使用的障礙、預算分配、OpenStack分布和SDN控制器等主題。這將幫助我們評估SDN和OpenStack是否能夠作為一個IaaS解決方案。
1 研究的問題
SDN和OpenStack可以一起推動IaaS的發展嗎?
我們將研究的問題劃分成3個子問題。
1)SDN和OpenStack集成的最佳方案是什么?
2)行業和社區對SDN和OpenStack的觀點是什么?
3)SDN和OpenStack集成后的性能和功能可以滿足行業需求嗎?
2 集成SDN與OpenStack
2.1 OpenStack
2010年7月，Rackspace和NASA啟動開源的云管理軟件OpenStack。這是創新軟件項目的集合，為快速供應、創造和管理公有云和私有云中的虛擬設備提供了一個架構，本質上是作為基礎設施即服務(IaaS)。所有服務協同使用API來提供靈活和可擴展的云解決方案。它也有許多項目在孵化階段，并在社區分階段開發并發布。圖1顯示了OpenStack9個主要的模塊。
圖1 OpenStack架構
Nova(Compute)：為云用戶提供虛擬服務器。
Neutron(Networking)：為OpenStack的Compute節點管理的接口設備提供網絡服務(虛擬網絡服務)。
Object Storage(Swift)：存儲和檢索數據(圖片、文件、文檔)。
Block Storage(Cinder)：為用戶虛擬機提供持久的塊存儲服務。
Image(Glance)：為Compute節點提供一個虛擬鏡像。
Dashboard(Horizon)：提供了基于web的圖形用戶界面(GUI)，讓云管理員和租戶(用戶)來管理OpenStack。
Identity(Keystone)：它存儲的信息為OpenStack提供身份驗證和授權服務。
Celiometer：通過監視和測量OpenStack云的使用來計費、設置標準和統計。
Heat：通過調用適當的API來管理云應用。
2.2 Neutron的功能
Neutron添加了一層虛擬的網絡服務讓租戶(用戶)構建自己的虛擬網絡。Neutron是對網絡的虛擬化，該網絡可以從一個地方移動到另一個地方，而不會影響現有的連接。它可以進一步解釋為一個網絡管理服務，為創建和管理虛擬網絡公開了一組可擴展的API(通過創建虛擬網絡為OpenStack Compute節點上的虛擬機提供網絡服務)。Neutron的插件架構為開源社區或第三方服務提供API。Neutron還允許供應商研究和添加新的插件，提供先進的網絡功能。
目前，Neutron的虛擬網絡服務沒有傳統網絡成熟。下圖描述了與Neutron組件交互的代理。組成Neutron的元素如下：
Neutron-server是python虛擬光驅, 是OpenStack網絡運行在Network節點的主過程。
Plugin agents和Neutron插件一起管理虛擬交換機，Plugin agents依賴Neutron插件。
DHCP agent是Neutron的一部分，為租戶的網絡提供DHCP服務。
L3 agent負責層3和NAT轉發來獲得租戶虛擬機的外部訪問。
SDN services：這些服務為租戶網絡提供附加的功能，通過API與plugin agents或neutron-server進行交互。
圖2 Neutron和SDN集成代理
在大規模、高密度、多租戶云環境中，Neutron的性能會下降。Neutron的低擴展能力還不能緊跟云環境的動態特性，但它提供了插件將SDN 控制器集成到OpenStack，達到將應用程序從IP地址、VLAN和端口等網絡環境中分離的目的，并且能夠節省時間和降低運營成本。
2.3 SDN及其與OpenStack的集成
引入SDN主要是克服Neutron的缺陷，SDN是一種網絡技術,通過集中的可編程控制平面來管理整個數據平面。這樣網絡運營商和供應商可以控制和管理自己的虛擬化資源和網絡。SDN是一種新型的網絡模式，允許硬件和操作系統之間以及物理/虛擬網元和操作系統之間通過開放API通信。
SDN模型中的網絡操作系統(NOS)，例如OpenDaylight、RYU、Floodlight和POX，負責提供網絡和其當前狀態的一個完整視圖。同時NOS也負責管理網絡變化，并將這些變化通知到網絡硬件和物理/虛擬網絡應用程序中。底層網絡的變化來自于運行在NOS上的網絡應用程序 (Neutron API, REST/JSON, Java RPC)，NOS通過北向API與應用程序通信，通過南向API管理和控制底層物理和虛擬硬件，使用的南向協議包括OpenFlow、OVSDB 、 OF-config和XMPP等。
SDN控制器以插件方式集成到Neutron中并提供集中式管理,有利于OpenStack網絡通過API提高網絡的可編程性。SDN控制器，像 OpenDaylight、Ryu和Floodlight等使用各自的插件讓Neutron和SDN控制器交互。下圖給出了SDN集成到 OpenStack的大體思路。
圖3 SDN集成到OpenStack
OpenDaylight使用北向Rest API通過網絡節點的二層插件與Neutron通信。RYU通過北向REST API將Neutron節點的RYU插件和RYU控制器連接，使用Compute節點的RYU代理和RYU插件交互。OpenDaylight和RYU都使用Open vSwitch數據庫(OVSDB)和南向OpenFlow協議與計算(nova)節點的虛擬交換機交互。
3 研究方法
通過回答三個子問題來回答主要研究的問題，如下分兩步解決子問題。
首先分別評估獨立部署OpenStack和其集成SDN控制器的性能和功能，這將解答子問題1和3。其次，組織開展一次商業調查，參與者是OpenStack和SDN社區的成員，這將幫助了解行業內對這兩種技術的觀點。
以下是測試床的主要組件
1)OpenStack分布
2)SDN控制器
3)硬件(服務器，交換機)
為本次研究選擇一種OpenStack分布，測試參數主要包括如下：易于安裝、可擴展性、開放性、社區支持、文檔、成本因素。選擇好合適的 OpenStack分布后，我們部署了一個多節點的OpenStack，其中一臺服務器上部署計算節點，另一臺服務器部署控制器、Neutron、 nova組件和glance。我們根據節點的功能分配資源(RAM、Storage，CPU)。
選擇與OpenStack集成的SDN控制器需要研究的參數如下：開源、實現的語言、GUI、支持平臺、OpenFlow版本、OpenStack Neutron組件、行業支持。
基于以上的結論，我們選擇如表1所示規格開發測試床。
表1 測試環境的參數
我們基于VMware ESXi在控制器和Compute節點部署Havana版本的OpenStack。
圖4 SDN和OpenStack集成(測試床)
為了回答第二個子問題，我們通過商業調查來了解SDN和OpenStack在行業內的狀態。 通過使用“SoGo Survey”調查工具在社會媒體網站(Facebook和LinkedIn)粘貼調查鏈接，并訪問業內專家。我們還采訪了研究SDN和 OpenStack 的專家了解目前情況和未來的趨勢，用數據分析工具得出調查結果。
回答第三個子問題，驗證SDN控制器和OpenStack集成的性能和功能是否滿足行業內的需求。我們用一系列的測試用例驗證和評估SDN控制器和OpenStack的集成。測試用例如下：
表2 數據平面測試用例
表3 功能測試用例
4 研究結果
圖5的調查結果顯示，73.68%的受訪者相信OpenStack和SDN會一起推動未來的基礎設施及服務(IaaS)。
圖5 SDN與OpenStack集成的未來(商業調查)
為了確定第一個子問題的答案，我們比較了基于預定義參數的不同的OpenStack分布，表4顯示了不同OpenStack分布的評估結果。
表4 不同OpenStack的比較
圖6的調查結果顯示，OpenStack開源安裝和DevStack是最受歡迎的版本。
圖6 被調查者對OpenStack分布的選擇(商業調查)
根據表2和圖6的調查結果，我們選擇DevStack作為本次調研的OpenStack分布。
為了選擇SDN控制器，我們調研當前流行的幾種開源SDN控制器，并且根據預定義參數比較其性能。表5顯示了比較結果，之后我們會繼續采用商業調查方式來肯定該調研結果。
表5 SDN控制器比較
商業調查的受訪者首選OpenDaylight、其次是Floodlight來提高Neutron的功能。綜合圖7和表5，我們選擇OpenDaylight和RYU控制器集成到DevStack環境。
圖7 受訪者對SDN控制器的選擇
為了確定第二子問題的答案，我們分析了商業調查結果。結果表明，45%的受訪者認為SDN和Neutron滿足他們組織的IaaS需要(圖8)。
圖8 受訪者對SDN和Neutron前景的觀點
當被問及OpenStack集成SDN后，SDN的哪些特性可以提高時(如圖9)，大約50%的參與者支持多租戶、網絡可擴展性、網絡可視性和無縫網絡等功能。
圖9 OpenStack集成SDN后可以提高的性能
當被問及目前采用SDN遇到的障礙，52%的參與者認為“當前產品不成熟”是一個主要的障礙。39%參與者認為“缺乏適當的資源評估SDN”(圖10)。
圖10 采用SDN的障礙(商業調查)
當被問及是否愿意將SDN(圖11)添加到到他們的實際網絡，42%的參與者是“非常愿意”或“完全愿意”，同時其他42%比較愿意對他們的產品做出顯著的改變來支持SDN。
圖11 SDN在生產網絡中的接受度
當被問及對SDN的預算分配，60%的受訪者愿意將他們主要的經費用于SDN部署(圖12)。
圖12 部署SDN的預算分配(商業調查)
為了評估集成SDN和OpenStack的性能和功能，我們使用第一個研究子問題的結果(OpenDaylight和RYU控制器與DevStack結合)進行數據平面和功能測試。測試用例的結果如表6和7所示：
表6 數據平面測試
表7 功能測試
從上面的測試用例結果可以幫助我們確定當前OpenDaylight和RYU控制器集成到OpenStack的程度。
5 結果討論
根據研究結果，我們選擇DevStack作為OpenStack的搭建方式。DevStack由于提供了高度可擴展的和靈活的測試環境，所以可以根據我們的要求迅速重建。而較多人選擇的OpenStack開源分布安裝是一個復雜的安裝過程，很難擴展。其他的選擇如Mirantis和RDO不滿足研究需求。接下來我們對四個流行的開源SDN控制器進行比較，我們首選OpenDaylight和RYU而不是POX和 Floodlight。因為POX不支持與OpenStack的集成，并且Floodlight和DevStack(OpenStack)集成會出現各種問題阻礙我們進行進一步的測試。
我們根據商業調查結果分析該行業對SDN和OpenStack的看法。我們的被調查者相信SDN和Neutron一起可以滿足他們的IaaS需求。參與者覺得SDN給OpenStack帶來了一些特性，如網絡可視性、無縫的網絡和網絡可擴展性，這些從我們的測試結果得以驗證。但受訪者擔心SDN控制器是不成熟的，評估起來也相當困難。SDN控制器集成OpenStack還不成熟，我們在測試階段驗證了這個結果。調查的結果還顯示在未來幾年，受訪者有意愿改變他們的生產網絡并分配大部分的預算支持SDN。從我們的商業調查結果顯示參與者對SDN集成OpenStack有很高的接受度。
分析數據平面測試結果時，我們觀察到在吞吐量、流量延遲和單向的TCP傳輸等參數上，OpenDaylight落后RYU，但 OpenDaylight在功能和可用性上比RYU更好。這兩個控制器通過了第三層的功能測試，VM遷移測試和容錯測試。然而，隨著虛擬機數量的增加，控制器無法執行，我們在測試部署遇到意想不到的失敗，證明這是一個不穩定的解決方案。從我們的測試、研究發現，SDN控制器目前每秒可以處理大約1000條流。另一方面，一個數據中心每秒處理大約100000條流。這清楚地表明當前SDN控制器的功能和數據中心的需求差距很大。此外，在集成SDN和 OpenStack的過程中若出現了問題，我們可以參考的文檔資源很有限。
盡管SDN和OpenStack集成是一個進化的IaaS解決方案，但目前在高利用率的環境下不可靠，所以不能用于生產環境。不過即使當前 OpenStack和SDN有很多約束，但我們堅信，這兩種技術將推動IaaS的未來發展，因為它們的功能正迅速發展，行業的接受度也很高。根據我們的調查結果推斷產業愿意投資他們主要的IT預算來部署這些技術。所有這些特性將有助于推動控制器和OpenStack性能開發的快速發展,有助于推動IaaS 的未來。
6 結論
基于已有的技術和商業調查結果，我們知道SDN集成OpenStack仍沒有完全成功，還有很多需要改進。這主要是因為集成解決方案還欠完備，特性集不完整，編排不可靠和相關文檔匱乏。行業內認為SDN在性能和功能上仍滯后于傳統的網絡基礎設施，同時OpenStack目前還沒有能力與市面上的商業產品競爭，像亞馬遜網絡服務(AWS)、微軟Azure、VMWare云等。然而SDN和OpenStack有大量的開發者基礎和行業支持，我們相信在大約兩年的開發和測試后，OpenStack和SDN集成將達到生產準備的要求并被廣泛采用。我們相信，匹配行業需求的性能和功能將成為OpenStack 和SDN一起推動IaaS未來的關鍵因素。SDN和OpenStack中網絡功能的虛擬化的引入將擴大IaaS的接受度。
京公網安備 11010502049343號