網路服務概覽

openstack網路(neutron)允許你建立和連線其它openstack服務管理的網路介面裝置。通過實現不同的外掛來適應不同的網路裝置和軟體，提供了靈活的openstack架構和部署。

它由以下2個元件構成：

neutron-server

接受API請求並將請求路由給適當的openstack網路外掛來執行實際的操作。

Openstack網路外掛和代理

插入和拔出埠，建立網路和子網，提供IP地址。這些外掛和代理會依賴於特定雲實現的供應商和技術而不同。Openstack網路通過外掛和代理來管理思科的虛擬和物理交換機，NEC OpenFlow產品，Open vSwitch,Linux橋接網路，和VMware NSX產品。

通用的代理是L3(3層）,DHCP(動態主機配置協議）和一個外掛代理程式。

訊息佇列

被大部分的openstack網路安裝包用來在neutron-server和不同的代理之間路由訊息。也會作為資料庫來為一些外掛儲存網路狀態。

Openstack主要與Openstack計算節點互動來為它的各個例項提供網路和連線。

網路(neutron)概念

OpenStack網路(neutron)管理你的openstack環境中各個方面的網路，包括虛擬的網路設施（VNI)和訪問物理層面的網路設施（PNI)。

OpenStack通過租戶的概念來提供先進的虛擬網路拓撲,可以提供防火牆,負載均衡和VPN等服務。

網路提供了網路，子網和路由這些抽象物件，每個抽象物件模擬對應的物理物件的功能:網路包含子網，路由在不同的網路和子網之間路由流量。

建立任何一個網路都至少有一個外部網路，和其它網路不同，這個外部網路不僅僅是一個定義的虛擬網路。它代表了物理網路一部分的一個檢視，外部網路能夠訪問外部的openstack。外部網路上的IP地址能夠被外部網路的其它物理網路所訪問。

除了外部網路，建立一個網路都會有一個或多個內部網路。這些軟體定義的網路直接連到虛擬機器VMs。只有內部網路中的虛擬機器，或者通過介面連線到類似路由器功能的裝置的子網，才能夠直接訪問網路中的虛擬機器。

對於外部網路要訪問VMs也是一樣的，需要網路間的路由器。每個路由器有一個閘道器連線到外部網路，有一個或多個介面連線到內部網路。和物理的路由器類似，子網間的裝置能夠通過路由器相互訪問，通過路由器的閘道器裝置也可以訪問外部網路。

另外，你可以為外部網路在內部網路上的埠分配IP地址。當任何東西連線到子網時，這個連線就稱為一個埠。你可以分配一個外部網路IP到VMs的埠上，這樣整個外部網路都能夠訪問VMs。

網路還支援安全組。安全組允許管理員在組內定義防火牆規則。一個VM可以屬於一個或多個安全組，網路在這些安全組上應用規則來為VMs關閉或開戶埠，配置埠範圍，或者流量型別。

網路中的每個外掛使用它自己的概念。儘管這些概念對操作VNI和Openstack環境不是至關重要的，但是理解這些概念能夠幫助你建立網路。所有的網路安裝都使用一個核心外掛和一個安全組外掛（或者沒有安全組外掛）。另外，還有防火牆服務（FWaaS)和負載均衡服務(LBaaS)可用。

Neutron體系結構

  類似於各個計算節點在Nova中被泛化為計算資源池，OpenStack所在的整個物理網路在Neutron中也被泛化為網路資源池，通過對物理網路資源的靈活劃分與管理，Netron能夠為同一物理網路上的每個租戶提供獨立的虛擬網路環境。

  我們在OpenStack雲環境裡基於Neutron構建自己私有網路的過程，就是建立各種Neutron資源物件並進行連線的過程，完全類似於使用真實的物理網路裝置來規劃自己的網路環境，如下圖所示：

          Router

  首先，應該至少有一個由管理員所建立的外部網路物件來負責OpenStack環境與Internet的連線，然後租戶可以建立自己私有的內部網路並在其中建立虛擬機器，為了使內部網路中的虛擬機器能夠訪問網際網路，必須建立一個路由器將內部網路連線到外部網路，具體可參考使用Horizon來建立網路的過程。

  這個過程中,Neutron提供了一個L3(三層)的抽象router與一個L2(二層）的抽象network，router對應於真實網路環境中的路由器，為使用者提供路由,NAT等服務，network則對應於一個真實物理網路中的二層區域網（LAN)，從租房角度看，它為租房所私有。

  這裡的subnet從Neutron的實現上來看並不能完全理解為物理網路中的子網概念。subnet屬於網路中的3層概念，指定一段IPv4或IPv6地址並描述其相關的配置資訊，它附加在一個二層network上指明屬於這個network的虛擬機器可使用的IP地址範圍。一個network可以同時擁有一個IPv4 subnet和一個IPv6 subnet,除此之外，即使我們為其配置多個subnet，也並能夠工作，可參考https://bugs.launchpad.net/neutron/+bug/1324459上的Bug描述。      

