為什么需要可預(yù)期高性能網(wǎng)絡(luò)呢？

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

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

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

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

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

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

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

μFAB：Predictable vFabric on Informative Data Plane

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

可預(yù)期DCN服務(wù)模型

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



圖 | μFAB的服務(wù)模型

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

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

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

帶寬延遲保障算法

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



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

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

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

理論分析和硬件實(shí)驗(yàn)




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

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



圖 | 應(yīng)用層實(shí)測(cè)結(jié)果 為了驗(yàn)證μFAB對(duì)于應(yīng)用的實(shí)際增益，我們將一個(gè)租戶運(yùn)行時(shí)延敏感型的Memcached，另一個(gè)租戶運(yùn)行大帶寬的MongoDB應(yīng)用進(jìn)行對(duì)比實(shí)驗(yàn)。實(shí)驗(yàn)表明，μFAB能實(shí)現(xiàn)接近于理想狀態(tài)下的QPS（Query Per Second）和QCT（Query Completion Time）。這是因?yàn)棣蘁AB總是能正確的選擇流量路徑，從而實(shí)現(xiàn)性能的隔離，以及快速的響應(yīng)網(wǎng)絡(luò)擁塞。上圖可以看出μFAB能為應(yīng)用等提供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)絡(luò)設(shè)計(jì)理念不同，可預(yù)期高性能網(wǎng)絡(luò)利用軟硬結(jié)合、跨層設(shè)計(jì)和端網(wǎng)協(xié)同的理念，可提供微秒級(jí)別的帶寬、延遲保障。

計(jì)算存儲(chǔ)分離架構(gòu)



圖 | 計(jì)算存儲(chǔ)分離架構(gòu)

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

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

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

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



圖 | luna的長尾性能收益

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



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

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

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

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



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

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

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

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



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



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



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

結(jié) 語

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

審核編輯：劉清