人工智能 (AI) 的興起極大地提高了對強大、高效和可擴展的網(wǎng)絡傳輸協(xié)議的需求。本文深入探討了 RDMA（遠程直接內(nèi)存訪問）傳輸協(xié)議，并重點討論 ROCEv2 協(xié)議，目前基于 ROCEv2 的 RDMA已經(jīng)在一些超大規(guī)模數(shù)據(jù)中心中取代了 TCP。

在最近的NDSI-23-Talk中，微軟強調(diào)，70% 的 Azure 云網(wǎng)絡流量（主要是存儲網(wǎng)絡流量）在基于以太網(wǎng)的 ROCEv2 RDMA 上運行，只有一小部分依賴基于 TCP/IP 的網(wǎng)絡，這一轉(zhuǎn)變在 Oracle、阿里巴巴和 Meta 等其他超大規(guī)模提供商中也很明顯。這一趨勢表明，隨著云計算、人工智能/機器學習工作負載的持續(xù)增長，整個行業(yè)正朝著采用RDMA技術(shù)來優(yōu)化網(wǎng)絡性能的方向發(fā)展。

01RDMA概述

RDMA 通過直接將“內(nèi)存映射”數(shù)據(jù)傳輸?shù)竭h程內(nèi)存位置來運行，具有兩個關(guān)鍵優(yōu)勢：

CPU 效率：與消耗多個 CPU 核心的 TCP/IP 不同，RDMA在內(nèi)存注冊后將數(shù)據(jù)傳輸委托給 RDMA 網(wǎng)絡適配器來執(zhí)行，這樣的方式釋放了CPU資源，對于云服務提供商來說，這可以更有效地利用這些新可用的CPU核心，實現(xiàn)更高的資源利用率。

低延遲和內(nèi)存效率：RDMA 繞過 Linux 內(nèi)核，直接將數(shù)據(jù)傳輸?shù)綉贸绦蚓彌_區(qū)，這一功能稱為零復制。這消除了在發(fā)送和接收端點節(jié)點處進行內(nèi)存復制的需要。內(nèi)核旁路和零拷貝功能可最大限度地減少延遲和抖動。

RoCEv2 RDMA 起源于高性能計算 (HPC)，并結(jié)合了 IB 傳輸協(xié)議。

| InfiniBand 和 ROCEv2 協(xié)議棧

RoCEv2 保留了 InfiniBand 語義及其傳輸和網(wǎng)絡協(xié)議，并將InfiniBand鏈路層和物理層替換為以太網(wǎng)。

因此，ROCEv2 RDMA 已成為數(shù)據(jù)中心后端網(wǎng)絡的標準，可提供高吞吐量、微秒范圍的低延遲和完整的 CPU 卸載。

注意：前端網(wǎng)絡通常運行 TCP/IP 或 QUIC 等其他協(xié)議。RDMA、InfiniBand 等協(xié)議作為后端網(wǎng)絡，通常被稱為東西向流量，占現(xiàn)代數(shù)據(jù)中心流量的 70-80%。

02以太網(wǎng) ROCEv2 挑戰(zhàn)

InfiniBand架構(gòu)

InfiniBand架構(gòu)是無損網(wǎng)絡，重點關(guān)注服務質(zhì)量 (QoS) 和傳輸層端到端信用。IB 協(xié)議棧非常適合 HPC 和 AI/ML 網(wǎng)絡。然而，InfiniBand 網(wǎng)絡通常比以太網(wǎng)更昂貴，可擴展性也更差。

注意：無損意味著底層網(wǎng)絡被配置為避免因網(wǎng)絡擁塞而導致數(shù)據(jù)包的丟失。盡管如此，偶爾仍可能會由于錯誤情況導致數(shù)據(jù)包損壞或丟失。在這種情況下，傳輸協(xié)議包括一種端到端的交付機制，其中內(nèi)置了數(shù)據(jù)包重傳邏輯，通常由硬件實現(xiàn)，以此在不需要軟件干預的情況下觸發(fā)，以恢復丟失的數(shù)據(jù)包。這確保了在網(wǎng)絡出現(xiàn)問題時可以自動糾正數(shù)據(jù)包的丟失，無需人工介入。

