Neutron管理著運行于Openstack之上的虛擬化網絡，并且為開發高級云服務創建了一系列松耦合及其相關的項目，如果把Neutron作為軟件定義網絡(SDN)的一個可擴展性應用是非常方便使用的。

每項服務屬于一個單獨的項目，這些項目由社區驅動，或者來自很多供應商和公司的貢獻。重要的是，OpenStack的Kilo版本包含了12個集成項目：

• Nova(計算)：為云用戶按需提供虛擬服務器/虛擬機。
• Neutron(網絡)：將網絡作為一項服務提供(虛擬網絡服務)。
• Swift(目標存儲)：允許API可訪問的數據鏡像、文件和文檔的存儲和調回。
• Cinder(塊存儲)：為用戶虛擬機提供永久塊存儲。
• Glance(映像)：為計算節點提供一系列的硬盤鏡像，這些鏡像被虛擬機使用，
• Horizon(儀表板)：為管理員或者租戶(用戶)管理Openstack提供基于web的圖形化用戶界面(GUI)。
• Keystone(驗證)：存儲OpenStack服務認證和授權信息。
• Ceilometer(遙測)：監控和測量Openstack云使用信息，為計費、基準測試和統計提供依據。
• Heat(調度):通過合適的API調用為管理云應用提供調度服務。
• Ironic(Baremetal配置):旨在配置裸機代替虛擬機，從Nova的Baremetal驅動分支出來。
• Sahara(大數據作為服務):該項目提供一個簡單的方法來配置一個運行于OpenStack之上以數據為目的的應用集群(Hadoop或者Spark)。
• Trove(數據庫作為服務):該項目旨在提供云數據庫服務，配置相關以及無關的數據庫引擎功能。

虛擬網絡是由租戶或者管理員創建，為OpenStack計算所管理的虛擬機之間提供網絡功能。Neutron是一項網絡管理服務，提供一系列可擴展的API用來創建和管理虛擬網絡。

在Neutron之前，OpenStack有一個簡單、扁平的網絡環境，不支持三層或者防火墻。這種網絡服務內嵌于Nova服務器中，使得網絡發生改變時很難適應。

Neutron的引入是用來將網絡作為一項單獨的服務，為網絡抽象提供不同的解決方案，Neutron服務器提供抽象定義和管理，網絡抽象的具體實施是由組件來實現。這種支持多租戶的基于組件的架構，被認為是與技術無關和模塊化的。我們需要注意Neutron是一項獨立的服務，也就是說，Neutron可以運行為一項自主的服務，暴露API給不同的供應商，提供解決方案或者其他合適的擴展。

Neutron所暴露的API分類與其子分類下支持的操作總結如下。那些操作可以縮寫為CRUD，即創建(C)、閱讀(R)、更新(U)和刪除(D)。核心API涵蓋了基本和必須的網絡操作，而擴展和屬性API的功能是用來構建多功能虛擬網絡。

核心API的操作

• 網絡(CRUD)
• 子網(CRUD)
• 端口(CRUD)

擴展和屬性API的操作

• 配額(RUD)
• 網絡提供商可擴展屬性(CRUD)
• 多個網絡提供商可擴展(CR)
• 綁定擴展屬性的端口(CRU)
• 安全組與規則(CRD)
• 三層網絡功能(CRUD)
• 計費標簽和規則(CRD)
• 負載均衡作為服務(LBaaS)(CRUD)

Neutron架構

軟件定義網絡技術的發展與成熟，基于SDN 技術的網絡虛擬化發展，使得網絡虛擬化可以不再基于物理網絡設備實現，使網絡虛擬化成為云計算網絡技術的核心之一，越來越多的廠商關注網絡虛擬化，并紛紛發布他們關于網絡虛擬化方面的方案。

圖一描述了OpenStack Neutron架構，由以下組件構成：

Neutron服務器

python后臺服務是OpenStack網絡的主要進程，一般運行于控制器節點(openstack部署中的一個術語)。它暴露API來加強網絡模型，并且傳遞請求給netron組件。

