openstack 網路架構 nova-network + neutron

標籤：基礎上   form   https   手動   分配   分割   log   實際應用   nbsp   

openstack網路架構（nova-network/neutron）

openstack網路體系中，網路技術沒有創新，但用到的技術點非常龐雜，包括bridge、vlan、gre、vxlan、ovs、openflow、sdn、iptables等，當然這裡不會做具體技術介紹，概述技術，主要將其與openstack的結合點做詳細分析。

nova-network網路架構

在nova-network中，其網路模型包括flat、dhcp flat、vlan，用到的技術主要有bridge、vlan，

dhcp flat多網路節點架構

優點：結構簡單，穩定

缺點：所有租戶都在一個水平面上，租戶之間沒有隔離，由於所有租戶都在一個子網內，當大規模部署後，其廣播風暴將會是不小的負面因素，至於這種模型其vm的上限，筆者還沒有條件測試。

vlan架構

• 為租戶建立獨佔的bridge
• 建立vlan介面vlan100，依據802.1q協議打vlanid
• Dnsmasq監聽橋接器網關，負責fixedip的分配
• switch port設定為chunk mode
• eth0負責vm之間的資料通訊，eth1負責外網訪問

優點：租戶有隔離

缺點：需要物理交換器chunk口的支援，實際部署時比較複雜，vlan id個數為4094個，也就是最多4094個子網租戶，不適用於公用雲端。

結論

相比於neutron網路，雖說沒有neutron那麼多的功能外掛程式，僅有bridge，但是其穩定性已得到大多數使用者的驗證，對於小規模的私人雲端(1千台虛機的規模)，nova-network是可以考慮的，目前線上部署的環境也是nova-network。

參考資料：

https://www.mirantis.com/blog/openstack-networking-flatmanager-and-flatdhcpmanager/

https://www.mirantis.com/blog/vlanmanager-network-flow-analysis/

https://www.mirantis.com/blog/openstack-networking-vlanmanager/

http://blog.csdn.NET/hilyoo/article/details/7721401

http://blog.csdn.Net/beginning1126/article/details/39371757

neutron網路架構

neutron網路體系相比於nova-network要複雜的多，用到的技術點也非常龐雜，在介紹網路架構之前，有必要概述下gre、vxlan、ovs、openflow、sdn技術點。

上面闡述過，vlan技術存在vlan id個數限制4094，公用雲端租戶肯定不止4094，二層技術，只能部署在一個區域網路內，無法實現跨機房部署。為了突破這倆個限制，增加了gre和vxlan隧道技術。

GRE：

跨機房部署：3層隧道技術，在原來小網ip頭前面加入大網ip頭和gre頭，大網ip頭裡面的ip是公網ip；

segment id：而gre頭裡面最重要的欄位應該是4位元組key值（segment id），充當了vlan技術裡面的vlan id，隔離租戶的作用，由於是4個位元組，已經不受4094 vlan id限制。是gre典型應用vpn。

當然gre也有其缺點，

1. gre是點對點技術，每兩個點之間都需要有一個隧道，對於4層的連接埠資源是一種浪費；
2. 增加ip頭，勢必減少vm的mtu值，同樣大小的資料，需要更多的ip包來傳，傳輸效率有影響。

VXLAN：

針對vlan和gre的第一個缺點，業界提出了vxlan技術，分別是vxlan頭結構和通訊流程。

1. 24bit的VNID：vxlan技術在原有mac幀基礎上增加了新的mac頭、ip頭、vxlan header，在vxlan header中，VNID相當於vlan id，24bit，16M的大小，遠大於4094.
2. 大二層網路，實現跨機房部署：在通訊兩端增加了VTEP裝置，可以硬體裝置，也可以軟體實現，當然在neutron網路中，其是由軟體實現的。該裝置記錄vlan id、vm mac、vtep ip的對應關係，這個關係是由vm發起arp請求擷取到的。在vxlan網路中有個組播地址，所有vtep裝置都需要加入該組播地址，vtep將arp的廣播請求增加組播ip頭轉變為組播請求，一旦一個vm發起arp請求，所有vtep都能收到，vtep在將組播ip頭去掉，將原始廣播包發給vm，這樣不同vm之間將建立起arp表。vxlan網路為所有vm建立一個大2層網路。
3. 能讓遺留子網不改變 IP 位址的情況下無縫的遷移到雲上來；也可以讓虛機跨資料中心進行遷移（以前頂多隻能在同一個 VLAN 裡遷移）
4. 關於跨機房vxlan互連：前述通過組播訊息實現arp的傳輸，但是在廣域網路上，組播包傳輸是受限制的，目前業界通常的解決方案是通過SDN controller，SDN controller兼做arp代理，並擷取vm內層mac和外層VTEP ip對應關係，不同controller之間交換這些資訊。