ROCEv2架構(gòu)

RoCEv2 在以太網(wǎng)鏈路上通過 UDP/IP 上運行。UDP 是一種不可靠的數(shù)據(jù)報服務，而以太網(wǎng)的架構(gòu)并非無損。由于 ROCEv2 期望底層網(wǎng)絡是無損的，因此在將以太網(wǎng)配置為無損網(wǎng)絡時面臨著多項挑戰(zhàn)，如下所述。

| ROCEv2 數(shù)據(jù)包格式

隊頭 (HOL) 阻塞：由于優(yōu)先流量控制 (PFC)，不同流中的數(shù)據(jù)包可能會被擁塞流阻塞，跨更大的網(wǎng)絡、跨多個交換機進行擴展成為一個挑戰(zhàn)。

擁塞管理：通常由軟件以帶外方式處理?，F(xiàn)有技術(shù)緩慢且復雜，一些供應商借用了 InfiniBand 的硬件技術(shù)，但這些是定制的，不是以太網(wǎng)標準的一部分。

減少有效吞吐量：以太網(wǎng)不是一個無損網(wǎng)絡。由于擁塞下降，可能會發(fā)生數(shù)據(jù)包丟失，這種數(shù)據(jù)包丟失會導致整個數(shù)據(jù)包窗口的重傳（稱為 Go-back-to-N），從而降低網(wǎng)絡“goodput”。

盡管存在這些挑戰(zhàn)，大型 ROCEv2 網(wǎng)絡已經(jīng)成功部署，但要求對其進行精細調(diào)優(yōu)和持續(xù)監(jiān)控。大多數(shù)超大規(guī)模企業(yè)都采用自定義、非標準的 ROCEv2 解決方案，并在針對不同工作負載微調(diào)RDMA堆棧方面投入了大量資金。

在某些情況下，組織甚至為 AI/ML 或存儲等特定應用程序建立了單獨的基于 ROCEv2 RDMA 的數(shù)據(jù)中心，但這也導致了運營成本的顯著增加。

接下來，我們將深入研究三個不同的案例，以便更全面地理解這一情況。

03大廠案例

微軟

十多年來，微軟一直在大型數(shù)據(jù)中心部署 RoCEv2，并發(fā)表了一篇見解深刻的Microsoft-RDMA-Challenges研究論文。微軟的部署面臨 PFC 死鎖挑戰(zhàn)、RDMA 傳輸活鎖挑戰(zhàn)以及其他網(wǎng)卡相關(guān)問題。

微軟認為，單靠協(xié)議理論不足以滿足現(xiàn)實世界的部署，嚴格的大規(guī)模測試、分階段部署和網(wǎng)卡供應商協(xié)作對于發(fā)現(xiàn)協(xié)議最初設計時隱藏的漏洞至關(guān)重要。微軟已經(jīng)為ROCEv2開發(fā)了自定義協(xié)議擴展，例如基于 DSCP 的 PFC，一些網(wǎng)卡/交換機供應商已經(jīng)支持該協(xié)議。此外，微軟還實施了用于健康跟蹤和故障排除的遙測系統(tǒng)，這對于識別這些隱藏的復雜性問題至關(guān)重要。

Oracle

OCI（Oracle Cloud Infrastructure，Oracle 云基礎設施）是一個公有云，可在同一 RDMA 網(wǎng)絡上運行 AI、HPC、數(shù)據(jù)庫和存儲等多種不同應用程序。

| Oracle RDMA 網(wǎng)絡結(jié)構(gòu)

Oracle 通過多種方法應對 ROCEv2 挑戰(zhàn)：

限制優(yōu)先級流控制 (PFC)：僅限于 3 層 Clos 網(wǎng)絡中的網(wǎng)絡邊緣。

網(wǎng)絡局部性提示：Oracle 根據(jù)網(wǎng)絡關(guān)聯(lián)性放置工作負載，以將大部分流量保持在本地，稱為網(wǎng)絡局部性提示。

微調(diào)擁塞控制：利用顯式擁塞通知 (ECN) 和 DC-QCN，每個都針對特定 RDMA 工作負載進行微調(diào)，以平衡延遲和吞吐量。

