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

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

2. Neutron(網(wǎng)絡(luò))：將網(wǎng)絡(luò)作為一項服務(wù)來提供(虛擬網(wǎng)絡(luò)服務(wù))。

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

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

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

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

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

8. Ceilometer(遙測)：監(jiān)控和測量Openstack云使用情況，用于計費、基準(zhǔn)測試和統(tǒng)計。

9. Heat(編排)：通過使用合適的API調(diào)用，提供用于管理云應(yīng)用程序的編排服務(wù)。

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

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

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

虛擬網(wǎng)絡(luò)由租戶或管理員構(gòu)建，提供了OpenStack計算所管理的虛擬機(jī)之間的聯(lián)網(wǎng)功能。Neutron是一項網(wǎng)絡(luò)管理服務(wù)，提供了一組可擴(kuò)展的API于構(gòu)建和管理虛擬網(wǎng)絡(luò)。

在Neutron之前，OpenStack有一種簡單的扁平網(wǎng)絡(luò)環(huán)境，不支持第3層或者防火墻。它包括在Nova服務(wù)器里面，因而很難適應(yīng)網(wǎng)絡(luò)方面出現(xiàn)的變化。

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

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

核心API的操作

•網(wǎng)絡(luò)(CRUD)

•子網(wǎng)(CRUD)

•端口(CRUD)

擴(kuò)展件和屬性API的操作

•配額(RUD)

•網(wǎng)絡(luò)提供商擴(kuò)展屬性(CRUD)

•多個網(wǎng)絡(luò)提供商擴(kuò)展(CR)

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

•安全組和規(guī)則(CRD)

•第3層網(wǎng)絡(luò)(CRUD)

•計量標(biāo)簽和規(guī)則(CRD)

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

Neutron架構(gòu)

下圖描述了OpenStack Neutron架構(gòu)，該架構(gòu)包括下列部分：

Neutron服務(wù)器

Python守護(hù)進(jìn)程是OpenStack網(wǎng)絡(luò)的主要進(jìn)程，通常在控制器節(jié)點(OpenStack部署中所用的一個術(shù)語)上運行。它暴露API，以執(zhí)行網(wǎng)絡(luò)模型，并將請求傳遞給netron組件。

插件

插件可能是核心插件，也可能是服務(wù)插件。核心插件實施“核心”的Neutron API――第2層網(wǎng)絡(luò)和IP地址管理。服務(wù)插件提供“額外”的服務(wù)，例如第3層路由、負(fù)載均衡、VPN、防火墻和計量。這些網(wǎng)絡(luò)服務(wù)還可以由核心插件通過實現(xiàn)相關(guān)的API擴(kuò)展來提供。簡而言之，插件在控制器節(jié)點上運行，并實施網(wǎng)絡(luò)API，這些API可與Neutron服務(wù)器、數(shù)據(jù)庫和代理進(jìn)行聯(lián)系。

圖一：OpenStack Neutron 架構(gòu)

插件代理

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

消息隊列

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

數(shù)據(jù)庫

幾乎所有插件都需要數(shù)據(jù)庫來維護(hù)持久網(wǎng)絡(luò)模型;因此，數(shù)據(jù)庫模式由已配置的核心插件和服務(wù)插件來定義。

DHCP代理

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

第3層代理

這種代理負(fù)責(zé)提供第3層和NAT轉(zhuǎn)發(fā)功能，以便租戶網(wǎng)絡(luò)上的虛擬機(jī)獲得外部訪問權(quán)。

模塊化第2層核心插件

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

圖二：ML2 插件結(jié)構(gòu)

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

另一方面，機(jī)制驅(qū)動支持網(wǎng)絡(luò)、子網(wǎng)和端口等資源的創(chuàng)建、更新和刪除，這種驅(qū)動是廠商指定的(比如OVS以及來自O(shè)DL、思科和NEC等廠商的驅(qū)動)，基于啟用的類型驅(qū)動。我們應(yīng)該注意到一點，廠商可能實施一種類似ML2的全新插件，或者干脆實施機(jī)制驅(qū)動。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控制器的全局

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

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

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

我們在介紹SDN控制器的文章中發(fā)現(xiàn)，Open Daylight、RYU及其他網(wǎng)絡(luò)操作系統(tǒng)負(fù)責(zé)提供網(wǎng)絡(luò)的完整視圖(拓?fù)浣Y(jié)構(gòu))及其當(dāng)前的一致狀態(tài)。我們還發(fā)現(xiàn)，控制器還通過將需求轉(zhuǎn)變成配置(及監(jiān)控)網(wǎng)絡(luò)元素(物理元素和虛擬元素)，負(fù)責(zé)“管理”(運用、執(zhí)行和確保)必要的網(wǎng)絡(luò)變化。底層網(wǎng)絡(luò)(及網(wǎng)絡(luò)元素)的這些變化通常來自在SDN控制器上運行的網(wǎng)絡(luò)應(yīng)用，使用北向API(northbound API)。

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

1. OpenStack儀表板(Horizon)上的用戶操作將被轉(zhuǎn)換成相應(yīng)的網(wǎng)絡(luò)API，并發(fā)送到Neutron服務(wù)器。

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

3. Neutron服務(wù)器/插件會對數(shù)據(jù)庫做適應(yīng)的變動。

4. 插件會調(diào)用與SDN控制器對應(yīng)的REST API。

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

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

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

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

最后我們談?wù)凷DN面臨的諸多挑戰(zhàn)之一。

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

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

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