0 摘要

亞馬遜網(wǎng)絡(luò)服務(wù) (AWS) 對網(wǎng)絡(luò)進行了重新梳理，以提供超級計算應(yīng)用程序所需的持續(xù)低延遲，同時保持公共云的優(yōu)勢：可擴展性、按需彈性容量、成本效益以及快速采用更新的CPU和GPU。我們構(gòu)建了一個新的網(wǎng)絡(luò)傳輸協(xié)議，可擴展的可靠數(shù)據(jù)報 (SRD，Scalable Reliable Datagram)，旨在利用現(xiàn)代商業(yè)化的多租戶數(shù)據(jù)中心網(wǎng)絡(luò)（具有大量網(wǎng)絡(luò)路徑），同時克服它們的局限性（負(fù)載不平衡和無關(guān)流沖突時的不一致延遲）。SRD不保留數(shù)據(jù)包順序，而是通過盡可能多的網(wǎng)絡(luò)路徑發(fā)送數(shù)據(jù)包，同時避免路徑過載。為了最大限度地減少抖動并確保對網(wǎng)絡(luò)擁塞波動的最快響應(yīng)，在AWS自定義Nitro網(wǎng)卡中實施了SRD。SRD由EC2主機上的HPC/ML框架通過AWS彈性結(jié)構(gòu)適配器（EFA，Elastic Fabric Adapter）內(nèi)核旁路接口使用。

1 概述

云計算的主要好處之一是按照需要，瞬間提供和取消配置的資源。這與傳統(tǒng)的超級計算截然不同，傳統(tǒng)的超級計算機是定制的（需要數(shù)月或數(shù)年），因為其成本和容量限制，超級計算機通常是難以獲取的。使用定制系統(tǒng)進行超級計算的主要原因之一是構(gòu)建高性能網(wǎng)絡(luò)并在應(yīng)用程序之間共享的挑戰(zhàn)。在云計算環(huán)境中，使用InfiniBand等專用硬件或?qū)Ｓ糜贖PC工作負(fù)載的商用硬件都非常昂貴、難以擴展且難以快速發(fā)展。

AWS選擇使用現(xiàn)有AWS網(wǎng)絡(luò)（從100 Gbps開始）為客戶提供經(jīng)濟實惠的超級計算，并添加了新的HPC優(yōu)化網(wǎng)絡(luò)接口，作為AWS Nitro卡提供的網(wǎng)絡(luò)功能的擴展。

正如預(yù)期的那樣，在共享網(wǎng)絡(luò)上運行HPC流量會帶來一系列挑戰(zhàn)。AWS使用商用以太網(wǎng)交換機來構(gòu)建具有等價多路徑(ECMP)路由的高基數(shù)折疊 Clos 拓?fù)洹CMP通常用于使用流哈希在可用路徑上靜態(tài)地對流進行條帶化。流到路徑的這種靜態(tài)映射有利于保持TCP的每個流的順序，但它不考慮當(dāng)前的網(wǎng)絡(luò)利用率或流率。哈希沖突會導(dǎo)致某些鏈路上出現(xiàn)“熱點”，從而導(dǎo)致路徑間負(fù)載分布不均勻、數(shù)據(jù)包丟失、吞吐量降低和尾部延遲高（如 Al-Fares等人、Ghorbani等人、Handley等人、Hopps等人和Vanini等人在文章中廣泛研究的那樣)。即使在過度配置的網(wǎng)絡(luò)中，大量流量也可能影響不相關(guān)的應(yīng)用程序。

數(shù)據(jù)包延遲和數(shù)據(jù)包丟棄會干擾HPC/ML應(yīng)用程序的低延遲要求，從而降低擴展效率。延遲異常值對這些應(yīng)用程序具有深遠的影響，因為它們通常遵循批量同步并行編程模型，計算的周期之后是整個集群的批量同步。單個異常值將使整個集群等待，阿姆達爾定律決定了可擴展性。

1.1 為什么不是 TCP

TCP是IP網(wǎng)絡(luò)中可靠數(shù)據(jù)傳輸?shù)闹饕侄?，它自誕生以來一直很好地服務(wù)于Internet，并且仍然是大多數(shù)通信的最佳協(xié)議。但是，它不適合對延遲敏感的處理。對于TCP在數(shù)據(jù)中心，而最好情況的往返延遲差不多是25us，因擁塞（或鏈路故障）的等待時間異常值可以是50 ms，甚至數(shù)秒，即使當(dāng)替代無擁塞網(wǎng)絡(luò)路徑之間的任何地方可用。這些異常值的主要原因之一是丟失TCP數(shù)據(jù)包的重傳：TCP被迫保持重傳所以超時很多，這也解釋了操作系統(tǒng)延遲問題。

