全面解析Google Cloud的云網(wǎng)絡(luò)設(shè)計(jì)

最近看了 18 年 Google 在 NSDI 上一篇介紹 Google Compute Platform 中整體網(wǎng)絡(luò)設(shè)計(jì)的論文。這篇論文從 GCP 面臨的大規(guī)模且變化頻繁的網(wǎng)絡(luò)挑戰(zhàn)講起，介紹了控制平面和數(shù)據(jù)平面的設(shè)計(jì)和改造。最終做到控制平面可以支撐單個(gè)網(wǎng)絡(luò) 100000 VM，數(shù)據(jù)平面以純軟件的方式做到接近物理網(wǎng)絡(luò)的性能，吞吐量做到 30Gb/s，單核 pps 做到了300萬(wàn)。并做到了網(wǎng)絡(luò)在線(xiàn)遷移，數(shù)據(jù)平面可以每周在線(xiàn)升級(jí)的高速靈活迭代。

相比于 AWS 所有網(wǎng)絡(luò)功能下沉到專(zhuān)門(mén)的硬件卡，Azure 使用專(zhuān)門(mén)的 FPGA 做網(wǎng)絡(luò)加速，GCP 只使用了 Intel 芯片的一些通用 offload 能力（encryption，checksums，memory copies）。流表查詢(xún)，數(shù)據(jù)包轉(zhuǎn)發(fā)，ACL, LB，NAT 等功能都是純軟件實(shí)現(xiàn)的，基本可以認(rèn)為是當(dāng)前最大規(guī)模純軟件 SDN 實(shí)踐了，當(dāng)下容器大規(guī)模網(wǎng)絡(luò)設(shè)計(jì)也可以從中借鑒很多思路。

由于 GCP 在主機(jī)的數(shù)據(jù)平面使用的是 OVS，編程模型也用到了 OpenFlow（當(dāng)然都修改了不少），閱讀的時(shí)候免不了會(huì)和 OVN 做一下對(duì)比。下面會(huì)從 GCP 網(wǎng)絡(luò)的設(shè)計(jì)目標(biāo)，控制平面和數(shù)據(jù)平面分別進(jìn)行介紹。

設(shè)計(jì)目標(biāo)

該網(wǎng)絡(luò)方案在 Google 的項(xiàng)目名為 Andromeda，是仙女座星系的英文。仙女座星系是一個(gè)比銀河系還要大的星系，可見(jiàn)這個(gè)項(xiàng)目的野心。Andromeda 的主要設(shè)計(jì)目標(biāo)有下面幾個(gè)：

1、控制平面的可擴(kuò)展性和隔離性：

由于 GCP 是公有云，控制平面的穩(wěn)定性和可擴(kuò)展性是重中之重。包括支持單個(gè)網(wǎng)絡(luò) 100k VM，單個(gè)的網(wǎng)絡(luò)變更需要在極短時(shí)間內(nèi)同步到整個(gè)集群。目前 OVN 在這方面做得就不是很好，當(dāng) VM 超過(guò) 10k，變更的延遲就到了接近分鐘級(jí)別的水平。而 Andromeda 在 100k 規(guī)模的變更延遲是 186ms。

控制平面的隔離性指的是對(duì)多租戶(hù)的支持，避免單個(gè)租戶(hù)的異常行為對(duì)其他租戶(hù)的擾動(dòng)。例如在某些機(jī)器學(xué)習(xí)場(chǎng)景下單個(gè)網(wǎng)絡(luò)可能會(huì)瞬時(shí) provision 10k VM，其他租戶(hù)的網(wǎng)絡(luò)操作不能因?yàn)檫@個(gè)租戶(hù)的突發(fā)請(qǐng)求而受到影響。

2. 數(shù)據(jù)平面的高性能和隔離：

數(shù)據(jù)平面的高吞吐和低延遲，同時(shí)要考慮多租戶(hù)的場(chǎng)景避免一個(gè)租戶(hù)搶占其他租戶(hù)的網(wǎng)絡(luò)帶寬和其他資源。

3. 可高速迭代：

控制平面的可擴(kuò)展性，數(shù)據(jù)平面的高性能以及多租戶(hù)的隔離這幾方面的需求是比較顯而易見(jiàn)的。不過(guò)可高速迭代這個(gè)目標(biāo)卻是我讀論文之前沒(méi)想到的一個(gè)點(diǎn)。一般認(rèn)為網(wǎng)絡(luò)組建作為基礎(chǔ)設(shè)施迭代周期會(huì)比較長(zhǎng)，升級(jí)復(fù)雜度也會(huì)比較高。但是在 GCP 里數(shù)據(jù)平面可以做到每周進(jìn)行線(xiàn)上更新，這樣開(kāi)發(fā)者可以快速的迭代功能和性能優(yōu)化，充分發(fā)揮了 SDN 的優(yōu)勢(shì)。作者在 presentation 上也提到不采用更多硬件加速方案的主要原因就是硬件無(wú)法做到純軟件網(wǎng)絡(luò)的高速迭代。

