將Neutron索性看作是一種軟件定義網絡(SDN)應用大有幫助。更具體地說，它可以管理在OpenStack上運行的網絡虛擬化，并創建一系列松散耦合的相關項目，用于開發高級云服務。這些服務每個還都是獨立項目，受社區和許多捐獻代碼的廠商和公司的共同驅動。重要的是，OpenStack Kilo版本共有12個集成的項目。

1. Nova(計算)：為云用戶按需提供虛擬服務器/虛擬機。

2. Neutron(網絡)：將網絡作為一項服務來提供(虛擬網絡服務)。

3. Swift(對象存儲)：允許存儲并檢索可通過API來訪問的數據映像、文件和文檔。

4. Cinder(塊存儲)：為用戶虛擬機提供永久塊存儲。

5. Glance(映像)：為虛擬機使用的計算節點提供一系列虛擬磁盤映像。

6. Horizon(儀表板)：提供基于Web的圖形化用戶界面(GUI)，以便管理員或租戶(用戶)管理Openstack。

7. Keystone(身份)：存儲用于為OpenStack提供驗證和授權機制的信息。

8. Ceilometer(遙測)：監控和測量Openstack云使用情況，用于計費、基準測試和統計。

9. Heat(編排)：通過使用合適的API調用，提供用于管理云應用程序的編排服務。

10. Ironic(裸機配置)：旨在配置裸機而不是虛擬機，從Nova Baremetal驅動(driver)派生而來。

11. Sahara(大數據即服務):該項目提供了一種簡單的方法，可以在OpenStack上配置數據密集型的應用集群(Hadoop或Spark)。

12. Trove(數據庫即服務)：該項目旨在為關系數據庫引擎和非關系數據庫引擎提供云數據庫即服務配置功能。

虛擬網絡由租戶或管理員構建，提供了OpenStack計算所管理的虛擬機之間的聯網功能。Neutron是一項網絡管理服務，提供了一組可擴展的API于構建和管理虛擬網絡。

在Neutron之前，OpenStack有一種簡單的扁平網絡環境，不支持第3層或者防火墻。它包括在Nova服務器里面，因而很難適應網絡方面出現的變化。

當初之所以引入Neutron，是為了將網絡當作一項單獨服務，并為抽象提供不同的實施方案――Neutron服務器提供抽象定義和管理，而抽象的具體實施由插件來實現。這種基于插件的多租戶支持框架可以說與與技術無關、具有模塊化特性。我們需要注意的是，Neutron是一項獨立式服務――也就是說，它可以作為一項自主服務來運行，暴露不同廠商的API，提供實施和任何合適的擴展。

下面總結了API類別以及每個子類下面的支持操作。這些操作可以縮寫為CRUD，即創建、讀取、更新和刪除。核心API涵蓋了基本而必要的網絡操作，而擴展和屬性API涵蓋了功能豐富的虛擬網絡的必要操作。

核心API的操作

•網絡(CRUD)

•子網(CRUD)

•端口(CRUD)

擴展件和屬性API的操作

•配額(RUD)

•網絡提供商擴展屬性(CRUD)

•多個網絡提供商擴展(CR)

•端口綁定擴展屬性(CRU)

•安全組和規則(CRD)

•第3層網絡(CRUD)

•計量標簽和規則(CRD)

•負載均衡即服務(LBaaS)(CRUD)

Neutron架構

下圖描述了OpenStack Neutron架構，該架構包括下列部分：

Neutron服務器

Python守護進程是OpenStack網絡的主要進程，通常在控制器節點(OpenStack部署中所用的一個術語)上運行。它暴露API，以執行網絡模型，并將請求傳遞給netron組件。

插件

插件可能是核心插件，也可能是服務插件。核心插件實施“核心”的Neutron API――第2層網絡和IP地址管理。服務插件提供“額外”的服務，例如第3層路由、負載均衡、VPN、防火墻和計量。這些網絡服務還可以由核心插件通過實現相關的API擴展來提供。簡而言之，插件在控制器節點上運行，并實施網絡API，這些API可與Neutron服務器、數據庫和代理進行聯系。

圖一：OpenStack Neutron 架構

插件代理

這種代理是使用的Neutron插件所特有的。它們在計算節點上運行，并與Neutron插件進行聯系，以管理虛擬交換機。這種代理在許多部署環境中是可選的，在每個虛擬機管理程序上執行本地虛擬交換機配置。

消息隊列

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

數據庫

幾乎所有插件都需要數據庫來維護持久網絡模型;因此，數據庫模式由已配置的核心插件和服務插件來定義。

DHCP代理

這種代理是Neutron的一部分，為租戶網絡提供了DHCP服務。它維護所需的DHCP配置，對所有插件而言都一樣。

第3層代理

這種代理負責提供第3層和NAT轉發功能，以便租戶網絡上的虛擬機獲得外部訪問權。

模塊化第2層核心插件

模塊化第2層(ML2)是Neutron的核心插件。ML2在OpenStack的Havana版本中引入，旨在取代原有的整塊式插件(比如Open vSwitch和Linux Bridge――這些只是插件，而不是代理!)，從而消除冗余代碼，減少開發和維護工作量。按照ML2作者的定義，“模塊化第2層(ML2)插件是一種框架，允許OpenStack Neutron同時利用復雜的實際數據中心中出現的各種第2層網絡技術。”

 

