Openstack中Neutron的實現模型
眾所周知，整個Open stack中網絡是通過Neutron組件實現，它也成為了整個Open stack中最復雜的部分，本文重點介紹Neutron的實現模型與應用場景，閑言少敘，步入正題。
1. Neutron的架構
Neutron的架構如下圖所示： 
Neutron Serve由Core Plugins和Service Plugins組成，原生Neutron的Core Plugins使用的是ML2插件，它又分為類型驅動和機制驅動，可以提供基礎的網絡類型和實現機制，高級的功能如×××等通過Service Plugins實現，同時Neutron作為一個開放性的組件，允許廠商在1，2，3位置處對接自己的插件，本文采用Core Plugins的ML2插件進行說明，通過OVS重點講述VLAN和VXLAN類型的網絡。
以3節點為例，Open stack由控制節點，網絡節點和計算節點組成，當位於控制節點的Neutron server通過RESTful或CLI接收到請求後，會通過RPC的方式將信息傳遞給網絡和計算節點的Agent，Agent在指揮具體的程序實現功能
舉例來說，當Neutron Server通過CLI接收到開啟DHCP功能的指令後，會將該指令下發給DHCP Agent，DHCP Agent則通過dnsmasq這個具體程序來實現DHCP功能，L3 Agent則是由開啟了轉發功能的Linux內核來實現。
3. Linux網絡虛擬基礎
通過上文也得知Neutron本身不做具體功能的實現，此處對Neutron中經常涉及的虛擬網絡設備進行說明。虛擬網絡設備也稱為虛擬網元，不同於現實中的物理設備，Linux中一個類似於數據結構，內核模塊或設備驅動都可以稱為一個設備，舉例來說，一個硬盤在創建了多個分區後每一個分區在Linux下都是一個設備，通過以上概念，引出以下設備：
Tap設備是Linux內核中二層的虛擬網絡設備，只與二層中的以太網協議對應，所以常被稱為虛擬以太網設備，它實現的是虛擬網卡的功能。
（2）名稱空間
namespace簡稱ns，傳統的Linux資源是全局的，ns是在一個HOST內創建了許多隔離的空間，彼此相互看不見，將全局的資源變成特定ns中獨有的資源，ns可以隔離的資源有
| 資源 | 含義 |
|---|---|
| uts_ns | UTS為Unix Timesharing System的簡稱，包含內存名稱、版本、底層體系結構等信息 |
| ipc_ns | 所有與進程通信（IPC）有關的信息 |
| mnt_ns | 當前裝載的文件系統 |
| pid_ns | 有關進程PID的信息 |
| user_ns | 資源配額的信息 |
| net_ns | 網絡信息 |
具體到網絡視角，每一個ns中都有一個獨立的網絡協議棧。
（3） veth pair
虛擬以太網接口，成對出現，可以理解為虛擬網線，數據從一頭發進去會從另一頭發出，連接不同的ns或者虛擬網元。 
（4） Bridge
虛擬交換機，即前文中的OVS或者Linux Bridge，具體實現請參考作者其他博文，本處不再贅述。
用一個示例對上述概念進行說明，如下圖所示：
一個host主機內有4個ns，通過1對veth pair連接到vbridge上 
創建veth pair對
[root@host3 ~]# ip link add tap1 type veth peer name tap1_peer
[root@host3 ~]# ip link add tap2 type veth peer name tap2_peer
[root@host3 ~]# ip link add tap3 type veth peer name tap3_peer
[root@host3 ~]# ip link add tap4 type veth peer name tap4_peer 創建ns
[root@host3 ~]# ip netns add ns1
[root@host3 ~]# ip netns add ns2
[root@host3 ~]# ip netns add ns3
[root@host3 ~]# ip netns add ns4 把tap移動到對應的ns中
[root@host3 ~]# ip link set tap1 netns ns1
[root@host3 ~]# ip link set tap2 netns ns2
[root@host3 ~]# ip link set tap3 netns ns3
[root@host3 ~]# ip link set tap4 netns ns4 創建bridge
[root@host3 ~]# yum install bridge-utils.x86_64 -y
[root@host3 ~]# brctl addbr br1 把tap peer添加到對應的bridge中
[root@host3 ~]# brctl addif br1 tap1_peer
[root@host3 ~]# brctl addif br1 tap2_peer
[root@host3 ~]# brctl addif br1 tap3_peer
[root@host3 ~]# brctl addif br1 tap4_peer 配置對應tap的IP地址
[root@host3 ~]# ip netns exec ns1 ip addr add 192.168.10.1/24 dev tap1
[root@host3 ~]# ip netns exec ns2 ip addr add 192.168.10.2/24 dev tap2
[root@host3 ~]# ip netns exec ns3 ip addr add 192.168.10.3/24 dev tap3
[root@host3 ~]# ip netns exec ns4 ip addr add 192.168.10.4/24 dev tap4 將bridge和所有tap設備up
[root@host3 ~]# ip link set br1 up
[root@host3 ~]# ip link set tap2_peer up
[root@host3 ~]# ip link set tap2_peer up
[root@host3 ~]# ip link set tap3_peer up
[root@host3 ~]# ip link set tap4_peer up
[root@host3 ~]# ip netns exec ns1 ip link set tap1 up
[root@host3 ~]# ip netns exec ns2 ip link set tap2 up
[root@host3 ~]# ip netns exec ns3 ip link set tap3 up
[root@host3 ~]# ip netns exec ns4 ip link set tap4 up 驗證結果
[root@host3 ~]# ip netns exec ns4 ping 192.168.10.1 二、Neutron的網絡實現模型
1. 整體網絡模型
還是以3節點為例，此時網絡模型如下圖所示： 
通過上圖可以知道，在原生Open stack下，所有計算節點中的VM，如果需要訪問外網，都必須經過網絡節點，每1個租戶都有自己的DHCP和Router，通過ns進行隔離。其中對外部網絡需要特別強調：Neutron中所說的外部網絡是其不能管理的網絡，不一定是公網。
2. 計算節點實現模型
2.1 VLAN實現模型
本小節重點介紹計算節點的實現模型，在Neutron中數據報文有個內外轉換的概念，舉例說明：假設Host1節點的VM1-1與Host2節點的VM2-1都屬於VLAN10，此時Neutron使用VLAN網絡類型，它們之間通信的流程為： 
（1）VM1-1發出純報文（VM可以接受和發送帶VID的保溫，在後文介紹）到qbr-xx。qbr-xx是一個Linux bridge設備，他與VM1-1之間通過tap設備連接，他們之間其實只有1個tap設備，可以理解為tap設備一半在br上一半在VM上，此處為了便於理解畫了2個tap，qbr-xx的作用在於應用安全功能，原生的OVS不支持安全功能（Stateful openflow已經支持），qbr-xx與VM的數量是1:1對應。
（2）報文在進入br-int的接口時打上VID10，br-int管理著本地網絡層，每個計算和網絡節點上都有且只有1個br-int。
（3）報文離開br-int，此時VID為10，在br-ethx處VID轉換為100，通過br-ethx離開Host1。br-ethx管理著租戶網絡層，即租戶所創建的網絡位於該層。
（4）報文經過物理交換機到達Host2，進入br-ethx，在br-ethx出口處VID由100轉換成10。
（5）報文流出br-ethx出口，進入br-int，此時VID為10，在離開br-int出口時Untag，以純以太網報文進入qbr-xx最後進入VM1-2。
2.2 VXLAN實現模型
如果Neutron的網絡類型是VXLAN，他與VLAN的流程大體上相似，只是不再進行VID的轉換，取而代之的是將VLAN封裝為VXLAN： 
上圖中br-tun和br-ethx都是由OVS實現，不同於br-ethx所執行的普通二層交換機功能，br-tun所執行的是VXLAN中的VTEP功能，2個IP為VXLAN的隧道終結IP。
3.網絡節點實現模型
從網絡角度看，網絡節點分為4層，前2層與計算節點幾乎相同，不再贅述，網絡服務層中1個網絡1個DHCP Service（通過dns masq程序實現），Router由開啟了轉發功能的Linux內核實現，提供了SNAT和DNAT功能，每1個DHCP和Router都運行在ns中。外部網絡層的br-ex一般也選用OVS，其上綁定的IP地址為FIP，為內部的VM提供DNAT功能。 
三、產生的疑問
通過上述的介紹可能會有人產生以下疑問：
1.不同於VXLAN的再次封裝，VLAN為什麽要有2個OVS（br-int和br-ethx），並且還必須經過1次VID轉換。
2.無論是VID（內部）到VID（租戶）還是VID到VNI，他們的對應關系是如何建立的。
以下就這兩個問題進行進一步的說明。
1.VID轉換的意義
前文得知，每個網絡和計算節點有且只有1個br-int，內部網絡又是由Neutron自行維護，同時Open stack也是允許租戶同時存在多種類型的網絡，比如租戶同時使用的VLAN和VXLAN，假如VLAN網絡類型下沒有br-ethx，租戶創建的VNI100按照算法轉換過來VID也是10，這樣VID就會在br-int上撞車，所以任何類型的網絡都需要轉換，這樣Neutron可以做到掌控全局。還需要說明的1點是，不管你租戶網絡層用的那種類型的網絡，本地網絡層只能是1種網絡類型：VLAN！
| 網絡類型 | br-int | br-tun |
|---|---|---|
| VLAN | 10 | ---- |
| VXLAN | 10 | 100 |
2. 轉換關系的建立
前文得知，每個OVS是由OVS Agent所創建，OVS Agent將內外VID（VNI）的映射關系存儲在OVS Bridge的端口表中的other_config字段中，以完成轉換。 
Openstack中Neutron的實現模型