前言

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

從 Nova-network 說(shuō)起

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

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

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

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

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

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

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

但是 Nova-network 的缺點(diǎn)也是很明顯的：

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

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

#p#

Neutron 的艱難前行

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

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

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

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

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

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

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

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

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

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

1. 因?yàn)橄⑹菑V播的，很耗費(fèi)資源;
2. 跨網(wǎng)絡(luò)的通訊還要依賴于路由器;
3. 它目前沒(méi)辦法和 L3 HA 共同工作!

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

#p#

新的架構(gòu)

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

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

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

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

對(duì)很多用戶來(lái)說(shuō)，南北流量不是他們最關(guān)心的問(wèn)題，他們最關(guān)心的是東西流量：

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

OK，我們解決了問(wèn)題，但也引入了新的問(wèn)題：

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

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

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

比較有特點(diǎn)去談的就是這個(gè)流表了：

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

#p#

第三方的發(fā)展

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

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

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

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

Midonet 有幾個(gè)組件，分別是

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

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

總結(jié)

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

注1: NSX 價(jià)格還需要額外購(gòu)買(mǎi) SNS 支持服務(wù)，數(shù)據(jù)來(lái)自http://technodrone.blogspot.com/2015/02/vmware-integrated-openstack-cost.html

注2:“ ✔*”表示支持有限，非全部支持，或數(shù)據(jù)可能不明確。

關(guān)于作者

[[142233]]

王為，UnitedStack有云SDN 工程師，專注于虛擬網(wǎng)絡(luò)和 SDN 方向，OpenStack 等多個(gè)開(kāi)源社區(qū)的活躍貢獻(xiàn)者。