結論：

1. gre解決了vlan id個數限制和跨機房互連問題；
2. vxlan解決了vlan id個數限制和跨機房互連問題，同時解決了gre點對點隧道個數過多問題，同時實現了大2層網路，可用於vm在機房之間的的無縫遷移。

參考資料：

http://blog.csdn.net/freezgw1985/article/details/16354897

http://www.cisco.com/c/en/us/products/collateral/switches/nexus-9000-series-switches/white-paper-c11-729383.html

openflow

openflow主要分為controller和flow table，並且其通訊遵循openflow協議。增加了controller點，openflow switch僅僅根據flow table設定好的規則對資料做路由或丟棄等操作，而整個系統的大腦部分在controller，所有flow table的路由規則、處理方法都是從controller得到。

 

Openflow的優點：

1. 控制邏輯和物理交換網路相分離；
2. 物理網路分割成相互獨立的邏輯網路

Openflow問題：

1. 和現有物理網路相衝突，很難實際應用

實驗室截取的流表執行個體：

參考資料：

 

http://www.ibm.com/developerworks/cn/cloud/library/1303_silei_openflow/

http://mytrix.me/2014/04/dive-into-openstack-neutron-on-compute-node/

http://www.kankanews.com/ICkengine/archives/101651.shtml

OVS：

相比於Linux bridge，ovs有以下好處

1. Qos配置，可以為每台vm配置不同的速度和頻寬
2. 流量監控
3. 資料包分析
4. 將openflow引入到ovs中，實現控制邏輯和物理交換網路分離。

 

參考資料：

http://blog.csdn.net/canxinghen/article/details/39344797

http://bengo.blog.51cto.com/4504843/791213                    

http://www.cloudstack-china.org/2013/09/2484.html

到此為止，關於gre、vxlan、openflow、ovs基本情況基本介紹完了，下面將是應用這些技術介紹neutron網路架構體系。

neutron體繫結構組成

1. Neutron Server： 這 一部分包含守護進程neutron-server和各種外掛程式neutron-*-plugin，它們既可以安裝在控制節點也可以安裝在網路節點。 neutron-server提供API介面，並把對API的調用請求傳給已經配置好的外掛程式進行後續處理。外掛程式需要訪問資料庫來維護各種配置資料和對應關係，例如路由器、網路、子網、連接埠、浮動IP、安全性群組等等。

2. 外掛程式代理（Plugin Agent）：虛擬網路上的資料包的處理則是由這些外掛程式代理來完成的。名字為neutron-*-agent。在每個計算節點和網路節點上運行。一般來說你選擇了什麼外掛程式，就需要選擇相應的代理。代理與Neutron Server及其外掛程式的互動就通過訊息佇列來支援。

3. DHCP代理（DHCP Agent）： 名字為neutron-dhcp-agent，為各個租戶網路提供DHCP服務，部署在網路節點上，各個外掛程式也是使用這一個代理。

4. 3層代理 （L3 Agent）： 名字為neutron-l3-agent， 為客戶機訪問外部網路提供3層轉寄服務。也部署在網路節點上。

 

Control node：neutronserver(api/neutron-*-plugin)

Network node：neutron-*-plugin-agent/l3-agent/dhcp-agent

Computer node：neutron-*-plugin-agent

在neutron體系中，應用最多的兩個外掛程式就是Linux bridge和ovs，筆者在實驗室分別搭建過Linux bridge+vxlan和ovs+vxlan。下面分別是從官網上截取的網路結構圖，官網給出的是vlan的情況，其實和vxlan區別不大。

ovs+vxlan computer node and network node

 

網路架構圖

 

是不是看到這2張圖就有些暈了，這麼多個bridge、tap裝置都是做什麼用的，理解這些裝置其實並不難，redhat有篇文章寫的非常詳細，大家看看就非常明白了，https://openstack.redhat.com/Networking_in_too_much_detail，官方給出的圖是vlan拓撲，其實只要將圖中的vlan device改成vxlan device就可以，不妨礙表述結構。

