探索 OpenStack 之（8）：Neutron 深入探索之 OVS + GRE 之 完整網絡流程 篇

前兩篇博文分別研究了Compute節點和Neutron節點內部的網絡架構。本文通過一些典型流程案例來分析具體網絡流程過程。

0. 環境

同 學習OpenStack之（7）：Neutron 深入學習之 OVS + GRE 之 Neutron節點篇 中所使用的環境。

簡單總結一下：

Compute 節點上由Neutron-OVS-Agent負責：

• br-int：每個虛機都通過一個Linux brige連到該OVS橋上
• br-tun：轉化網絡packet中的VLAN ID 和 Tunnel ID
• GRE tunnel：虛擬GRE通道

Neutron節點上：

• br-tun/br-int：同Compute節點，由Neutron-OVS-Agent負責
• br-ex：連接物理網卡，用於和外網通信
• Network namespace：用於tenant 網絡DHCP服務的qDHCP由Neutron-DHCP-Agent負責，和用於網絡間routing的qRouter由Neutron-L3-Agent負責

2. 幾個典型流程案例

2.1 流程1： 同一個host上同一個子網內虛機之間的通信過程

因為br-int是個虛擬的二層交換機，所以同一個host上的同一個子網內的虛機之間的通信只是經過 br-int 橋，不需要經過 br-tun 橋。如下圖中紅線所示：

 

2.2 流程2： 不同主機上同一個子網內的虛機之間的通信過程

過程：

1. 從左邊的虛機1出發的packet，經過Linux bridge到達br-int，被打上 VLAN ID Tag

2. 到達br-tun，將VLAN ID轉化為Tunnel ID，從GRE Tunnel 發出，到達另一個compute節點

3. 在另一個compute節點上經過相反的過程，到達右邊的虛機

注：本配置待不久之后的實驗驗證。

2.3 流程3： 虛機訪問外網

1. Packet離開虛機，經過Linux bridge， 到達br-int，打上 VLAN ID Tag

2. 達到 br-tun，將 VLAN ID轉化為 Tunnel ID

3. 從物理網卡進入GRE通道

4. 從GRE通道達到 Neutron 節點的網卡

5. 達到跟物理網卡相連的br-tun，將 Tunnel ID 轉化為 VLAN ID

6. 達到 br-int，再達到 router，router的NAT 表 將 fixed IP 地址 轉化為 floatiing IP 地址，再被route 到br-ex

7. 從br-ex相連的物理網卡上出去到外網

外網IP訪問虛機是個相反的過程。

2.4 流程4：虛機發送DHCP請求

過程：

1. 虛機的packet -> br-int -> br-tun -> GRE Tunnel -> eth2 ------>eth2->br-tun->br-int->qDHCP

2. qDHCP返回其fixed IP地址，原路返回

例如：在虛機（IP為10.0.22.202）啟動過程中，DHCP Server （10.0.22.201）所收到的請求及其回復：

root@network:/home/s1# ip netns exec qdhcp-d24963da-5221-481e-adf5-fe033d6e0b4e tcpdump

listening on tap15865c29-9b, link-type EN10MB (Ethernet), capture size 65535 bytes //dnsmasq在此TAP設備上監聽

07:16:56.686349 IP (tos 0x0, ttl 64, id 41569, offset 0, flags [DF], proto UDP (17), length 287)

    10.0.22.202.bootpc > 10.0.22.201.bootps: [udp sum ok] BOOTP/DHCP, Request from fa:16:3e:19:65:62 (oui Unknown), length 259, xid 0xab1b9011, secs 118, Flags [none] (0x0000)

  Client-IP 10.0.22.202 //虛機eth0的IP地址

  Client-Ethernet-Address fa:16:3e:19:65:62 (oui Unknown)

  Vendor-rfc1048 Extensions

    Magic Cookie 0x63825363

    DHCP-Message Option 53, length 1: Release

    Client-ID Option 61, length 7: ether fa:16:3e:19:65:62 //虛機eth0的Mac地址

    Server-ID Option 54, length 4: 10.0.22.201 //DHCP Server IP地址

 2.5 不同tenant內虛機之間的通信

Neutron Tenant網絡是為tenant中的虛機之間的通信。如果需要不同tenant內的虛機之間通信，需要在兩個subnet之間增加Neutron路由。

3. 關於GRE/OVS/Neutron的一些快速結論

1. GRE 可以隔離廣播風暴，不需要交換機配置chunk口， 解決了vlan id個數限制，3層隧道技術可以實現跨機房部署，但它是點對點技術，每兩個點之間都需要有一個隧道，對於4層的端口資源是一種浪費；同時，在IP頭中 增加Tunnel ID，勢必減少vm的mtu值，同樣大小的數據，需要更多的ip包來傳，傳輸效率有影響。

2. OVS ：可以針對每個vm做流量限制、流量監控、數據包分析，同時可以引入OpenFlow，使控制邏輯和物理交換相分離，並且sdn controller可以實現vxlan的跨機房大二層通信，但是可能性能是個潛在問題。

3. Neutron的優點：

       （1）提供REST API

       （2）Neutron 把部分傳統網絡管理的功能推到了租戶方，租戶通過它可以創建一個自己專屬的虛擬網絡及其子網，創建路由器等，在虛擬網絡功能的幫助下，基礎物理網絡就可以向外提供額外的網絡服務了，比如租戶完全可以創建一個屬於自己的類似於數據中心網絡的虛擬網絡。Neutron 提供了比較完善的多租戶環境下的虛擬網絡模型以及 API。像部署物理網絡一樣，使用 Neutron 創建虛擬網絡時也需要做一些基本的規划和設計。

4. Neutron的可能問題：

    （1）單點故障：Neutron節點做為network的中心控制節點，很容易導致單點故障。生產環境中HA應該是必須有的。

    （2）性能降低：network traffic經過太多的層次，latency增加。

     （3）可擴展性不夠：當Compute 節點快速增加的時候，Neutron節點也需要擴展。