OpenStack實戰系列:漫談Neutron 的架構

一.前言

由於OpenStack Neutron項目本身的高度複雜性和抽象性,加之作為一名初學者,其理解能力有限。因此這裡,闡述的僅是鳳毛麟角而已,其目的是幫助、引導和我一樣對Neutron又敬又畏的朋友們!如果本文中出現紕漏和錯誤,懇請指正。接受教育,本身也是一種學習。

在這裡,需要指出的是,本文僅從宏觀角度而言,起一個引導、拋磚引玉的作用。

——即做到Neutron的整體原理是什麼。

二.Neutron架構

Neutron項目共由約1千多個文件構成(k版)。

# tree -l 1 neutron/

313 directories, 1224 files

一切,讓我們先從Neutron架構圖說起走吧,如下所示:

OpenStack實戰系列:漫談Neutron 的架構

分析

1)位於最上層的Neutron Server充當一個門派中的「掌門人」角色(RESTful Server),負責接受來自外部門派(服務)的API請求,比如Nova API創建網路的請求。

2)位於中間層的Neutron plugin充當一個門派中的「信使」角色,負責傳達最高層指令給下面的人。

3)位於下層的Neutron Agent充當一個門派中「幹活」角色,負責執行一些具體的任務和操作。

類似於各個計算、存儲節點被虛擬化為計算、存儲資源池,Openstack所在的整個物理網路在Neutron中也被虛擬化為網路資源池。通過對網路資源的劃分和可擴展性,Neutron能夠為每個租戶提供獨立的虛擬網路環境。

Neutron分別提供了二層(L2)vSwitch交換和三層(L3)Router路由抽象的功能,對應於物理網路環境中的交換機和路由器做到。具體做到了如下功能:

  •     Router:為租戶提供路由、NAT等服務。

  •     Network:對應於一個真實物理網路中的二層局域網(VLAN),從租戶的的角度而言,是租戶私有的。

  •     Subnet:為網路中的三層概念,指定一段IPV4或IPV6地址並描述其相關的配置信息。它附加在一個二層Network上,指明屬於這個network的虛擬機可使用的IP地址範圍。

1. Linux虛擬網路

Neutron中最為核心的工作便是對二層物理網路network的抽象與管理。

虛擬機的網路功能由虛擬網卡(vNIC)提供,Hypervisor可以為每個虛擬機創建一個或多個vNIC,從虛擬機的角度出發,這些vNIC等同於物理的網卡,為了做到與傳統物理網路一樣的網路功能,與物理網卡一樣,Switch也被虛擬化成虛擬交換機(OpenvSwitch),各個vNIC連接在vSwitch的端口(br-int)上,最後這些vSwitch通過物理服務器的物理網卡訪問外部的物理網路。

對一個虛擬的二層網路結構而言,主要是完成兩種網路設備的虛擬化,即物理網卡和交換設備。在Linux環境下網路設備的虛擬化主要有以下幾種形式:

1)TAP/TUN/VETH

提到Neutron的虛擬網路功能做到,不得不先提基於Linux內核級的虛擬設備。

TAP/TUN/VETH是Linux內核做到的一對虛擬網路設備,TAP工作在二層,收發的是 MAC 層數據幀;TUN工作在三層,收發的是 IP 層數據包。Linux 內核通過TAP/TUN設備向綁定該設備的用戶程序發送數據,反之,用戶程序也可以像操作硬體網路設備一樣,通過TAP/TUN設備接收數據。

基於TAP設備,做到的是虛擬網卡的功能,當一個TAP設備被創建時,在Linux的設備文件目錄下將會生成一個對應的字符設備文件(/dev/tapX文件),而運行其上的用戶程序便可以像使用普通文件一樣打開這個文件進行讀寫。

VETH設備總是成對出現的,接收數據的一端會從另一端發送出去,理解為一根虛擬的網線即可。

2)Linux Bridge

Linux Bridge(Linux內核做到的網橋)是工作在二層的虛擬網路設備,功能類似於物理的交換機。

它的做到原理是,通過將其他Linux網路設備綁定到自身的Bridge上,並將這些設備虛擬化為端口。為什麼我們已經有了OVS,還要有Linux Bridge 呢?這是因為Linux Bridge做到了qbrxxx設備,提供了OVS無法支持的安全組(Security Group)功能。

