一：簡介
一、概述
1. 傳統的網絡管理方式很大程度上依賴於管理員手工配置和維護各種網絡硬件設備；而雲環境下的網絡已經變得非常復雜，特別是在多租戶場景里，用戶隨時都可能需要創建、修改和刪除網絡，網絡的連通性和隔離不已經太可能通過手工配置來保證了。
2. 如何快速響應業務的需求對網絡管理提出了更高的要求。傳統的網絡管理方式已經很難勝任這項工作，而“軟件定義網絡（software-defined networking, SDN）”所具有的靈活性和自動化優勢使其成為雲時代網絡管理的主流。
3. Neutron 的設計目標是實現“網絡即服務（Networking as a Service）”。為了達到這一目標，在設計上遵循了基於 SDN 實現網絡虛擬化的原則，在實現上充分利用了 Linux 系統上的各種網絡相關的技術。
4. SDN 模式服務— NeutronSDN( 軟件定義網絡 ), 通過使用它，網絡管理員和雲計算操作員可以通過程序來動態定義虛擬網絡設備。Openstack 網絡中的 SDN 組件就是 Quantum.但因為版權問題而改名為Neutron 。
二、基本概念
1. Network：是一個隔離的二層廣播域。Neutron 支持多種類型的 Network，包括 Local, Flat, VLAN, VxLAN 和 GRE。
1. Local網絡與其他網絡和節點隔離。Local 網絡中的 instance 只能與位於同一節點上同一網絡的 Instance 通信，主要用於單機測試。
2. Flat 網絡是無 vlan tagging 的網絡。Flat 網絡中的 instance 能與位於同一網絡的 instance 通信，並且可以跨多個節點。
3. VLAN 網絡是具有 802.1q tagging 的網絡，是一個二層的廣播域，同一 Vlan 中的 instance 可以通信，不同 vlan 只能通過 router 通信。vlan 網絡可跨節點，是應用最廣泛的網絡類型。
4. Vxlan 是基於隧道技術的 overlay 網絡。Vxlan 網絡通過唯一的 segmentation ID（也叫 VNI）與其他 Vxlan 網絡區分。vxlan 中數據包會通過 VNI 封裝成 UDP 包進行傳輸。因為二層的包通過封裝在三層傳輸，能夠克服 VLAN 和物理網絡基礎設施的限制。
5. GRE 是與 Vxlan 類似的一種 overlay 網絡。主要區別在於使用 IP 包而非 UDP 進行封裝。
2. Subnet：是一個 IPv4 或者 IPv6 地址段。Instance 的 IP 從 Subnet 中分配。每個 Subnet 需要定義 IP 地址的范圍和掩碼。
1. Network 與 Subnet 是 1對多 關系。同一個Network 的 Subnet 可以是不同的 IP 段，但CIDR不能重疊。
1. 有效配置
2. 無效配置（同一個Network）
2. 不同 Network 的 Subnet 的CIDR 和 IP 都是可以重疊的。因為 Neutron 的 router 是通過 Linux network namespace 實現的。
3. Network Namespace：是一種網絡的隔離機制，通過網絡命名空間的每個 router 都有自己獨立的路由表
1. 如果兩個 subnet 是通過同一個 router 路由，根據 router 的配置，只有指定的一個 subnet 可被路由。
2. 如果兩個 subnet 是通過不同 router 路由，因為 router 的路由表是獨立的，所以兩個 subnet 都可以被路由。
3. Port：是虛擬交換機上的一個端口。Port 上定義了 MAC 地址和 IP 地址，當 instance 的虛擬網卡 VIF（Virtual Interface） 綁定到 Port 時，Port 會將 MAC 和 IP 分配給 VIF。
4. Project、Network、Subnet、Port之間的關系：Project 1 : m Network 1 : m Subnet 1 : m Port 1 : 1 VIF m : 1 Instance。
三、功能
1. Neutron 為整個 OpenStack 環境提供網絡支持，包括二層交換，三層路由，負載均衡，防火牆和 VPN 等。Neutron 提供了一個靈活的框架，通過配置，無論是開源還是商業軟件都可以被用來實現這些功能。
2. 二層交換 Switching
1. Nova 的 Instance 是通過虛擬交換機連接到虛擬二層網絡的。Neutron 支持多種虛擬交換機，包括 Linux 原生的 Linux Bridge 和 Open vSwitch。 Open vSwitch（OVS）是一個開源的虛擬交換機，它支持標准的管理接口和協議。
2. 利用 Linux Bridge 和 OVS，Neutron 除了可以創建傳統的 VLAN 網絡，還可以創建基於隧道技術的 Overlay 網絡，比如 VxLAN 和 GRE（Linux Bridge 目前只支持 VxLAN）。
3. 三層路由 Routing
1. Instance 可以配置不同網段的 IP，Neutron 的 router（虛擬路由器）實現 Instance 跨網段通信。router 通過 IP forwarding，iptables 等技術來實現路由和 NAT。
2. Neutron 路由器是一個三層的（L3）的抽象，其模擬物理路由器，為用廣提供路由、NAT等服務，在 Openstack網絡中，不用子網之間的通信需要路由器，網絡與外部網絡之間的通信更需要路由器。
3. Neutron 提供虛擬路由器，也支持物理路由器。例如，兩個隔離的ⅥLAN網絡之間需要實現通信，可以通過物理路由器實現，由物理路由器提供相應的 IP 路由表，確保兩個IP子網之間的通信，將兩個VLAN網絡中的虛擬機默認網關分別設置為路由路由器的接口A和B的IP地址。VLAN中的虛擬機要與 VLANB中的虛擬機通信時，數據包將通過LANA中的物理網卡到達路由器，有物理路由器轉發到 VLAN B中的物理網卡，在到目的的虛擬機。
4. 負載均衡 Load Balancing
1. Openstack 在 Grizzly 版本第一次引入了 Load-Balancing-as-a-Service（LBaaS），提供了將負載分發到多個 instance 的能力。
2. LBaaS 支持多種負載均衡產品和方案，不同的實現以 Plugin 的形式集成到 Neutron，目前默認的 Plugin 是 HAProxy。
5. 防火牆 Firewalling
1. Neutron 通過 Security Group 和 Firewall-as-a-Service 兩種方式來保障 instance 和網絡的安全性。
2. Security Group 通過 iptables 限制進出的 instance 的網絡包。
3. Firewall-as-a-Service FWaas 通過 iptables 限制進出虛擬路由器的網絡包。
二：架構
一、核心架構
1. Neutron Server：對外提供 OpenStack 網絡 API，接收請求，並調用 Plugin 處理請求。
2. Plugin：處理 Neutron Server 發來的請求，維護 OpenStack 邏輯網絡狀態， 並調用 Agent 處理請求。
3. Agent：處理 Plugin 的請求，負責在 network provider 上真正實現各種網絡功能。
4. Network Provider：提供網絡服務的虛擬或物理網絡設備，例如 Linux Bridge，Open vSwitch 或者其他支持 Neutron 的物理交換機。
5. Queue：Neutron Server，Plugin 和 Agent 之間通過 Messaging Queue 通信和調用。
6. Database：存放 OpenStack 的網絡狀態信息，包括 Network, Subnet, Port, Router 等。
二、組件詳解
1. Neutron Server 詳解
1. Core API：對外提供管理 network, subnet 和 port 的 RESTful API。
2. Extension API：對外提供管理 router, load balance, firewall 等資源 的 RESTful API。
3. Commnon Service：認證和校驗 API 請求。
4. Neutron Core：Neutron server 的核心處理程序，通過調用相應的 Plugin 處理請求。
5. Core Plugin API：定義了 Core Plgin 的抽象功能集合，Neutron Core 通過該 API 調用相應的 Core Plgin。
6. Extension Plugin API：定義了 Service Plgin 的抽象功能集合，Neutron Core 通過該 API 調用相應的 Service Plgin。
7. Core Plugin：實現了 Core Plugin API，在數據庫中維護 network, subnet 和 port 的狀態，並負責調用相應的 agent 在 network provider 上執行相關操作，比如創建 network。
8. Service Plugin：實現了 Extension Plugin API，在數據庫中維護 router, load balance, security group 等資源的狀態，並負責調用相應的 agent 在 network provider 上執行相關操作，比如創建 router。
2. ML2 Core Plugin 詳解
1. 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）。
2. 不同 plugin 之間存在大量重復代碼，開發新的 plugin 工作量大。所有傳統的 core plugin 都需要編寫大量重復和類似的數據庫訪問的代碼，大大增加了 plugin 開發和維護的工作量。
2. Moduler Layer 2（ML2）：是 Neutron 在 Havana 版本實現的一個新的 core plugin，用於替代原有的 linux bridge plugin 和 open vswitch plugin。 作為新一代的 core plugin，提供了一個框架，允許在 OpenStack 網絡中同時使用多種 Layer 2 網絡技術，不同的節點可以使用不同的網絡實現機制。
3. 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。
2. Mechansim Driver：Neutron 支持的每一種網絡機制都有一個對應的 ML2 mechansim driver。mechanism driver 負責獲取由 type driver 維護的網絡狀態，並確保在相應的網絡設備（物理或虛擬）上正確實現這些狀態。
1. Agent-based類型：包括 linux bridge, open vswitch 等
2. Controller-based類型：包括 OpenDaylight, VMWare NSX 等
3. 基於物理交換機：包括 Cisco Nexus, Arista, Mellanox 等。
3. Service Plugin / Agent 詳解
1. Core Plugin/Agent 負責管理核心實體：net, subnet 和 port。而對於更高級的網絡服務，則由 Service Plugin/Agent 管理。
2. Service Plugin 及其 Agent 提供更豐富的擴展功能，包括路由，load balance，firewall等。
3. DHCP：dhcp agent 通過 dnsmasq 為 instance 提供 dhcp 服務。
4. Routing：l3 agent 可以為 project（租戶）創建 router，提供 Neutron subnet 之間的路由服務。路由功能默認通過 IPtables 實現。
5. Firewall：l3 agent 可以在 router 上配置防火牆策略，提供網絡安全防護。另一個與安全相關的功能是 Security Group，也是通過 IPtables 實現。 Firewall 與 Security Group 的區別在於：
1. Firewall 安全策略位於 router，保護的是某個 project 的所有 network。
2. Security Group 安全策略位於 instance，保護的是單個 instance。
4. Load Balance：Neutron 默認通過 HAProxy 為 project 中的多個 instance 提供 load balance 服務。
三、部署方式
1. 計算節點和控制節點
2. 多個節點，適合大規模的OpenStack平台
三：Open vSwitch
一、簡介
1. 概念：Open vSwitch，簡稱OVS，是一個虛擬交換軟件，主要用於虛擬機VM環境，作為一個虛擬交換機，支持Xen/XenServer, KVM, and VirtualBox多種虛擬化技術。
2. 作用：讓大規模網絡自動化可以通過編程擴展，支持跨越多個物理服務器的分布式環境，同時仍然支持標准的管理接口和協議（例如NetFlow, sFlow, SPAN, RSPAN, CLI, LACP, 802.1ag）。
3. 工作原理
1. 在虛擬化的環境中，一個虛擬交換機主要有兩個作用：傳遞虛擬機之間的流量，以及實現虛擬機和外界網絡的通信。
2. 內核模塊實現了多個“數據路徑”（類似於網橋），每個都可以有多個“vports”（類似於橋內的端口）。每個數據路徑也通過關聯一下流表（flow table）來設置操作，而這些流表中的流都是用戶空間在報文頭和元數據的基礎上映射的關鍵信息，一般的操作都是將數據包轉發到另一個vport。當一個數據包到達一個vport，內核模塊所做的處理是提取其流的關鍵信息並在流表中查找這些關鍵信息。當有一個匹配的流時它執行對應的操作。如果沒有匹配，它會將數據包送到用戶空間的處理隊列中（作為處理的一部分，用戶空間可能會設置一個流用於以后碰到相同類型的數據包可以在內核中執行操作）。
二、組成
1. ovs-vswitchd：守護程序，實現交換功能，和Linux內核兼容模塊一起，實現基於流的交換flow-based switching。
2. ovsdb-server：輕量級的數據庫服務，主要保存了整個OVS的配置信息，包括接口啊，交換內容，VLAN啊等等。ovs-vswitchd會根據數據庫中的配置信息工作。
3. ovs-dpctl：一個工具，用來配置交換機內核模塊，可以控制轉發規則。
4. ovs-vsctl：網橋、接口等的創建、刪除、設置、查詢等。
5. ovs-appctl：主要是向OVS守護進程發送命令的，一般用不上。
6. ovsdbmonitor：GUI工具來顯示ovsdb-server中數據信息。
7. ovs-controller：一個簡單的OpenFlow控制器
8. ovs-ofctl：用來控制OVS作為OpenFlow交換機工作時候的流表內容。
三、工作流程
1. VM實例 instance 產生一個數據包並發送至實例內的虛擬網絡接口VNIC，圖中就是instance中的eth0.
2. 這個數據包會傳送到物理節點上的VNIC接口，如圖就是vnet接口vnet1。
3. 數據包從vnet NIC出來，到達橋（虛擬交換機）br100上.
4. 數據包經過交換機的處理，從物理節點上的物理接口發出，如圖中物理節點上的eth0.
5. 數據包從eth0出去的時候，是按照物理節點上的路由以及默認網關操作的，這個時候該數據包其實已經不受我們的linux-box的控制了,進入報文的傳輸環節。
四：常用操作
一、網絡、子網、路由、端口管理
二、防火牆管理
三、負載均衡管理
四、Open vSwitch 管理