#p#

插件

插件可以是核心組件也可以是一項服務。核心插件實現“核心”的Neutron API——二層網絡和IP地址管理。服務插件提供“額外”的服務，例如三層路由、負載均衡、VPN、防火墻和計費。核心組件也可以通過相關的API擴展提供這些網絡服務。簡而言之，組件運行在控制節點上，并且調用網絡API，這些API會同Neutron服務器、數據庫和代理進行交互。

圖一：OpenStack Neutron 架構

插件代理

插件代理指定正在被使用的Neutron插件。他們運行于計算節點之上，并且會同Neutron插件進行交互來管理虛擬交換機。這些代理在許多部署中是可選的，而且在每個虛擬機管理程序上可執行本地虛擬交換機配置。

消息隊列

OpenStack組件，包括Neutron，使用高級消息隊列協議(AMQP)進行內部通信。AMQP代理，RabbitMQ,位于 Neutron的任何兩個內部組件之間，允許它們通過松耦合的方式交互，例如，Neutron組件使用遠程過程調用協議(RPC)與另外一個組件通信。

數據庫

幾乎所有組件都需要用數據庫來維護一個持續的網絡模型;因此,數據庫的語法是由已配置的核心插件和服務插件來定義。

DHCP代理

這個代理是Neutron的一部分，給租戶網絡提供DHCP服務。它維護所需的DHCP配置，且在所有插件中，DHCP代理是相同的(它維護所有組件中相同的DHCP配置)。

三層代理

三層代理負責提供三層和NAT轉發功能，目的是為租戶網絡中的虛擬機提供外網接入。

二層模塊化核心插件

二層模塊化(ML2)是Neutron的核心插件。ML2的引入(從OpenStack的Havana版本開始)是為了替代原有的統一插件 (如，Open vSwitch和Linux橋接-它們僅僅是插件，而不是代理)消除冗余代碼，降低開發和維護成本。根據ML2作者所定義的，模塊化二層組件(ML2)組件是一個允許OpenStack Neutron同時利用二層網絡多樣性技術的架構，該二層網絡技術來源于實際的復雜數據中心。

圖二：ML2 組件結構

ML2通過驅動模型實現模塊化。如圖二所示，它包含了兩類驅動：類型驅動和機制驅動。類型驅動(比如flat、虛擬局域網、GRE和VXLAN等) 定義了一個特殊的二層類型，每個可用網絡類型由對應的類型驅動管理。該驅動維護了類型驅動具體的狀態信息，實現了租戶網絡之間的隔離，這種隔離是由供應商網絡驗證過的。

另一方面，機制驅動是由廠商指定的(比如說OVS，還有來自ODL、Cisco、NEC等廠家的驅動)，基于功能性的類型驅動——支持創建、更新和刪除網絡、子網和端口資源。我們應該注意到供應商有可能執行一整套新的類似于ML2的組件，或者僅僅實現一個機制驅動組件。Salvatore Orlando和Armando Miliaccio的對話使這個決定更容易實現。

#p#

OpenStack和SDN控制器：偉大的藍圖

軟件定義網絡的引入不僅是為了克服Neutron的缺陷，而且是為了提供支持多網絡虛擬化技術(一個集中控制平面創建分隔的租戶虛擬網絡)和方法(來自F5 網絡的Christian Koenning所說的軟件定義網絡和OpenStack)。有了SDN的集成，Neutron極有可能去支持大容量、高密度和多租戶云環境的動態特性。

OpenStack Neutron連同它的插件架構，提供集成SDN控制器到OpenStack的能力。這種SDN控制器使用插件集成Neutron技術提供集中式管理，并且促進OpenStack網絡利用API實現可編程性。

SDN控制器，諸如OpenDaylight、Ryu和Floodlight，運用對應的機制驅動，使用指定的插件或者使用ML2插件，實現Neutron和SDN控制器之間的通信。OpenStack與SDN控制器的融合，如下圖三所示。

