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組件。
[page]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和物聯網。
譯者簡介：
黃雅楠([email protected])，愛立信上海研發中心，主要專攻電信核心網、IP多媒體子系統(IMS)以及基于LTE的語音傳輸(VoLTE)
原始鏈接：http://www.sdnlab.com/11926.html
京公網安備 11010502049343號