【原理解析】OpenStack Neutron架構指南
一.前言
由于OpenStack Neutron項目本身的高度復雜性和抽象性，加之我僅作為一名初學者，其理解能力有限。因此這里，闡述的僅是鳳毛麟角而已，其目的是幫助、引導和我一樣對Neutron又敬又畏的朋友們!如果本文中出現紕漏和錯誤，懇請指正。接受教育，本身也是一種學習。
在這里，需要指出的是，本文僅從宏觀角度而言，起一個引導、拋磚引玉的作用。
——即實現Neutron的整體原理是什么。
好了，下面讓我們一起踏上Neutron這條不歸之路吧!
二.Neutron架構
Neutron項目共由約1千多個文件構成(k版)。
- # tree -l 1 neutron/
- 313 directories, 1224 files
一切，讓我們先從Neutron架構圖說起走吧，如下所示：
分析
1)位于最上層的Neutron Server充當一個門派中的“掌門人”角色(RESTful Server)，負責接受來自外部門派(項目)的API請求，比如Nova API創建網絡的請求。
2)位于中間層的Neutron plugin充當一個門派中的“信使”角色，負責傳達最高層指令給下面的人。
3)位于下層的Neutron Agent充當一個門派中“干活”角色，負責執行一些具體的任務和操作。
類似于各個計算、存儲節點被虛擬化為計算、存儲資源池，Openstack所在的整個物理網絡在Neutron中也被虛擬化為網絡資源池。通過對網絡資源的劃分和可擴展性，Neutron能夠為每個租戶提供獨立的虛擬網絡環境。
Neutron分別提供了二層(L2)vSwitch交換和三層(L3)Router路由抽象的功能，對應于物理網絡環境中的交換機和路由器實現。具體實現了如下功能：
- Router：為租戶提供路由、NAT等服務。
- Network：對應于一個真實物理網絡中的二層局域網(VLAN)，從租戶的的角度而言，是租戶私有的。
- Subnet：為網絡中的三層概念，指定一段IPV4或IPV6地址并描述其相關的配置信息。它附加在一個二層Network上，指明屬于這個network的虛擬機可使用的IP地址范圍。
1. Linux虛擬網絡
Neutron中最為核心的工作便是對二層物理網絡network的抽象與管理。
虛擬機的網絡功能由虛擬網卡(vNIC)提供，Hypervisor可以為每個虛擬機創建一個或多個vNIC，從虛擬機的角度出發，這些vNIC等同于物理的網卡，為了實現與傳統物理網絡一樣的網絡功能，與物理網卡一樣，Switch也被虛擬化成虛擬交換機(OpenvSwitch)，各個vNIC 連接在vSwitch的端口(br-int)上，最后這些vSwitch通過物理服務器的物理網卡訪問外部的物理網絡。
對一個虛擬的二層網絡結構而言，主要是完成兩種網絡設備的虛擬化，即物理網卡和交換設備。在Linux環境下網絡設備的虛擬化主要有以下幾種形式：
1)TAP/TUN/VETH
提到Neutron的虛擬網絡功能實現，不得不先提基于Linux內核級的虛擬設備。
TAP/TUN/VETH是Linux內核實現的一對虛擬網絡設備，TAP工作在二層，收發的是 MAC 層數據幀;TUN工作在三層，收發的是 IP 層數據包。Linux 內核通過TAP/TUN設備向綁定該設備的用戶程序發送數據，反之，用戶程序也可以像操作硬件網絡設備一樣，通過TAP/TUN設備接收數據。
基于TAP設備，實現的是虛擬網卡的功能，當一個TAP設備被創建時，在Linux的設備文件目錄下將會生成一個對應的字符設備文件(/dev/tapX文件)，而運行其上的用戶程序便可以像使用普通文件一樣打開這個文件進行讀寫。
VETH設備總是成對出現的，接收數據的一端會從另一端發送出去，理解為一根虛擬的網線即可。
2)Linux Bridge
Linux Bridge(Linux內核實現的網橋)是工作在二層的虛擬網絡設備，功能類似于物理的交換機。
它的實現原理是，通過將其他Linux網絡設備綁定到自身的Bridge上，并將這些設備虛擬化為端口。為什么我們已經有了OVS，還要有 Linux Bridge 呢?這是因為Linux Bridge實現了qbrxxx設備，提供了OVS無法支持的安全組(Security Group)功能。
3)Open vSwitch
對于云計算中的虛擬網絡而言，交換設備的虛擬化是很關鍵的一環，vSwitch負責連接vNIC與物理網卡，同時也橋接同一物理服務器內的各個VM的vNIC。
因此，我們可以像配置物理交換機一樣，將接入到OpenvSwitch(需要指出的是在多個以上時，vSwitch是分布式虛擬交換機)上的各個 VM分配到不同的VLAN中實現網絡隔離，并且，我們也可以在OVS端口上為VM配置QOS，同時OVS也支持包括NetFlow、sFlow等標準的管理接口和協議。從而，通過這些接口可以實現VM流量監控的任務。
運行在云環境中各種或相同虛擬化平臺上的多個vSwitch實現了分布式架構的虛擬交換機。一個物理服務器上的vSwitch可以透明的與其他服務器上的vSwitch連接通信。
關于OVS更加詳細的內容，請參閱其他資料。
2.Neutron RPC
RPC是neutron中跨模塊進行方法調用的很重要的一種方式，主要包括client端和server端。client端用于發出rpc消息，server端用于監聽消息并進行相應處理。
1)Agent 端RPC
在dhcp agent、 l3 agent、 firewall agent以及metering agent的main函數中都能找到類似的創建一個Agent rpc服務端的代碼。
2)plugin端的rpc
3)neutron-server端的rpc
具體的RPC實現，請參閱源代碼和其他資料。
#p#
三.Neutron 虛擬網絡
1.Neutron網絡資源
通過對上面的了解，我們已經知道了Neutron通過L3虛擬的Router提供路由器功能，通過L2(二層)虛擬的network/subnet /port 提供物理二層網絡的功能，并且其二層network分別由linux bridge和OpenvSwitch等共同實現。
在L2中，Neutron還提供了一個重要的網絡資源抽象Port，其作為虛擬交換機上的一個虛擬端口。當一個port被創建時，默認情況下，會為它分配其指定subnet中可用的IP。
對于L2層虛擬network而言，Linux bridge 和OpenvSwitch只是實現了虛擬網絡的底層機制，并不能代表物理網絡的拓撲類型。而目前，neutron支持如下的網絡類型來映射到真正的物理網絡中：
- Flat
- VLAN
- GRE
- VXLAN
除了上述的L2和L3層虛擬資源外，Neutron還提供了更高層次的一些服務，主要有FWaaS、LBaaS和VPNaaS等。
2. Neutron Plugin
與其他項目服務不同，Neutron只有一個主要的服務進程neutron-server，它運行于網絡控制節點上，提供RESTful API作為訪問Neutron的入口，neutron-server接收到的用戶HTTP請求最終由遍布于計算節點和網絡節點上的各種agent來完成。
Neutron提供的眾多API資源對應了前面所講的各種虛擬網絡資源。其中L2的抽象network/subnet/port可以被認為是核心資源API(Core API)，其他層次的抽象，包括router以及眾多的高層次服務則是擴展資源API(Extension API)。
為了更容易的進行擴展，Neutron項目利用Plugin的方式組織代碼，每一個Plugin支持一組API資源并完成特定的操作，這些操作最終由Plugin通過RPC調用相應的Agent來完成。
這些Plugin又被做了一些區分，一些提供基礎二層虛擬網絡支持的Plugin稱為Core Plugin。而Core Plugin之外的其他Plugin則被稱為Service Plugin，比如提供防火墻服務的FWaaS等。
Agent一般專屬于某個功能，用于使用物理網絡設備或一些虛擬化技術來完成某些實際的操作，比如實現router具體操作的L3 agent。
因為各種Core Plugin的實現之間存在很多重復的代碼，比如對數據庫的CRUD等操作。自H版起，Neutron實現了一個ML2 Core Plugin，它采用了更加靈活的結構進行實現，通過Driver的形式對現有的各種Core Plugin提供支持，因此可以說ML2 Plugin的問世意在取代目前的Core Plugin。
3. Neutron API
Neutron將基于各種虛擬網絡資源得到的API資源分為核心資源(Core API)和擴展資源(Exten API)兩種。Core API只對應于L2層的network/subnet/port三種抽象。其余的各層抽象都屬于Extension API的范圍。Neutron API實現的主要代碼位于/neutron/api目錄。
4. Neutron-server
作為Neutron中的唯一一個服務進程，neutron-server承擔著接收用戶RESTful API請求并分發處理的任務。主要代碼位于neutron/services目錄。
5. ML2 plugin
ML2 plugin被社區提出來的目的是用于取代所有的Core Plugin，它采用了更加靈活的結構進行實現。作為一個Core plugin，ML2 自然會實現network/subnet/port這三種核心資源，同時它也實現了包括Port Binding等在內的部分擴展資源。
ML2實現了網絡拓撲類型(Flat、VLAN、VXLAN、GRE)和底層虛擬網絡(linux bridge、OVS)分離的機制，并分別通過Driver的形式進行擴展。其中，不同的網絡拓撲類型對應著type driver，由type manager管理，不同的網絡實現機制對應著Mechanism Driver(比如Linux bridge、OVS、NSX等)，由Mechanism Manager管理。
詳情，請參閱neutron.plugins.ml2.drivers.mech_agent文件中的AgentMechanismDriverBase類。
6. Port Binding擴展
Extension API有兩種方式擴展現有的資源：一種是為network/port/subnet增加屬性，比如port binding擴展。另外一種就是增加一些新的資源，比如VPNaaS等。
Extension API的定義都位于neutron/extension目錄，他們的基類以及一些公用的代碼則位于neutron/api/extension.py文件。其中Extension Descriptor類是所有Extension API的基類。添加新的資源時需要實現get_resources( )方法，而擴展現有的資源時，則只需要實現get_extended_resources( ) 方法。
7.OpenvSwitch Agent
ML2 Plugin的主要工作是管理虛擬網絡資源，保證數據正確無誤，具體物理設備的設置則由Agent來完成，這里我們宏觀闡述下Neutron項目中的OVS Agent。
基于Plugin rpc提供的信息，OVS Agent負責在計算節點和網絡節點上，通過對OVS虛擬交換機的管理將一個Network映射到物理網絡，這需要OVS Agent去執行一些linux 網絡和OVS相關的配置與操作，Neutron通過如下兩個庫提供了最為基礎的操作接口，從而可以通過Linux Shell命令完成OVS的配置。
比如：
- ovs_lib.py
通過shell執行各種ovs-vsctl操作。
代碼目錄：neutron/agent/common
- ip_lib.py
通過linux的br-ctl命令操作Linux的veth、router、namespace等。
代碼目錄：neutron/agent/linux/
主要是完成如下的一些工作：
- agent初始化
- agent和Plugin RPC的通信
- br-int創建與初始化
- br-eth初始化
- br-tun初始化
- 創建Tunnel Port
- 分配LVID(Local VLAN ID)
- L2 population
8. Service plugin
Neutron中除了network、port、subnet這三種二層的核心資源外，其他的都被作為Extension API進行實現，隨著ML2的成熟和發展，Extension API 的實現演變為兩種方式，一種是實現在某個Core plugin內，比如ML2內的port binding、Security Group等。
另一種就是使用Service plugin的方式，去實現FWaaS、LBaaS、VPNaaS等高級服務。
代碼目錄：neutron/services
至此，我們已經從宏觀上認識了Neutron架構，接下來的則是自己考究了。