Linux虛擬網路

  Neutron最為核心的工作是對二層物理網路network的抽象與管理。在一個傳統的物理網路裡，可能有一組物理的Server，上面分別執行有各種各樣的應用，比如Web伺服器，資料庫服務等。為了彼此之間能夠互相通訊，每個物理Server都擁有一個或多個物理網絡卡(NIC)，這些NIC被連線在物理交換裝置上，比如交換機(Switch),如下圖所示:

                                                 傳統二層物理網路

    虛擬化技術被引入後，上述的多個作業系統和應用可以以虛擬機器的形式分享同一物理Server,虛擬機器的生成與管理由Hypervisor(或VMM)來完成，於是上圖的網路結構被演化為：

虛擬網路結構

 虛擬機器的網路功能由虛擬網絡卡(vNIC)提供，Hypervisor可以為每個虛擬機器建立一個或多個vNIC，站在虛擬機器的角度，這些vNIC等同於物理的網絡卡。為了實現與傳統物理網路等同的網路結構，與NIC一樣Switch也被虛擬化為虛擬交換機(vSwitch)，各個vNIC連線在vSwitch的埠上，最後這些vSwitch通過物理Server的物理網絡卡訪問外部的物理網路。

  由此可見，對一個虛擬的二層網路結構來說，主要是完成兩種網路裝置的虛擬化:NIC硬體與交換裝置。Linux環境下網路裝置的虛擬化主要有以下幾種形式，Neutron也是基於這些技術來完成租戶私有虛擬網路network的構建。

 (1) TAP/TUN/VETCH

   TAP/TUN是Linux核心實現的一對虛擬網路裝置，TAP工作在二層，TUN工作在三層，Linux核心通過TAP/TUN裝置向繫結該裝置的使用者空間程式傳送資料，反之，使用者空間程式也可以像操作網路裝置那樣，通過TAP/TUN裝置傳送資料。

   基於TAP驅動，即可以實現虛擬網絡卡的功能，虛擬機器的每個vNIC都與Hypervisor中的一個TAP裝置相連。當一個TAP裝置被建立時，在Linux裝置檔案目錄下將會生成一個對應的字元裝置檔案，使用者程式可以像開啟普通檔案一樣開啟這個檔案進行讀寫。

  當對這個TAP裝置檔案執行write()操作時，對於Linux網路子系統來說，就相當於TAP裝置收到了資料，並請求核心接受它，Linux核心收到此資料後將根據網路配置進行後續處理，處理過程類似於普通的物理網絡卡從外界接收資料。當用戶程式執行read()請求時，相當於向核心查詢TAP裝置上是否有資料要被髮送，有的話則取出到使用者程式裡，從而完成TAP裝置傳送資料的功能。在這個過程裡，TAP裝置可以被當做本機的一個網絡卡，而操作TAP裝置的應用程式相當於另外一臺計算機，它通過read/write系統呼叫，和本機進行網路通訊，Subnet屬於網路中的3層概念，指定一段IPv4或IPv6地址並描述其相關的配置資訊，它附加在一個二層network上並指明屬於這個network的虛擬機器可使用的IP地址範圍。

  VETH裝置總是成對出現，送到一端請求傳送的資料總是從另一端以請求接受的形式出現。建立並配置正確後，向其一端輸入資料，VETH會改變資料的方向並將其送入核心網路子系統，完成資料的注入，而在另一端則能讀到此資料。

 （2）Linux Bridge

  Linux Bridge（網橋）是工作於二層的虛擬網路裝置，功能類似於物理的交換機。

  Bridge可以繫結其他Linux網路裝置作為從裝置，並將這些從裝置虛擬化為埠，當一個從裝置被繫結到Bridge上時，就相當於真實網路中的交換機埠插入了一個連線有終端的網線。

                                                                                          Linux Bridge 結構
  如上圖所示,Bridge裝置br0綁定了實際裝置eth0與虛擬裝置tap0/tap1，此時，對於Hypervisor的網路協議上層來說，只看得到br0，並不會關心橋接的細節。當這些從裝置接收到資料包時，會將其將給br0決定資料包的去向，br0會根據MAC地址與埠的對映關係進行轉發。

 因為Bridge工作在第二層，所以繫結在br0上的從裝置eth0,tap0與tap1均不需要再設定IP，對上層路由器來說，它們都位於同一子網，因此只需為br0設定IP（Bridge雖然工作於二層，但它只是Linux網路裝置抽象的一種，能夠設定IP也可以理解），比如10.0.1.0/24。此時,eth0,tap0,tap1均通過br0處於10.0.1.0/24網段。

  因為具有自己的IP，br0可以被加入到路由表，並利用它來發送資料，而最終實際的傳送過程則由某個從裝置來完成。

  如果eth0本來具有自己的IP，比如192.168.1.1，在繫結到br0之後，它的IP會立即失效，使用者程式不能接收到傳送到這個IP的資料。只有目的地址為br0 IP的資料包才會被Linux接收。

 (3)Open vSwitch

  Open vSwitch是一個具有產品級質量的虛擬交換機，它使用C語言進行開發，從而充分考慮了在不同虛擬化平臺間的移植性，同時，它遵循Apache2.0許可，因此對商用也非常友好。

  如前所述，對於虛擬網路來說，交換裝置的虛擬化是很關鍵的一環，vSwitch負責連線vNIC與物理網絡卡,同時也橋接同一物理Server內的各個vNIC。Linux Bridge已經能夠很好地充當這樣的角色，為什麼我們還需要Open vSwitch?

  Open vSwitch在文章WHY-OVS中首先高度讚揚了Linux Bridge之後，給出了詳細的解答:

  we love the existing network stack in Linux. It is robust, flexible, and feature rich. Linux already contains an in-kernel L2 switch (the linux bridge)which can be used by VMs for inter-VM communication. So, it is reasonable to ask why there is a need for a new network switch.

  在傳統資料中心中，網路管理員對交換機的埠進行一定的配置，可以很好控制物理機的網路接入，完成網路隔離，流量監控，資料包分析，Qos配置，流量優化等一系列工作。

  但是在雲環境中，僅憑物理交換機的支援，管理員無法區分被橋接的物理網絡卡上流淌的資料包屬於哪個VM哪個OS及哪個使用者，Open vSwitch的引入則使雲環境中虛擬網路的管理以及對網路狀態和流量的監控變得容易。

  比如，我們可以像配置物理交換機一樣，將接入到Open vSwitch(Open vSwitch同樣會在物理Server上建立一個或多個vSwitch供各個虛擬機器接入）上的各個VM分配到不同的VLAN中實現網路的隔離。我們也可以在Open vSwitch埠上為VM配置Qos,同時Open vSwitch也支援包括NetFlow,sFlow很多標準的管理介面和協議，我們可以通過這些介面完成流量監控等工作。

  此外，Open vSwitch也提供了對Open Flow的支援，可以接受Open Flow Controller的管理。

  總之，Open vSwitch在雲環境中的各種虛擬化平臺上（比如Xen與KVM）實現了分散式的虛擬交換機（Distributed Virtual Switch)，一個物理Server上的vSwitch可以透明地與另一Server上的vSwitch連線在一起，如下圖所示:

