探索 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節點也須要擴展。