0 摘要

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

1 概述

云計算的主要好處之一是按照需要，瞬間提供和取消配置的資源。這與傳統的超級計算截然不同，傳統的超級計算機是定制的（需要數月或數年），因為其成本和容量限制，超級計算機通常是難以獲取的。使用定制系統進行超級計算的主要原因之一是構建高性能網絡并在應用程序之間共享的挑戰。在云計算環境中，使用InfiniBand等專用硬件或專用于HPC工作負載的商用硬件都非常昂貴、難以擴展且難以快速發展。

AWS選擇使用現有AWS網絡（從100 Gbps開始）為客戶提供經濟實惠的超級計算，并添加了新的HPC優化網絡接口，作為AWS Nitro卡提供的網絡功能的擴展。

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

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

1.1 為什么不是 TCP

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

1.2 為什么不RoCE

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

1.3 我們的方法

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

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

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

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

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

2 可擴展的可靠數據報設計

2.1 多路徑負載平衡

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

在規模上，偶爾的硬件故障是不可避免的；為了允許從網絡鏈路故障中快速恢復，如果用于原始傳輸的路徑變得不可用，SRD能夠重新路由重傳的數據包，而無需等待，需要2-3個數量級時長的，整個網絡范圍的路由更新收斂。此路由更改由SRD完成，無需重新建立昂貴的連接通路。

2.2 無序交付

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

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

應用程序處理亂序數據包對于字節流協議（如TCP）是站不住腳的，其中消息邊界對傳輸層是不透明的，但在使用基于消息的語義時很容易。每個流的排序或其他類型的依賴跟蹤由SRD之上的消息傳遞層完成；消息層排序信息與數據包一起傳輸到另一端，對SRD不透明。

2.3 擁塞控制

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

噴灑實際上會使incast問題變得更糟，因為來自同一發送者的微突發，即使最初受到發送者鏈路帶寬的限制，即使不同的路徑依然有可能同時到達。因此，對于多路徑傳輸的擁塞控制將所有路徑上的聚合排隊保持在最低限度是至關重要的。

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

3 用戶接口：EFA

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

3.1 EFA 作為Elastic Network Adapter的擴展

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

3.2 EFA SRD傳輸類型

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

3.3 亂序數據包處理挑戰

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

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

對于消息語義，如果應用程序消息傳遞層希望將數據接收到虛擬連續的緩沖區而不是收集列表中，那么對于大型傳輸的消息段的無序到達可能需要進行數據復制。這并不比 TCP 差，后者需要從內核緩沖區到用戶緩沖區的副本?？梢栽?EFA 中使用 RDMA 功能避免此副本（超出本文范圍）。

4 SRD性能評估

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

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

4.1 Incast FCT 和公平

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

圖2 最大FCT，突發48流incast

“突發”Incast FCT

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

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

圖3 2 MB傳輸的FCT的CDF，突發48流incast

持續擁塞Incast下的流量吞吐量

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

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

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

4.2 多路徑負載平衡

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

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

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

圖6 ECMP不平衡的影響

5 結論

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

(正文完)