1.2 為什么不RoCE

InfiniBand是一種用于高性能計算的流行的高吞吐量低延遲互連，它支持內(nèi)核旁路和傳輸卸載。RoCE（RDMA over Converged Ethernet），也稱為InfiniBand over Ethernet，允許在以太網(wǎng)上運行InfiniBand傳輸，理論上可以提供AWS數(shù)據(jù)中心中TCP的替代方案。我們考慮了RoCEv2支持，彈性結(jié)構(gòu)適配器(EFA)主機接口與InfiniBand/RoCE接口非常相似。但是，我們發(fā)現(xiàn)InfiniBand傳輸不適合AWS可擴展性要求。原因之一是RoCE [v2]需要優(yōu)先級流量控制(PFC)，這在大型網(wǎng)絡(luò)上是不可行的，因為它會造成隊頭阻塞、擁塞擴散和偶爾的死鎖。郭在文章中描述了一種大規(guī)模PFC問題的解決方案，但它明確依賴于比AWS數(shù)據(jù)中心小得多的數(shù)據(jù)中心規(guī)模。此外，即使使用PFC，RoCE在擁塞（類似于TCP）和次優(yōu)擁塞控制下仍會遭受ECMP沖突。

1.3 我們的方法

由于TCP和其他傳輸協(xié)議都不能提供我們需要的性能級別，因此在我們使用的網(wǎng)絡(luò)中，我們選擇設(shè)計自己的網(wǎng)絡(luò)傳輸協(xié)議?？蓴U展的可靠數(shù)據(jù)報 (SRD) 針對超大規(guī)模數(shù)據(jù)中心進行了優(yōu)化：它提供跨多個路徑的負(fù)載平衡以及從數(shù)據(jù)包丟失或鏈路故障中快速恢復(fù)。它利用商用以太網(wǎng)交換機上的標(biāo)準(zhǔn)ECMP功能并解決其局限性：發(fā)送方通過操縱數(shù)據(jù)包封裝來控制ECMP路徑選擇。SRD采用專門的擁塞控制算法，通過將排隊保持在最低限度，有助于進一步降低丟包的機會并最大限度地減少重傳時間。

我們做出了一個有點不尋常的“協(xié)議保證”選擇：SRD提供可靠但亂序的交付，并將次序恢復(fù)留給上層。我們發(fā)現(xiàn)嚴(yán)格的有序交付通常是不必要的，強制執(zhí)行它只會造成隊列頭部阻塞、增加延遲并減少帶寬。例如，如果使用相同的消息標(biāo)簽，消息傳遞接口 (MPI) 標(biāo)記的消息必須按順序傳遞。因此，當(dāng)網(wǎng)絡(luò)中的并行導(dǎo)致數(shù)據(jù)包無序到達時，我們將消息順序恢復(fù)留給上層，因為它對所需的排序語義有更好的理解。

我們選擇在AWS Nitro卡中實施SRD可靠性層。我們的目標(biāo)是讓SRD盡可能靠近物理網(wǎng)絡(luò)層，并避免主機操作系統(tǒng)和管理程序注入的性能噪音。這允許快速適應(yīng)網(wǎng)絡(luò)行為：快速重傳并迅速減速以響應(yīng)隊列建立。

圖1 不使用和使用EFA的HPC堆棧

SRD作為EFA PCIe設(shè)備公開給主機。EFA是Amazon EC2實例（即虛擬和裸機服務(wù)器）的網(wǎng)絡(luò)接口，使客戶能夠在AWS上大規(guī)模運行緊密耦合的應(yīng)用程序。特別是，EFA支持運行HPC應(yīng)用程序和ML分布式訓(xùn)練，目前支持多種MPI實現(xiàn)：OpenMPI、Intel MPI和MVAPICH，以及NVIDIA集體通信庫。如圖1所示，EFA提供了一個“用戶空間驅(qū)動程序”，它利用操作系統(tǒng) (OS) 繞過硬件接口來增強實例間通信的性能（減少延遲、抖動、避免OS系統(tǒng)調(diào)用、并減少內(nèi)存副本），這是擴展這些應(yīng)用程序的關(guān)鍵。

2 可擴展的可靠數(shù)據(jù)報設(shè)計

2.1 多路徑負(fù)載平衡

