openstack 網絡架構 nova-network + neutron

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環境，大二層通信的需求相對弱一些。