OpenStack----Neutron插件、Linux Bridge代理、Open VSwitch代理的理論知識

一、ML2插件（core plugin）

1.1、前言

Neutron可以通過開發不同的插件和代理來支持不同的網絡技術、這是一種相當開發的架構。
不過隨着所支持的網絡提供者種類的增加，開發人員發現兩個突出的問題。

• 一個問題是多種網絡提供者無法共存。Core Plugin負責管理和維護Neutron二層的虛擬網絡的狀態信息，一個Neutron網絡只能由一個插件管理，而Core Plugin插件與相應的代理是一 一對應的，如果Linux Bridge插件，則只能選擇Linux Bridge代理，必須在OpenStack的所有節點上使用Linux Bridge作爲虛擬交換機。

• 另外一個問題是開發插件的工作量太大，所有傳統的Core Plugin之間存在大量重複的代碼(如數據庫訪問代碼)

1.2、ML2插件的出現

• 爲了解決這二個問題，從OpenStack的Havana版本開始，Neutron 實現一個插件 ML2(Moduler Layer2)。

• ML2插件爲了取代所有Core Plugin，允許在OpenStack網絡中同時使用多種二層的網絡技術，不同的節點可以使用不同的網絡實現機制，ML2能夠與現在所有的代理無縫集成，以前使用的代理無需變更，只要將傳統的Core Plugin替換ML2插件。

• ML2使得對新的網絡技術支持更爲簡單，無須從新開發新的Core Plugin,只需要開發相應的機制驅動(Mechansion Driver) ,大大減少要編寫和維護的代碼。

1.3、ML2的實現架構圖

• ML2對二層的網絡進行抽象，解鎖了Neutron所支持的網絡類型(Type)與訪問這些網絡類型的虛擬網絡實現機制(Mechansim)，並通過驅動的形式進行擴展。

• 不同的網絡類型對應不同的類型的驅動(Type Driver) ,由類型管理器(Typer Manager)進行管理。不同的網絡實現機制對應不同的機制驅動(Mechansiom Driver)，由機制管理器(Mechansim Manager)進行管理。

• 這種實現框架ML2具有彈性，易於擴展，能夠支持多種網絡類型和實現機制。

1.4、類型驅動和機制驅動

1、類型驅動 (Type Driver)

Neutron支持的每一種網絡類型都有一個對應的ML2類型驅動，類型驅動負責維護網絡類型的狀態，執行驗證、創建網絡等工作。目前Neutron己經實現的網絡類型包括Flat、Local、VLAN、VXLAN、GRE

2、機制驅動 (Mechansim Driver)

Neutron支持的每一種網絡機制都有一個對應的ML2機制驅動。機制驅動負責獲取類型驅動維護的網絡狀態，並確保在相應的網絡設備 (物理或虛擬的)上正確實現這些狀態。

舉列：類型驅動VLAN，機制驅動爲Linux Bridge，如果創建VLAN10，那麼VLAN的類型驅動會確保將VLAN 10的信息保存到Neutron數據庫中，包括網絡的名稱、VLAN ID等, 而Linux Bridge機制驅動會確保各個節點上的Linux Bridge代理在物理網卡上創建ID爲10 的VLAN設備和Bridge設備，並將二者進行橋接。

• 目前Neutron已經實現的網絡機制有3種類型。

  • 基於代理 (Agent-based) :包括Linux bridge、Open vSwitch
  • 基於控制器 (controller Based):包括OpenStacDaylight、VMWavre NSX等
  • 基於物理交換的:包括Cisco Nexus、Arista、 Mellanox 等

1.5、擴展資源

• ML2作爲一個Core Plugin，在實現網絡、子網和端口核心資源的同時，也實現了包括端口綁定(Port Bindings)、安全組(Security Group)等部分擴展資源。

二、Linux Bridge代理

Linux Bridge是成熟可靠的Neutron二層網絡虛擬化技術，支持Local、Flat、VLAN、VXLAN這四種網絡類型，目前不支持GRE。

• Linux Bridge可以將一臺主機上的多個網卡橋接起來，充當一臺交換機，它可以橋接物理網卡，又可以是虛擬網卡，用於橋接虛擬機網卡的是Tap接口，這是一個虛擬機出來的網絡設備，稱爲Tap設備，作爲網橋的一個端口，Tap 接口在邏輯上與物理接口具有相同的功能，可以接收和發送數據包。

2.1、Linux Bridge代理過程

如果選擇Linux Bridge代理，在計算機節點上數據包從虛擬機發送到物理網卡需要經過以下設備。

