【干貨】：通向企業(yè)級的 OpenStack 網(wǎng)絡(luò)服務(wù)

作者：王為 2015-07-27 15:45:29

事實上，從 OpenStack 誕生起，其網(wǎng)絡(luò)的模型和設(shè)計就一直在進化并且保持著高效、快速的迭代，特別是從 Neutron 誕生，Legacy 網(wǎng)絡(luò)、Provider 網(wǎng)絡(luò)、L3 HA、L2 Population、DVR、DragonFlow 相繼提出，我們看到 Neutron 在其每一個 Cycle 都在向企業(yè)級的生產(chǎn)軟件靠近，本文將嘗試對 OpeStack 的網(wǎng)絡(luò)發(fā)展做一個綜合性的總結(jié)和比較。

前言

當(dāng)我們提到 OpenStack 的網(wǎng)絡(luò)，很多人會望而生畏，說 OpenStack 網(wǎng)絡(luò)好復(fù)雜、Neutron 難以維護、Overlay 網(wǎng)絡(luò)性能低下…… 這樣的印象阻礙了 OpenStack 特別是 Neutron 在企業(yè)的部署腳步，事實上從 OpenStack 誕生起，其網(wǎng)絡(luò)的模型和設(shè)計就一直在進化并且保持著高效、快速的迭代，特別是從 Neutron 誕生，Legacy 網(wǎng)絡(luò)、Provider 網(wǎng)絡(luò)、L3 HA、L2 Population、DVR、DragonFlow 相繼提出，我們看到 Neutron 在其每一個 Cycle 都在向企業(yè)級的生產(chǎn)軟件靠近，本文將嘗試對 OpeStack 的網(wǎng)絡(luò)發(fā)展做一個綜合性的總結(jié)和比較。

從 Nova-network 說起

我們知道最初 OpenStack 只有 Nova 和 Swift 兩個組件，所以 Nova 除了提供基礎(chǔ)的計算服務(wù)，包括調(diào)度、塊設(shè)備和網(wǎng)絡(luò)也一并由 Nova 提供，當(dāng)時的網(wǎng)絡(luò)是什么樣呢?為什么現(xiàn)在還有很多 Superuser 還在使用 Nova-network?

最開始，大家期望中的 OpenStack 網(wǎng)絡(luò)是什么樣的?

能給虛擬機提供 IP 地址;
虛擬機在需要時可以連通外網(wǎng);
相同網(wǎng)絡(luò)下的虛擬機之間允許內(nèi)部通信;
一些虛擬機還希望能獲得一個外網(wǎng) IP 來對外提供服務(wù)。

最后特別對于公有云，租戶間還需要保證網(wǎng)絡(luò)隔離。

基于以上需求，Nova-network 提供了這樣的參考模型(VlanManager+MultiHost)：

首先，dnsmasq 進程綁定在租戶的網(wǎng)橋上，用于提供 DHCP 服務(wù)，提供 IP 地址;然后，計算節(jié)點上配置默認(rèn)路由并將一個網(wǎng)口連接至公網(wǎng)，這樣虛擬機按默認(rèn)路由發(fā)送的報文將被網(wǎng)橋以節(jié)點的默認(rèn)路由送出，發(fā)往公網(wǎng)的接入層;同一租戶的網(wǎng)絡(luò)處于同于 Vlan，通過網(wǎng)橋廣播允許其互相通信;不同租戶的虛擬機如果則通過節(jié)點上的路由表路由到對應(yīng)網(wǎng)橋并轉(zhuǎn)發(fā)(見上圖);如果虛擬機需要公網(wǎng) IP，則可以在計算節(jié)點上直接起 NAT 規(guī)則對應(yīng)到相應(yīng)內(nèi)網(wǎng) IP。

整個模型很簡單明了，全部使用 Linux 中較為成熟的網(wǎng)絡(luò)技術(shù)，所有路由選擇由本地決定，不依賴某個單點，這個在 Nova-network 中被稱為 MultiHost，是Nova-network 的重要特性，所以其一出世就獲得了很多人的青睞。