在ovs結構中，如果網路拓撲是vxlan或gre，則有兩個bridge，分別是br-int和br-tun(由於是vlan環境，沒有br-tun，而是br-eth1)，br-int叫整合橋接器，用於串連起上方的各個裝置（包括vm、dhcp-agent、l3-agent），br-tun叫隧道橋接器，隧道既可以是gre，也可以是vxlan，br-tun負責在原始報文中加入gre或vxlan報文頭。相當於軟體實現了vtep裝置(對於vxlan而言)，

flow table

這裡值得一提的是network node br-tun中的flow table，如所示，對於flow table的各個表項大家可以參考文章http://mytrix.me/2014/04/dive-into-openstack-neutron-on-compute-node/，這裡不做過多闡述。

作者實驗室搭建了1個network node和2個computer node，port 1對應網路節點的br-int，port 2、3對應2個computer node，可以看出，當由computer node來的資料包（port 2、3），改完vlan標籤之後，要先通過自學習的過程（對應table 10），然後輸出給port 1，學習的結果就是table 20，table 20將vlan id和目標vm的mac地址作為匹配項，匹配上之後。輸出給port 2、3。

 

通訊流程

同一租戶不同host vm fixed ip通訊流程如所示，如果通過fixed ip通訊，不需要經過network node，通過br-tun加上vxlan標籤則可以實現不同host上的vm通訊。

不同租戶不同host vm floating ip通訊流程如所示，如果是通過floating ip進行通訊，需要經過network node做dnat、snat、路由，為什麼要通過network node呢？原因是目標ip地址是floating ip，和vm2 fixed ip不在一個網段，所以其對ip包的處理需要將包傳遞給租戶2的預設閘道mac4/ip4，傳給給預設閘道後需要做dnat轉換，然後路由給租戶1的預設閘道mac3/ip3，再做snat轉換，最後將包傳遞給vm1，注意包傳遞過程中，其內外層mac地址和ip地址的轉換。

Linux bridge + vxlan computer node and network node

有了ovs的基礎，理解bridge的結構就簡單多了，但是作者在用rdo搭建bridge + vxlan的環境時，遇到很多問題：

1. rdo安裝linuxbridge，需修改neutron_350.py create_l3_manifests函數；

2.  

   配置Linuxbridge + vxlan環境，computer node network node，其linuxbridge_conf.ini配置項enable_vxlan、vxlan_group、local_ip一定要加以配置，否則bridge、vxlan裝置則不能正確建立，虛擬機器也無法建立；

3.  

   對於Linuxbridge + vxlan環境，network node需要2塊網卡，一個內網、一個外網，一個用於dhcp，一個用於floating ip外網訪問，這個是必須的，否則二者功能只能取其一，但是在搭建ovs環境時，卻沒有這個問題，很奇怪；
4. network node需要手工建立一個br-ex，用於外網訪問；
5. 最詭異的是，環境搭建完成初始狀態，network node上，各tap裝置綁定的bridge全是錯誤的，需要手動修改；
6. 需要修改vm mtu值，否則vm之間通訊效率非常差。

 

組網方式

典型的組網方式包括nova-network的dhcpflat、vlan，neutron的bridge + vlan、bridge + vxlan、ovs + vlan、ovs + vxlan，其選擇上可以從3個維度來看，nova-network和neutron的選擇、網路拓撲flat、vlan、gre、vxlan的選擇、外掛程式Linux bridge和ovs的選擇。

nova-network和neutron的選擇：

1. nova-network：穩定，結構簡單，但目前僅支援linux bridge一種外掛程式；
2. neutron：可以支援bridge、ovs等眾多外掛程式，並且通過ml2技術可以實現眾多外掛程式混合使用，引入openflow等sdn技術，是控制邏輯和物理網路相隔離。但neutron目前最大的問題是穩定性（例如建立過多的vm，host會無故重啟，neutron服務會無故down掉，floating ip無法正常釋放等，這些問題目前都在尋找原因，尚未解決），而且iec house版本不支援network muti-host部署（據說juno版本支援，接下來搭建個環境研究一下）

