近日，阿里云智能在SIGCOMM 2022斬獲兩篇關(guān)于“可預期高性能網(wǎng)絡”的研究論文“μFAB”和“Solar”。

可預期高性能網(wǎng)絡，是阿里云基礎設施研發(fā)的下一代數(shù)據(jù)中心網(wǎng)絡架構(gòu)，是一種可以為上層應用提供穩(wěn)定的可用性、帶寬和低延遲保證的網(wǎng)絡。作為可預期高性能網(wǎng)絡的技術(shù)成果之一，本文將對“μFAB”和“Solar”這兩篇發(fā)表在SIGCOMM 2022的論文進行深度解讀。

為什么需要“可預期高性能網(wǎng)絡”？

當前的數(shù)據(jù)中心發(fā)展面臨重大挑戰(zhàn)，無論從硬件更迭、應用規(guī)模，還是架構(gòu)演進都對網(wǎng)絡提出了更高的要求。

首先，隨著CPU、GPU、TPU、DPU等新型算力硬件的不斷推陳出新，大量的數(shù)據(jù)需要網(wǎng)絡進行交互。存儲介質(zhì)的不斷推陳出新，使得磁盤處理的時延從毫秒級降低到了微秒級，數(shù)據(jù)讀取的吞吐也得到了極大的提升，從而使得網(wǎng)絡逐漸成為端到端性能的短板。

其次，ML/HPC、存儲、數(shù)據(jù)庫等大型新型分布式系統(tǒng)和應用，對于性能越來越敏感，作為端到端性能的重要一環(huán)，勢必要求網(wǎng)絡提供極致的網(wǎng)絡傳輸服務：例如，ESSD存儲要求百萬IOPS和100微秒的訪問時延，這種情況下任何網(wǎng)絡的抖動都會造成應用性能的下降。另外，分布式機器學習在單集群部署規(guī)模已達到10K-100K加速卡的情況下，需要頻繁的數(shù)據(jù)聚合和再分配，依賴網(wǎng)絡帶寬的保障和微秒級別的網(wǎng)絡時延，系統(tǒng)的瓶頸已經(jīng)逐漸從計算轉(zhuǎn)移到了網(wǎng)絡傳輸。

此外，數(shù)據(jù)中心的資源池化（包括硬盤、GPU，甚至內(nèi)存等）已成為主流。資源池化能夠帶來應用部署的便利，并且不同資源可以獨立進行演進升級，更能節(jié)省資源降低使用成本。但資源池化對網(wǎng)絡有非?？量痰囊?，各種資源至少需要100G以上的接入網(wǎng)絡帶寬和10us以內(nèi)甚至2us以內(nèi)的時延。隨著內(nèi)存池化的研發(fā)，對于網(wǎng)絡的依賴會更加迫切。

μFAB：Predictable vFabric on Informative Data Plane

今天，隨著云計算的不斷發(fā)展，高性能存儲、分布式機器學習、資源池化等應用和架構(gòu)的變革，對于網(wǎng)絡傳輸?shù)囊笠苍絹碓礁?，即使微秒級別的網(wǎng)絡異常也會使得應用受影響。傳統(tǒng)的“盡力而為”的網(wǎng)絡服務模型已越來越不適應未來應用的需求。

可預期DCN服務模型

μFAB的目標，是在云數(shù)據(jù)中心為租戶提供帶寬保障、低延遲保障，以及最大化利用網(wǎng)絡帶寬資源。但在目前的網(wǎng)絡架構(gòu)中，要同時實現(xiàn)這三點是非常困難，主要原因是：之前的工作通常把網(wǎng)絡當作一個黑盒，利用時延、探測等一系列的啟發(fā)式算法來做速率控制和路徑選擇，這樣便造成了需要毫秒級別的收斂時間，難以滿足應用日漸增加的對于性能的需求。



圖 | μFAB的服務模型

μFAB的設計理念則恰好相反，其核心思想是網(wǎng)絡的透明化和信息化，即利用可編程網(wǎng)絡數(shù)據(jù)平面提供的鏈路狀態(tài)和租戶信息，并將這些信息反饋到主機側(cè)用于智能的速率控制和路徑選擇。