但是 Nova-network 的缺點也是很明顯的：

因為 Vlan 技術(shù)固有缺陷，一個 Region 下無法服務(wù)太多租戶;
路由實現(xiàn)粗糙，路由決策和 NAT 依賴 IP 地址，所以很難實現(xiàn)Overlap IP，用戶的 IP 管理不自由;
前面說不同租戶(其實是不同網(wǎng)絡(luò))之間似乎可以在沒有公網(wǎng)IP的情況下互香通訊，但這是有條件的，再看前面的圖，我們看到如果想在計算節(jié)點下做路由決策，讓數(shù)據(jù)包成功封裝另一個租戶的 Vlan，我們需要這個計算節(jié)點擁有另一個租戶的網(wǎng)橋，而且因為這個鏈路的非對稱性，對方節(jié)點也需要相同的要求。因為 Nova-network 的網(wǎng)橋是按需建立的(不然太多)，所以其實這種通信是無法保障的。

最后，Nova-network 提供的網(wǎng)絡(luò)高級功能很有限，只有基本的安全組，很難滿足用戶需求，而且將網(wǎng)絡(luò)緊耦合在計算服務(wù)中也不符合云計算的架構(gòu)，所以社區(qū)最終成立了 Neutron 項目。

#p#

Neutron 的艱難前行

Neutron 的誕生承載著大家對面向大型云基礎(chǔ)設(shè)施的網(wǎng)絡(luò)服務(wù)的期望，它在一開始就著手設(shè)計了基于 Overlay 網(wǎng)絡(luò)的網(wǎng)絡(luò)模型，通過先進的 VxLan 和 NVGRE 協(xié)議， Neutron 克服了很多在 Nova-network 中無法解決的網(wǎng)絡(luò)問題。Overlay 網(wǎng)絡(luò)是什么的，簡單的說，它是一個邏輯網(wǎng)，運行在物理網(wǎng)之上，一般要求物理網(wǎng) IP 可達，然后通過 UDP 等三層傳輸協(xié)議承載二層，形成 L2 over L3 的模型，這樣我們就可以實現(xiàn)突破物理拓?fù)涞娜我庾远x網(wǎng)絡(luò)拓?fù)洹verlap IP 等。

首先針對 Nova-network 面臨的幾個問題，VxLan、NVGRE 等都支持上千萬的租戶數(shù)量，遠遠滿足一般需求;其次通過 L2 over L3，用戶完全實現(xiàn)了自定網(wǎng)絡(luò)拓?fù)洌瑳]有 IP 地址的限制;不同網(wǎng)絡(luò)間擁有不用的 VxLan tag，當(dāng)需要在不同網(wǎng)絡(luò)下互相通信時，可以通過路由器路由轉(zhuǎn)換 VxLan tag，不再有種種限制。

針對 Nova-network 的高級功能匱乏的問題，借助靈活的網(wǎng)絡(luò)模型和虛擬路由器的實現(xiàn)，Neutron 擁有自定義路由、VPNaaS、FWaaS 和 LBaaS 等多種高級功能。此外，由于 Neutron 定義良好的北向接口和 Plugin-extension 架構(gòu)，它可以支持大量廠商的設(shè)備，用戶擁有徹底的自主選擇權(quán)，廠商擁有高度的自主開發(fā)空間。

既然我們說的這么好，為什么很多人對其都不滿意呢?原因也很多：

Neutron 使用了 Namespace、Open vSwitch、網(wǎng)橋、veth、iptables 等技術(shù)，其中有些內(nèi)容，特別是 OVS 對很多人都是比較陌生的，而且在一開始，其穩(wěn)定性也受人質(zhì)疑，這讓人們有了充分的質(zhì)疑理由;
南北向通訊和跨網(wǎng)絡(luò)通訊都依賴于網(wǎng)絡(luò)節(jié)點，而這個節(jié)點在默認(rèn)的模型下是單點。
Overlay 網(wǎng)絡(luò)的默認(rèn)性能并不能讓人滿意，需要專業(yè)工程師或廠商設(shè)計方案和調(diào)優(yōu)。

