上回說到OpenStack Neutron項目中有關ML2插件的事兒,ML2做爲H版本更新後新生代核心插件的寵兒,其實現了network/subnet/port三種核心資源,同時也實現了包括Port Binding等在內的部分擴展資源。ML2插件經過解耦網絡拓撲類型與底層的虛擬網絡實現機制,並經過Driver的形式進行擴展,解決了傳統核心插件的相關問題。linux
而咱們知道在neutron所提供的服務中,插件和代理是對應着的,儘管咱們說ML2解決了在使用傳統核心插件時全部節點只能使用同一種網絡提供者的問題,可是這並不是意味着不一樣的機制驅動能夠用與之不一樣的網絡提供者提供代理服務,但其實咱們無需考慮這麼多,開發者只須要針對agent開發對應的驅動便可。shell
ML2 Core Plugin及其agent負責將實例鏈接到OpenStack Layer 2虛擬網絡,本文就來談談有關Linux Bridge和Open vSwitch代理的內容。數據庫
在Neutron項目中,官方對於服務和代理給出的介紹爲:一個常見的Neutron設置包括多個服務和運行在一個或多個節點上的代理(儘管有些設置可能不須要任何代理)。每一個服務都提供一些網絡或API服務。特別注意的是:centos
本文談的是基於二層的代理,主要是講述Linux Bridge agent以及Open vSwitch agent,這二者都屬於L2(Layer 2)agent。安全
Linux Bridge是成熟可靠的Neutron二層網絡虛擬技術,支持local、flat、vlan、vxlan這四種網絡類型,目前不支持gre。網絡
Linux Bridge能夠將一臺主機上的多個網卡橋接起來,充當一臺交換機,它能夠橋接物理網卡,又能夠理解爲虛擬網卡,用於橋接虛擬機網卡的是tap設備(通常說是接口),這是一個虛擬機出來的網絡設備,稱爲tap設備,做爲網橋的一個端口,tap接口在邏輯上與物理接口具備相同的功能,能夠接收和發送數據包。(具體tap的原理與建立本文暫且不談論太多,瞭解如下設備含義有助於下面的例子)數據結構
那麼Linux Bridge代理到底是怎麼處理plugin(ML2)傳遞過來的請求的呢?(注意這裏指的是Linux Bridge)ide
咱們舉基於Linux Bridge下flat網絡和vlan網絡來理解,先從flat開始,由於比較簡單,入手方便你們從本質上理解,而vlan網絡來講,是使用的比較多的一種模式,所以仍是須要了解理解一下的。性能
仍是先來理解一下Linux Bridge實現虛擬交換機的原理,雖然比較簡單,可是對於沒有接觸過linux虛擬網絡的朋友而言,下面的內容可能更加無法理解。參考下圖:學習
br0——Linux Bridge,充當虛擬交換機的做用,負責將物理網卡eth0和虛擬網卡tap設備vnet0/vent1鏈接到同一個二層網絡,實現虛擬機VM1和VM2,以及虛擬機與外網之間的通訊(具體的實現過程仍是要學習一下網絡虛擬化相關基礎理論和操做來理解的)
咱們知道,flat network是不帶tag的網絡,因此必需要求宿主機的物理網卡直接與Linux網橋鏈接,這也就代表,每個flat network都會獨佔一起物理網卡,如上圖所示即,eth1橋接到brqxxxx,從而爲實例提供flat網絡。該圖表示的是單一的flat 網絡,若是是多個flat網絡就須要再添加一個物理網卡eth2了。
固然在一些配置文件中確認或修改一下,例如ML2的配置文件是否支持對應類型等等。這裏不深刻探究,明白就好。繼續從橋接到brqxxxxx開始說一下實現flat網絡的原理。對於圖中的kvm若是對其不瞭解,這裏能夠暫時忽略KVM(全寫Kernel-based Virtual Machine——基於內核的虛擬機,屬於2型虛擬化,本文這裏不須要深究,若是有興趣能夠查閱相關文章資料)
Linux Bridge須要和虛擬機實例創建網絡鏈接,就須要經過一個設備(接口)做爲介質,這個設備(接口)就是tap。其實tap常常與tun一塊兒談及,兩者都屬於操做系統內核中的虛擬網絡設備(注意!linux中一切皆文件),只不過tap位於二層,而tun位於三層,而它們之間的差異僅僅在於數據結構封裝中的flag不同而已,這也是如何區分它們的方法,可是它們兩者所承載的功能相差甚遠。本文篇幅有限,就不繼續深究了。只須要知道tap所對應的數據鏈路層協議爲以太網協議(IEEE 802.3),所以tap設備有時候也被稱爲"虛擬以太設備"。
在Linux系統中(centos7)能夠經過下面的命令查看tap有關信息,本文了解便可:
[root@localhost ~]# modinfo tun #查看是否有tun以及其相關信息 filename: /lib/modules/3.10.0-693.el7.x86_64/kernel/drivers/net/tun.ko.xz alias: devname:net/tun alias: char-major-10-200 license: GPL author: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com> description: Universal TUN/TAP device driver rhelversion: 7.4 srcversion: 4E9F57A6269CFD0F4BE4021 depends: intree: Y vermagic: 3.10.0-693.el7.x86_64 SMP mod_unload modversions signer: CentOS Linux kernel signing key sig_key: DA:18:7D:CA:7D:BE:53:AB:05:BD:13:BD:0C:4E:21:F4:22:B6:A4:9C sig_hashalgo: sha256 #顯示如以上信息代表有相關信息 [root@localhost ~]# lsmod | grep tun #是否已經加載 tun 31621 1 #出現這些內容則什麼已經加載過了 [root@localhost ~]# modprobe tun #加載命令 [root@localhost ~]# lsmod | grep tun tun 31621 1
tap實現linux網橋與虛擬機實例之間的網絡通訊,構建了整個基於Linux Bridge的單一flat網絡。
可是咱們知道flat網絡模式對於多租戶的狀況並不友好。因此有了vlan網絡來實現租戶組件網絡的隔離。
其實,基於Linux Bridge實現vlan網絡與前面的flat仍是有相似之處的,不一樣的地方在於flat與vlan自己的不一樣,前面說過flat network是不帶tag的網絡,而vlan剛好與之相反。先看下圖:
3個虛擬機實例一樣是經過tap設備鏈接到brqxxxx的Linux網橋,而右邊的物理網卡eth1就會建立一個名稱爲eth1.100的vlan 接口(100則表示ID號,能夠理解爲tag標記),而且與Linux bridge(brqxxxx)相連,這樣,實例經過eth1.100發送的數據包到eth1上就會被打上100的標記。能夠聯想一下咱們NAT中端口多路複用實現地址轉換的方法來類比理解。
這樣,就建立了一個基於Linux Bridged、vlan100的虛擬網絡,固然這樣的vlan能夠劃分多個,例如eth1.101,eth1.102......以此類推,固然須要鏈接新的Linux Bridge(brqyyyy)。
當每個vlan 網絡都有本身的網橋,那麼這就實現了基於vlan的網絡隔離。可是這裏須要注意的是,該模式下物理交換機與eth1設備之間相連的口須要作trunk了。
說完Linux Bridge,再來談談Open vSwitch吧。
Open vSwitch Agent是L2 Agent的一種實現。L2 Agent與Neutron的Bridge類型相對應(二層),有多種實現,好比:neutron-linuxbridge-agent、neutron-openvswitch-agent等。
與linux bridge相比,Open vSwitch (可簡稱OVS)具備幾種管控功能,並且性能更加優化,支持更多的功能,目前在openstack領域被稱爲主流。不過對於OVS實現網絡而言理解起來更加複雜,因此先前就先從Linux Bridge入手。
OVS支持local、flat、vlan、vxlan、gre、geneve等全部網絡類型。
先來了解一下OVS中的各類網絡設備:
(1)tap interface,命名爲tapXXXX。 (2)linux bridge,命名爲qbrXXXX。 (3)veth pair,命名爲qvbXXXX,qvoXXXX。 (4)OVS integration bridge,命名爲br-int,集成網橋,全部實例的虛擬網卡和其餘虛擬網絡設備都鏈接到該網橋。 (5)OVS patch ports,命名爲int-br-ethX和phy-br-ethX(X爲interface的序號)。 (6)OVS provider bridge,命名爲br-ethX(X爲interface的序號)。 (7)物理interface,命名爲ethX(X爲interface的序號)。 (8)OVS tunnel bridge,命名爲br-tun,隧道(tunnel)網橋,基於隧道技術的 VxLAN 和 GRE 網絡將使用該網橋進行通訊
注意:OVS provider bridge會在flat和vlan網絡中使用;OVS tunnel bridge則會在vxlan和gre網絡中使用。
其中,集成網橋br-int在neutron網絡中,一般用來鏈接Linux網橋和隧道網橋,而且進行不一樣網絡ID之間的映射轉換。對於不一樣的網絡模式中,其實現的功能也是不一樣的。
下面經過基於OVS的vlan網絡結構案例來講明OVS實現網絡的原理過程。
筆者PS水平通常,因此從網上截取來一張圖來做爲案例,省點時間,勿怪~^_^!左側是圖例,對應顏色來看哦!
上面三層之間的聯繫沒必要多說,而中間的veth對是個什麼玩意兒呢?
先來了解一下上圖中的一些小模塊。
一、qbrxxx:Linux網橋(Bridge)設備,qbrxxx位於實例和br-int網橋之間,主要負責網絡安全組(Security Group)規則設置; 二、qvbxxx:Neutron的VETH設備,qvb表示Linux Bridge一側的veth設備,qvb各個字母解釋爲:q-quantum, v-veth, b-bridge(quantum是Neutron的前身); 三、qvoxxx:Neutron的VETH設備,qvo表示OpenVswitch一側的veth設備,qvo各個字母的解釋爲:q-quantum, v-veth, o-openvswitch;
根據網上資料介紹,veth pair是虛擬Ethernet設備,VETH設備老是成對出現,向其一端輸入數據,VETH會改變數據的方向並將其送入內核網絡核心,完成數據的注入,以後在另外一端便能讀到此數據。簡單而言,從VETH設備一端輸入的數據老是會從另外一端輸出。
所以,在Neutron中,兩個不一樣網橋之間一般使用VETH對進行數據傳輸。也就是說,Linux網橋與OVS集成網橋之間是提供veth對進行數據傳輸通訊的。而且經過端口所分配的vlan ID進行隔離。
再來看OVS集成網橋br-int與OVS供應商網橋之間的PATCH端口,這裏正好能夠與前面的Veth pair類比理解,Patch Port兩段鏈接的也是不一樣的網橋,其中int-br-eth 1則是集成網橋上的Patch port設備,phy-br-eth 1供應商網橋上的Patch Port設備。而vlan ID在兩者之間作轉換,能夠類比NAT理解。
從外到內來看,即向上傳輸數據包的時候,vlan id根據flow table作轉換,將外部定義好的id號轉換爲內部使用的vid號,即101——>1,102——>2,而從內到外而言剛好相反。而這塊是真正基於二層代理所配置的部分。
本文主要講述的是經過部分案例介紹有關L2代理中Linux Bridge和OVS基於不一樣網絡類型實現網絡服務的原理,其中還包括擴展補充了一些Linux虛擬網絡的理論部分知識。