一、Openstack網絡基礎
下面對Openstack和Neutron的介紹，要從幾個關鍵詞入手。
1. 三代網絡
在網絡這一口，OpenStack經歷了由nova-network到Quantum再到Neutron的演進過程。我們直觀地來看看三代網絡的對比分析：
| 出現 版本 |
支持組 網模式 |
優點 |
缺點 |
適用場景 |
|
| Nova-network | 早期 |
|
以實現HA |
|
對性能和穩定性要求比較高；中小規模網絡；網絡運維成本有限；私有雲環境 |
| Quantum | Folsom |
|
|
共同運行 |
基本上已經都跟進到了Neutron |
| Neutron | Havana |
|
|
|
對功能要求比較多或希望向SDN演進；大規模網絡或對可擴展性要求高；有專業的網絡運維團隊；公有雲環境 |
- Nova-network是隸屬於nova項目的網絡實現，它利用了linux-bridge（早期，目前也支持OVS）作為交換機，具備Flat、Flat DHCP、VLAN三種組網模式。優點是性能出色，工作穩定，支持multi-host部署以實現HA；缺點是網絡模塊不獨立，功能不夠靈活，組網模式也比較受限。
- Quantum作為獨立的網絡管理項目出現在F版本，除了linux-bridge外還支持OVS，以及以及其他商業公司的插件，組網模式上增加了對GRE和VxLAN兩個Overlay技術的支持。優點是功能靈活，支持大二層組網；缺點是集中式的網絡節點缺乏HA，而且各廠商插件無法同時在底層網絡中運行。
- Neutron出現在H版本，由來是Quantum和一家公司的名稱沖突而改名。Neutron對Quantum的插件機制進行了優化，將各個廠商L2插件中獨立的數據庫實現提取出來，作為公共的ML2插件存儲租戶的業務需求，使得廠商可以專注於L2設備驅動的實現，而ML2作為總控可以協調多廠商L2設備共同運行。Neutron繼承了Quantum對大二層的支持，還支持L2 PoP，DVR，VRRP，HA等關鍵功能，集成了很多L4-L7的網絡服務，一些blueprint也正在積極開發中，如SFC等。優點是開始引入SDN思想，功能上更為豐富，網絡兼容性強；缺點是代碼結構復雜，工作不夠穩定，HA機制仍缺乏大規模商用的檢驗。
從應用場景來看，Nova-network組網模式過於簡單，一些復雜的網絡需求無法實現（比如兩個公司合並，有大量IP重合的VM要遷移到一個平台，而且要求遷移后都要用原來的IP）。不過由於其簡單穩定的特點，仍適合於中小型企業的生產環境；Quantum的實際部署目前基本都跟進到了Neutron；Neutron的大二層組網，適合於雲計算規模的生產環境，但是由於分布式和HA機制仍不夠成熟，因此目前多見於私有雲和小規模共有雲的部署，大規模的公有雲仍然難以使用Neutron實現。
2. 四種組網模型
說完了基本特征與應用場景，下面開始對上述提到的一些網絡問題進行詳細的描述。我們拋開技術，結合圖例來抽象地看看不同的組網模型。當然，以下模型的實現不僅僅局限於三張圖中的方式。
- Flat模型最為簡單，所有的虛擬機共用一個私有IP網段，IP地址在虛擬機啟動時完成注入，虛擬機間的通信直接通過HyperVisor中的網橋轉發，公網流量在該網段的網關上進行NAT（Nova-network實現為開啟nova-network主機內核的iptables，Neutron實現為網絡節點上的l3-agent）。Flat DHCP模型與Flat區別在於網橋中開啟了DHCP進程，虛擬機通過DHCP消息獲得IP地址（Nova-network實現為nova-network主機中的dnsmaq，Neutron實現為網絡節點上的dhcp-agent）。
- VLAN模型引入了多租戶機制，虛擬機可以使用不同的私有IP網段，一個租戶可以擁有多個IP網段。虛擬機IP通過DHCP消息獲取IP地址（Nova-network實現為nova-network主機中的dnsmaq，Neutron實現為網絡節點上的dhcp-agent）。網段內部虛擬機間的通信直接通過HyperVisor中的網橋轉發，同一租戶跨網段通信通過網關路由，不同租戶通過網關上的ACL進行隔離，公網流量在該網段的網關上進行NAT（Nova-network實現為開啟nova-network主機內核的iptables，Neutron實現為網絡節點上的l3-agent）。如果不同租戶邏輯上共用一個網關，則無法實現租戶間IP地址的復用。
- Overlay模型（主要包括GRE和VxlAN隧道技術），相比於VLAN模型有以下改進。1）租戶數量從4K增加到16million；2）租戶內部通信可以跨越任意IP網絡，支持虛擬機任意遷移；3）一般來說每個租戶邏輯上都有一個網關實例，IP地址可以在租戶間進行復用；4）能夠結合SDN技術對流量進行優化。
3. 三類節點和三類網絡
看過抽象的組網模型，下面我們來介紹組網具體的實現技術。下面的介紹都是針對Neutron的，對nova-network和Quantum將不做討論。
- 3類節點——管理節點：實現鏡像、塊存儲、身份認證、前端等服務，運行nova-compute的調度模塊以及nova api-server；計算節點：實現nova-compute，以及neutron的各種agent（一般不包括l3-agent，DVR除外）；網絡節點，：實現neutron各種agent。注意，由於OpenStack為分布式架構實現，因此neutron-server既可以運行在控制節點，也可以運行在網絡節點。
- 3種網絡——OpenStack內部模塊之間的交互發生在管理網絡，虛擬機之間的通信發生在數據網絡，而External Network/API Network網絡是連接外網的，無論是用戶調用Openstack API，還是虛擬機與外網間的互通都需要經過這個網絡。
目前OpenStack通常采用out-of-bound方式進行部署，管理網絡與另外兩個網絡是獨立的，管理節點上一般也不會承載Openstack的業務流量，下面的分析中網絡只涉及數據網絡與External Network/API Network網絡，節點只涉及計算節點和網絡節點。
4. 兩張圖例
有了以上知識作為基礎，就可以來分析Openstack中的網絡通信了。由於OpenStack中容器的通信機制目前尚不成熟，並且有專門的項目Kuryr去實現容器相關網絡技術，以下內容將不涉及OpenStack中的容器通信。
以下將通過兩張圖來分析Neutron中的VLAN組網模型，HyperVisor中的網絡設備以OpenvSwitch為例。這三張圖中每一個信息都是有用的，把這些信息完全弄懂了，Neutron的組網也就能基本掌握了，Overlay模型與VLAN模型的區別只在於將圖中的br-eth1替換成br-tun即可，具體隧道如何進行封裝，稍后我們再詳細介紹。
第一張圖是計算節點上的網絡實現。以虛擬機發出流量方向為例，從虛擬機處開始分析：
1)流量經由虛擬機IP內核交給虛擬網卡處理，虛擬網卡由TAP軟件實現，TAP允許用戶態程序向內核協議棧注入數據，它可以運行於虛擬機操作系統之上，能夠提供與硬件以太網卡完全相同的功能。
2)TAP設備並不是直接連接到OVS上的，而是通過Linux bridge中繼到ovs br-int上，其原因在於ovs無法實現linux bridge中一些帶狀態的iptables規則，而這些規則往往用於以虛擬機為單位的安全組（security group）功能的實現。qbr是quantum bridge的縮寫，Neutron中沿用了Quantum的叫法。
3)linux bridge與ovs br int間的連接通過veth-pair技術實現，qvb代表quantum veth bridge，qvo代表quantum veth ovs。veth-pair用於連接兩個虛擬網絡設備，總是成對出現以模擬虛擬設備間的數據收發，其原理是反轉通訊數據的方向，需要發送的數據會被轉換成需要收到的數據重新送入內核網絡層進行處理。veth-pair與tap的區別可以簡單理解為veth-pair是軟件模擬的網線，而tap是軟件模擬的網卡。
4)ovs br-int是計算節點本地的虛擬交換設備，根據neutron-server中OVS Plugin的指導，完成流量在本地的處理：本地虛擬機送入的流量被標記本地VLAN tag，送到本地虛擬機的流量被去掉本地VLAN tag，本地虛擬機間的2層流量直接在本地轉發，本地虛擬機到遠端虛擬機、網關的流量由int-br-eth1送到ovs br-eth1上（在Overlay模型中送到ovs br-tun上）。注意，無論是VLAN模型還是Overlay模型，由於br-int上VLAN數量的限制，計算節點本地最多支持4K的租戶。
5)ovs br-int與ovs br-eth1間的連接通過veth-pair技術實現。
6)ovs br-eth1將該計算節點與其他計算節點、網絡節點連接起來，根據neutron-server中OVS Plugin的指導，完成流量送出、送入本地前的處理：根據底層物理網絡租戶VLAN與本地租戶VLAN間的映射關系進行VLAN ID的轉換（Overlay模型中此處進行隧道封裝，並進行VNI與本地租戶VLAN ID間的映射）。由於底層物理網絡中VLAN數量的限制，VLAN模型最多支持4K的租戶，而Overlay模型中，24位的VNI最多支持16million的租戶。
7)ovs br-eth1直接關聯物理宿主機的硬件網卡eth1，通過eth1將數據包送到物理網絡中。Overlay模型中ovs br-tun通過TUN設備對數據包進行外層隧道封裝並送到HyperVisor內核中，內核根據外層IP地址進行選路，從硬件網卡eth1將數據包送到物理網絡中。TUN與TAP的實現機制類似，區別在於TAP工作在二層，而TUN工作在三層。
第二張圖是網絡節點上的網絡實現，以流量流入網絡節點方向為例，從底層物理網絡流量通過eth1進入ovs br-eth1（Overlay模型中為ovs br-tun）開始分析：
1)ovs br-eth1將網絡節點與計算節點連接起來，根據neutron-server中OVS Plugin的指導，完成流量送入網絡節點前的處理：根據底層物理網絡租戶VLAN與本地租戶VLAN間的映射關系進行VLAN ID的轉換（Overlay模型中此處進行解封裝，並進行VNI與本地租戶VLAN ID間的映射）。注意，雖然同一租戶在底層物理網絡上的VLAN ID（Overlay模型中為VNI）唯一，但是在網絡節點與計算節點，不同計算節點中同一租戶對應的本地VLAN ID可能有所不同。另外由於網絡節點也要在ovs br-int上使用本地VLAN，而租戶跨網段流量與公網流量都要經過網絡節點，因此使用單個網絡節點時，Neutron最多能支持4K租戶，可采用部署多個網絡節點的方式來解決這一問題。
2)送入網絡節點的流量，由ovs br-eth1（ovs br-tun）通過veth-pair送給ovs br-int，ovs br-int連接了本地不同的namespace，包括實現dhcp功能的dhcp-agent——dnsmasq，以及實現路由功能的l3-agent——router。Dnsmasq負責給對應租戶的虛擬機分配IP地址，而router負責處理租戶內跨網段流量以及公網流量。不同的租戶有不同的dnsmasq和router實例，因此不同租戶間可以實現IP地址的復用。
3)Router namesapce通過qr接口（Quantum Router）接收到租戶內跨網段流量以及公網流量，在ns的IP內核中對跨網段流量進行路由，改寫MAC地址並通過相應的qr接口向ovs br-int送出數據包。在ns的IP內核中對公網流量進行NAT，並通過qg接口（Quantum Gateway）發送給ovs br-ex。
4)Ovs br-ex通過關物理聯宿主機的硬件網卡eth1將流量送至Internet路由器。
5)上述兩幅圖中，ovs br-int與ovs br-ex間有直連，據說主要是防止l3-agent出現問題時能夠保證流量不中斷，但實際上看來很少出現此問題。
5. Neutron網絡全家福
上圖是在網上看過的更加細致，更為全面的一張圖（http://blog.csdn.net/canxinghen/article/details/46761591#comments），圖中清晰地展示了Neutron對多種L2技術（VLAN、VxLAN、GRE）共同運行的支持。圖中的mellonax是intel等硬件廠商搞出的具備轉發功能的網卡，能夠避免虛擬交換機帶來的資源消耗，並能夠加快轉發速率。一塊這樣的網卡能虛擬出63個VF，每個VF就好像一個獨立的物理網卡一樣，通過將VF直接掛到虛擬機上，能夠實現轉發性能的大幅度提高。
以上介紹了OpenStack中網絡組件的演進，以及Neutron組網的基本原理。下面我們將對Neutron的軟件實現進行簡單的介紹。
二、Nova虛擬機啟動時的網絡處理
設備啟動了，網絡有了，可是現在還沒有虛擬機。下面我們來看看nova虛擬機啟動時的網絡處理過程。
從頭開始講。虛擬機的啟動通常來自於控制節點命令行的nova boot，該命令被組裝成REST API送到nova-api。Nova-api與neutron-server干的是一樣的活：接收REST請求，調nova-scheduler跑一些調度機制，計算出虛擬機部署的位置，然后通過rpc與相應計算節點上的agent——nova-compute進行通信，而啟動虛擬機的實際工作由nova-compute完成。
當然，以上過程與網絡並沒有發生什么關系，這里不做深入分析，大家要是有興趣可參考http://www.linuxqq.net/archives/1277.html。
假定nova-compute已經通過rpc收到了開始干活的命令，我們就從這里開始漫長的代碼分析。在此之前，先來看一看OpenStack組件層面的調用流程。這里借用OpenStack大神SammyLiu的一張圖吧，圖中1-6步驟依次做了這么幾件事：
- Nova-compute向neutron-server請求虛擬機對應的Port資源。
- Neutron-server根據neutron-database生成Port資源。
- Neutron-server通知Dhcp agent虛擬機信息。
- Dhcp agent將虛擬機信息通知給dhcp server。
- 虛擬機接入並啟動。
- 虛擬機從dhcp server處獲得IP地址。
最后一步就是傳統的dhcp的交互過程，這里就不講了，下面來看1-5的實現。時間有限，代碼不再一步步回溯了，詳見SDNLAB“網絡虛擬化”專題的后續文章，這里給出代碼的主體思路。
- Nova-compute向neutron-server發送create_port的REST API請求，生成新的Port資源。
- Neutron-server收到該REST請求，通過APIRouter路由到ML2的create_port方法。該方法中，獲得了neutron-database新生成的Port，並通知ML2 Mechanism Driver該Port的生成。
- Nova-compute向neutron發送update_port的REST API請求，
- Neutron-server收到該REST請求，通過APIRouter路由到ML2的update_port方法。該方法中，在neutron-database更新該Port的狀態，並根據ML2 Mechanism Driver的不同，決定后續的處理：若Mechanism Driver為hyperv/linuxbridge/ofagent/openvswitch，則需要通過ML2的update_port方法中執行rpc遠程調用update_port；對於其余的Mechanism Driver，ML2的update_port方法調用其的update_port_postcommit方法進行處理，這些Mechanism Driver可能使用非rpc方式與自身的agent通信（如REST API、Netconf等）。
- ML2執行完update_port方法后，Port資源在wsgi中對應的Controller實例通過DhcpAgentNotifyAPI實例rpc通知給網絡節點上的dhcp agent（也可能通過一些調度機制通知給分布在計算節點上的dhcp agent）。
- Dhcp agent收到該rpc通知，通過call_driver方法將虛擬機MAC與IP的綁定關系傳遞給本地的DHCP守護進程Dnsmaq。
- Nova-compute通過libvirt driver的spawn方法將虛擬機接入網絡，然后啟動虛擬機。
到這里，虛擬機啟動過程中的網絡處理就都結束了，虛擬機間就可以開始通信了。下面開始介紹Neutron中OVS的流表邏輯，看看OVS是怎么支持虛擬機間的通信的。