【干貨】：通向企業級的 OpenStack 網絡服務
前言
當我們提到 OpenStack 的網絡，很多人會望而生畏，說 OpenStack 網絡好復雜、Neutron 難以維護、Overlay 網絡性能低下…… 這樣的印象阻礙了 OpenStack 特別是 Neutron 在企業的部署腳步，事實上從 OpenStack 誕生起，其網絡的模型和設計就一直在進化并且保持著高效、快速的迭代，特別是從 Neutron 誕生，Legacy 網絡、Provider 網絡、L3 HA、L2 Population、DVR、DragonFlow 相繼提出，我們看到 Neutron 在其每一個 Cycle 都在向企業級的生產軟件靠近，本文將嘗試對 OpeStack 的網絡發展做一個綜合性的總結和比較。
從 Nova-network 說起
我們知道最初 OpenStack 只有 Nova 和 Swift 兩個組件，所以 Nova 除了提供基礎的計算服務，包括調度、塊設備和網絡也一并由 Nova 提供，當時的網絡是什么樣呢?為什么現在還有很多 Superuser 還在使用 Nova-network?
最開始，大家期望中的 OpenStack 網絡是什么樣的?
- 能給虛擬機提供 IP 地址;
- 虛擬機在需要時可以連通外網;
- 相同網絡下的虛擬機之間允許內部通信;
- 一些虛擬機還希望能獲得一個外網 IP 來對外提供服務。
最后特別對于公有云，租戶間還需要保證網絡隔離。
基于以上需求，Nova-network 提供了這樣的參考模型(VlanManager+MultiHost)：
首 先，dnsmasq 進程綁定在租戶的網橋上，用于提供 DHCP 服務，提供 IP 地址;然后，計算節點上配置默認路由并將一個網口連接至公網，這樣虛擬機按默認路由發送的報文將被網橋以節點的默認路由送出，發往公網的接入層;同一租戶 的網絡處于同于 Vlan，通過網橋廣播允許其互相通信;不同租戶的虛擬機如果則通過節點上的路由表路由到對應網橋并轉發(見上圖);如果虛擬機需要公網 IP，則可以在計算節點上直接起 NAT 規則對應到相應內網 IP。
整個模型很簡單明了，全部使用 Linux 中較為成熟的網絡技術， 所有路由選擇由本地決定，不依賴某個單點，這個在 Nova-network 中被稱為 MultiHost，是Nova-network 的重要特性，所以其一出世就獲得了很多人的青睞。
但是 Nova-network 的缺點也是很明顯的：
- 因為 Vlan 技術固有缺陷，一個 Region 下無法服務太多租戶;
- 路由實現粗糙，路由決策和 NAT 依賴 IP 地址，所以很難實現Overlap IP，用戶的 IP 管理不自由;
- 前面說不同租戶(其實是不同網絡)之間似乎可以在沒有公網IP的情況下互香通訊，但這是有條件的，再看前面的圖，我們看到如果想在計算節點下做路由決策，讓 數據包成功封裝另一個租戶的 Vlan，我們需要這個計算節點擁有另一個租戶的網橋，而且因為這個鏈路的非對稱性，對方節點也需要相同的要求。因為 Nova-network 的網橋是按需建立的(不然太多)，所以其實這種通信是無法保障的。
最后，Nova-network 提供的網絡高級功能很有限，只有基本的安全組，很難滿足用戶需求，而且將網絡緊耦合在計算服務中也不符合云計算的架構，所以社區最終成立了 Neutron 項目。
#p#
Neutron 的艱難前行
Neutron 的誕生承載著大家對面向大型云基礎設施的網絡服務的期望，它在一開始就著手設計了基于 Overlay 網絡的網絡模型，通過先進的 VxLan 和 NVGRE 協議， Neutron 克服了很多在 Nova-network 中無法解決的網絡問題。Overlay 網絡是什么的，簡單的說，它是一個邏輯網，運行在物理網之上，一般要求物理網 IP 可達，然后通過 UDP 等三層傳輸協議承載二層，形成 L2 over L3 的模型，這樣我們就可以實現突破物理拓撲的任意自定義網絡拓撲、Overlap IP 等。
首先針 對 Nova-network 面臨的幾個問題，VxLan、NVGRE 等都支持上千萬的租戶數量，遠遠滿足一般需求;其次通過 L2 over L3，用戶完全實現了自定網絡拓撲，沒有 IP 地址的限制;不同網絡間擁有不用的 VxLan tag，當需要在不同網絡下互相通信時，可以通過路由器路由轉換 VxLan tag，不再有種種限制。
針對 Nova-network 的高級功能匱乏的問題，借助靈活的網絡模型和虛擬路由器的實現，Neutron 擁有自定義路由、VPNaaS、FWaaS 和 LBaaS 等多種高級功能。此外，由于 Neutron 定義良好的北向接口和 Plugin-extension 架構，它可以支持大量廠商的設備，用戶擁有徹底的自主選擇權，廠商擁有高度的自主開發空間。
既然我們說的這么好，為什么很多人對其都不滿意呢?原因也很多：
- Neutron 使用了 Namespace、Open vSwitch、網橋、veth、iptables 等技術，其中有些內容，特別是 OVS 對很多人都是比較陌生的，而且在一開始，其穩定性也受人質疑，這讓人們有了充分的質疑理由;
- 南北向通訊和跨網絡通訊都依賴于網絡節點，而這個節點在默認的模型下是單點。
- Overlay 網絡的默認性能并不能讓人滿意，需要專業工程師或廠商設計方案和調優。
軟件的復雜度隨著軟件功能的豐富和接口的復雜性的上升幾乎是必然的，Open vSwitch 的穩定性和性能也一直在提升，所以社區決定要發動力量主要解決第二個問題。
首先是 HA，企業 IT 系統首先關心的，莫過于系統的穩定性，一個可靠的 HA 方案是社區首先考慮的。很多網絡服務的高可用都是借助 VRRP 協議的，Neutron 也不例外，通過 Keepalived + conntrackd，實現 Master 和 Slave 共同維護 VIP，一旦 Master 掛掉了，VIP 將自動飄到 Slave 節點上，因為 conntrackd 始終在自動拷貝session 信息，所以理論上可以實現用戶的無感知自動切換。
L3 HA 確實實現了高可用，但是東西流量還是沒有優化啊，這里面一大原因是 VxLan本來支持組播的，但是 OVS 目前支持有限，我們總是不得把一些無效的 ARP 廣播發送出去。比如說下圖中，A 的廣播包其實只對 3 和 4 有用，但是 2 和 5 也收到了：
如何優化，這里的問題是虛擬機不知道通信對方的位置，可是 Neutron 知道啊，Neutron 數據庫中保存著每一個 Port 聯接的虛擬機信息、其 IP、MAC 地址、其宿主機信息等等，所以如果有新的虛擬機建立起來，連接了網絡，那么 Neutron 就往所有 Agent 發送消息，告訴他們新的 Port 的所有信息，大家就低頭檢查看看自己是不是也有這個網絡的虛擬機，如果有就更新流表規則，將來要請求這個 IP 的 ARP 可以直接回應，如果沒有就忽略。這就是 L2 Population 和 ARP responder。
OK，更加優化了一步，但是他也有問題啊，就是
- 因為消息是廣播的，很耗費資源;
- 跨網絡的通訊還要依賴于路由器;
- 它目前沒辦法和 L3 HA 共同工作!
為什么它無法和 L3 HA 共同工作呢，因為 L2 Pop 假定了每個 Port 都工作在一個固定的節點上，這樣 L2 Pop 才能將 ARP 和 Tunnel 引過去，然而 L3 HA 破壞了這個假設…… Bug 的 report 見 Launchpad 上的 #1365476 ，目前尚未解決……
#p#
新的架構
這么說來，Neutron 在企業化道路上真實困難重重啊，怎么辦，社區決定不能在舊的架構上修修補補了，讓我們真正實現一個分布式虛擬路由(Distributed Virtual Routing 簡稱 DVR)吧!
由 于過去的集中化的虛擬路由 L3 Agent 實現的很完整了，社區決定方案就是將其從單獨部署在網絡節點轉為分布式的部署在所有計算節點上，每個計算節點都有自己的 Router Namespace，就像之前 Nova-network 在各個節點上都有自己的 Gateway 一樣。
首先我們看虛擬機綁定公網 IP 情況下的公網流量：
當 一個外部的報文需要和虛擬機通信時，首先會發到網橋 br-ex，然后 FIP Namespace 的 fg 設備響應其 ARP，再被路由到 fpr 上，進入 DVR Namespace，這里再通過 iptables 將公網 IP DNAT 為內網地址，發往虛擬機。內部網外部通信也是類似的道理。
對很多用戶來說，南北流量不是他們最關心的問題，他們最關心的是東西流量：
因為現在路由器就在計算節點上，所以我們只需要在 Namespace 內完成路由就行了，這和以前在網絡節點上是一樣的。但是會出現多個計算節點上會存在同一子網的網關，怎么辦?解決方案是為每一個計算節點生成唯一的DVR MAC 地址，在對外發出數據包之前，將原有 MAC 替換成 DVR MAC，保證雙向通信的正常進行。
OK，我們解決了問題，但也引入了新的問題：
- 因為現在 ARP 應答無法跨計算節點，像 Allowed address pair 這樣的擴展也無法工作了(回應非 Port 自己本身綁定的 IP 的 ARP 請求)。
- IO 路徑比較復雜，且充斥著大量虛假 ARP 應答，增加了運維難度。
針對 DVR 的這些問題，社區另一撥人提出一種新的架構，他們稱之為 SDN way。那就是我們看到所有流表都是 Neutron 主動下發的，而不是像 OpenFlow 那樣首包上送，我們能不能實現一個基于首包上送的反應式控制器呢?
于是 DragonFlow 被提了出來，其特點是未知流量首包上送到控制器，控制器知道一切，下發流表規則，這樣東西向通信的其余流量就都可以都直接走到對方計算節點了。
比較有特點去談的就是這個流表了：
但是這樣控制器的性能會成為瓶頸嗎?DragonFlow 團隊聲稱的性能提高真的可靠嗎?恐怕無論 DVR 還是 DragonFlow 都還是需要真正生產環境的考驗。
#p#
第三方的發展
前面說到因為 Neutron 的 Plugin-extension 架構，給了廠商良好的自定義空間，所以 Neutron 的第三方解決方案也是層出不窮，這里簡單談談 NSX 與 Midonet。
NSX 改造自原 Nicira 的 NVP，據 VMware 宣稱其應用在了多家云計算系統中，但我們外界所知資料并不是很豐富，下面的圖介紹了 NSX 對東西流量的處理，可見與 DVR 有相似之處：
其優點是擁有良好的商業公司支持，缺點是價格高昂、無法自主可控。
再說一個新秀 Midonet，是 Midokura 公司提出的網絡解決方案，與今年年中宣布開源，實現了很多企業級的特性，比如 BGP 的支持、Tunnel Zone、DoS抵御隔離的支持等等，但是對我們來說最吸引人的，是其基于 Java 重新設計的全新的軟件架構。
Midonet 有幾個組件，分別是
- Cluster：保存集群狀態，同步信息，檢查外部設備等，依賴于 Zookeeper 和 Cassandra;
- midonet-util：一些其它模塊用到的工具類;
- midolman：類似于 Neutron 中的 Agent，
- midonet-api：實現 API;
- netlink：與內核通信用模塊，基于 Linux netlink;
- odp：于內核的 Open Datapath 通信用模塊。
Midonet 充分借助了已有成熟的分布式軟件降低自己本身的復雜性，而且只使用了 Open vSwitch 的 Datapath 模塊，使轉發和控制更加靈活，不失為一個好的設計。但是其企業級服務還需要定制，對社區的部分高級功能也支持有限，這也是它的缺點。
總結
最后我們以一個表格做總結：
注1: NSX 價格還需要額外購買 SNS 支持服務，數據來自http://technodrone.blogspot.com/2015/02/vmware-integrated-openstack-cost.html
注2:“ ✔*”表示支持有限，非全部支持，或數據可能不明確。
關于作者
王為，UnitedStack有云SDN 工程師，專注于虛擬網絡和 SDN 方向，OpenStack 等多個開源社區的活躍貢獻者。