下面將介紹控制平面和數(shù)據(jù)平面分別是如何設(shè)計(jì)來(lái)滿(mǎn)足這些目標(biāo)的。

控制平面

控制平面最重要的工作是把整個(gè)虛擬網(wǎng)絡(luò)的拓?fù)湟?guī)則下發(fā)給集群里的機(jī)器，可以理解為給每個(gè)機(jī)器一個(gè)地址簿，告知每一個(gè) VM 的對(duì)應(yīng)物理機(jī)是哪個(gè)，應(yīng)該通過(guò)哪條路徑找到對(duì)應(yīng)的 VM。傳統(tǒng)的控制平面數(shù)據(jù)下發(fā)有 Preprogrammed ， On Demand 和 Gateway 三種方式。

1、Preprogrammed Model：

這種模型在我的概念中對(duì)應(yīng)的是 full-mesh 模型。即每個(gè)宿主機(jī)節(jié)點(diǎn)都需要保存完整的集群網(wǎng)絡(luò)拓?fù)?，?gòu)建完整的轉(zhuǎn)發(fā)地址簿。OVN 目前采用的就是這種方式，集群中的每個(gè)節(jié)點(diǎn)之間都需要相互建立隧道，所有跨主機(jī) VM 的數(shù)據(jù)包都是直接通過(guò)對(duì)應(yīng)隧道發(fā)送到對(duì)端機(jī)器。這種方式的好處就是邏輯清晰明了，實(shí)現(xiàn)也相對(duì)簡(jiǎn)單。所有數(shù)據(jù)包都是分布式處理的，集群中的節(jié)點(diǎn)角色也很單純。由于數(shù)據(jù)包直接發(fā)送到目標(biāo)機(jī)器，沒(méi)有額外的中轉(zhuǎn)，理論上數(shù)據(jù)平面的性能也最好。缺點(diǎn)就是任何一個(gè)網(wǎng)絡(luò)變更都需要更新所有節(jié)點(diǎn)的流表， 更新的延遲會(huì)隨著規(guī)模變大而迅速上升。此外每臺(tái)機(jī)器都要維護(hù)全局的路由信息，額外的資源消耗也會(huì)隨著規(guī)模變大而增加。

2、On Demand Model:

這種模式下本機(jī)不保存全局信息，每個(gè)flow的第一個(gè)包要上傳到控制器，控制器返回對(duì)應(yīng)的路由信息。這種模式的擴(kuò)展性比第一種要好，但是首包的延遲時(shí)間會(huì)顯著上升。并且控制器成為了網(wǎng)絡(luò)的一個(gè)瓶頸，控制器的故障可能會(huì)導(dǎo)致整個(gè)網(wǎng)絡(luò)的中斷。此外惡意的租戶(hù)可能會(huì)利用這個(gè)機(jī)制生成大量的隨機(jī)訪(fǎng)問(wèn)，對(duì)控制器進(jìn)行 DDOS 攻擊來(lái)影響其他租戶(hù)的網(wǎng)絡(luò)質(zhì)量。

3、Gateway Model：

只是一種在 OpenStack 中比較常見(jiàn)的網(wǎng)絡(luò)模式，即使用專(zhuān)門(mén)的網(wǎng)絡(luò)節(jié)點(diǎn)來(lái)處理數(shù)據(jù)包的路由。這種模式下宿主機(jī)端的邏輯大幅簡(jiǎn)化了，只需要知道關(guān)聯(lián)的 Gateway 節(jié)點(diǎn)把所有數(shù)據(jù)包都轉(zhuǎn)給 Gateway 節(jié)點(diǎn)就可以了。Gateway 專(zhuān)門(mén)用來(lái)處理相應(yīng)的路由更新邏輯。但是缺點(diǎn)是要消耗額外的資源，在不超售的情況下需要額外付出一倍的網(wǎng)絡(luò)資源來(lái)處理網(wǎng)絡(luò)數(shù)據(jù)。即使是進(jìn)行了超賣(mài)，由于網(wǎng)絡(luò)流量的變化會(huì)十分劇烈可能會(huì)有上百倍的波動(dòng)，如何動(dòng)態(tài)調(diào)度 Gateway 節(jié)點(diǎn)保證帶寬也是很困難的事情。