Meta

Meta 專注于針對 AI/ML 工作負載的 ROCEv2 RDMA 部署，正如Meta @Scale 2023活動視頻中所討論的那樣，主要工作負載包括推薦引擎、內(nèi)容理解和大語言模型（LLM），這些集群的規(guī)模從數(shù)百個 GPU 到數(shù)萬個 GPU不等。

有趣的是，Meta 并沒有面臨與微軟相同的挑戰(zhàn)。例如，由于骨干交換機中的深度緩沖區(qū)，PFC HOL 阻塞不再是問題。Meta 還成功地使用 DC-QCN 進行擁塞控制，并且由于現(xiàn)代 NIC 具有更大的 NIC 緩存，因此沒有面臨擴展問題?？偟膩碚f，由于具有先進功能的新硬件以及拓撲、工作負載和軟件策略的差異等多種原因，Meta 沒有遇到相同的問題。

Meta的關(guān)鍵挑戰(zhàn)主要圍繞負載均衡，這通過依靠 SDN 控制器對路由進行編程來解決。在網(wǎng)絡事件發(fā)生之前，這些路由不會更新。ECMP 哈希方案僅在網(wǎng)絡事件發(fā)生后生效?？缍鄠€隊列對 (QP) 的元多路復用流和定制的 ECMP 哈希方案以增加熵。

Meta 使用 PCIe 點對點 (P2P) DMA 技術(shù)，通過支持跨 GPU 的直接數(shù)據(jù)傳輸來提高應用程序性能。

Meta 還超額訂閱了主干層，因為 AI/ML 流量模式不需要完整的非阻塞主干連接。這降低了數(shù)據(jù)中心成本。

與許多其他公司一樣，Meta 正在探索數(shù)據(jù)包噴射、基于分解 VOQ 的交換機以及可以容忍亂序交付的自定義傳輸協(xié)議。

一篇MIT + Meta 研究論文《針對 LLM 的優(yōu)化網(wǎng)絡架構(gòu)》提出了一種針對 LLM 流量模式的新網(wǎng)絡架構(gòu)，可以將網(wǎng)絡成本削減 37% - 75%。該架構(gòu)為具有高通信需求的 GPU 定義了高帶寬或 HB 域。在 HB 內(nèi)，GPU 通過任意對任意互連進行互連。在Meta部署中，跨HB網(wǎng)絡流量稀疏，可以消除跨HB域的連接和交換機，從而降低網(wǎng)絡成本。

04RDMA 的未來

超大規(guī)模廠商和供應商都以自定義的方式解決了 ROCEv2 的潛在問題。ROCEv2 網(wǎng)絡仍然需要針對每個工作負載進行定制和微調(diào)。

1RMA 擴展框架

具有多個租戶的公共云需要大規(guī)模擴展，達到數(shù)百萬個節(jié)點和數(shù)十億個流。由于 ROCEv2 面向連接的特性，工作隊列條目 (WQE) 通常在硬件中實現(xiàn)，這限制了流量擴展。跨多個租戶的安全性和線速加密給 RoCEv2 帶來了額外的挑戰(zhàn)。

| 消費者排隊模型

云數(shù)據(jù)中心的一個替代方案是1RMA 論文中記錄的 1-Shot 遠程內(nèi)存訪問 (1RMA) 方法，該方法建議以軟件為中心的重新架構(gòu)。由于片上系統(tǒng) (SoC)處理器內(nèi)核現(xiàn)在可在基于 DPU/IPU 的網(wǎng)絡適配器上運行軟件，因此這種以軟件為中心的方法變得更加可行。主要思想是：

軟件重點：將一些傳統(tǒng)的網(wǎng)卡硬件數(shù)據(jù)結(jié)構(gòu)（例如排隊、數(shù)據(jù)包排序、數(shù)據(jù)包調(diào)步和擁塞控制）轉(zhuǎn)移到軟件中。

硬件重點：將網(wǎng)卡硬件重點放在主數(shù)據(jù)路徑、DMA 傳輸、incast 邊界、身份驗證和加密上。硬件無需連接，并向軟件提供細粒度的延遲測量和故障通知。