Open vSwitch

 至於Open vSwitch軟體本身，則由核心態的模組以及使用者態的一系列後臺程式所組成。

  其中ovs-vswitched是最主要的模組，實現了虛擬機器交換機的後臺，負責同遠端的Controller進行通訊，比如通過OpenFlow協議與OpenFlow Controller通訊，通過sFlow協議同sFlow Trend通訊。此外，ovs-switched也負責同核心態模組通訊，基於netlink機制下發具體的規則和動作至核心態的datapath,datapath負責執行資料交換，也就是把從接收埠收到的資料包在流表(Flow Table)中進行匹配，並執行匹配到的動作。

  每個datapath都和一個流表關聯，當datapath接收到資料之後，會在流表中查詢可以匹配的Flow,執行對應的動作，比如轉發資料到另外的埠。

Open vSwitch軟體結構

Neutron網路抽象

    目前為止， 我們已經知道Neutron通過L3的抽象router提供路由器的功能，通過L2的抽象network/subnet完成對真實二層物理網路的對映，並且network有Linux Bridge,Open vSwitch等不同的實現方式。

    除此之外，在L2中，Neutron還提供了一個重要的抽象port,代表了虛擬交換機上的一個虛擬交換埠，記錄其屬於哪個網路協議以及對應的IP等資訊。當一個port被建立時，預設情況下，會為它分配其指定subnet中可用的IP。當我們建立虛擬機器時，可以為其指定一個port。

    對於L2層抽象network來說，必然需要對映到真正的物理網路，但Linux Bridge與Open vSwitch等只是虛擬網路的底層實現機制，並不能代表物理網路的拓撲型別，目前Neutron主要實現瞭如下幾種網路型別的支援：

    Flat: Flat型別的網路不支援VLAN,因此不支援二層隔離，所有虛擬機器都在一個廣播域。

    VLAN: 與Flat相比，VLAN型別的網路自然會提供VLAN的支援。

    NVGRE: NVGRE(Network Virtualization using Generic Routing Encapsulation)是點對點的IP隧道技術，可以用於虛擬網路互聯。NVGRE容許在GRE內傳輸乙太網幀，而GRE key拆成兩部分，前24位作為TenantID,後8位作為Entropy用於區分隧道兩端連線的不同虛擬網路。

   VxLAN: VxLan技術的本質是將L2層的資料幀頭重新定義後通過L4層的UDP進行傳輸。相較於採用物理VLAN實現的網路虛擬化，VxLAN是UDP隧道，可以穿越IP網路，使得兩個虛擬VLAN可以實現二層聯通，並且突破4095的VLAN ID限制提供多達1600萬的虛擬網路容量。