3)Open vSwitch

對於雲計算中的虛擬網路而言,交換設備的虛擬化是很關鍵的一環,vSwitch負責連接vNIC與物理網卡,同時也橋接同一物理服務器內的各個VM的vNIC。

因此,我們可以像配置物理交換機一樣,將接入到OpenvSwitch(需要指出的是在多個以上時,vSwitch是分布式虛擬交換機)上的各個VM分配到不同的VLAN中做到網路隔離,並且,我們也可以在OVS端口上為VM配置QOS,同時OVS也支持包括NetFlow、sFlow等標準的管理接口和協議。從而,通過這些接口可以做到VM流量監控的任務。

運行在雲環境中各種或相同虛擬化平台上的多個vSwitch做到了分布式架構的虛擬交換機。一個物理服務器上的vSwitch可以透明的與其他服務器上的vSwitch連接通信。

關於OVS更加詳細的內容,請參閱其他資料。

2.Neutron RPC

RPC是neutron中跨模塊進行方法調用的很重要的一種方式,主要包括client端和server端。client端用於發出rpc消息,server端用於監聽消息並進行相應處理。

1)Agent 端RPC

在dhcp agent、 l3 agent、 firewall agent以及metering agent的main函數中都能找到類似的創建一個Agent rpc服務端的代碼。

2)plugin端的rpc

3)neutron-server端的rpc

具體的RPC做到,請參閱源代碼和其他資料。

三.Neutron 虛擬網路

1.Neutron網路資源

通過對上面的了解,我們已經知道了Neutron通過L3虛擬的Router提供路由器功能,通過L2(二層)虛擬的network/subnet/port 提供物理二層網路的功能,並且其二層network分別由linux bridge和OpenvSwitch等共同做到。

在L2中,Neutron還提供了一個重要的網路資源抽象Port,其作為虛擬交換機上的一個虛擬端口。當一個port被創建時,默認情況下,會為它分配其指定subnet中可用的IP。

對於L2層虛擬network而言,Linux bridge 和OpenvSwitch只是做到了虛擬網路的底層機制,並不能代表物理網路的拓撲類型。而目前,neutron支持如下的網路類型來映射到真正的物理網路中:

  •     Flat

  •     VLAN

  •     GRE

  •     VXLAN

除了上述的L2和L3層虛擬資源外,Neutron還提供了更高層次的一些服務,主要有FWaaS、LBaaS和VPNaaS等。

2. Neutron Plugin

與其他項目服務不同,Neutron只有一個主要的服務進程neutron-server,它運行於網路控制節點上,提供RESTful API作為訪問Neutron的入口,neutron-server接收到的用戶HTTP請求最終由遍布於計算節點和網路節點上的各種agent來完成。

Neutron提供的眾多API資源對應了前面所講的各種虛擬網路資源。其中L2的抽象network/subnet/port可以被認為是核心資源API(Core API),其他層次的抽象,包括router以及眾多的高層次服務則是擴展資源API(Extension API)。

為了更容易的進行擴展,Neutron項目利用Plugin的方式組織代碼,每一個Plugin支持一組API資源並完成特定的操作,這些操作最終由Plugin通過RPC調用相應的Agent來完成。

這些Plugin又被做了一些區分,一些提供基礎二層虛擬網路支持的Plugin稱為Core Plugin。而Core Plugin之外的其他Plugin則被稱為Service Plugin,比如提供防火牆服務的FWaaS等。

Agent一般專屬於某個功能,用於使用物理網路設備或一些虛擬化技術來完成某些實際的操作,比如做到router具體操作的L3 agent。

因為各種Core Plugin的做到之間存在很多重復的代碼,比如對數據庫的CRUD等操作。自H版起,Neutron做到了一個ML2 Core Plugin,它採用了更加靈活的結構進行做到,通過Driver的形式對現有的各種Core Plugin提供支持,因此可以說ML2 Plugin的問世意在取代目前的Core Plugin。

3. Neutron API