可以說(shuō)這三種模式都有各自的問(wèn)題，GCP 采用了一種結(jié)合 Gateway 和 On Demand 的動(dòng)態(tài)路由卸載模式，并稱(chēng)其為 Hoverboard 模式。這種動(dòng)態(tài)路由卸載模式是基于網(wǎng)絡(luò)流量模式幾個(gè)統(tǒng)計(jì)學(xué)的發(fā)現(xiàn)：

83% 的 VM 之間從來(lái)沒(méi)有網(wǎng)絡(luò)通信；

98% 的 VM 之間的網(wǎng)絡(luò)吞吐量峰值小于 20kbps；

也就是說(shuō)網(wǎng)絡(luò)的流量分布存在著明顯的冷熱不均，絕大多數(shù)的流量只出現(xiàn)在極少數(shù)的 VM 之間。經(jīng)過(guò)計(jì)算可以得出 2% 的 VM 之間網(wǎng)絡(luò)通信占據(jù)了 99.5% 的網(wǎng)絡(luò)帶寬。也就是說(shuō)和 full mesh 模式相比，只需要本機(jī)保留五十分之一的路由地址簿就可以處理絕大多數(shù)的請(qǐng)求。而我們要做的就是找出那些熱點(diǎn)的 flow 將規(guī)則加載到宿主機(jī)實(shí)現(xiàn)直接轉(zhuǎn)發(fā)，而將那些長(zhǎng)尾的基本沒(méi)有流量的 flow 放在 Gateway 上來(lái)處理，減小宿主機(jī)的規(guī)則條數(shù)。

具體的處理流程如上圖所示，VM x 到 z 的流量最初都是通過(guò) hoverboard 這個(gè)特殊的 Gateway 進(jìn)行轉(zhuǎn)發(fā)。在這個(gè)過(guò)程中宿主機(jī)會(huì)定期向 VM Controller 上報(bào)流量統(tǒng)計(jì)信息，Controller 以 20kbps 作為閾值，考慮是否將對(duì)應(yīng)路徑的流表下發(fā)到主機(jī)。一旦 x 到 z 的流表下發(fā)到主機(jī)，x 和 z 就可以直接通信而不經(jīng)過(guò) hoverboard。

這種模式很巧妙的解決了之前提到三種模式的問(wèn)題。相比 full-mesh 模式大幅降低了主機(jī)流表的規(guī)模，可擴(kuò)展性得到了提升。相比 On Demand 模式降低了首包的延遲和控制器的壓力。相比 Gateway 模式降低了額外的網(wǎng)絡(luò)資源開(kāi)銷(xiāo)也提升了 Gateway 的處理能力。

數(shù)據(jù)平面

論文里主要介紹的是 On HOST Datapath，也就是基于 OVS 的性能優(yōu)化，其實(shí)我比較感興趣的是 hoverboard 里怎么對(duì)長(zhǎng)尾流量進(jìn)行優(yōu)化的，但是論文中沒(méi)有介紹。

數(shù)據(jù)平面的很多工作和 OVS-DPDK 做的類(lèi)似，例如 Userspace Datapath，Busy Polling，無(wú)鎖隊(duì)列，無(wú)系統(tǒng)調(diào)用，Hugepage，Batch Processing 等等。比較有特點(diǎn)的是在 HOST Datapath 中，依然采用了冷熱分離的兩個(gè) Datapath 進(jìn)行數(shù)據(jù)處理。

在 OVN 中所有的數(shù)據(jù)處理邏輯包括轉(zhuǎn)發(fā)，acl，nat，lb，arp reply，dns，dhcp 都是通過(guò)一套流表組成的 pipeline 來(lái)完成的，好處是邏輯統(tǒng)一，缺點(diǎn)就是很難針對(duì)性的進(jìn)行優(yōu)化。這其中轉(zhuǎn)發(fā)是最常見(jiàn)也是最關(guān)鍵的處理操作，而和其他功能混在一起來(lái)實(shí)現(xiàn)會(huì)拖慢轉(zhuǎn)發(fā)的性能。

GCP 中的做法是分成 Fast Path 和 Coprocessor Path。Fast Path 中只處理轉(zhuǎn)發(fā)的操作，用到了上面所說(shuō)的和 OVS-DPDK 類(lèi)似的所有比較極端的優(yōu)化手段，做到了一個(gè)數(shù)據(jù)包平均只需要 300ns 進(jìn)行處理就可以完成從 VM 網(wǎng)卡到物理網(wǎng)卡的操作。同時(shí)由于功能極為簡(jiǎn)單，flow table 的查詢(xún)更新也變得簡(jiǎn)單，無(wú)需像開(kāi)源的 ovs 那樣需要考慮遍歷所有元組才能查詢(xún)到規(guī)則。