圖二：ML2 插件結構

ML2通過驅動模型(driver model)來實現模塊化。如圖所示，它包括兩類驅動：類型和機制。類型驅動(比如flat、虛擬局域網、GRE和VXLAN)定義了特定的第2層類型，其中每個可用網絡類型由相應的類型驅動管理。該驅動維護針對特定類型的狀態信息，并實現了租戶網絡之間的隔離，另外還能驗證提供商網絡。

另一方面，機制驅動支持網絡、子網和端口等資源的創建、更新和刪除，這種驅動是廠商指定的(比如OVS以及來自ODL、思科和NEC等廠商的驅動)，基于啟用的類型驅動。我們應該注意到一點，廠商可能實施一種類似ML2的全新插件，或者干脆實施機制驅動。Salvatore Orlando和Armando Miliaccio的一番談話可能幫助我們更容易做出這個決定：https://www.openstack.org/summit/openstack-summit-hong-kong-2013/session-videos/presentation/how-to-write-a-neutron-plugin-if-you-really-need-to。

#p#

OpenStack和SDN控制器的全局

軟件定義網絡的引入不僅是為了克服Neutron的不足，還為了支持多種網絡虛擬化技術(集中式控制平面構建隔離的租戶虛擬網絡)和方法。由于在SDN上集成，Neutron有望支持大規模、高密度的多租戶云環境具有的動態性。

OpenStack Neutron及其插件架構提供了將SDN控制器集成到OpenStack的功能。使用插件將SDN控制器集成到Neutron的這種做法提供了集中式管理，還為使用API對OpenStack網絡實現網絡可編程性提供了方便。

OpenDaylight、Ryu和Floodlight等SDN控制器使用特定的插件或擁有相應機制驅動的ML2插件，允許Neutron和SDN控制器之間進行通信。下圖顯示的全局表明了OpenStack與SDN控制器集成。

我們在介紹SDN控制器的文章中發現，Open Daylight、RYU及其他網絡操作系統負責提供網絡的完整視圖(拓撲結構)及其當前的一致狀態。我們還發現，控制器還通過將需求轉變成配置(及監控)網絡元素(物理元素和虛擬元素)，負責“管理”(運用、執行和確保)必要的網絡變化。底層網絡(及網絡元素)的這些變化通常來自在SDN控制器上運行的網絡應用，使用北向API(northbound API)。

由于OpenStack Neutron和SDN控制器的這種集成，還可以從OpenStack用戶觸發網絡及網絡元素的變化，這些變化可以轉換成Neutron API，并由Neutron插件和SDN控制器中運行的相應代理來處理。比如說，OpenDaylight與Neutron進行通信所采取的方式是，采用Neutron網絡節點上的ML2插件，并經由使用北向通信的REST API。如果OpenStack用戶執行任何網絡相關操作(創建/更新/刪除/讀取網絡網絡、子網和端口等資源)，典型流程將如下所示：

1. OpenStack儀表板(Horizon)上的用戶操作將被轉換成相應的網絡API，并發送到Neutron服務器。

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

3. Neutron服務器/插件會對數據庫做適應的變動。

4. 插件會調用與SDN控制器對應的REST API。

5. 一收到請求，ODL會使用任何南向插件/協議，比如OpenFlow、OVSDB或OF-Config，對網絡元素做必要的變化。

 

圖三：OpenStack和SDN控制器的全局

值得注意的是，SDN控制器和OpenStack方面存在不同的集成選項;比如說，a)可以完全消除Neutron服務器與計算節點上的代理之間的RPC通信，SDN控制器作為管理網絡的唯一實體;或者 b)SDN控制器只由物理交換機管理，虛擬交換機可以從Neutron服務器直接管理。

SDN控制器部署選項和OpenStack集成

最后我們談談SDN面臨的諸多挑戰之一。

部署的SDN控制器可能具有不同的形式，如下面三張表格總結的那樣。可以采用下列不同組合的選項來加以部署。比如說，我們在數據中心中可能有非虛擬化、集成的單一/冗余控制器，管理數據中心的所有網絡元素。

選項	描述
非虛擬化	整個控制器實例在單一系統（物理機）上運行
虛擬化	控制器實例在虛擬化環境（虛擬機）中運行

選項	描述
集成式	所有SDN控制器功能在單一實例下運行
分布式	SDN控制器功能呈分布式

選項	描述
單一/冗余	面向網絡的單一（或冗余）控制器
層次化	采用層次結構的控制器，而控制器之間可能有客戶機/服務器關系

SDN控制器虛擬化的好處包括，能夠更有效地向上擴展和向外擴展――為現有的SDN控制器動態添加更多的資源(比如存儲資源)。在虛擬化分布式部署環境中――SDN控制器被實施成一組協同工作的虛擬機，面對增加的工作負載，可以添加額外的虛擬機實例。

設想這種場景：SDN控制器呈虛擬化和集成化/分布式，SDN網絡元素包括虛擬元素和物理元素。此外，管理數據中心環境下的這些虛擬基礎設施應該適合現有的編排模型――與OpenStack等當前的VIM(虛擬化基礎設施管理器)集成起來。為了做到這一點，我們必須面對克服種種挑戰，比如性能和動態服務管理。鼓勵讀者認真考慮在這種場景下構建端到端解決方案的不同選項。