Neutron將基於各種虛擬網路資源得到的API資源分為核心資源(Core API)和擴展資源(Exten API)兩種。Core API只對應於L2層的network/subnet/port三種抽象。其餘的各層抽象都屬於Extension API的範圍。

Neutron API做到的主要代碼位於/neutron/api目錄。

4. Neutron-server

作為Neutron中的唯一一個服務進程,neutron-server承擔著接收用戶RESTful API請求並分發處理的任務。

主要代碼位於neutron/services目錄。

5. ML2 plugin

ML2 plugin被社區提出來的目的是用於取代所有的Core Plugin,它採用了更加靈活的結構進行做到。作為一個Core plugin,ML2 自然會做到network/subnet/port這三種核心資源,同時它也做到了包括Port Binding等在內的部分擴展資源。

ML2做到了網路拓撲類型(Flat、VLAN、VXLAN、GRE)和底層虛擬網路(linux bridge、OVS)分離的機制,並分別通過Driver的形式進行擴展。其中,不同的網路拓撲類型對應著type driver,由type manager管理,不同的網路做到機制對應著Mechanism Driver(比如Linux bridge、OVS、NSX等),由Mechanism Manager管理。

詳情,請參閱neutron.plugins.ml2.drivers.mech_agent文件中的AgentMechanismDriverBase類。

6. Port Binding擴展

Extension API有兩種方式擴展現有的資源:一種是為network/port/subnet增加屬性,比如port binding擴展。另外一種就是增加一些新的資源,比如VPNaaS等。

Extension API的定義都位於neutron/extension目錄,他們的基類以及一些公用的代碼則位於neutron/api/extension.py文件。其中Extension Descriptor類是所有Extension API的基類。添加新的資源時需要做到get_resources( )方法,而擴展現有的資源時,則只需要做到get_extended_resources( ) 方法。

7.OpenvSwitch Agent

OpenStack實戰系列:漫談Neutron 的架構

ML2 Plugin的主要工作是管理虛擬網路資源,保證數據正確無誤,具體物理設備的設置則由Agent來完成,這裡我們宏觀闡述下Neutron項目中的OVS Agent。

基於Plugin rpc提供的信息,OVS Agent負責在計算節點和網路節點上,通過對OVS虛擬交換機的管理將一個Network映射到物理網路,這需要OVS Agent去執行一些linux 網路和OVS相關的配置與操作,Neutron通過如下兩個庫提供了最為基礎的操作接口,從而可以通過Linux Shell命令完成OVS的配置。

如下:

  •     ovs_lib.py

    通過shell執行各種ovs-vsctl操作。

    代碼目錄:neutron/agent/common

  •     ip_lib.py

    通過linux的br-ctl命令操作Linux的veth、router、namespace等。

    代碼目錄:neutron/agent/linux/

主要是完成如下的一些工作:

1) agent初始化

2) agent和Plugin RPC的通信

3) br-int創建與初始化

4) br-eth初始化

5) br-tun初始化

6) 創建Tunnel Port

7) 分配LVID(Local VLAN ID)

8) L2 population

8. Service plugin

Neutron中除了network、port、subnet這三種二層的核心資源外,其他的都被作為Extension API進行做到,隨著ML2的成熟和發展,Extension API 的做到演變為兩種方式,一種是做到在某個Core plugin內,比如ML2內的port binding、Security Group等。

另一種就是使用Service plugin的方式,去做到FWaaS、LBaaS、VPNaaS等高級服務。

代碼目錄:neutron/services

至此,我們已經從宏觀上認識了Neutron的架構,接下來的則是自己考究了。

個人簡介:徐超:任職於九州雲信息科技有限公司(上海),從事OpenStack相關工作。個人傾向於研究CI-CT-CD-CD。

閱讀原文


關於作者:
CSDN分享Hadoop、Spark、NoSQL/NewSQL、HBase、Impala、記憶體計算、流計算、機器學習和智能算法等相關大數據觀點,提供雲計算和大數據技術、平台、實踐和產業信息等服務。

微信號:csdnbigdata

推薦閱讀:

》生不出男孩被婆家逼走,獨自養兩個女兒流落街頭,如今她是身價60億的水餃皇后!

》她是中國史上最強女海盜,讓多少洋人感受過被她支配的恐懼!