上圖所示μFAB的服務模型，每個租戶會被分配一個虛擬的網(wǎng)絡（Virtual Fabric），該虛擬網(wǎng)絡為租戶提供最小帶寬保障、最大化利用資源、低長尾延遲等三個SLA保障。而租戶的最小帶寬分配遵循云的彈性部署規(guī)范，租戶總帶寬之和不會超過網(wǎng)絡物理總帶寬。μFAB利用可編程網(wǎng)絡提供的精確信息，再通過端網(wǎng)協(xié)同的機制達到上述目標。

端網(wǎng)協(xié)同的具體工作方式為：一方面，主機側(cè)的μFAB-E模塊發(fā)送探測包，用以獲取網(wǎng)絡的信息，從而指導其做“速率控制”和“路徑選擇”。另一方面，網(wǎng)絡交換機上的μFAB-C模塊收集鏈路狀態(tài)和租戶的信息，并將這些信息做聚合，插入到發(fā)過來的探測包中，反饋給μFAB-E。

帶寬延遲保障算法

有了網(wǎng)絡透明化和端網(wǎng)協(xié)同，如何才能做到帶寬和時延的保障呢？ μFAB使用的是按權(quán)重分配的做法，這樣做的好處是可以很快判斷出帶寬是否得到了滿足。發(fā)送窗口的計算方法為：



其中，是按租戶的權(quán)重進行的按權(quán)分配，而是交換機維護的所有租戶的發(fā)送窗口之和，則是根據(jù)鏈路的負載進行的調(diào)整，用于最大化鏈路利用，同時做擁塞避免。、由探測包攜帶到網(wǎng)絡交換機中，、由交換機維護的租戶信息的聚合，而tx、qlen是交換機維護的網(wǎng)絡鏈路信息。 ?

那么，當多個租戶同時有流量請求的時候，是不是大家一起發(fā)流量就會造成網(wǎng)絡擁塞，從而導致長尾時延呢？μFAB在解決這個問題同時保障長尾低時延的做法是：允許租戶無論何時都可以按照最小帶寬保障發(fā)送，只有在網(wǎng)絡有剩余帶寬的情況下，才會逐漸增大發(fā)送速率。這么做的原理是，最小帶寬是租戶的SLA保障必須滿足，而盡可能地提高發(fā)送速率則是額外的獎勵，時效性要求相對較低。這樣既滿足了租戶對于隨時獲取最小帶寬的承諾，又使得在有多租戶突發(fā)流量的沖突的時候，依然能夠保障網(wǎng)絡的長尾時延。

另一個重要的點是，μFAB能夠充分利用整個網(wǎng)絡的帶寬資源，當一個路徑上的帶寬資源已經(jīng)被分配完時，能夠快速地進行路徑切換，從而使用多個路徑的網(wǎng)絡帶寬資源。在路徑切換時，需要考慮兩種場景：一是當前路徑的帶寬已經(jīng)不滿足租戶SLA，這種情況需要立刻進行路徑切換，但也要注意不要過于頻繁地連續(xù)切換。二是發(fā)現(xiàn)有路徑的更多帶寬資源的時候，這種情況的路徑切換是一種最大化利用網(wǎng)絡資源的行為，但相對來說沒有緊迫的時間需求，因此不用做得過于頻繁。

理論分析和硬件實驗




圖 | 測試環(huán)境和硬件測試結(jié)果

μFAB的理論分析表明：μFAB具備快速收斂，帶寬和時延保障等特性，即使在路徑切換中也能做到快速收斂而不會造成網(wǎng)絡震蕩。我們分別在FPGA和SOC的硬件網(wǎng)卡和Tofino交換機上做了相應的算法實現(xiàn)，并在三層fat-tree的網(wǎng)絡拓撲上做了網(wǎng)絡層驗證和應用層驗證。實驗表明，μFAB能提供給租戶最小帶寬保障和長尾低延遲，同時提供最大化地網(wǎng)絡帶寬利用，即使面對網(wǎng)絡故障的場景下，依然能夠快速收斂。