為了減少丟包的機會，流量應(yīng)該在可用路徑上均勻分布。即使對于單個應(yīng)用程序流，SRD發(fā)送方依然需要在多個路徑上噴灑（Spray）數(shù)據(jù)包。尤其是對于重量流，以最小化熱點的機會并檢測次優(yōu)路徑。我們將SRD設(shè)計為與未啟用多路徑的傳統(tǒng)流量共享網(wǎng)絡(luò)，因此僅隨機噴射流量是不夠的。為了盡量減少繁重的傳統(tǒng)流的影響，SRD避免使用過載路徑，這可以通過為每條路徑收集的往返時間 (RTT) 信息獲取。

在規(guī)模上，偶爾的硬件故障是不可避免的；為了允許從網(wǎng)絡(luò)鏈路故障中快速恢復(fù)，如果用于原始傳輸?shù)穆窂阶兊貌豢捎?，SRD能夠重新路由重傳的數(shù)據(jù)包，而無需等待，需要2-3個數(shù)量級時長的，整個網(wǎng)絡(luò)范圍的路由更新收斂。此路由更改由SRD完成，無需重新建立昂貴的連接通路。

2.2 無序交付

平衡多條可用路徑之間的流量有助于減少排隊延遲并防止數(shù)據(jù)包丟失，但是，它不可避免地導(dǎo)致大型網(wǎng)絡(luò)中的無序數(shù)據(jù)包到達。眾所周知，恢復(fù)網(wǎng)卡中的數(shù)據(jù)包排序非常昂貴，這些網(wǎng)卡通常具有有限的資源（內(nèi)存帶寬、重排序緩沖區(qū)容量或開放排序上下文的數(shù)量）。

我們考慮讓Nitro網(wǎng)卡按順序發(fā)送接收消息，類似于常見的可靠傳輸，如TCP或Infiniband可靠連接(RC)。但是，這將限制可擴展性或在出現(xiàn)丟包時增加平均延遲。如果我們推遲向主機軟件發(fā)送亂序數(shù)據(jù)包，我們將需要一個大的中間緩沖區(qū)，并且我們將大大增加平均延遲，因為許多數(shù)據(jù)包被延遲，直到丟失的數(shù)據(jù)包被重新發(fā)送。大多數(shù)或所有這些數(shù)據(jù)包可能與丟失的數(shù)據(jù)包無關(guān)，因此這種延遲是不必要的。丟棄亂序數(shù)據(jù)包“解決”了緩沖問題，而不是延遲問題，并增加了網(wǎng)絡(luò)帶寬消耗。因此，我們決定將數(shù)據(jù)包傳送到主機，即使它們可能是亂序的。

應(yīng)用程序處理亂序數(shù)據(jù)包對于字節(jié)流協(xié)議（如TCP）是站不住腳的，其中消息邊界對傳輸層是不透明的，但在使用基于消息的語義時很容易。每個流的排序或其他類型的依賴跟蹤由SRD之上的消息傳遞層完成；消息層排序信息與數(shù)據(jù)包一起傳輸?shù)搅硪欢耍瑢RD不透明。

2.3 擁塞控制

多路徑噴灑減少了網(wǎng)絡(luò)中間交換機的負(fù)載，但它本身并不能緩解incast擁塞問題。Incast是一種流量模式，其中許多流會聚在交換機的同一接口上，耗盡該接口的緩沖區(qū)空間，從而導(dǎo)致數(shù)據(jù)包丟失。這在以多對一通信模式連接到接收器的最后一跳交換機中很常見，但也可能發(fā)生在其他層。

噴灑實際上會使incast問題變得更糟，因為來自同一發(fā)送者的微突發(fā)，即使最初受到發(fā)送者鏈路帶寬的限制，即使不同的路徑依然有可能同時到達。因此，對于多路徑傳輸?shù)膿砣刂茖⑺新窂缴系木酆吓抨牨３衷谧畹拖薅仁侵陵P(guān)重要的。

SRD擁塞控制的目標(biāo)是以最少的傳輸中字節(jié)獲得公平的帶寬份額，防止隊列增長和數(shù)據(jù)包丟失（而不是依賴它們進行擁塞檢測）。SRD擁塞控制有點類似于BBR，有額外的數(shù)據(jù)中心多路徑考慮。它基于每個連接的動態(tài)速率限制，并結(jié)合飛行限制。發(fā)送方根據(jù)傳入確認(rèn)數(shù)據(jù)包的時間指示的速率估計調(diào)整其每個連接的傳輸速率，同時考慮最近的傳輸速率和RTT變化。如果大多數(shù)路徑上的RTT上升，或者如果估計速率變得低于傳輸速率，則會檢測到擁塞。該方法允許檢測影響所有路徑的連接范圍的擁塞，例如，在incast的情況下，擁塞機制通過重新路由獨立處理單個路徑。

3 用戶接口：EFA