軟件的復(fù)雜度隨著軟件功能的豐富和接口的復(fù)雜性的上升幾乎是必然的，Open vSwitch 的穩(wěn)定性和性能也一直在提升，所以社區(qū)決定要發(fā)動力量主要解決第二個問題。

首先是 HA，企業(yè) IT 系統(tǒng)首先關(guān)心的，莫過于系統(tǒng)的穩(wěn)定性，一個可靠的 HA 方案是社區(qū)首先考慮的。很多網(wǎng)絡(luò)服務(wù)的高可用都是借助 VRRP 協(xié)議的，Neutron 也不例外，通過 Keepalived + conntrackd，實現(xiàn) Master 和 Slave 共同維護 VIP，一旦 Master 掛掉了，VIP 將自動飄到 Slave 節(jié)點上，因為 conntrackd 始終在自動拷貝session 信息，所以理論上可以實現(xiàn)用戶的無感知自動切換。

L3 HA 確實實現(xiàn)了高可用，但是東西流量還是沒有優(yōu)化啊，這里面一大原因是 VxLan本來支持組播的，但是 OVS 目前支持有限，我們總是不得把一些無效的 ARP 廣播發(fā)送出去。比如說下圖中，A 的廣播包其實只對 3 和 4 有用，但是 2 和 5 也收到了：

如何優(yōu)化，這里的問題是虛擬機不知道通信對方的位置，可是 Neutron 知道啊，Neutron 數(shù)據(jù)庫中保存著每一個 Port 聯(lián)接的虛擬機信息、其 IP、MAC 地址、其宿主機信息等等，所以如果有新的虛擬機建立起來，連接了網(wǎng)絡(luò)，那么 Neutron 就往所有 Agent 發(fā)送消息，告訴他們新的 Port 的所有信息，大家就低頭檢查看看自己是不是也有這個網(wǎng)絡(luò)的虛擬機，如果有就更新流表規(guī)則，將來要請求這個 IP 的 ARP 可以直接回應(yīng)，如果沒有就忽略。這就是 L2 Population 和 ARP responder。

OK，更加優(yōu)化了一步，但是他也有問題啊，就是

因為消息是廣播的，很耗費資源;
跨網(wǎng)絡(luò)的通訊還要依賴于路由器;
它目前沒辦法和 L3 HA 共同工作!

為什么它無法和 L3 HA 共同工作呢，因為 L2 Pop 假定了每個 Port 都工作在一個固定的節(jié)點上，這樣 L2 Pop 才能將 ARP 和 Tunnel 引過去，然而 L3 HA 破壞了這個假設(shè)…… Bug 的 report 見 Launchpad 上的 #1365476 ，目前尚未解決……

#p#

新的架構(gòu)

這么說來，Neutron 在企業(yè)化道路上真實困難重重啊，怎么辦，社區(qū)決定不能在舊的架構(gòu)上修修補補了，讓我們真正實現(xiàn)一個分布式虛擬路由(Distributed Virtual Routing 簡稱 DVR)吧!

由于過去的集中化的虛擬路由 L3 Agent 實現(xiàn)的很完整了，社區(qū)決定方案就是將其從單獨部署在網(wǎng)絡(luò)節(jié)點轉(zhuǎn)為分布式的部署在所有計算節(jié)點上，每個計算節(jié)點都有自己的 Router Namespace，就像之前 Nova-network 在各個節(jié)點上都有自己的 Gateway 一樣。

首先我們看虛擬機綁定公網(wǎng) IP 情況下的公網(wǎng)流量：

當(dāng) 一個外部的報文需要和虛擬機通信時，首先會發(fā)到網(wǎng)橋 br-ex，然后 FIP Namespace 的 fg 設(shè)備響應(yīng)其 ARP，再被路由到 fpr 上，進入 DVR Namespace，這里再通過 iptables 將公網(wǎng) IP DNAT 為內(nèi)網(wǎng)地址，發(fā)往虛擬機。內(nèi)部網(wǎng)外部通信也是類似的道理。