• Tap接口(Tap interface)：用於網橋虛擬機的網卡，命令爲tapXXX
• Linux網橋(Linux Bridge) :作爲二層交換機，命令爲brgxxx
• VIAN接口(VLANInterface) :在VLAN網絡中用於連接網橋，命名爲ethx:y(ethx爲物理網卡名稱，y爲VLAN ID) .
• VXLAN接口(VXLAN Interface) :在VXLAN網絡中用於連接網橋，命名爲vyxlan-z(z是VNID)
• 物理網絡接口：用於連接到物理網絡。

2.2、Linux Bridge代理網絡結構圖

計算節點上的Linux Bridge環境下的Flat網絡和VLAN網絡，下面2個圖中網橋是核心。

• VLAN網絡有2個VLAN接口，分別有自己的網橋，實現了基於VLAN的隔離，VLAN網絡的缺點：支持用戶少，安全性不好。
• 基於Linux Bridge 的 flat 網絡
  
• 基於Linux Bridge的VLAN網絡
  

三、Open vSwitch代理

與linux Bridge相比，Open vSwitch (可簡稱ovs)具有幾種管控功能，而且性能更加優化，支持更多的功能，目前在OpenStack領域稱爲主流。它支持Local、 Flat、 VLAN、VXLAN、GRE和GENEVE等所有網絡類型。

3.1、Open vswitch 的設備類型

(1)、Tap設備：用於網橋連接虛擬機網卡

(2)、Linux網橋:橋接網絡接口(包括虛擬接口)

(3)、VETH對(VETH Pair) :直接相連的一對虛擬機網絡接口，發送VETH對一段的數據包由另一端接收。在OpenStack中，它用來連接兩個虛擬網橋。

(4)、OVS網橋: Open Vswitch的核心設備，包括一個OVS集成網橋( Integration Bridge )和一個OVS物理連接網橋。所有在計算節點上運行的虛擬機連接到集成網橋，Neutron 通過配置集成網橋上的端口來實現虛擬機網絡隔離。物理連接網絡直接連接到物理網卡。這兩個OVS網絡通過一個VETH對連接，Open Vswitch的每個網橋都可以看做是一個真正的交換機，可以支持VLAN。

3.2、Open vSwitch數據包流程

如果選擇Open Vswitch代理，在計算節點上的數據包從虛擬機發送到物理網卡需要依次經過一下設備。

• Tap接口(Tap interface) :用於網橋虛擬機的網卡，命令爲tapxxx
• Linux網橋(Linux Bridge):與Linux Bridge不用，命名爲gbrxxx (其中編號xxx與tapxxx中的x相同)
• VETH對：兩端分別命名爲qvbxxx和gvoxxx(其中編號xxx與tapxxx中的xxx保持一致)
• OVS集成網橋:命名爲br-int
• OVS PATCH端口:兩端分別命名爲int-br-ethx和phy-br-ethx(x爲物理網卡名稱的編號)
• OVS物理連接網橋:分爲兩種類型，在Flat和VLAN網絡中使用OVS提供者網橋(Provider Bridge)，命名爲Br-ethx(x爲物理網卡名稱的編號)，在VXLAN、GRE和GENEVE疊加網絡中使用OVS隧道網橋(Tunnel Bridge)，命名爲Br-tun，另外在Local 網絡中不需要任何OVS物理連接網橋
• 物理網絡接口：用於連接到物理網絡，命名爲ethx(x爲物理網卡的名稱中的編號)

3.3、open vSwitch網絡的邏輯結構

• 與Linux Bridge代理不同，Open vSwitch代理不通過Eth1.101、Eth1.102 等VLAN接口隔離不同的VLAN網絡。

• 所有的虛擬機都連接到同一個網橋br-int，Open vSwitch通過配置br-int 和br-ethx上的流規則(Flow rule)來進行VLAN轉換，進而實現VLAN之間的隔離。

• 例如：內部標籤分別爲1和2，而物理網絡的VLAN標籤是101和102，當br-eth1網橋上的phy-br-eth1端口收到一個VLAN 1標記的數據包時，會將其中的VLAN 1轉讓爲VLAN 101，當br-int網橋上的int-br-eth1端口收到一個VLAN 101標記的數據包時。會將其中的VLAN101轉讓爲VLAN 1。

• 下面是VLAN網絡爲例的Open vSwitch網絡邏輯結構：

  • 基於Open vSwitch的VLAN網絡
    br-eth1是橋接在物理網卡上的，也就是br-eth1是公網，那內部的br-int就相當於是內網交換機