Google Cloud 的網(wǎng)絡(luò)設(shè)計,googlecloud的網(wǎng)絡(luò)設(shè)計

Google Cloud 的網(wǎng)絡(luò)設(shè)計

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

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

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

設(shè)計目標

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

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

控制平面的隔離性指的是對多租戶的支持，避免單個租戶的異常行為對其他租戶的擾動。例如在某些機器學(xué)習(xí)場景下單個網(wǎng)絡(luò)可能會瞬時provision 10k VM，其他租戶的網(wǎng)絡(luò)操作不能因為這個租戶的突發(fā)請求而受到影響。

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

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

下面將介紹控制平面和數(shù)據(jù)平面分別是如何設(shè)計來滿足這些目標的。

控制平面

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

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

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

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

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

1.83%的VM之間從來沒有網(wǎng)絡(luò)通信

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

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

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

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

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

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

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

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

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

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

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

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

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

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

而OVN為了保證整體架構(gòu)的一致和邏輯的統(tǒng)一，沒有這么碎的冷熱分離和On Demand方案，通用性會更好，但是在大規(guī)模場景下會碰到性能瓶頸問題。當(dāng)然OVN社區(qū)目前也在控制平面做了大量的性能優(yōu)化，包括各種緩存和增量式更新，降低單個網(wǎng)絡(luò)變更的消耗，目測20.03后的下一個版本還會有很大改善。而數(shù)據(jù)平面看上去在一些技術(shù)使用上和OVSDPDK的技術(shù)是一致的，不過GCP這種冷熱分離，在線遷移的靈活性設(shè)計，在工程上還是很值得借鑒的。當(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

特別聲明：以上文章內(nèi)容僅代表作者本人觀點，不代表ESG跨境電商觀點或立場。如有關(guān)于作品內(nèi)容、版權(quán)或其它問題請于作品發(fā)表后的30日內(nèi)與ESG跨境電商聯(lián)系。