[轉]OpenStack Neutron運行機制解析概要

標籤：

轉載自：http://panpei.net.cn/2013/12/04/openstack-neutron-mechanism-introduce/

 

 

自從開學以來，玩OpenStack也已經3個月了，這段時間主要把精力投在了OpenStack的安裝部署和網路組件Neutron的研究上了。這期間零零散散在安裝部署和Neutron運作原理上來回切換，有點在實踐中學習的味道，雖然在安裝部署的過程遇到了不少的問題，也一一都給解決了。然而，總是覺得對於Neutron的機制理解的還是不夠透徹。前一陣子剛剛部署好一套Havana版本的系統，並開始投入使用。這陣子又開始投入OpenStack的IPv6的實驗中，因為需要對底層的路由機制進行徹底的瞭解，所以不得不又開始重新捋了一遍這方面的知識，在網上Google了一把資料，這次算是徹底的把Neutron的運作機制徹底的理清楚了，之前那些半懂不懂的東西，現在也是覺得豁然開朗了。

這次在RDO找到了想要的資料，至少這篇資料對於之前的那些零散的知識做了一個很好的連貫，對於自己而言，算是把Neutron講解徹底明了,現在把那篇材料翻譯下再糅合點自己的理解吧。

借用原資料上的一張架構圖為開篇：

從這張架構圖中，我們可以明顯的看到有兩個物理主機，計算節點和網路節點，這是因為採用了網路節點集中式的部署方式。至於為什麼採用這種部署方式，那是因為自從E版之後，OpenStack開始把network功能從Nova中分離出來，使之成為獨立的Neutron組件。而坑爹的是，分離後的版本，反而不支援網路分布式部署的特性了，所以目前的Grizzly和Havana版本都是只能使用網路集中式部署方案的，或者說，叢集中只能存在一個部署網路功能的節點。

計算節點：虛擬機器執行個體的網路

看，這段網路包含了A、B、C這三段的流程。A就是虛擬機器test0的虛擬網卡，這塊沒什麼好講的。和它相連的B倒是值得好好講一下。B是一個TAP裝置，通常是以tap開頭的一段名稱，它掛載在Linux Bridge qbr上面。那什麼又是TAP裝置呢？Linux 中的虛擬網路中給出了這樣的解釋：

TAP是一個虛擬網路核心驅動，該驅動實現Ethernet裝置，並在Ethernet架構層級操作。TAP驅動提供了Ethernet “tap”，訪問Ethernet架構能夠通過它進行通訊。

總而言之，TAP裝置其實就是一個Linux核心虛擬化出來的一個網路介面。OK，我們明白了TAP裝置了，如果還是不明白可以查看TAP的具體定義。接下來就是qbr，這之前就說了，是一個Linux Bridge，很是奇怪，我們在這個架構中，使用的OpenvSwitch實現虛擬交換裝置的，為什麼會出現Linux Bridge呢？OpenStack Networking Administration Guide給出了這樣的解釋：

Ideally, the TAP device vnet0 would be connected directly to the integration bridge, br-int. Unfortunately, this isn’t possible because of how OpenStack security groups are currently implemented. OpenStack uses iptables rules on the TAP devices such as vnet0 to implement security groups, and Open vSwitch is not compatible with iptables rules that are applied directly on TAP devices that are connected to an Open vSwitch port.

其實就是說，OpenvSwitch不支援現在的OpenStack的實現方式，因為OpenStack是把iptables規則丟在TAP裝置中，以此實現了安全性群組功能。沒辦法，所以用了一個折衷的方式，在中間加一層，用Linux Bridge來實現吧，這樣，就莫名其妙了多了一個qbr橋接器。在qbr上面還存在另一個裝置C，這也是一個TAP裝置。C通常以qvb開頭，C和br-int上的D串連在一起，形成一個串連通道，使得qbr和br-int之間順暢通訊。

計算節點：整合橋接器(br-int)的網路

剛才說到D(這也是一個TAP裝置)在br-int上面，現在輪到br-int出場了，br-int是由OpenvSwitch虛擬化出來的橋接器，但事實上它已經充當了一個虛擬交換器的功能了。br-int的主要職責就是把它所在的計算節點上的VM都串連到它這個虛擬交換器上面，然後利用下面要介紹的br-tun的 穿透功能，實現了不同計算節點上的VM串連在同一個邏輯上的虛擬交換器上面的功能。這個似乎有點拗口，其實就是在管理員看來，所有的VM都是串連在一個虛 擬交換器上面的，但事實上這些VM又都是分布在不同的物理主機上面。OK，回到D上面，D通常以qvo開頭。在上面還有另一個連接埠E，它總是以patch-tun的形式出現，從字面就可以看出它是用來串連br-tun的。

計算節點：通道橋接器(br-tun)的網路

br-tun在上面已經提及了，這同樣是OpenvSwitch虛擬化出來的橋接器，但是它不是用來充當虛擬交換器的，它的存在只是用來充當一個通道層，通過它上面的裝置G與其他物理機上的br-tun通訊，構成一個統一的通訊層。這樣的話，網路節點和計算節點、計算節點和計算節點這樣就會點對點的形成一個以GRE為基礎的通訊網路，互相之間通過這個網路進行大量的資料交換。這樣，網路節點和計算節點之間的通訊就此打通了。而圖中的G、H正是描畫這一通訊。

網路節點：通道橋接器（br-tun）的網路

正如前面所說，網路節點上也是存在一個br-tun，它的作用同計算節點上的br-tun如出一轍，都是為了在整個系統中構建一個統一的通訊層而存在的。所以，這一部分的網路同計算節點上的網路的功能是一致的，因此，也就沒有必要多說了。

網路節點：整合橋接器（br-int）的網路

網路節點上的br-int也是起了交換器的作用，它通過I、J與br-tun串連在一起。最終的要的是，在這個虛擬交換器上，還有其他兩個重要的tap裝置M、O，它們分別同N、P相連，而N、P作為tap裝置則是分別歸屬兩個namespacerouter和dhcp，沒錯，正如這兩個namespace的名稱所示，它們承擔的就是router和dhcp的功能。這個router是由l3-agent根據網路管理的需要而建立的，然後，該router就與特定一個子網綁定到一起，管理這個子網的路由功能。router實現路由功能，則是依靠在該namespace中的iptables實現的。dhcp則也是l3-agent根據需要針對特定的子網建立的，在這個namespace中，l3-agent會啟動一個dnsmasq的進程，由它來實際掌管該子網的dhcp功能。由於這個兩個namespace都是針對特定的子網建立的，因而在現有的OpenStack系統中，它們常常是成對出現的。

網路節點：外部橋接器（br-ex）的網路

當資料從router中路由出來後，就會通過L、K傳送到br-ex這個虛擬橋接器上，而br-ex實際上是混雜模式載入在物理網卡上，即時接收著網路上的資料包。至此，我們的計算節點上的VM就可以與外部的網路進行自由的通訊了。當然，前提是我們要給這個VM已經分配了float-ip。

關於OpenStack Neutron的分析大致描述這些吧，後續的話會詳細的寫一些文章來詳細介紹整個的詳細流程和相關的實現方式。

[轉]OpenStack Neutron運行機制解析概要