除了上述L2與L3的抽象，Neutron還提供了更高層次的一些服務，主要有FWaaS,LBaaS,VPNaaS。

Neutron網路架構

   不同於Nova與Swift,Neutron只有一個主要的服務程序neutron-server,它運行於網路控制節點上，提供RESTful API作為訪問Neutron的入口，neutron-server接收到的使用者HTTP請求最終由遍佈於計算節點和網路節點上的各種Agent來完成。

   Neutron提供的眾多API資源對應了前面所述的各種Neutron網路抽象，其中L2的抽象network/subnet/port可以被認為是核心資源，其他層次的抽象，包括router以及眾多的高層次服務則是擴充套件資源（Extension API)。

   為了更容易進行擴充套件，Neutron利用Plugin的方式組織程式碼，每一個Plugin支援一組API資源並完成特定的操作，這些操作最終由Plugin通過RPC呼叫相應的Agent來完成。

   這些Plugin又被做了一些區分，一些提供基礎二層虛擬網路支援的Plugin稱為Core Plugin，它們必須至少實現L2的三個主要抽象，管理員需要從這些已經實現的Core Plugin中選擇一種。Core Plugin之外的其他Plugin則稱稱為Service Plugin，比如提供防火牆服務的Firewall Plugin。

   至於L3抽象router,許多Core plugin並沒有實現，H版本之前他們是採用Mixin設計模式，將標準的router功能包含進來，以提供L3服務給租戶。H版本之中，Neutron實現了一個專門的名為L3 Router Service Plugin提供router服務。

   Agent一般專屬於某個功能，用於使用物理網路裝置或一些虛擬化技術完成某些實際的操作。比如實現router具體操作的L3 Agent。

   Neutron的完整架構如下圖所示:

                  Neutron 架構

    因為各種Core Plugin的實現之間存在很多重複程式碼，比如對資料庫的訪問操作，所以H版本中Neutron實現了一個ML2 Core Plugin，它採用了更加靈活的結構進行實現，通過Driver的形式可以對現有的各種Core Plugin提供支援，因此可以說ML2 Plugin的出現意在取代目前所有的Core Plugin。

    對於 ML2 Core plugin以及各種Service Plugin來說，雖然有被剝離出Neutron作為獨立專案存在的可能，但它們的基本實現方式與本章所涵蓋的內容相比並不會發生大的改變。

參考:

  <<OpenStack設計與實現>> 英特爾開源技術中心