深入淺出新一代雲網路——VPC中的那些功能與基於OpenStack Neutron的實現（三）-路由與隧道

在系列的上一篇，

深入淺出新一代雲網路--VPC中的那些功能與基於OpenStack Neutron的實現（二） - 知乎專欄 ，主要講了在多租戶場景下一個重要的網路功能——帶寬QOS的原理與實現。

先同樣給出一份 aio風格的 REST API 示例代碼，同樣可以在不修改Neutron代碼的情況下獨立使用。

opencloudshare/Op_vmqos

邏輯原理在上一篇中介紹的比較詳細，主要就是通過 OpenStack API 找到雲主機的虛擬NIC設備所在的宿主機，通過paramiko到宿主機上執行寫入TC規則。

使用的話可以靈活的修改 region、domain等參數，代碼里使用的默認的。

找到虛擬NIC設備也不一定通過VM id的方式，可以根據需要修改。比如，在之前的一個項目中，涉及到了 「根據當前網路流量自動擴容帶寬」 功能，簡單來說是 「當前雲資產帶寬使用率達到X時，自動通過控制器對雲資產所享有的帶寬進行擴容」。當時的環境沒有Ceilometer ，使用的方案是 在宿主機上裝了 Zabbix agent，對所有網卡實現自動發現，然後監控並在觸發閾值後，傳值調用 QOS的REST API，當時傳的值，就是具體的 NIC設備名，而不是 VM id。

實現三層共享帶寬與控制原理是相同的，只是提取L3 namespace里的NIC設備名時，為 router-port 相關方法。

進入今天的正題——路由、隧道與案例，在實際的雲計算場景中，混合雲佔了很大一部分，一般我們對混合雲的概念定義，是指既有私有雲的內容，又結合了在公有雲上的部分，共同建設、組成的雲環境。

經典案例，是在各大峰會上被經常拿來說的 新浪微博混合雲架構實踐。既包含了業務層面 網路、存儲、Docker 等領域的挑戰，也存在 控制層面的 運維管理、彈性調度等的考量。n

上面說的「私有雲內容」，其實可以擴充為 「任何私有IT環境」 。各位雲計算工程師們一定遇到過很多 在「雲」 的概念提出以前的IT建設項目 與 新的雲計算環境打通接入 的需求。就好像私有雲項目中客戶經常會要求能和以前的IT設施互訪，而不是簡單的部署一個割裂的環境或遷移。直接使用VLAN技術將租戶網路接入外部網路可能並不是一個通用性的選擇，因為與VXLAN二層+VPC網路相比，前者有更多的侵入性、需要更複雜的網關層面的路由控制等。NAT技術則是將網路連接的層次提高了一層，用戶有明確的感知，在雲資產數量較多及全埠的需求下，對NAT規則的控制與上層網路可使用的IP數量成了瓶頸。因而隧道技術成了更好的選擇。

接下來我將以幾個參與的case為例，講講在面對複雜的互聯互通需求時，可以考慮的方案，與利用 OpenStack Neutron 完成的功能。

• case 1

客戶已有一套傳統IT環境，現要求與新部署的OpenStack環境某一VPC內雲資產進行互訪。n

OpenStack 的 neutron-vpn-agent 可以提供 IPsec VPN服務，在路由間建立隧道。

在企業內網環境，還可以使用配置更方便的 GRE隧道和IPIP隧道。

當然，具體使用何種協議，更多的是看路由設施對協議的支持程度，l3-agent 在 namespace建立的軟路由因為基於linux kernel ，在沒有極高性能要求的場景下可以支撐種類繁多的協議。而當對端是物理設備時，則得確定是否支持。

IPsec VPN就不做示例了，官方文檔即可查看。

軟實現GRE隧道打通的簡單示例：

# 載入模塊nmodprobe ip_gren# 建立隧道，隧道名，隧道類型，遠端地址，本地地址nip tunnel add mytunnel mode gre remmote 10.200.11.22 local 10.100.1.11n# 設置隧道介面地址，任一不和待打通的網路衝突的即可nifconfig mytunnel 10.199.199.1 netmask 255.255.255.0n# 添加到對端網路的路由nip route add 192.168.3.0/24 dev mytunneln

在對端：

# 載入模塊nmodprobe ip_gren# 建立隧道，隧道名，隧道類型，遠端地址，本地地址nip tunnel add mytunnel mode gre remmote 10.100.1.11 local 10.200.11.22n# 設置隧道介面地址，任一不和待打通的網路衝突的即可nifconfig mytunnel 10.199.199.2 netmask 255.255.255.0n# 添加到對端網路的路由nip route add 192.168.1.0/24 dev mytunneln

之後，便可測試OpenStack VPC內的這個網路到右側已有網路的打通互訪效果。

• case 2

客戶已有一套傳統IT環境，現要求與新部署的OpenStack環境內 多個 VPC內雲資產進行互訪。n

這個case是上一個的加強版。如果是在OpenStack環境內的網路打通，同一project下，我們會將多個網路連接同一路由，如果介面不是默認網關，添加對應的路由表。

在這個案例中，傳統IT環境與OpenStack環境的外部網路其實是通過物理專線相連接的，而OpenStack內多個VPC的使用者是企業的不同項目組。簡而言之，這多個項目組，要求共用同一條物理專線，但都能訪問到各自的VPC內。