Nitro卡上的SRD傳輸通過EFA向AWS客戶公開。EFA接口類似于InfiniBand verbs。然而，其SRD語義與標(biāo)準(zhǔn)InfiniBand傳輸類型截然不同。EFA用戶空間軟件有兩種形式：基本的“用戶空間驅(qū)動程序”軟件公開可靠的亂序交付，由Nitro卡EFA硬件設(shè)備本地提供；而 libfabric “供應(yīng)者”層在驅(qū)動之上，實現(xiàn)數(shù)據(jù)包重新排序作為消息分段和MPI標(biāo)簽匹配支持的一部分。

3.1 EFA 作為Elastic Network Adapter的擴展

Nitro卡是一系列卡，可卸載和加速AWS EC2服務(wù)器上的網(wǎng)絡(luò)、存儲、安全和虛擬化功能。特別是，用于VPC的Nitro卡包括彈性網(wǎng)絡(luò)適配器 (ENA) PCIe控制器，該控制器將經(jīng)典網(wǎng)絡(luò)設(shè)備呈現(xiàn)給主機，同時還為AWS VPC實現(xiàn)數(shù)據(jù)平面。ENA使用 PCIe SR-IOV來提供高性能網(wǎng)絡(luò)功能，而無需管理程序參與；它將專用PCIe設(shè)備暴露給在AWS主機上運行的EC2實例，與傳統(tǒng)的半虛擬化網(wǎng)絡(luò)接口相比，可實現(xiàn)更高的I/O性能、更低的延遲和更少的CPU利用率。EFA是AWS上的Nitro VPC卡提供的附加可選服務(wù)，適用于HPC和ML的高性能服務(wù)器。

3.2 EFA SRD傳輸類型

與InfiniBand verbs一樣，所有EFA數(shù)據(jù)通信都是通過隊列對 (QP) 完成的，隊列對是包含發(fā)送隊列和接收隊列的可尋址通信端點，用于提交請求以異步發(fā)送和接收消息，直接來自/送到用戶空間。QP是昂貴的資源，傳統(tǒng)上需要大量QP才能在大型集群（其中通常在每個服務(wù)器上運行大量進程）中建立全對全進程連接。EFA SRD傳輸允許如
https://github.com/amzn/amzn-drivers/blob/master/kernel/linux/efa/SRD.txt中所述，所需數(shù)量的QP顯著節(jié)省。EFA SRD語義類似于InfiniBand可靠數(shù)據(jù)報(RD)模型，但消除了RD限制（由處理從不同發(fā)送方到同一目標(biāo)QP的交錯分段消息的復(fù)雜性難以維持，同時提供有序傳遞）。與RD不同，SRD QP提供無序數(shù)據(jù)并限制消息大小以避免分段。這允許支持多個未完成的消息，而不會創(chuàng)建隊頭阻塞，以便可以多路復(fù)用單獨的應(yīng)用程序流而不會相互干擾。

3.3 亂序數(shù)據(jù)包處理挑戰(zhàn)

EFA SRD QP語義為EFA上層處理引入了一種陌生的排序要求，我們稱之為“消息層”，通常由HPC應(yīng)用程序用于抽象網(wǎng)絡(luò)細(xì)節(jié)。與成熟的傳輸實現(xiàn)（如TCP）相比，這種新功能是輕量級的，因為卸載了可靠性層。

理想情況下，消息傳遞層完成的緩沖區(qū)管理和流量控制應(yīng)該與應(yīng)用程序緊密耦合，這是可行的，因為我們的主要關(guān)注點是類似HPC的應(yīng)用程序，它已經(jīng)支持并且實際上更喜歡具有管理能力的用戶空間網(wǎng)絡(luò)用戶緩沖區(qū)。

對于消息語義，如果應(yīng)用程序消息傳遞層希望將數(shù)據(jù)接收到虛擬連續(xù)的緩沖區(qū)而不是收集列表中，那么對于大型傳輸?shù)南⒍蔚臒o序到達可能需要進行數(shù)據(jù)復(fù)制。這并不比 TCP 差，后者需要從內(nèi)核緩沖區(qū)到用戶緩沖區(qū)的副本。可以在 EFA 中使用 RDMA 功能避免此副本（超出本文范圍）。

4 SRD性能評估

我們將 EFA SRD性能與AWS云上同一組服務(wù)器上的TCP（使用默認(rèn)配置）進行了比較。我們不分析由于操作系統(tǒng)內(nèi)核繞過而產(chǎn)生的差異，因為它對EFA的影響與經(jīng)過充分研究的InfiniBand案例沒有本質(zhì)區(qū)別，并且它是與擁堵情況下網(wǎng)絡(luò)流量通行為差異相比較小。