結論：未來的openstack，neutron組件會是其趨勢，nova-network會漸漸被替換掉，但是在未解決其穩定性和network node ha問題之前還不適用於線上環境。

網路拓撲flat、vlan、gre、vxlan的選擇：

1. flat： 模式簡單，但有廣播風暴的風險，不適於大規模部署（一千台vm？）；
2. vlan：可以隔離廣播風暴，但需要配置物理交換器chunk口；
3. gre：可以隔離廣播風暴，不需要交換器配置chunk口， 解決了vlan id個數限制，3層隧道技術可以實現跨機房部署。但gre是點對點技術，每兩個點之間都需要有一個隧道，對於4層的連接埠資源是一種浪費；
4. vxlan：可以隔離廣播風暴，不需要交換器配置chunk口， 解決了vlan id個數限制，解決了gre點對點隧道個數過多問題，實現了大2層網路，可用於vm在機房之間的的無縫遷移，便於跨機房部署。唯一的缺點就是vxlan增加了ip頭部大小，需要降低vm的mtu值，傳輸效率上會略有下降。

結論：如果不需要通過大二層網路實現跨機房部署，可以選擇vlan，如果涉及到跨機房部署，需要大二層的通訊方式，選擇vxlan。

Linux bridge和ovs的選擇：

這兩種外掛程式是目前業界使用最多的，非官方統計（摘自http://wenku.it168.com/d_001350820.shtml） 二者在眾多外掛程式使用份額是，Linux bridge31%、ovs 39%

1. Linux bridge：曆史悠久，穩定性值得信賴，但是當vm個數過多，二層交換出現問題時，目前沒有特別好的定位手段。
2. ovs：可以針對每個vm做流量限制、流量監控、資料包分析，同時可以引入openflow，引入sdn controller，使控制邏輯和物理交換相分離，並且sdn controller可以實現vxlan的跨機房大二層通訊，但是業界普遍認為其效能是個大問題。

 

實驗室測試結果：

不同host上的兩個vm，通過ping測試回應時間，如下表所示

組網	fixed ip	floating ip	備忘
Linux bridge + vxlan	1.124ms	1.509ms
ovs + vxlan	1.179ms	1.898ms
關閉安全性群組 ovs + vxlan	1.073ms

在同一個host上的，2個vm互跑流量，如下表所示

組網	輸送量	cpu佔用情況	備忘
Linux bridge + vxlan	7.86 Gbits/sec	23.7%us, 15.7%sy, 52.1%id, 8.5%si
ovs + vxlan	7.10 Gbits/sec	23.1%us, 16.5%sy, 46.9%id, 13.5%si
關閉安全性群組ovs + vxlan	8.32 Gbits/sec	28.7%us, 19.4%sy, 46.3%id, 5.6%si

測試結果說明：

1、cpu佔用量記錄的是瞬時值，上下會有大約5%的波動。

2、關於回應時間：ovs+ vxlan（關閉安全性群組）< Linux bridge + vxlan <  ovs +vxlan

3、關於輸送量：ovs+ vxlan（關閉安全性群組）> Linux bridge + vxlan >  ovs +vxlan

4、在ovs組網中，需要為每個vm建立一個bridge（用於安全性群組的實現），所以關閉安全性群組，將vm直接橋接到ovs上，其輸送量回應時間都會有所改善。

5、就本次結果來看，在不採用安全性群組的情況下，ovs效能要略好於Linux bridge

網上找的一篇測試報告（原文連結：https://docs.google.com/viewer?url=http%3A%2F%2Fwww.ustack.com%2Fwp-content%2Fuploads%2F2013%2F10%2FNeutron-performance-testing.pdf）

 

結論：關於ovs的效能問題，還需要大量線上測試（這部分工作，作者正在做，希望儘快給出量化指標），所以在未確定ovs效能是否達到我們要求之前，建議使用Linux bridge。

官方推薦的組網方式：

通過查閱openstack官方文檔，其更傾向於bridge+vlan和ovs+vlan

私人雲端和公用雲端的組網差異：

公用雲端其vm個數巨大，幾十萬、幾百萬的數量級，涉及跨機房部署，需要大二層通訊機制。私人雲端其vm個數相對有限，幾千、幾萬的數量級，可以在每個機房單獨部署一套openstack環境，大二層通訊的需求相對弱一些。

openstack 網路架構 nova-network + neutron