圖 | 應用層實測結(jié)果 為了驗證μFAB對于應用的實際增益，我們將一個租戶運行時延敏感型的Memcached，另一個租戶運行大帶寬的MongoDB應用進行對比實驗。實驗表明，μFAB能實現(xiàn)接近于理想狀態(tài)下的QPS（Query Per Second）和QCT（Query Completion Time）。這是因為μFAB總是能正確的選擇流量路徑，從而實現(xiàn)性能的隔離，以及快速的響應網(wǎng)絡擁塞。上圖可以看出μFAB能為應用等提供2.5倍的QPS提升、21倍的長尾延遲下降。

From Luna to Solar：The Evolutions of the Compute-to-Storage Networks in Alibaba Cloud

與傳統(tǒng)的“盡力而為（best effort）”的網(wǎng)絡設計理念不同，可預期高性能網(wǎng)絡利用軟硬結(jié)合、跨層設計和端網(wǎng)協(xié)同的理念，可提供微秒級別的帶寬、延遲保障。

計算存儲分離架構(gòu)



圖 | 計算存儲分離架構(gòu)

在計算存儲分離架構(gòu)下，所有的存儲I/O都需要網(wǎng)絡傳遞，因此網(wǎng)絡成為存儲應用的重要瓶頸。而存儲流量本身占了整個DCN的60%左右，大量的流量都是很多的小流組成的，例如40%的流量都不超過4KB。因此，存儲的流量對于帶寬和時延都有極高的要求。

Luna用戶態(tài)TCP協(xié)議

在應對SSD介質(zhì)帶來的低時延同時，傳統(tǒng)內(nèi)核態(tài)的tcp協(xié)議已然成為端到端性能的瓶頸。與存儲內(nèi)部網(wǎng)絡使用RDMA來提高性能不同，計算到存儲網(wǎng)絡由于它的特殊要求，例如，需要支持十萬個連接這個規(guī)模，同時需要很高的互通性，而選擇了截然不同的協(xié)議。

2018年，阿里云在計算到存儲部署了用戶態(tài)tcp協(xié)議luna，實現(xiàn)了網(wǎng)絡到存儲的零拷貝和無鎖、零共享等機制，長尾延遲降低了80%。支持了新發(fā)布的ESSD產(chǎn)品，實現(xiàn)百萬IOPS和100微秒的I/O時延。



圖 | luna的長尾性能收益

裸金屬下的存儲挑戰(zhàn)



圖 | 裸金屬云的部署 裸金屬云為租戶提供整個物理主機，這樣租戶不僅可以靈活地定制機型和虛擬化平臺，快速上云，還能提供安全和性能的保障。例如，租戶在使用裸金屬服務器時，可以運行自定義的虛擬化平臺（如VMware cloud）或完成多云部署，甚至可以調(diào)用硬件底層API功能（如Intel RDT）。

但裸金屬云在提供給租戶更多可能的同時，也面臨自身性能和成本的挑戰(zhàn)。因為在將整個物理服務器交付給租戶的同時，裸金屬也不得不將云基礎設施軟件運行在“非侵入式”的硬件中，通常是網(wǎng)絡設備，如智能網(wǎng)卡、DPU、IPU、交換機等等。這樣的部署面臨著以下兩大挑戰(zhàn)：

● 資源受限：相對于物理服務器，這些網(wǎng)絡設備通常面臨更少的資源和更低的功耗限制。在這種條件下，要實現(xiàn)相同甚至更好的云服務性能變得極具挑戰(zhàn)；

● 帶寬受限：與傳統(tǒng)的虛擬化部署中，hypervisor和租戶使用內(nèi)存拷貝交互數(shù)據(jù)不同，裸金屬場景下的虛擬化和數(shù)據(jù)交互需要經(jīng)過智能網(wǎng)卡的緩存、處理和轉(zhuǎn)發(fā)，在單個方向上數(shù)據(jù)會兩次通過智能網(wǎng)卡內(nèi)的PCIe拷貝，數(shù)據(jù)在網(wǎng)卡中的雙向拷貝造成帶寬減半。



