傳統網絡到虛擬化網絡的演進
傳統網絡：
虛擬網絡：
布式虛擬網絡：
單一平面網絡到混合平面網絡的演進
單一平面租戶共享網絡：所有租戶共享一個網絡（IP 地址池），只能存在單一網絡類型（VLAN 或 Flat）。
- 沒有私有網絡
- 沒有租戶隔離
- 沒有三層路由
![請添加圖片描述]()
多平面租戶共享網絡：具有多個共享網絡供租戶選擇。
- 沒有私有網絡
- 沒有租戶隔離
- 沒有三層路由
混合平面（共享/私有）網絡：共享網絡和租戶私有網絡混合。
- 有私有網絡
- 沒有租戶隔離
- 沒有三層路由
NOTE：因爲多租戶之間還是依賴共享網絡（e.g. 需要訪問外部網絡），沒有做到完全的租戶隔離。
基於運營商路由功能的多平面租戶私有網絡：每個租戶擁有自己私有的網絡，不同的網絡之間通過運營商路由器（公共）來實現三層互通。
- 有私有網絡
- 有租戶隔離
- 共享三層路由
基於私有路由器實現的多平面租戶私有多網絡：每個租戶可以擁有若干個私有網絡及路由器。租戶可以利用私有路由器實現私有網絡間的三層互通。
- 有私有網絡
- 有租戶隔離
- 有三層路由
![在這裏插入圖片描述]()
NEUTRON 簡述
Neutron is an OpenStack project to provide “network connectivity as a service” between interface devices (e.g., vNICs) managed by other OpenStack services (e.g., nova). The OpenStack Networking service (neutron) provides an API that allows users to set up and define network connectivity and addressing in the cloud. The project code-name for Networking services is neutron. OpenStack Networking handles the creation and management of a virtual networking infrastructure, including networks, switches, subnets, and routers for devices managed by the OpenStack Compute service (nova). Advanced services such as firewalls or virtual private network (VPN) can also be used. — — 官方網站：https://docs.openstack.org/neutron/latest/
Neutron 是爲 OpenStack 提供 Network Connectivity as s Service 的項目，當然 Neutron 也可以脫離 Keystone 體系作爲一個獨立的 SDN 中間件。
- 作爲 OpenStack 組件：爲 OpenStack 虛擬機、裸機、容器提供網絡服務。
- 作爲 SDN 中間件：北向提供統一抽象資源接口，南向對接異構 SDN 控制器。
之所以有前兩個章節，是希望以此來引出 Neutron 所追求的目標 —— 雲計算時代的分佈式虛擬化網絡與多租戶隔離私有的多平面網絡。
從軟件實現的角度來看，對 Neutron 熟悉的開發者不難察覺：Neutron 團隊肯定首先設計好 Core API Models（核心資源模型）然後再往下實現的。這也是很多 OpenStack 項目的實現風格，值得我們學習。在設計軟件架構時，不要急於擼代碼，而是首先思考清楚 「XXX as a Service」中 Service 的含義，即 “什麼是服務、爲誰服務、提供什麼服務、如何提供”？Neutron 提供的網絡即服務的精髓就在於租戶只需關心服務，不必關心實現細節，而服務的內容就是資源類型（API）的定義。只有穩定、兼容、平滑過渡的 API 才能引發 APIs 經濟（圍繞開放式 API 的生態圈），讓軟件得以在殘酷的開源市場中存活下來。
而且 Neutron 的設計初衷是純粹的 “軟件定義”，無需設計新的硬件，而是對現有硬件的協同，這是一個務實的設計思想，通過 Plugin-Driver 的方式來調用底層物理/虛擬網元功能，爲上層服務提供支撐。這一特點使 Neutron 得以在業界收到廣泛的關注。
NEUTRON 的網絡實現模型
在瞭解 Neutron 網絡實現模型的過程中，我們主要弄明白三個問題：
- Neutron 是怎麼支持多類型網絡的（e.g. VLAN、VxLAN）？
- 同一個租戶網絡內的跨計算節點虛擬機之間是怎麼通信的？
- 虛擬機是怎麼訪問外網的？
Neutron 的網絡實現模型概覽：
計算節點網絡實現模型
下面我們直接介紹計算機節點上的虛擬機流量是如果被送出計算節點的，並在過程中插入介紹相關的虛擬網絡設備於工作機理。
Step 1. 流量經由虛擬機內核 TCP/IP Stack 交給虛擬網卡 vNIC 處理，vNIC 是一個 Tap 設備，它允許用戶態程序（這裏指 GuestOS，一個 qemu 進程）向內核 TCP/IP 協議棧注入數據。Tap 設備可以運行在 GuestOS 上，提供與物理 NIC 完全相同的功能。
Step 2. 虛擬機的 vNIC（Tap 設備）沒有直連到 OvS Bridge 上，而是通過 Linux Bridge 中繼到 OvS br-int（Integrated bridge，綜合網橋）。爲什麼 vNIC 不直連 br-int？這是因爲 OvS 在 v2.5 以前只有靜態防火牆規則，並不支持有狀態的防火牆規則。這些規則是 Neutron Security Group 的底層支撐，爲虛擬機提供針對端口（vNIC）級別的安全防護，所以引入了 Linux Bridge 作爲安全層，應用 iptables 對有狀態的數據包進行過濾。其中 Linux Bridge qbr 是 quantum bridge 的縮寫。還有一些其他原因：
- Openstack Neutron需要在宿主機上執行一定的安全策略；
- Hulk平臺使用的ovs版本是2.3.1，該版本尚未完全支持安全策略的內核模塊實施部分：netfilter模塊；
- 增加一箇中間層Linux bridge可以解決網絡策略配置。
Step 3. Linux Bridge 與 OvS Bridge 之間通過 veth pair （虛擬網線）設備連接，“網線” 的一端命名爲 qvb（quantum veth bridge）另一端命名爲 qvo（quantum veth ovs）。veth pair 設備總是成對存在的，用於連接兩個虛擬網絡設備，模擬虛擬設備間的數據收發。veth pair 設備的工作原理是反轉通訊數據的方向，需要發送的數據會被轉換成需要收到的數據重新送入內核 TCP/IP 協議棧進行處理，最終重定向到目標設備（“網線” 的另一端）。
Step 4. OvS br-int 是一個綜合網橋，作爲計算節點本地（Local）虛擬交換設備，完成虛擬機流量在本地的處理 —— Tenant flows are separated by internally assigned VLAN ID.（Tenant 網絡的 Local VLAN ID 由 內部分配）
- 虛擬機發出的流量在 br-int 打上 Local VLAN tag，傳輸到虛擬機的流量在 br-int 被去掉 Local VLAN tag。
- 本地虛擬機之間的 2 層流量直接在 br-int 轉發，被同 VLAN tag 的端口接收。
Step 5. 從本地虛擬機傳輸到遠端虛擬機（或網關）的流量由 OvS br-int 上的 int-br-eth1（ovs patch peer 設備）端口送到 OvS br-ethX 上。需要注意的是，br-ethX 並未是一成不變的：當網絡類型爲 Flat、VLAN 時，使用 br-ethX；當網絡類型爲 Tunnel（e.g. VxLAN、GRE）時，br-ethX 就會被 br-tun 替換。上圖示例爲 VLAN 網絡。我們將 br-ethX、br-tun 統稱爲租戶網絡層網橋設備（TNB），以便於敘述。
NOTE： qbr-xxx 與 OvS br-int 之間使用 veth pair 設備相連，br-int 與 br-ethx/br-tun 之間使用 patch peer 設備相連。兩種都是類似的虛擬 “網線”，區別在於前者是 Linux 虛擬網絡設備，後者是 OvS 實現的虛擬網絡設備。
NOTE： 如果租戶網橋是 br-tun 而不是 br-ethX，那麼在 br-tun 上會有 port:patch-int，br-int 上會有 port:patch-tun，通過 patch-int 和 patch-tun 實現租戶網橋 br-tun 和本地網橋 br-int 之間的通信。
Step 6. 當虛擬機流量流經 OvS br-int 與 OvS br-ethX 之間時，需要進行一個至關重要且非常複雜的動作 —— 內外 VID 轉換。這是一種 “分層兼容” 的設計理念，讓我想起了：所有計算機問題都可以通過引入一箇中間層來解決。而 Neutron 面對的這個問題就是 —— 支持多種租戶網絡類型（Flat、VLAN、VxLAN、GRE）。
Step 7. 最後虛擬機流量通過掛載到 TNB（br-ethX/br-tun）上的物理網卡 ethX 發出到物理網絡。OvS br-int 與 OvS br-ethX 之間也是通過 veth pair 設備實現。
Step 8. 虛擬機的流量進入到物理網絡之後，剩下的就是傳統網絡的那一套了。網絡包被交換機或其他橋接設備轉發到其他計算、網絡節點（PS：這取決於具體的部署網絡拓撲，一般虛擬機流量只會被同處 Internal Network 的計算節點）接收到。
內外 VID 轉換
從網絡層的角度看，計算節點的網絡模型可分爲：租戶網絡層、本地網絡層。
其中本地網絡層通過 VLAN ID 來劃分 br-int 中處於不同網絡的虛擬機（端口），本地網絡僅支持 VLAN 類型；而租戶網絡層爲了實現多類型混合平面的需求卻要支持非隧道類型網絡 Flat、VLAN（br-ethX）及隧道類型網絡 VxLAN、GRE（br-tun）。顯然，本地網絡層和租戶網絡層之間必須存在一層轉換。這就是所謂的 VID 轉換。
VID 是一個邏輯概念，針對不同的租戶網絡類型也有不同類型的 “VID”。
需要注意的是 VID 的範圍是由租戶定義的 —— Tenant flows are separated by user defined VLAN ID.（租戶網絡的 VID 由 User Defined，此時示例爲 VLAN 類型網絡）。所謂 “User Defined” 就是用戶通過 Neutron 配置文件 ml2_conf.ini 爲各種網絡類型配置的 range。e.g.
# /etc/neutron/plugins/ml2/ml2_conf.ini
[ml2_type_vlan]
network_vlan_ranges = public:3001:4000
[ml2_type_vxlan]
vni_ranges = 1:1000
[ml2_type_gre]
tunnel_id_ranges = 1:1000
再次強調，本地網絡的 VLAN ID 是由內部代碼邏輯算法分配的，而租戶網絡的 VID 纔是由用戶自定義配置的。
或許你會感到奇怪，爲什麼租戶網絡與本地網絡同爲 VLAN 類型的情況下還需要進行內外 VID 轉換？解答這個問題只需要辯證思考一下：加入不進行內外 VID 轉換會怎樣？答案是會在混合 VLAN 和 VxLAN 類型租戶網絡的場景中出現內外 VID 衝突的情況。
假設網絡1：租戶網絡 VLAN 的 VID 爲 100，不做內外 VID 轉換，那麼本地網絡 VLAN ID 也是 100。 網絡2：租戶網絡 VxLAN 的 VID 爲 1000，進行內外 VID 轉換，本地網絡 VLAN 100 也可能是 100。
這是因爲 VxLAN 網絡再進行內外 VID 轉換的時候並不知道 VLAN 網絡的 VID 是多少，只有當 VLAN 網絡進行了內外 VID 轉換之後纔會知道，因爲 VID 轉換是有由 OvS Flow Table 記錄並執行的 —— VLAN ID is converted with flow table。
所以 VLAN 類型網絡也要進行內外 VID 轉換是爲了防止混合 VLAN 和 VxLAN 類型租戶網絡的場景中出現內外 VID 衝突的情況！
至此，我們就可以回到開篇的其中兩個問題了。
- Neutron 是怎麼支持多類型網絡的？
- 同一個租戶網絡內的跨計算節點虛擬機之間是怎麼通信的？
網絡節點網絡實現模型
網絡節點所承載的最核心的功能就是解決虛擬機與外部網絡（e.g. Internet）通信的問題，圍繞這個問題我們設想一下在傳統網絡中是怎麼實現的？
- 所有計算節點內的虛擬機，要訪問 Internet，必須先經過網絡節點，網絡節點作爲第一層網關。
- 網絡節點會通過連接 DC 物理網絡中的一個設備（e.g. 交換機，或者是路由器）到達 DC 的網關 。這個設備稱爲第二層網關。當然，網絡節點也可以直接對接 DC 網關（如果 DC 網關可控的話），這時候，就不需要第二層網關了。
- DC 網關再連接到 Internet上。
可見，網絡節點要處理的事情就是第一層網關處理的事情，西接所有計算節點的流量，東接物理網絡（第二層）網關設備。爲此，網絡節點所需要的元素就是一個 L3 Router。需要注意的是，這裏所提到的 L3 Router 並不是一個 vRouter（SDN 中的虛擬路由器），而是網絡節點本身（一個可作爲路由器的 Linux 服務器）。藉助於 Linux 服務器本身的路由轉發功能，網絡節點得以成爲了上文提到的：訪問外部網絡所需要通過的 第一層網關。
依舊從分層的角度來看，網絡節點的網絡實現模型可以分爲 4 層：
- 租戶網絡層：對接所有（計算、控制、網絡）節點，支持多種網絡類型。
- 本地網絡層：基於內外 VID 轉換機制，通過 Local VLAN tag 來區分網絡包所屬的網絡。
- 服務網絡層：提供 L3 Router 和 DHCP 服務。
- 外部網絡層：對接外部網絡（e.g. Internet）。
網絡節點出了提供 L3 Router 服務，同時也爲每個有必要（用戶手動開啓）的租戶網絡提供 DHCP 服務。爲了實現多租戶網絡資源隔離，應用了 Linux 提供的 Network Namesapce 技術。每創建一個 L3 Router 資源對象，就會添加一個與之對應的 qrouter-XXX namesapce；每爲一個租戶網絡開啓 DHCP 服務，就會添加一個與之對應的 qdhcp-XXX namesapce。
上圖可見，DHCP 服務實際是由 dnsmasq 服務進程提供的，在 qdhcp-XXX namesapce 中會添加一個 DHCP 的端口（Tap 設備），這個 DHCP 端口連接到 br-int 上，具有與對應的租戶網絡相同的 Local VLAN tag（和租戶網絡 VID），以此實現爲租戶網絡提供 DHCP 服務。
除此之外，還可以看見在 qrouter-XXX namesapce 中 br-int 和 br-ex 兩個網橋設備通過 veth pair 設備 qr-XXX（quantum router） 和 qg-XXX（quantum gateway）連接到了一起。而且 qr-XXX 端口也具有租戶網絡對應的 Local VLAN tag。不同的租戶網絡通過不同的 Network Namesapce 實現了 Router 配置（路由表、iptables 規則）的隔離，啓用 iptables 在 qrouter-XXX 中主要是提供 NAT 功能，支撐 Neutron 的 Floating IP 功能。
不同的租戶具有不同的 qrouter-XXX 與 qdhcp-XXX 實例，所以不同租戶間可以實現 IP 地址的複用。
計算節點的網絡模型章節中國我們介紹了虛擬機流量如何被送出計算節點，這裏繼續介紹虛擬機流量是如何被送出外部網絡的：
Step 9. 物理網卡 ethX（OvS br-ethX/br-tun）從物理網絡接收到從計算節點上虛擬機發出的外部網絡訪問流量，首先進行內外 VID 轉換，然後通過 VETH Pair 設備傳輸到 OvS br-int。
NOTE： 針對每一個租戶網絡在租戶網絡層上的 VID 肯定的一致的，而在不同（計算、網絡）節點上的 Local VLAN ID 卻未必一樣，但這並不會導致不同租戶網絡間的數據包混亂，因爲這一切都在 Open vSwitch 流表的掌握之中，我們暫且先對這個問題有個印象。
Step 10. 在網絡節點上 OvS br-int 連接了不同的 Network namesapce，qrouter-XXX 通過 qr-XXX 端口接收到租戶內跨網段訪問流量以及公網訪問流量。
-
跨網段訪問流量： qr-XXX 端口接收到流量後，內核 TCP/IP 協議棧根據 qrouter-XXX中的路由規則對跨網段訪問流量進行路由、改寫 MAC 地址並通過相應的 qr-YYY 接口向 OvS br-int傳輸數據包。實現不同網段之間的路由轉發。
-
公網訪問流量： qr-XXX 端口接收到流量後，內核 TCP/IP 協議棧根據 qrouter-XXX 中的 iptables NAT 規則對流量進行網絡地址轉換（Floating IP 的實現原理），之後再通過 qg-XXX 接口將數據包發送給 OvS br-ex。
Step 11. 最終由連接第二層網關並掛載到 br-ex 上的物理網卡 ethX 發出送至 Internet 路由器。
綜上，“虛擬機是怎麼訪問外網的？” 這個問題解決了。
控制節點的網絡實現模型
控制節點的網絡實現模型就相對好理解很多了，因爲控制節點不負責數據平面的問題，所以也沒有實現具體的網絡功能。我們需要關心的只是 neutron-server 這個服務進程。Neutron 沒有顯式（名爲）的 neutron-api 服務進程，而是由 neutron-server 提供 Web Server 的服務。北向接收 REST API 請求，南向通過 RPC 協議轉發各節點上的 Neutron Agent 服務進程，這就是 Neutron 在控制節點上的網絡實現模型。
至此，我們介紹完了 Neutron 在分別計算、網絡、控制節點上的網絡實現模型，我們不妨回味一下這之間最重要的的設計思想 —— 分層。
讓我們先拋開 OpenStack 和 Neutron，單純的想象如何應用虛擬交換機實現跨主機間的虛擬機通信以及虛擬機訪問外網的需求？答案其實很簡單，如果應用 OvS，就會簡單到只需要在每個節點上創建一個 Bridge（e.g. br-int）設備即可，無需 br-ex、br-ethX/br-tun、Linux Bridge 等等一大堆東西。e.g.
# Host1
ovs-vsctl add-br br-vxlan
# Host2
ovs-vsctl add-br br-vxlan
# Host1 上添加連接到 Host2 的 Tunnel Port
ovs-vsctl add-port br-vxlan tun0 -- set Interface tun0 type=vxlan options:remote_ip=<host2_ip>
# Host2 上添加連接到 Host1 的 Tunnel Port
ovs-vsctl add-port br-vxlan tun0 -- set Interface tun0 type=vxlan options:remote_ip=<host1_ip>
如果應用 Linux Bridge 的話，就會稍微複雜一些，正如我在《KVM + LinuxBridge 的網絡虛擬化解決方案實踐》所記錄的一般，這裏不再贅述。e.g.
但如果考慮到需要實現的是在「雲平臺上的多租戶多平面網絡」的話，那麼事情就會變得相當複雜。一個有生命力的靈活的雲平臺，需要支持的網絡類型實在是太多了，Neutron 至今仍在爲之付出努力。在這樣的條件下就急需設計出一個「上層抽象統一，下層異構兼容」的軟件架構，而這種架構設計就是我們常說的 —— 分層架構設計。設計方案總是依賴於底層支撐選型，Neutron 網絡實現模型的分層架構得益於 Open vSwitch（OpenFlow 交換機）的 Flow Table 定義功能。通過這個章節，希望大家能夠對此有所感受。