MPI實現(xiàn)是另一個對HPC 應(yīng)用程序性能產(chǎn)生深遠影響的因素，特別是對于早期版本 EFA 上的 MPI，如 Chakraborty等人的文章所示。12 由于我們的目標(biāo)是評估傳輸協(xié)議，并且 MPI 實現(xiàn)超出了本文的范圍，我們只在 OpenMPI 中使用了基本的 MPI 原語（包括重新排序邏輯），或者繞過 MPI 層的微基準(zhǔn)測試。

4.1 Incast FCT 和公平

我們評估了從4個服務(wù)器發(fā)送的48個獨立流，每個流運行12個進程，發(fā)送到單個目標(biāo)服務(wù)器，在最后一個網(wǎng)絡(luò)躍點處造成瓶頸。我們測量SRD和TCP的流完成時間( FCT)，并將其與最佳FCT進行比較，即在100%的瓶頸鏈路利用率在流之間均分的情況下的理想 FCT。

圖2 最大FCT，突發(fā)48流incast

“突發(fā)”Incast FCT

我們在EFA/SRD或TCP上運行了MPI帶寬基準(zhǔn)測試，此時發(fā)送方使用屏障在大約同一時間開始每個傳輸。圖2顯示了不同傳輸大小的理想和最大FCT。SRD FCT接近最優(yōu)，抖動非常低，而TCP FCT有噪聲，最大時間比理想值高3-20倍。

圖3顯示了用于2 MB傳輸?shù)腇CT的CDF。超過50毫秒的TCP尾部延遲反映了重傳，因為最小重傳超時為50毫秒。即使僅查看50ms以下的樣本（即，當(dāng)延遲不是因于超時），大量樣本也比理想情況高3倍。

圖3 2 MB傳輸?shù)腇CT的CDF，突發(fā)48流incast

持續(xù)擁塞Incast下的流量吞吐量

為了了解TCP的高FCT方差（即使忽略長尾導(dǎo)致的超時），我們檢查了incast下的單個流吞吐量。我們使用繞過MPI的底層基準(zhǔn)測試來測量連續(xù)發(fā)送數(shù)據(jù)時的吞吐量。我們每秒對每個流的吞吐量進行采樣。在100 Gb/s的組合速率下，每個流的預(yù)期公平份額約為2 Gb/s。

圖4分別顯示了兩個有代表性的發(fā)送方的TCP和SRD吞吐量。SRD流吞吐量對于所有流來說都是一致且接近理想的，而每個流的TCP吞吐量都在劇烈振蕩，并且某些流的平均吞吐量遠低于預(yù)期，這解釋了FCT抖動。

圖4 每秒采樣的吞吐量，48路incast典型流量

4.2 多路徑負(fù)載平衡

圖5 共享交換機間鏈路的獨立流

我們還評估了一個要求較低的案例，沒有相關(guān)的負(fù)載。如圖5所示，我們從位于同一個機架到位于另一個機架中的8個服務(wù)器，在一個全平分網(wǎng)絡(luò)中。每臺機器運行16個MPI等級（進程），所有數(shù)據(jù)都在不同的流上發(fā)送或接收到/從同一臺遠程機器。TOR交換機上行鏈路的利用率為50%，下行鏈路預(yù)計不會擁塞，因為只有一個發(fā)送方向發(fā)送數(shù)據(jù)到每個接收方。

圖6顯示了TCP和EFA的8個發(fā)送方之一的所有流的FCT（其他發(fā)送方看起來類似）。即使在理想的負(fù)載平衡下根本不會出現(xiàn)擁塞，但由于交換機間鏈路的ECMP平衡不均勻，TCP顯然會遇到擁塞甚至丟包。TCP中位延遲變化很大，平均值比預(yù)期高50%，而尾部延遲比預(yù)期高1-2個數(shù)量級。中值SRD FCT僅比理想值高15%，最大SRD FCT低于平均TCP FCT。

圖6 ECMP不平衡的影響

5 結(jié)論

EFA允許HPC/ML應(yīng)用程序在AWS公共云上大規(guī)模運行。它提供始終如一的低延遲，尾部延遲數(shù)量級低于TCP。這是通過SRD提供的新型網(wǎng)絡(luò)傳輸語義，結(jié)合網(wǎng)絡(luò)接口卡和不同主機軟件層之間的非正統(tǒng)功能拆分來實現(xiàn)的。通過在Nitro卡上運行SRD多路徑負(fù)載平衡和擁塞控制，我們既減少了網(wǎng)絡(luò)中丟包的機會，又可以更快地從丟包中恢復(fù)。

(正文完)