一. neutron 介紹

1. Neutron 概述

傳統的網路管理方式很大程度上依賴於管理員手工配置和維護各種網路硬體裝置；而云環境下的網路已經變得非常複雜，特別是在多租戶場景裡，使用者隨時都可能需要建立、修改和刪除網路，網路的連通性和隔離不已經太可能通過手工配置來保證了。   如何快速響應業務的需求對網路管理提出了更高的要求。傳統的網路管理方式已經很難勝任這項工作，而“軟體定義網路（software-defined networking, SDN）”所具有的靈活性和自動化優勢使其成為雲時代網路管理的主流。   Neutron 的設計目標是實現“網路即服務（Networking as a Service）”。為了達到這一目標，在設計上遵循了基於 SDN 實現網路虛擬化的原則，在實現上充分利用了 Linux 系統上的各種網路相關的技術。   SDN 模式服務— NeutronSDN( 軟體定義網路 ), 通過使用它，網路管理員和雲端計算操作員可以通過程式來動態定義虛擬網路裝置。Openstack 網路中的 SDN 元件就是 Quantum.但因為版權問題而改名為Neutron 。

2.Neutron 網路基本概念

1.network

network 是一個隔離的二層廣播域 。Neutron 支援多種型別的 network，包括 local, flat, VLAN, VxLAN 和 GRE。   local local 網路與其他網路和節點隔離。local 網路中的 instance 只能與位於同一節點上同一網路的 instance 通訊， local 網路主要用於單機測試。   flat flat 網路是無 vlan tagging 的網路。flat 網路中的 instance 能與位於同一網路的 instance 通訊，並且可以跨多個節點。  (tagging 標記）   vlan vlan 網路是具有 802.1q tagging 的網路。 vlan 是一個二層的廣播域，同一 vlan 中的 instance 可以通訊，不同 vlan 只能通過 router 通訊。vlan 網路可跨節點，是應用最廣泛的網路型別。   vxlan vxlan 是基於隧道技術的 overlay 網路。vxlan 網路通過唯一的 segmentation ID（也叫 VNI）與其他 vxlan 網路區分。vxlan 中資料包會通過 VNI 封裝成 UDP 包進行傳輸。因為二層的包通過封裝在三層傳輸，能夠克服 vlan 和物理網路基礎設施的限制。   gre gre 是與 vxlan 類似的一種 overlay 網路。主要區別在於使用 IP 包而非 UDP 進行封裝。   不同 network 之間在二層上是隔離的。   以 vlan 網路為例，network A 和 network B 會分配不同的 VLAN ID，這樣就保證了 network A 中的廣播包不會跑到 network B 中。當然，這裡的隔離是指二層上的隔離，藉助路由器不同 network 是可能在三層上通訊的。   network 必須屬於某個 Project（ Tenant 租戶），Project 中可以建立多個 network。 network 與 Project 之間是 1對多 關係。  （project  專案）

2.subnet （子網）

ubnet 是一個 IPv4 或者 IPv6 地址段。instance 的 IP 從 subnet 中分配。每個 subnet 需要定義 IP 地址的範圍和掩碼。   network 與 subnet 是 1對多 關係。一個 subnet 只能屬於某個 network；一個 network 可以有多個 subnet，這些 subnet 可以是不同的 IP 段，但不能重疊。下面的配置是有效的 但下面的配置則無效，因為 subnet 有重疊 這裡不是判斷 IP 是否有重疊，而是 subnet 的 CIDR 重疊（都是 10.10.1.0/24）。但是，如果 subnet 在不同的 network 中，CIDR 和 IP 都是可以重疊的，比如 這裡大家不免會疑惑： 如果上面的IP地址是可以重疊的，那麼就可能存在具有相同 IP 的兩個 instance，這樣會不會衝突？ 簡單的回答是：不會！   具體原因： 因為 Neutron 的 router 是通過 Linux network namespace 實現的。network namespace 是一種網路的隔離機制。通過它，每個 router 有自己獨立的路由表。上面的配置有兩種結果： 1. 如果兩個 subnet 是通過同一個 router 路由，根據 router 的配置，只有指定的一個 subnet 可被路由。   2. 如果上面的兩個 subnet 是通過不同 router 路由，因為 router 的路由表是獨立的，所以兩個 subnet 都可以被路由。

3. port

port 可以看做虛擬交換機上的一個埠。port 上定義了 MAC 地址和 IP 地址，當 instance 的虛擬網絡卡 VIF（Virtual Interface） 繫結到 port 時，port 會將 MAC 和 IP 分配給 VIF。   subnet 與 port 是 1對多 關係。一個 port 必須屬於某個 subnet；一個 subnet 可以有多個 port。

3.小結：

  下面總結了 Project，Network，Subnet，Port 和 VIF 之間關係。 Project 1 : m Network 1 : m Subnet 1 : m Port 1 : 1 VIF m : 1 Instance

二. Neutron 功能

Neutron 為整個 OpenStack 環境提供網路支援，包括二層交換，三層路由，負載均衡，防火牆和 VPN 等。Neutron 提供了一個靈活的框架，通過配置，無論是開源還是商業軟體都可以被用來實現這些功能。

1.二層交換機 Switching

Nova 的 Instance（實列，個體） 是通過虛擬交換機連線到虛擬二層網路的。Neutron 支援多種虛擬交換機，包括 Linux 原生的 Linux Bridge 和 Open vSwitch。 Open vSwitch（OVS）是一個開源的虛擬交換機，它支援標準的管理介面和協議。   利用 Linux Bridge 和 OVS，Neutron 除了可以建立傳統的 VLAN 網路，還可以建立基於隧道技術的 Overlay 網路，比如 VxLAN 和 GRE（Linux Bridge 目前只支援 VxLAN）。在後面章節我們會學習如何使用和配置 Linux Bridge 和 Open vSwitch。

2. 三層路由 Routing

Instance 可以配置不同網段的 IP，Neutron 的 router（虛擬路由器）實現 instance 跨網段通訊。router 通過 IP forwarding，iptables 等技術來實現路由和 NAT。我們將在後面章節討論如何在 Neutron 中配置 router 來實現 instance 之間，以及與外部網路的通訊。

3.負載均衡 Load Balancing

Openstack 在 Grizzly 版本第一次引入了 Load-Balancing-as-a-Service（LBaaS），提供了將負載分發到多個 instance 的能力。LBaaS 支援多種負載均衡產品和方案，不同的實現以 Plugin 的形式整合到 Neutron，目前預設的 Plugin 是 HAProxy。我們會在後面章節學習 LBaaS 的使用和配置。

4.防火牆 Firewalling

Neutron 通過下面兩種方式來保障 instance 和網路的安全性。   Security Group 通過 iptables 限制進出 instance 的網路包。

 

Firewall-as-a-Service FWaaS，限制進出虛擬路由器的網路包，也是通過 iptables 實現。     Neutron 優點： Openstack 中的 SDN 元件架構也屬於可插拔型別。通過各種外掛可以管控不同種類的交換機、路由器、防火牆、負載均衡器並實現 firewall as a service 等許多功能。通過軟體來定義的網路，可以對整個雲端計算設施進行更為精細的掌控。

三 Neutron 部署方案

案1：控制節點 + 計算節點：

  控制節點： 部署的服務包括：neutron server, core plugin 的 agent 和 service plugin 的 agent。   計算節點： 部署 core plugin 的agent，負責提供二層網路功能。   這裡有幾點需要說明：  1. core plugin 和 service plugin 已經整合到 neutron server，不需要執行獨立的 plugin 服務。 2. 控制節點和計算節點都需要部署 core plugin 的 agent，因為通過該 agent 控制節點與計算節點才能建立二層連線。   3. 可以部署多個控制節點和計算節點
 

方案2：控制節點 + 網路節點 + 計算節點

在這個部署方案中，OpenStack 由控制節點，網路節點和計算節點組成。   控制節點： 部署 neutron server 服務。   網路節點： 部署的服務包括：core plugin 的 agent 和 service plugin 的 agent。   計算節點： 部署 core plugin 的agent，負責提供二層網路功能。   這個方案的要點是將所有的 agent 從控制節點分離出來，部署到獨立的網路節點上。

1. 控制節點只負責通過 neutron server 響應 API 請求。  
2. 由獨立的網路節點實現資料的交換，路由以及 load balance等高階網路服務。  
3. 可以通過增加網路節點承擔更大的負載。  
4. 可以部署多個控制節點、網路節點和計算節點。

該方案特別適合規模較大的 OpenStack 環境。  

四.配置多個網絡卡區分不同型別的網路資料

OpenStack 至少包含下面幾類網路流量 Management API VM External   Management 網路 用於節點之間 message queue 內部通訊以及訪問 database 服務，所有的節點都需要連線到 management 網路。   API 網路 OpenStack 各元件通過該網路向用戶暴露 API 服務。Keystone, Nova, Neutron, Glance, Cinder, Horizon 的 endpoints 均配置在 API 網路上。通常，管理員也通過 API 網路 SSH 管理各個節點。   VM 網路 VM 網路也叫 tenant 網路，用於 instance 之間通訊。 VM 網路可以選擇的型別包括 local, flat, vlan, vxlan 和 gre。 VM 網路由 Neutron 配置和管理。   External 網路 External 網路指的是 VM 網路之外的網路，該網路不由 Neutron 管理。 Neutron 可以將 router attach 到 External 網路，為 instance 提供訪問外部網路的能力。 External 網路可能是企業的 intranet，也可能是 internet。   這幾類網路只是邏輯上的劃分，物理實現上有非常大的自由度。   我們可以為每種網路分配單獨的網絡卡；也可以多種網路共同使用一個網絡卡；為提高頻寬和硬體冗餘，可以使用 bonding 技術將多個物理網絡卡繫結成一個邏輯的網絡卡
  我們的實驗環境採用下面的網絡卡分配方式：
  1. 控制節點 3 網絡卡（eth0, eth1, eth2），計算節點 2 網絡卡（eth0, eth1）。 2. 合併 Management 和 API 網路，使用 eth0 3. VM 網路使用 eht1。 4. 控制節點的 eth2 與 External 網路連線 分割線上方的網路由網路管理員（就是我們啦）配置。 主要涉及 Management, API 和 external 網路。 配置的內容包括節點上的物理網絡卡，物理交換機和外部路由器，防火牆以及物理連線等   分割線下方是 VM 網路，由 Neutron 管理。 我們只需要通過 Web GUI 或者 CLI 操作，Neutron 會負責實現。

五. Neutron 架構

與 OpenStack 的其他服務的設計思路一樣，Neutron 也是採用分散式架構，由多個元件（子服務）共同對外提供網路服務。 agent :代理  plugin : 外掛目錄 provider 提供商 Neutron 由如下元件構成：   Neutron Server 對外提供 OpenStack 網路 API，接收請求，並呼叫 Plugin 處理請求。   Plugin 處理 Neutron Server 發來的請求，維護 OpenStack 邏輯網路狀態， 並呼叫 Agent 處理請求。   Agent 處理 Plugin 的請求，負責在 network provider 上真正實現各種網路功能。   network provider 提供網路服務的虛擬或物理網路裝置，例如 Linux Bridge，Open vSwitch 或者其他支援 Neutron 的物理交換機。   Queue Neutron Server，Plugin 和 Agent 之間通過 Messaging Queue 通訊和呼叫。   Database 存放 OpenStack 的網路狀態資訊，包括 Network, Subnet, Port, Router 等。 Neutron 架構非常靈活，層次較多，目的是：

1. 為了支援各種現有或者將來會出現的優秀網路技術。  
2. 支援分散式部署，獲得足夠的擴充套件性。

通常魚和熊掌不能兼得，雖然獲得了這些優勢，但這樣使得 Neutron 更加複雜，更不容易理解。 後面我們會詳細討論 Neutron 的各個元件，但在這之前，非常有必要先通過一個例子瞭解這些元件各自的職責以及是如何協同工作。   以建立一個 VLAN100 的 network 為例，假設 network provider 是 linux bridge， 流程如下：

1. Neutron Server 接收到建立 network 的請求，通過 Message Queue（RabbitMQ）通知已註冊的 Linux Bridge Plugin。  
2. Plugin 將要建立的 network 的資訊（例如名稱、VLAN ID等）儲存到資料庫中，並通過 Message Queue 通知執行在各節點上的 Agent。  
3. Agent 收到訊息後會在節點上的物理網絡卡（比如 eth2）上建立 VLAN 裝置（比如 eth2.100），並建立 bridge （比如 brqXXX） 橋接 VLAN 裝置。

1. plugin 解決的是 What 的問題，即網路要配置成什麼樣子？而至於如何配置 How 的工作則交由 agent 完成。  
2. plugin，agent 和 network provider 是配套使用的，比如上例中 network provider 是 linux bridge，那麼就得使用 linux bridge 的 plungin 和 agent；如果 network provider 換成了 OVS 或者物理交換機，plugin 和 agent 也得替換。  
3. plugin 的一個主要的職責是在資料庫中維護 Neutron 網路的狀態資訊，這就造成一個問題：所有 network provider 的 plugin 都要編寫一套非常類似的資料庫訪問程式碼。為了解決這個問題，Neutron 在 Havana 版本實現了一個 ML2（Modular Layer 2）plugin，對 plgin 的功能進行抽象和封裝。有了 ML2 plugin，各種 network provider 無需開發自己的 plugin，只需要針對 ML2 開發相應的 driver 就可以了，工作量和難度都大大減少。ML2 會在後面詳細討論。  
4. plugin 按照功能分為兩類： core plugin 和 service plugin。core plugin 維護 Neutron 的 netowrk, subnet 和 port 相關資源的資訊，與 core plugin 對應的 agent 包括 linux bridge, OVS 等； service plugin 提供 routing, firewall, load balance 等服務，也有相應的 agent。後面也會分別詳細討論。

 

六. Neutron Server  元件詳解

1.Neutron server 分層模型

extension ：延期。外延 common：共同 圖是 Neutron Server 的分層結構，至上而下依次為：   Core API： 對外提供管理 network, subnet 和 port 的 RESTful API。 （Restful：平靜的） restful api ：輕量級的介面 Extension API： 對外提供管理 router, load balance, firewall 等資源 的 RESTful API。 extension api 擴充套件API Commnon Service： 認證和校驗 API 請求。   Neutron Core： Neutron server 的核心處理程式，通過呼叫相應的 Plugin 處理請求。   Core Plugin API： 定義了 Core Plgin 的抽象功能集合，Neutron Core 通過該 API 呼叫相應的 Core Plgin。   Extension Plugin API： 定義了 Service Plgin 的抽象功能集合，Neutron Core 通過該 API 呼叫相應的 Service Plgin。   Core Plugin： 實現了 Core Plugin API，在資料庫中維護 network, subnet 和 port 的狀態，並負責呼叫相應的 agent 在 network provider 上執行相關操作，比如建立 network。   Service Plugin： 實現了 Extension Plugin API，在資料庫中維護 router, load balance, security group 等資源的狀態，並負責呼叫相應的 agent 在 network provider 上執行相關操作，比如建立 router。   歸納起來，Neutron Server 包括兩部分： 1. 提供 API 服務。 2. 執行 Plugin。   即 Neutron Server = API + Plugins
  明白了 Neutron Server 的分層模型，我們就更容易理解 Neutron 是如何支援多種 network provider。

2. ML2 CORE Plugin  詳解

  上節提到 Core Plugin，其功能是維護資料庫中 network, subnet 和 port 的狀態，並負責呼叫相應的 agent 在 network provider 上執行相關操作，比如建立 network。 openstack中有兩大常見 Core Plugin： linux bridge plugin 和 open vswitch plugin。 Neutron 可以通過開發不同的 plugin 和 agent 支援不同的網路技術。這是一種相當開放的架構。不過隨著支援的 network provider 數量的增加，開發人員發現了兩個突出的問題：       1. 只能在 OpenStack 中使用一種 core plugin，多種 network provider 無法共存。             只使用一個 core plugin 本身沒有問題。但問題在於傳統的 core plugin 與 core plugin agent 是一一對應的。也就是說，如果選擇了 linux bridge plugin，那麼 linux bridge agent 將是唯一選擇，就必須在 OpenStack 的所有節點上使用 linux bridge 作為虛擬交換機（即 network provider）。            同樣的，如果選擇 open vswitch plugin， 所有節點上只能使用 open vswitch，而不能使用其他的 network provider。
  2. 不同 plugin 之間存在大量重複程式碼，開發新的 plugin 工作量大。 所有傳統的 core plugin 都需要編寫大量重複和類似的資料庫訪問的程式碼，大大增加了 plugin 開發和維護的工作量。  解決傳統 core plugin 的問題 Moduler Layer 2（ML2）： 是 Neutron 在 Havana 版本實現的一個新的 core plugin，用於替代原有的 linux bridge plugin 和 open vswitch plugin。 作為新一代的 core plugin，提供了一個框架，允許在 OpenStack 網路中同時使用多種 Layer 2 網路技術，不同的節點可以使用不同的網路實現機制。 如上圖所示，採用 ML2 plugin 後，可以在不同節點上分別部署 linux bridge agent, open vswitch agent, hyper-v agent 或其他第三方 agent。 ML2 不但支援異構部署方案，同時能夠與現有的 agent 無縫整合：以前用的 agent 不需要變，只需要將 Neutron server 上的傳統 core plugin 替換為 ML2。 有了 ML2，要支援新的 network provider 就變得簡單多了：無需從頭開發 core plugin，只需要開發相應的 mechanism driver，大大減少了要編寫和維護的程式碼。   ML2 Core Plugin 詳解： ML2 對二層網路進行抽象和建模，引入了 type driver 和 mechansim driver。這兩類 driver 解耦了 Neutron 所支援的網路型別（type）與訪問這些網路型別的機制（mechanism），其結果就是使得 ML2 具有非常好的彈性，易於擴充套件，能夠靈活支援多種 type 和 mechanism
  （1） Type Driver     Neutron 支援的每一種網路型別都有一個對應的 ML2 type driver。 type driver 負責維護網路型別的狀態，執行驗證，建立網路等。 ML2 支援的網路型別包括 local, flat, vlan, vxlan 和 gre。 我們將在後面章節詳細討論每種 type。   （2） Mechansim Driver Neutron 支援的每一種網路機制都有一個對應的 ML2 mechansim driver。 mechanism driver 負責獲取由 type driver 維護的網路狀態，並確保在相應的網路裝置（物理或虛擬）上正確實現這些狀態。 type 和 mechanisim 都太抽象，現在我們舉一個具體的例子： type driver 為 vlan，mechansim driver 為 linux bridge，我們要完成的操作是建立 network vlan100，那麼：

1. vlan type driver 會確保將 vlan100 的資訊儲存到 Neutron 資料庫中，包括 network 的名稱，vlan ID 等。
2. linux bridge mechanism driver 會確保各節點上的 linux brige agent 在物理網絡卡上建立 ID 為 100 的 vlan 裝置 和 brige 裝置，並將兩者進行橋接。

    mechanism driver 有三種類型：   Agent-based 包括 linux bridge, open vswitch 等。   Controller-based 包括 OpenDaylight, VMWare NSX 等。   基於物理交換機 包括 Cisco Nexus, Arista, Mellanox 等。 比如前面那個例子如果換成 Cisco 的 mechanism driver，則會在 Cisco 物理交換機的指定 trunk 埠上新增 vlan100。     本教程討論的 mechanism driver 將涉及 linux bridge, open vswitch 和 L2 population。   linux bridge 和 open vswitch 的 ML2 mechanism driver 作用是配置各節點上的虛擬交換機。linux bridge driver 支援的 type 包括 local, flat, vlan, and vxlan。open vswitch driver 除這 4 種 type 還支援 gre。   L2 population driver 作用是優化和限制 overlay 網路中的廣播流量。 vxlan 和 gre 都屬於 overlay 網路。   ML2 core plugin 已經成為 OpenStack Neutron 的首選 plugin，本教程後面會討論如何在實驗環境中配置 ML2 的各種 type 和 mechansim
  Core Plugin/Agent 負責管理核心實體： net, subnet 和 port。而對於更高階的網路服務，則由 Service Plugin/Agent 管理。   Service Plugin 及其 Agent 提供更豐富的擴充套件功能，包括路由，load balance，firewall等，如圖所示   DHCP dhcp agent 通過 dnsmasq 為 instance 提供 dhcp 服務。   Routing l3 agent 可以為 project（租戶）建立 router，提供 Neutron subnet 之間的路由服務。路由功能預設通過 IPtables 實現。   Firewall l3 agent 可以在 router 上配置防火牆策略，提供網路安全防護。另一個與安全相關的功能是 Security Group，也是通過 IPtables 實現。 Firewall 與 Security Group 的區別在於：

1. Firewall 安全策略位於 router，保護的是某個 project 的所有 network。
2. Security Group 安全策略位於 instance，保護的是單個 instance。

Firewall 與 Security Group 後面會詳細分析。   Load Balance Neutron 預設通過 HAProxy 為 project 中的多個 instance 提供 load balance 服務。   後面的章節會結合 linux bridge 和 open vswitch 詳細討論每一種 service。

七. Neutron 框架總結

前面我們詳細討論了 Neutron 架構，包括 Neutron Server，Core 和 Service Agent。 現在用兩張圖做個總結。   與 OpenStack 其他服務一樣，Neutron 採用的是分散式架構，包括 Neutorn Server、各種 plugin/agent、database 和 message queue。 1. Neutron server 接收 api 請求。 2. plugin/agent 實現請求。 3. database 儲存 neutron 網路狀態。 4. message queue 實現元件之間通訊。   metadata-agent 之前沒有講到，這裡做個補充：          instance 在啟動時需要訪問 nova-metadata-api 服務獲取 metadata 和 userdata，這些 data 是該 instance 的定製化資訊，比如 hostname, ip， public key 等。   但 instance 啟動時並沒有 ip，那如何通過網路訪問到 nova-metadata-api 服務呢？   答案就是 neutron-metadata-agent 該 agent 讓 instance 能夠通過 dhcp-agent 或者 l3-agent 與 nova-metadata-api 通訊       如果我們將 Neutron 架構展開，則會得到下面第二張圖
   

1. Neutron 通過 plugin 和 agent 提供的網路服務。
2. plugin 位於 Neutron server，包括 core plugin 和 service plugin。
3. agent 位於各個節點，負責實現網路服務。
4. core plugin 提供 L2 功能，ML2 是推薦的 plugin。
5. 使用最廣泛的 L2 agent 是 linux bridage 和 open vswitch。
6. service plugin 和 agent 提供擴充套件功能，包括 dhcp, routing, load balance, firewall, vpn 等。

至此，Neutron 架構已經討論完，希望大家已經理解。

八  Neutron - 網路實踐

1. 用namspace 隔離 DHCP 服務

Neutron 通過 dnsmasq 提供 DHCP 服務，而 dnsmasq 通過 Linux Network Namespace  獨立的為每個 network 服務 隔離 在二層網路上，VLAN 可以將一個物理交換機分割成幾個獨立的虛擬交換機。類似地，在三層網路上， Linux network namespace 可以將一個物理三層網路分割成幾個獨立的虛擬三層網路。 每個 namespace 都有自己獨立的網路棧，包括 route table，firewall rule，network interface device 等。 Neutron 通過 namespace 為每個 network 提供獨立的 DHCP 和路由服務，從而允許租戶建立重疊的網路。如果沒有 namespace，網路就不能重疊，這樣就失去了很多靈活性。 每個 dnsmasq 程序都位於獨立的 namespace, 命名為 qdhcp-<network id>，例如 flat_net： ip netns list         命令列出所有的 namespace ip netns exec <network namespace name> <command>        管理 namespace root namespace： 其實，宿主機本身也有一個 namespace，叫 root namespace，擁有所有物理和虛擬 interface device。物理 interface 只能位於 root namespace。 新建立的 namespace 預設只有一個 loopback de