RDMA(遠(yuǎn)程直接內(nèi)存訪問(wèn))傳輸協(xié)議概述和應(yīng)用案例

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

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

01RDMA概述

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

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

低延遲和內(nèi)存效率：RDMA 繞過(guò) Linux 內(nèi)核，直接將數(shù)據(jù)傳輸?shù)綉?yīng)用程序緩沖區(qū)，這一功能稱為零復(fù)制。這消除了在發(fā)送和接收端點(diǎn)節(jié)點(diǎn)處進(jìn)行內(nèi)存復(fù)制的需要。內(nèi)核旁路和零拷貝功能可最大限度地減少延遲和抖動(dòng)。

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

| InfiniBand 和 ROCEv2 協(xié)議棧

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

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

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

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

InfiniBand架構(gòu)

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

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

ROCEv2架構(gòu)

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

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

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

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

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

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

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

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

03大廠案例

微軟

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

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

Oracle

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

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

Oracle 通過(guò)多種方法應(yīng)對(duì) ROCEv2 挑戰(zhàn)：

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

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

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

Meta

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

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

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

Meta 使用 PCIe 點(diǎn)對(duì)點(diǎn) (P2P) DMA 技術(shù)，通過(guò)支持跨 GPU 的直接數(shù)據(jù)傳輸來(lái)提高應(yīng)用程序性能。

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

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

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

04RDMA 的未來(lái)

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

1RMA 擴(kuò)展框架

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

| 消費(fèi)者排隊(duì)模型

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

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

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

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

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

UEC聯(lián)盟

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

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

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

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

響應(yīng)式擁塞控制機(jī)制

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

堆棧的所有層可能都需要進(jìn)行更改。

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

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

未來(lái)的開放標(biāo)準(zhǔn)

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

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

# UEC聯(lián)盟

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

# 工作負(fù)載特征

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

# 多種拓?fù)?/strong>