在關于SDN控制器的文章里，網絡操作系統如Open Daylight、RYU，或者其他網絡操作系統，負責提供一個完整的網絡(拓撲)視圖，也負責管理(應用、實行和保證)對網絡必要的更新，通過轉換需求去配置(和監控)網絡元素(物理的和虛擬的)。典型地，這些對下層網絡(和網絡元素)的更新來自運行于SDN控制器上的網絡應用，SDN控制器通過北向 API調用。

隨著OpenStack Neutron和SDN控制器的集成，對于網絡和網絡節點的改變也由OpenStack用戶所觸發，被轉換成Neutron API，由Neutron插件和對應的SDN控制器上的代理來處理。例如，OpenDaylight通過Neutron網絡節點上的ML2插件使用北向通信的RestAPI與Neutron交互。當一個OpenStack用戶執行任何與網絡有關的操作時(創建/更新/刪除/閱讀 關于網絡、子網和端口資源)，典型流程如下：

1. 在OpenStack面板(Horizon)的用戶操作將會被轉換成對應的網絡API，并且發往Neutron服務器。

2. Neutron服務器收到請求，然后傳遞請求給配置好的插件(假設ML2配置了一個ODL機制驅動和一個VXLAN類型驅動)。

3. Neutron服務器/插件將會對DB做相應的改變。

4. 插件將從SDN控制器(假設是一個ODL)調用對應的RestAPI。

5. ODL，一旦收到請求，將使用任意的南向插件/協議，例如OpenFlow，OVSDB或者OF-Config，對網絡節點執行必要的改變。

圖三：OpenStack和SDN控制器

在SDN控制器和OpenStack之間仍然存在不同的集成選項，例如，a)SDN控制器作為唯一的控制實體管理網絡，能完全消除計算節點上 Neutron服務器與代理之間的RPC通信，或者 b)SDN控制器僅僅管理物理交換機，虛擬交換機由Neutron服務器直接管理。

引人深思的是：SDN控制器部署選項與OpenStack的集成

SDN控制器部署可以采取不同的形式，如下面三個表格的總結，部署不同排列組合的下列選項是有可能的，例如，我們可以讓非虛擬化的、集成的、單一/冗余的控制器在一個數據中心管理數據中心所有的網絡節點。

SDN控制器虛擬化的好處是，更好的可擴展性——在現有的SDN控制器動態添加更多的資源(比如存儲資源)。在一個虛擬化分布式部署中——SDN控制器由一系列協同工作的虛擬機實現-可以添加額外的虛擬機實例來增加工作負載。

考慮到SDN控制器被虛擬化和集成化/分布式的場景，SDN網絡元素從虛擬到物理實體的變化。此外，數據中心環境下虛擬設施的管理應該適應目前 VIM(虛擬化基礎設施管理員)如OpenStack的編配模型。為了達到這一點，我們面對克服各種各樣的挑戰，諸如性能和動態服務管理。并鼓勵讀者思考在這種場景下創建端到端的解決方案的不同選項。

作者簡介：

Sridhar，2007年新加坡國立大學取得計算機科學博士學位，2000年印度蘇拉卡KREC大學獲得計算機科學碩士學位，1997年印度杜姆吉爾的班加羅爾大學SIT取得儀器與電子本科學位。曾在印度SRM研究院從事研發組長;在新加坡信息通信研發中心(I2R)任職研發員。他曾工作于各種部署方案和部署項目包括ZigBee、WiFi和WiMax。Sridhar目前是NEC印度技術有限公司的技術專家，研發方向主要是下一代有線和無線網絡領域，諸如OpenFlow、軟件定義網絡、軟件定義無線系統為認知網絡、HotSpot 2.0和物聯網。

譯者簡介：

黃雅楠(huangyanan_2006@126.com)，愛立信上海研發中心，主要專攻電信核心網、IP多媒體子系統(IMS)以及基于LTE的語音傳輸(VoLTE)

原文鏈接：http://www.sdnlab.com/11926.html