在各VPC原有路由不變(默認網關為 x.x.x.1)的情況下，建立一個專用路由，將各VPC內各網路接入該專用路由(專線網關為 x.x.x.99)，用該路由通過物理專線與傳統環境形成打通。

軟實現IPIP隧道打通的簡單示例：

# 載入模塊nmodprobe ipipn# 建立隧道，隧道名，隧道類型，遠端地址，本地地址nip tunnel add mytunnel mode ipip remmote 10.200.11.22 local 10.100.1.11n# 設置隧道介面地址，任一不和待打通的網路衝突的即可nifconfig mytunnel 10.199.199.1 netmask 255.255.255.0n# 添加到對端網路的路由nip route add 192.168.3.0/24 dev mytunneln

在對端：

# 載入模塊nmodprobe ipipn# 建立隧道，隧道名，隧道類型，遠端地址，本地地址nip tunnel add mytunnel mode ipip remmote 10.100.1.11 local 10.200.11.22n# 設置隧道介面地址，任一不和待打通的網路衝突的即可nifconfig mytunnel 10.199.199.2 netmask 255.255.255.0n# 添加到對端網路的路由nip route add 192.168.1.0/24 dev mytunnelnip route add 192.168.2.0/24 dev mytunnelnip route add 192.168.0.0/24 dev mytunneln

還沒有完，因為對VPC內的雲資產來說，默認網關是 x.x.x.1 ，意味著在不改動雲資產內路由表的情況下，發往 192.168.3.0/24 的數據包都將發往 x.x.x.1 。所以我們需要對三個VPC的路由設施添加路由表，將數據包轉發至 x.x.x.99 。

vpc1_routes: {"destination": "192.168.3.0/24", "nexthop": "192.168.1.99"}nvpc2_routes: {"destination": "192.168.3.0/24", "nexthop": "192.168.2.99"}nvpc3_routes: {"destination": "192.168.3.0/24", "nexthop": "192.168.0.99"}n

由傳統環境到雲上多個VPC的互訪功能即可實現，且 VPC 與VPC 間仍是不能互訪的。

在這個 case 中，我更推薦將用於專線的路由不使用默認的L3-agent —— neutron api 中的router 去創建，而是以雲主機的形式建立，理由如下：

1. 原router所有的內部介面現在是雲主機的各NIC，可以通過對雲主機的控制來改變配置，避免了直接操作L3節點可能的風險；
2. 可以在雲主機而非L3節點內裝 滿足複雜網路監控需求的軟體/Agent；
3. 通過調整CPU來調整轉發能力；
4. 通過控制port 來控制各VPC對專線帶寬的佔用情況與應急斷連的保護；
5. 雲主機可以主備，在自動切換、恢復與遷移方面更方便。

在OpenStack環境建立用於轉發功能的雲主機，除了將 雲主機操作系統內核參數的 ip_forward打開外，還需通過Neutron 對該雲主機的port 進行 port_security_enabled = False 的操作。這一點在部署雲主機版的NAT網關時同樣適用。

case 3

客戶要求將一台高性能物理機接入雲上VPC內，方便資源的互訪。n

走南北方向的其它區域，是最簡單的方案。

但難點在於，客戶並不想暴露OpenStack環境所在區域南北方向上的其它IP地址。換而言之，想讓VPC內租戶通過VPC內網路的地址訪問到物理機。NAT是個不錯的選擇，基於前兩個case的路由隧道方案也可以不必暴露基礎環境中南北方向的IP規劃。

但我們也可以利用 OVS 的特性，將以有這個需求的VPC內網路用 VLAN 組網，實現基於物理 VLAN 交換機的跨物理伺服器二層虛擬網路 ；或是 仍用 VXLAN 組網，但使用支持 VXLAN 的物理交換機來擴展原本架構。

我們知道， VTEP 和 VXLAN GW 是VXLAN組網在東西向擴展的核心組件，混合Overlay 方案通過結合軟硬實現VTEP等組件的功能， 同時對虛擬化環境與物理機提供了很好的支持。

不過這當然需要物理硬體的支撐。如果在宿主機上安裝openvswitch 等軟實現，不可避免的會在物理機shell暴露東西向VXLAN GW，肯定是在考慮之外的。

關於Neutron VXLAN的內容可以參考雲極星創（現海航雲）CTO 劉大神寫得非常詳細的系列：

Neutron 理解 (1): Neutron 所實現的虛擬化網路 [How Netruon Virtualizes Network]

在有其它SDN控制器的場景下，通過Neutron 載入不同 driver 實現對控制器的調度，也能達到效果。

之前在和 VMware NSX做技術交流的時候，NSX在對同樣需求時給出的參考建議也是通過NSX直接控制 用於物理機接入的交換機。

在公有雲上，雲資產向VPC的引入更常見的方法是通過私有DNS解析與NAT技術相結合的方式，這方面就不展開多談了，結合前面的文章可以思考他們的大致實現。

企業內網與專線環境下，對互聯互通功能實現的選擇可以使用payload更小，性能更好的隧道技術。但在公網環境下，基於IPSec與SSL的隧道技術從傳輸安全的角度上是必須考慮的。

系列上一篇 ： 深入淺出新一代雲網路--VPC中的那些功能與基於OpenStack Neutron的實現（二） - 知乎專欄

微信：

這兒分享雲計算相關的原創技術實踐和項目經驗，還有各種在雲、雲安全方面搞出的大新聞、趣事兒。

推薦閱讀：