對很多用戶來說，南北流量不是他們最關(guān)心的問題，他們最關(guān)心的是東西流量：

因為現(xiàn)在路由器就在計算節(jié)點上，所以我們只需要在 Namespace 內(nèi)完成路由就行了，這和以前在網(wǎng)絡(luò)節(jié)點上是一樣的。但是會出現(xiàn)多個計算節(jié)點上會存在同一子網(wǎng)的網(wǎng)關(guān)，怎么辦?解決方案是為每一個計算節(jié)點生成唯一的DVR MAC 地址，在對外發(fā)出數(shù)據(jù)包之前，將原有 MAC 替換成 DVR MAC，保證雙向通信的正常進行。

OK，我們解決了問題，但也引入了新的問題：

因為現(xiàn)在 ARP 應(yīng)答無法跨計算節(jié)點，像 Allowed address pair 這樣的擴展也無法工作了(回應(yīng)非 Port 自己本身綁定的 IP 的 ARP 請求)。
IO 路徑比較復(fù)雜，且充斥著大量虛假 ARP 應(yīng)答，增加了運維難度。

針對 DVR 的這些問題，社區(qū)另一撥人提出一種新的架構(gòu)，他們稱之為 SDN way。那就是我們看到所有流表都是 Neutron 主動下發(fā)的，而不是像 OpenFlow 那樣首包上送，我們能不能實現(xiàn)一個基于首包上送的反應(yīng)式控制器呢?

于是 DragonFlow 被提了出來，其特點是未知流量首包上送到控制器，控制器知道一切，下發(fā)流表規(guī)則，這樣?xùn)|西向通信的其余流量就都可以都直接走到對方計算節(jié)點了。

比較有特點去談的就是這個流表了：

但是這樣控制器的性能會成為瓶頸嗎?DragonFlow 團隊聲稱的性能提高真的可靠嗎?恐怕無論 DVR 還是 DragonFlow 都還是需要真正生產(chǎn)環(huán)境的考驗。

#p#

第三方的發(fā)展

前面說到因為 Neutron 的 Plugin-extension 架構(gòu)，給了廠商良好的自定義空間，所以 Neutron 的第三方解決方案也是層出不窮，這里簡單談?wù)?NSX 與 Midonet。

NSX 改造自原 Nicira 的 NVP，據(jù) VMware 宣稱其應(yīng)用在了多家云計算系統(tǒng)中，但我們外界所知資料并不是很豐富，下面的圖介紹了 NSX 對東西流量的處理，可見與 DVR 有相似之處：

其優(yōu)點是擁有良好的商業(yè)公司支持，缺點是價格高昂、無法自主可控。

再說一個新秀 Midonet，是 Midokura 公司提出的網(wǎng)絡(luò)解決方案，與今年年中宣布開源，實現(xiàn)了很多企業(yè)級的特性，比如 BGP 的支持、Tunnel Zone、DoS抵御隔離的支持等等，但是對我們來說最吸引人的，是其基于 Java 重新設(shè)計的全新的軟件架構(gòu)。

Midonet 有幾個組件，分別是

Cluster：保存集群狀態(tài)，同步信息，檢查外部設(shè)備等，依賴于 Zookeeper 和 Cassandra;
midonet-util：一些其它模塊用到的工具類;
midolman：類似于 Neutron 中的 Agent，
midonet-api：實現(xiàn) API;
netlink：與內(nèi)核通信用模塊，基于 Linux netlink;
odp：于內(nèi)核的 Open Datapath 通信用模塊。

Midonet 充分借助了已有成熟的分布式軟件降低自己本身的復(fù)雜性，而且只使用了 Open vSwitch 的 Datapath 模塊，使轉(zhuǎn)發(fā)和控制更加靈活，不失為一個好的設(shè)計。但是其企業(yè)級服務(wù)還需要定制，對社區(qū)的部分高級功能也支持有限，這也是它的缺點。

總結(jié)

最后我們以一個表格做總結(jié)：