1RMA 方法主張將連接和大部分狀態(tài)轉(zhuǎn)移到軟件中，以獲得更好的可擴展性。這簡化了硬件并支持公共云所需的大規(guī)模擴展。

請注意，采用 1RMA 方法可能需要從頭開始重新架構(gòu)，涉及新協(xié)議和 NIC 硬件。此外，1RMA 的研究重點是云數(shù)據(jù)中心的需求；AI/ML 和 HPC 網(wǎng)絡可能需要不同的權(quán)衡。

UEC聯(lián)盟

UEC聯(lián)盟提議用基于UDP/IP的新開放協(xié)議取代ROCEv2。UEC 的重點是 AI/ML 和 HPC 網(wǎng)絡。

# ROCEv2 替代協(xié)議的關(guān)鍵屬性

多路徑和數(shù)據(jù)包噴射

靈活的交付順序和選擇性重傳

響應式擁塞控制機制

規(guī)模更大、穩(wěn)定可靠

堆棧的所有層可能都需要進行更改。

UEC聯(lián)盟白皮書中的一些主題確實與1RMA Paper和EDQS Paper(由Correct Networks撰寫，被Broadcom收購)產(chǎn)生了共鳴。

在10 月 17 日的OCP峰會上，OCP與 UEC 達成合作，利用兩家組織的專業(yè)技能來提高AI工作負載的以太網(wǎng)性能。已確定初步探索潛在合作的領域包括 OCP交換機抽象接口（SAI）、OCP Caliptra Workstream、OCP網(wǎng)絡項目、OCP網(wǎng)卡Workstream、OCP Time Appliance項目和OCP未來技術(shù)倡議。

未來的開放標準

到目前為止，還沒有 ROCEv3 標準。針對這些挑戰(zhàn)的可擴展、通用和開放的解決方案仍然難以實現(xiàn)。

AI/ML、HPC 和云數(shù)據(jù)中心工作負載的需求可能差異很大，以至于我們需要多種解決方案。例如，

# UEC聯(lián)盟

UltraEthernet 聯(lián)盟僅專注于大規(guī)模人工智能和高性能計算。

# 工作負載特征

HPC 要求超低延遲，而 AI/ML 訓練優(yōu)先考慮高吞吐量和低尾延遲。

# 多種拓撲

公共云通常使用 2 層或 3 層 Clos 網(wǎng)絡，而 AI/HPC 網(wǎng)絡可能采用蜻蜓、3D 環(huán)面或超立方體拓撲，這些仍在不斷發(fā)展。

# 不斷變化的需求

AI/ML 算法不斷發(fā)展，云數(shù)據(jù)中心工作負載也在不斷發(fā)展，這可能會導致未來進一步分化。

# 開放與封閉

云數(shù)據(jù)中心可以繼續(xù)使用定制解決方案或在 OCP 等論壇中協(xié)作來定義開放標準。

如果出現(xiàn)多種開放解決方案，協(xié)作可以幫助建立統(tǒng)一的基礎架構(gòu)。這將防止解決方案出現(xiàn)分歧以及相關(guān)的成本問題。雖然具有挑戰(zhàn)性，但重要性不言而喻。

新標準需要時間才能成熟。定義后，硬件開發(fā)可能需要長達兩年的時間，然后是規(guī)模測試和錯誤修復，這讓時間線又增加了幾年。短期內(nèi)，預計主要參與者將繼續(xù)進行定制創(chuàng)新。

05結(jié) 論

雖然有多種定制和復雜的方法可以解決 ROCEv2 的挑戰(zhàn)，但業(yè)界正在積極探索基于開放標準的 ROCEv2 RDMA 替代方案。未來的 RDMA 協(xié)議必須發(fā)展成為適用于廣泛工作負載的“即插即用”解決方案，就像今天的 TCP 一樣。

最后，DPU/IPU與內(nèi)置SOC正在徹底改變我們對網(wǎng)絡的看法，它們使我們能夠重新定義硬件-軟件邊界，直接在網(wǎng)絡硬件上運行關(guān)鍵軟件，使我們的系統(tǒng)變得靈活且面向未來。

審核編輯：湯梓紅