而 Coprocessor Path 則沒(méi)有這么高的性能要求可以做一些更復(fù)雜的功能和邏輯，這樣可以將復(fù)雜的網(wǎng)絡(luò)功能和簡(jiǎn)單的轉(zhuǎn)發(fā)功能解耦，利于復(fù)雜網(wǎng)絡(luò)功能的迭代，同時(shí)避免對(duì)整體性能產(chǎn)生大的影響。

Fast Path 和 Coprocessor 之間的交互類(lèi)似流表和 ovn-controller 之間的交互。對(duì)于特定的數(shù)據(jù)包在 Fast Path 中插入一條上傳給 Coprocessor 的規(guī)則，Coprocessor 處理完后再交還給 Fast Path 進(jìn)行處理。

論文中還介紹到了數(shù)據(jù)平面的在線(xiàn)遷移，由于是純軟件的實(shí)現(xiàn)，可以做到在升級(jí)過(guò)程中同時(shí)運(yùn)行新舊兩個(gè)數(shù)據(jù)平面，舊的數(shù)據(jù)不斷的往新的遷移，然后在某個(gè)時(shí)間點(diǎn)進(jìn)行切換，這中間暫停服務(wù)的時(shí)間大約有 270ms。通過(guò)這種方式他們做到了數(shù)據(jù)平面每周更新的高速迭代。

聽(tīng)說(shuō)阿里云的網(wǎng)絡(luò)部分現(xiàn)在也已經(jīng)是硬件實(shí)現(xiàn)的了，這么大規(guī)模集群的純軟實(shí)現(xiàn)已經(jīng)很少見(jiàn)了?？礃幼?Google 工程師對(duì)軟實(shí)現(xiàn)在工程方面高速迭代的能力還是十分熱衷的。不過(guò)這個(gè)論文在 presentation 的同期， Azure 也展示了他們用 FPGA 實(shí)現(xiàn)的數(shù)據(jù)平面，也可以通過(guò)編程的方式實(shí)現(xiàn)網(wǎng)絡(luò)功能的快速迭代。此外 Azure 還很心機(jī)的做了個(gè)和 GCP 的性能測(cè)試比較來(lái)展示 Azure 在性能上的優(yōu)勢(shì)。不知道 GCP 的純軟線(xiàn)路還能堅(jiān)持多久，畢竟從規(guī)模效應(yīng)上來(lái)看，硬件方案性能好還能省 CPU 整體的性?xún)r(jià)比還是不錯(cuò)的。

再回過(guò)頭來(lái)和 OVN 做個(gè)整體對(duì)比。GCP 最大的特點(diǎn)就是在控制平面和數(shù)據(jù)平面各個(gè)層次都做了冷熱分離，盡可能的優(yōu)化常用路徑的性能。而這種做法在實(shí)現(xiàn)上就會(huì)導(dǎo)致不同的情況下要用不同的方案，整體的實(shí)現(xiàn)會(huì)比較分散，但是針對(duì)單個(gè)公司的場(chǎng)景下能榨取盡可能多的性能。

而 OVN 為了保證整體架構(gòu)的一致和邏輯的統(tǒng)一，沒(méi)有這么碎的冷熱分離和 On Demand 方案，通用性會(huì)更好，但是在大規(guī)模場(chǎng)景下會(huì)碰到性能瓶頸問(wèn)題。當(dāng)然 OVN 社區(qū)目前也在控制平面做了大量的性能優(yōu)化，包括各種緩存和增量式更新，降低單個(gè)網(wǎng)絡(luò)變更的消耗，目測(cè) 20.03 后的下一個(gè)版本還會(huì)有很大改善。而數(shù)據(jù)平面看上去在一些技術(shù)使用上和 OVS-DPDK 的技術(shù)是一致的，不過(guò) GCP 這種冷熱分離，在線(xiàn)遷移的靈活性設(shè)計(jì)，在工程上還是很值得借鑒的。當(dāng)然這兩年又出現(xiàn)了更多的新方案，例如 FPGA 加速，各種智能網(wǎng)卡和 eBPF 的 Kernel Bypass 方案，都給數(shù)據(jù)平面的加速提供了更多的選擇方案。

參考資料：

https://www.usenix.org/conference/nsdi18/presentation/dalton

https://www.usenix.org/conference/nsdi18/presentation/firestone

GCP網(wǎng)絡(luò)系統(tǒng)Andromeda https://zhuanlan.zhihu.com/p/102951479