圖 | 裸金屬下存儲前端的挑戰(zhàn) 帶寬減半原因如上圖所示。當租戶發(fā)送數(shù)據(jù)→數(shù)據(jù)通過主機PCIe到達智能網(wǎng)卡→通過智能網(wǎng)卡內(nèi)部PCIe到達網(wǎng)卡CPU（一次拷貝）→網(wǎng)卡CPU處理→再通過智能網(wǎng)卡內(nèi)部PCIe發(fā)到網(wǎng)口（二次拷貝），再從網(wǎng)口中發(fā)出。同理，租戶從網(wǎng)絡中接收數(shù)據(jù)也要經(jīng)歷2次拷貝，例如，當網(wǎng)口提供雙向100Gb/s吞吐時候，租戶實際能獲得的帶寬只有雙向50Gb/s。

理想情況下，我們希望數(shù)據(jù)平面能夠直達主機PCIe，不用經(jīng)歷智能網(wǎng)卡內(nèi)部PCIe的中轉(zhuǎn)。

存儲與網(wǎng)絡融合的Solar協(xié)議

Solar的設計目標是：能夠極大地卸載存儲和網(wǎng)絡處理到硬件網(wǎng)卡中，從而降低CPU開銷，在提供網(wǎng)絡性能的同時規(guī)避網(wǎng)絡故障。但面臨的現(xiàn)實問題是存儲和網(wǎng)絡的協(xié)議處理都非常復雜，且存在大量的狀態(tài)。尤其在資源受限的智能網(wǎng)卡中，能留給存儲使用的資源非常有限。做硬件卸載是非常困難的。



圖 | 存儲硬件卸載的挑戰(zhàn)和解決方案 因此，Solar的設計理念是盡可能地減少協(xié)議的復雜度，使得硬件卸載可以非常容易地實現(xiàn)。如上圖所示，具體做法是對網(wǎng)絡和存儲進行跨層融合，利用網(wǎng)絡的jumbo frame使得一個網(wǎng)絡的數(shù)據(jù)包就直接等效成一個存儲的block。這樣協(xié)議上就不需要維護數(shù)據(jù)包到block的映射，也不會有在丟包后出現(xiàn)的隊首阻塞問題。更少的狀態(tài)處理也意味著Solar能夠節(jié)省CPU開銷，以及支持多路徑等能力。



圖 | Solar的性能收益 從線上觀測看到，在采用Solar之后，計算側(cè)Storage agent（SA）的長尾時延下降了40%，這是因為Solar采用了存儲流量的數(shù)據(jù)平面卸載，這樣減少了CPU上的協(xié)議處理時延和時延的抖動。同時，由于流量不用經(jīng)過兩次DPU上的PCIe bus，所以網(wǎng)絡吞吐能夠翻倍。



圖 | EBS存儲的時延和帶寬演進 多年的線上實測試數(shù)據(jù)表明，隨著luna和Solar的規(guī)?；渴穑琫bs存儲的時延在近幾年降低了72%，而IOPS提高了3倍。

結(jié) 語

可預期高性能網(wǎng)絡，是阿里云基礎設施為ML/HPC、高性能存儲等新型應用打造的新一代網(wǎng)絡架構(gòu)，其核心目標是“為應用提供微秒級別的時延和帶寬保障”。μFAB和Solar分別闡述了實現(xiàn)上述目標的兩種重要技術(shù)手段：μFAB揭示了端網(wǎng)協(xié)同的融合設計，利用可編程網(wǎng)絡提供的精細網(wǎng)絡信息，在端上智能網(wǎng)卡用于速率控制和路徑選擇；Solar闡述了應用和網(wǎng)絡融合的設計理念，利用數(shù)據(jù)包和數(shù)據(jù)塊的一一映射，從而極大簡化狀態(tài)處理，提高處理吞吐、降低時延。這些設計的部署，極大地提升了網(wǎng)絡傳輸?shù)姆召|(zhì)量，也給云上客戶以及未來算力融合帶來了持續(xù)價值。

審核編輯：劉清