雲計算openstack核心組件——neutron網絡服務（8）

一、neutron 介紹：

 

Neutron 概述

傳統的網絡管理方式很大程度上依賴於管理員手工配置和維護各種網絡硬件設備；而雲環境下的網絡已經變得非常復雜，特別是在多租戶場景里，用戶隨時都可能需要創建、修改和刪除網絡，網絡的連通性和隔離不已經太可能通過手工配置來保證了。

 

如何快速響應業務的需求對網絡管理提出了更高的要求。傳統的網絡管理方式已經很難勝任這項工作，而“軟件定義網絡（software-defined networking, SDN）”所具有的靈活性和自動化優勢使其成為雲時代網絡管理的主流。

 

Neutron 的設計目標是實現“網絡即服務（Networking as a Service）”。為了達到這一目標，在設計上遵循了基於 SDN 實現網絡虛擬化的原則，在實現上充分利用了 Linux 系統上的各種網絡相關的技術。

SDN 模式服務— NeutronSDN( 軟件定義網絡 ), 通過使用它，網絡管理員和雲計算操作員可以通過程序來動態定義虛擬網絡設備。Openstack 網絡中的 SDN 組件就是 Quantum.但因為版權問題而改名為Neutron 。

 

Neutron網絡基本概念

（1）neutwork

network 是一個隔離的二層廣播域。Neutron 支持多種類型的 network，包括 local, flat, VLAN, VxLAN 和 GRE。

 

local

local 網絡與其他網絡和節點隔離。local 網絡中的 instance 只能與位於同一節點上同一網絡的 instance 通信，local 網絡主要用於單機測試。

 

flat

flat 網絡是無 vlan tagging 的網絡。flat 網絡中的 instance 能與位於同一網絡的 instance 通信，並且可以跨多個節點。

 

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對多 關系。

 

（2）subnet

subnet 是一個 IPv4 或者 IPv6 地址段。instance 的 IP 從 subnet 中分配。每個 subnet 需要定義 IP 地址的范圍和掩碼。

 

network 與 subnet 是 1對多 關系。一個 subnet 只能屬於某個 network；一個 network 可以有多個 subnet，這些 subnet 可以是不同的 IP 段，但不能重疊。下面的配置是有效的：

network A   subnet A-a: 10.10.1.0/24  {"start": "10.10.1.1", "end": "10.10.1.50"}

                   subnet A-b: 10.10.2.0/24  {"start": "10.10.2.1", "end": "10.10.2.50"}

 

但下面的配置則無效，因為 subnet 有重疊

network A    subnet A-a: 10.10.1.0/24  {"start": "10.10.1.1", "end": "10.10.1.50"}

                    subnet A-b: 10.10.1.0/24  {"start": "10.10.1.51", "end": "10.10.1.100"}

 

這里不是判斷 IP 是否有重疊，而是 subnet 的 CIDR 重疊（都是 10.10.1.0/24）。但是，如果 subnet 在不同的 network 中，CIDR 和 IP 都是可以重疊的，比如

network A    subnet A-a: 10.10.1.0/24  {"start": "10.10.1.1", "end": "10.10.1.50"}

network B    subnet B-a: 10.10.1.0/24  {"start": "10.10.1.1", "end": "10.10.1.50"}

 

這里大家不免會疑惑： 如果上面的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。

小結：

下面總結了 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 提供了一個靈活的框架，通過配置，無論是開源還是商業軟件都可以被用來實現這些功能。

 

二層交換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。

 

三層路由routing：

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

 

負載均衡Load-Balancing：

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

 

防火牆Firewalling：

Neutron 通過下面兩種方式來保障 instance 和網絡的安全性。

(1) Security Group

通過 iptables 限制進出 instance 的網絡包。

(2) 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 架構：

Nuetron 架構

與 OpenStack 的其他服務的設計思路一樣，Neutron 也是采用分布式架構，由多個組件（子服務）共同對外提供網絡服務。

 

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 組件詳解：

 

Neutron server 分層模型

上圖是 Neutron Server 的分層結構，至上而下依次為：

 

Core API：對外提供管理 network, subnet 和 port 的 RESTful API。

 

Extension API：對外提供管理 router, load balance, firewall 等資源 的 RESTful 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。

 

 

三、ML2 Core Plugin 詳解：

 

Neutron 是如何支持多種 network provider？

 

上節提到 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 開發和維護的工作量。

 

ML2 能解決傳統 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。

 

 

 

 

四、Service Plugin / Agent 詳解：

 

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 架構已經討論完，希望大家已經理解。