近期打算提綱挈領(lǐng)地整理一下工業(yè)界已經(jīng)使用起來或有潛力使用起來的大規(guī)模RDMA相關(guān)技術(shù)，供大家參考，也為自己梳理一下脈絡(luò)。里面每一章甚至每一節(jié)的內(nèi)容都可以單獨(dú)寫成一篇文章，待后續(xù)點(diǎn)贊情況和評論情況再進(jìn)行更新，也歡迎學(xué)界和業(yè)界的各位同行朋友批評指正，多提寶貴意見。注：此技術(shù)雜談面向有一定網(wǎng)絡(luò)和系統(tǒng)基礎(chǔ)的同學(xué)。
RDMA技術(shù)調(diào)研
RDMA技術(shù)專題匯總（1）
RDMA技術(shù)專題匯總（2）
作者簡介：
本章主要介紹3種RDMA協(xié)議（InfiniBand、RoCE(v2)、iWARP）、RDMA和TCP的異同（Protocol Offload、Zero Copy、OS by-pass）、RDMA傳輸原語（Send、Receive、RDMA Read、RDMA Write，Atomic），傳輸類型（RC、UC、UD）和核心基礎(chǔ)概念（e.g., SR、RR、CQ、MR、MW、PD），參考RDMA Aware Networks Programming User Manual可以參考我搞的一個(gè)簡單的RDMA Toturial2、大規(guī)模RDMA的關(guān)鍵網(wǎng)絡(luò)技術(shù)為了讓上層業(yè)務(wù)能充分利用RDMA帶來的高性能能力，RDMA需要正確配置、使用一系列關(guān)鍵網(wǎng)絡(luò)技術(shù)，并根據(jù)業(yè)務(wù)場景的需求，做相應(yīng)的調(diào)整和優(yōu)化。本章主要介紹網(wǎng)絡(luò)層次的關(guān)鍵技術(shù)，如擁塞控制算法、無損網(wǎng)絡(luò)到有損網(wǎng)絡(luò)的演進(jìn)、RDMA多路徑傳輸等。這些都是網(wǎng)絡(luò)同學(xué)必須了解甚至熟練掌握的技術(shù)。2.1 RDMA擁塞控制算法
經(jīng)典RDMA需要配置Priority Flow Control (PFC)來保證不丟包，進(jìn)而形成無損網(wǎng)絡(luò)以實(shí)現(xiàn)高性能。然而，PFC是一種粗粒度機(jī)制。它以端口（或端口加優(yōu)先級）級別運(yùn)行，不區(qū)分流。這可能會(huì)導(dǎo)致?lián)矶侣蝇F(xiàn)象（congestion-spreading），進(jìn)而有不公平現(xiàn)象、受害者流、PFC deadlock、PFC storm等一系列性能問題。緩解PFC缺陷的根本性方案是使用一個(gè)流級別（per-flow）的擁塞控制算法。擁塞控制算法的本質(zhì)是，網(wǎng)絡(luò)路徑上的交換機(jī)對流量擁塞情況進(jìn)行標(biāo)記，攜帶擁塞標(biāo)記信號的報(bào)文到達(dá)接收者后，再被傳回發(fā)送者由其根據(jù)網(wǎng)絡(luò)擁塞情況進(jìn)行調(diào)速，確保既要避免網(wǎng)絡(luò)過度擁塞，又要充分地利用網(wǎng)絡(luò)帶寬（當(dāng)然不同場景對公平性的要求不盡相同，有些場景需要對所有流公平對待，有些場景希望對小流友好一些）。在RDMA中，由于主機(jī)側(cè)的傳輸層協(xié)議大部分位于網(wǎng)卡上，因?yàn)檎{(diào)速基本都是在網(wǎng)卡上進(jìn)行的。要想讓業(yè)務(wù)/應(yīng)用能夠真正RDMA的高性能優(yōu)勢，設(shè)計(jì)、使用和配置符合業(yè)務(wù)場景需求的擁塞控制算法是重中之重。- DCQCN算法：目前Mellanox網(wǎng)卡支持的主要擁塞控制算法，由微軟和Mellanox聯(lián)合研發(fā)，在交換機(jī)上以ECN為擁塞標(biāo)記信號，發(fā)送者在主機(jī)網(wǎng)卡側(cè)根據(jù)ECN標(biāo)記情況來推測網(wǎng)絡(luò)擁塞情況，實(shí)現(xiàn)了一種基于速率（rate-based）的調(diào)速方法，是目前Mellanox RDMA網(wǎng)卡商業(yè)上直接可用、使用最為廣泛的擁塞控制算法。算法主要思想?yún)⒖?/span>Congestion Control for Large-Scale RDMA Deployments，SIGCOMM 2015
- TIMELY和Swift算法：Google數(shù)據(jù)中心中使用的擁塞控制算法，交換機(jī)不需要做額外的支持，發(fā)送者在主機(jī)網(wǎng)卡上對端到端往返延遲（RTT）進(jìn)行測量，基于RTT的變化進(jìn)行梯度計(jì)算，進(jìn)而根據(jù)梯度實(shí)現(xiàn)了基于速率（rate-based）的調(diào)速方法。目前主要是在Google內(nèi)部使用，依賴于Google的自研網(wǎng)卡。算法思想?yún)⒖糡IMELY: RTT-based Congestion Control for the Datacenter，SIGCOMM 2016和Swift: Delay is Simple and Effective for Congestion Control in the Datacenter，SIGCOMM 2020
- HPCC算法：阿里網(wǎng)絡(luò)研究團(tuán)隊(duì)研發(fā)出的擁塞控制算法，使用INT攜帶網(wǎng)絡(luò)擁塞情況，發(fā)送者在主機(jī)網(wǎng)卡側(cè)實(shí)現(xiàn)了一種基于窗口（window-based）的調(diào)速方法。受限于INT的精度、網(wǎng)卡實(shí)現(xiàn)的復(fù)雜性和對可編程交換機(jī)的依賴，HPCC目前應(yīng)該只是停留在論文階段，未有大規(guī)模部署。算法思想?yún)⒖糎PCC: High Precision Congestion Control，SIGCOMM 2019
- 其他網(wǎng)卡的算法：Broadcom RDMA網(wǎng)卡上擁塞控制算法采取了類似于DCTCP算法的變種，算法具體可以參考Data Center TCP (DCTCP)，SIGCOMM，這里不再詳細(xì)描述。
2.2 無損網(wǎng)絡(luò)（Lossless）到有損網(wǎng)絡(luò)（Lossy）的演進(jìn)
傳統(tǒng)的RDMA跑在InfiniBand（IB）網(wǎng)絡(luò)上，IB鏈路層使用逐跳的、基于credit的流控，丟包非常罕見。而在數(shù)據(jù)中心中，RDMA則需要跑在三層IP網(wǎng)絡(luò)之上，即RoCEv2。RoCEv2保留了IB傳輸層，但是使用IP和UDP封裝替換了IB的網(wǎng)絡(luò)層，其中IP層用來路由，UDP層用來進(jìn)行ECMP。由于歷史性的RDMA網(wǎng)卡（e.g., CX-3, CX-4, CX-5）的傳輸層處理丟包很不高效，如接收端會(huì)丟棄所有的out-of-order packets、發(fā)送端需要重傳上一個(gè)acked packet后的所有packets（go-back-N機(jī)制），RoCEv2需要無損網(wǎng)絡(luò)（Lossless）來保證高性能。無損網(wǎng)絡(luò)的核心是在交換機(jī)和網(wǎng)卡上使能Priority Flow Control (PFC)。PFC允許以太網(wǎng)交換機(jī)通過強(qiáng)制直接上游實(shí)體（另一個(gè)交換機(jī)或主機(jī)網(wǎng)卡）暫停數(shù)據(jù)傳輸來避免緩沖區(qū)溢出。然而，PFC是一種粗粒度機(jī)制。它以端口（或端口加優(yōu)先級）級別運(yùn)行，不區(qū)分流。這可能會(huì)導(dǎo)致?lián)矶侣蝇F(xiàn)象（congestion-spreading），進(jìn)而有不公平現(xiàn)象、受害者流、PFC deadlock、PFC storm等一系列性能問題。盡管有一系列擁塞控制算法（如2.1所講）來緩解PFC帶來的問題，但是PFC并不能從根本上消除。這是因?yàn)樵谝粋€(gè)端到端路徑中，擁塞標(biāo)記信號需要先經(jīng)過數(shù)跳交換機(jī)到達(dá)接受者，再被CNP攜帶著穿越數(shù)跳交換機(jī)回到發(fā)送者，發(fā)送者才能降低自己的發(fā)送速率，這中間需要至少一個(gè)端到端往返時(shí)間（RTT）。而在這個(gè)往返時(shí)間內(nèi)，發(fā)送者可能仍然在提高發(fā)送速率，PFC仍然可能會(huì)被觸發(fā)。尤其在規(guī)模更大、跳數(shù)較多的網(wǎng)絡(luò)中，PFC的問題仍然會(huì)出現(xiàn)，給網(wǎng)絡(luò)運(yùn)營帶來了較大的穩(wěn)定性風(fēng)險(xiǎn)。隨著新一代RDMA網(wǎng)卡（e.g., CX-6, CX-7）片上資源的增加，不依賴于PFC的RoCEv2網(wǎng)絡(luò)成為了可能。相比于上一代的RDMA網(wǎng)卡，新一代的RDMA網(wǎng)卡上在片上實(shí)現(xiàn)了更為高效的丟包恢復(fù)機(jī)制和更好的端到端流控來約束in-flight數(shù)據(jù)包，從而讓Lossy的性能有潛力不輸于Lossless！這也將有潛力把RDMA推廣到規(guī)模更大、跳數(shù)更多的網(wǎng)絡(luò)中。核心思想?yún)⒖糝evisiting Network Support for RDMA，SIGCOMM 20182.3 RDMA多路徑傳輸
在RDMA的大規(guī)模組網(wǎng)中，常常基于Fat-Tree的Clos架構(gòu)進(jìn)行組網(wǎng)，從而接入更多的服務(wù)器?；贔at-Tree的Clos架構(gòu)的基本理念是使用大量的商用交換機(jī)，在服務(wù)器之間構(gòu)造出多個(gè)等價(jià)路徑（multiple path），進(jìn)而形成大規(guī)模的無阻塞網(wǎng)絡(luò)。但是在實(shí)際流量的路徑選擇時(shí)，交換機(jī)只是對流（flow）進(jìn)行Equal Cost Multi-Path（ECMP）實(shí)現(xiàn)負(fù)載均衡，當(dāng)流的數(shù)目比較少且大流較多時(shí)，往往會(huì)造成路徑?jīng)_撞，進(jìn)而導(dǎo)致鏈路帶寬無法被充分利用。這里面的本質(zhì)原因是因?yàn)镋CMP是一個(gè)無狀態(tài)的局部決策，當(dāng)流的數(shù)量比較少且大流較多時(shí)，很容易hash到同一個(gè)路徑上。尤其在有網(wǎng)絡(luò)鏈路發(fā)生故障時(shí)，會(huì)導(dǎo)致基于Fat-Tree的Clos架構(gòu)的不對稱性，進(jìn)而造成業(yè)務(wù)性能較大程度的下降。- 采取Multi-path RDMA的思路，即以數(shù)據(jù)包為粒度把一個(gè)流分散到多個(gè)等價(jià)路徑上，再在網(wǎng)卡硬件上實(shí)現(xiàn)大部分的Multi-path傳輸層邏輯，如擁塞感知的流量切分、解決接收端亂序等問題。具體思想?yún)⒖嘉④泚喲性旱墓ぷ鱉ulti-Path Transport for RDMA in Datacenters，NSDI 2018
- 仍然是采用把一個(gè)流分散到多個(gè)等價(jià)路徑上，形成多個(gè)subflow（e.g., flowlet, flowcell），來實(shí)現(xiàn)更好的均衡性進(jìn)而提高多鏈路的利用率。但是，這里不再在接收端的硬件網(wǎng)卡上解決亂序（out-of-order）問題，而是把這一功能放到軟件層，如網(wǎng)卡驅(qū)動(dòng)或者通訊庫里面，具體思想?yún)⒖紒嗰R遜的SRD。
- 根據(jù)業(yè)務(wù)場景特性和流量模型特性，進(jìn)行智能路由選路。如在AI訓(xùn)練的場景中，由于流量模型具有所有流大小相同、同時(shí)發(fā)起同時(shí)結(jié)束的屬性，可以采用類似阿里ACCL的思路，進(jìn)行基于源端口的有序規(guī)劃，實(shí)現(xiàn)基于探測的擁塞感知的路由控制算法。
RDMA虛擬化主要用于想將RDMA用到云上的場景，代表性工作有微軟的FreeFlow: Software-based Virtual RDMA Networking for Containerized Clouds，NSDI 2019和華為的MasQ: RDMA for Virtual Private Cloud，SIGCOMM 2020。為了讓上層業(yè)務(wù)更好的使用RDMA帶來的高性能，業(yè)務(wù)需要在通訊中間件上做出一定程度的適配。這一章主要介紹RDMA在機(jī)器學(xué)習(xí)訓(xùn)練和高性能存儲(chǔ)兩個(gè)領(lǐng)域的通訊中間件情況。這部分需要網(wǎng)絡(luò)同學(xué)和業(yè)務(wù)同學(xué)共同努力，才能拿到更好的效果。4.1 RDMA在機(jī)器學(xué)習(xí)訓(xùn)練領(lǐng)域的應(yīng)用
RDMA服務(wù)于機(jī)器學(xué)習(xí)訓(xùn)練業(yè)務(wù)主要體現(xiàn)在各種集合通訊庫上，以NVIDIA的NCCL通訊庫最具有代表性，當(dāng)然Facebook也搞出了一個(gè)Gloo通訊庫。各家大廠也搞出了一些變種，以滿足自己AI訓(xùn)練框架的特殊需求：- Google：github.com/google/nccl-
- Microsoft：github.com/microsoft/ms
- facebook：github.com/facebookincu
- AWS：github.com/aws/aws-ofi-
- 華為：HCCL - Atlas Data Center Solution V100R020C00 中心訓(xùn)練解決方案概述 01 - 華為
4.2 RDMA在存儲(chǔ)領(lǐng)域的應(yīng)用
RDMA應(yīng)用于存儲(chǔ)領(lǐng)域也需要通訊中間件，可以參考阿里的X-RDMA: Effective RDMA Middleware in Large-scale Production Environments，CLUSTER 2019（2）NVMe-over-Fabric（NVMe-oF）4.3 在AI、存儲(chǔ)等業(yè)務(wù)場景充分發(fā)揮RDMA潛力的小tips
如何在不同的業(yè)務(wù)場景、結(jié)合應(yīng)用的獨(dú)特特性，充分發(fā)揮RDMA的性能優(yōu)勢也是一個(gè)很大的課題。這里面有一系列編程上、verbs使用上的技巧，也有一大批文章去針對各類應(yīng)用做針對性優(yōu)化。- Using RDMA Ef?ciently for Key-Value Services，SIGCOMM 2014，如何根據(jù)key-value store的特性更加合理地使用RDMA原語，讓其在RDMA網(wǎng)絡(luò)上能降低延遲和提高吞吐
- FaRM: Fast Remote Memory，NSDI 2014
- Fast In-memory Transaction Processing using RDMA and HTM，SOSP 2015
5、RDMA性能優(yōu)化、監(jiān)控和運(yùn)維5.1 RDMA性能優(yōu)化
相比于傳統(tǒng)TCP/IP，目前RDMA基本都使用在對網(wǎng)絡(luò)性能有極致需求的場景。因此，在業(yè)務(wù)使用RDMA時(shí)，與傳統(tǒng)TCP/IP往往有以下幾個(gè)區(qū)別：一是為了追求高性能，業(yè)務(wù)在使用RDMA時(shí)往往會(huì)打破以前的分層架構(gòu)，業(yè)務(wù)的通訊邏輯多直接使用網(wǎng)卡提供的verbs原語，導(dǎo)致業(yè)務(wù)代碼、通訊代碼等耦合在一起，很難去分開；這不像傳統(tǒng)的TCP/IP，業(yè)務(wù)多基于內(nèi)核協(xié)議棧提供的socket來進(jìn)行編程。二是在追求極致性能時(shí)，服務(wù)器內(nèi)部的PCIe通訊、操作系統(tǒng)調(diào)度開銷等瓶頸常常會(huì)顯露出來，而這些問題在傳統(tǒng)TCP/IP下沒有這么嚴(yán)重。這兩個(gè)區(qū)別，給RDMA業(yè)務(wù)系統(tǒng)的性能異常診斷、定位和優(yōu)化帶來了很大的挑戰(zhàn)。為了了解應(yīng)用/業(yè)務(wù)的流量模型是否會(huì)觸發(fā)RDMA系統(tǒng)的異常性能行為，字節(jié)跳動(dòng)設(shè)計(jì)了Collie工具，來幫助開發(fā)者自動(dòng)發(fā)現(xiàn)和定位基于RDMA的業(yè)務(wù)/應(yīng)用系統(tǒng)的性能異常。Collie使用改進(jìn)的模擬退火算法，把RDMA相關(guān)的性能和診斷計(jì)數(shù)器引導(dǎo)向極端區(qū)域，從而來發(fā)現(xiàn)會(huì)導(dǎo)致性能異常的流量模型。具體思想可以見Collie: Finding Performance Anomalies in RDMA Subsystems，NSDI 2022此外，在日常的工作中，我個(gè)人也總結(jié)了一些性能優(yōu)化的經(jīng)驗(yàn)：（1）網(wǎng)卡（服務(wù)器端）是RDMA業(yè)務(wù)系統(tǒng)正常工作、拿到性能收益的關(guān)鍵- 網(wǎng)卡承載了RDMA功能里面最復(fù)雜的部分，包括RDMA verbs、rkey校驗(yàn)、地址映射、RDMA傳輸層協(xié)議（go-back-N，congestion control）；而交換機(jī)的功能則相對簡單（PFC、ECN）
- 網(wǎng)卡上的資源非常受限，需要使用服務(wù)器的DRAM來存儲(chǔ)它的數(shù)據(jù)結(jié)構(gòu)，而只是用自己的本地DRAM作為cache；而cache管理非常復(fù)雜，經(jīng)常會(huì)引入性能問題（e.g.，cache換入換出引發(fā)slow-receiver symptom）
（2）打破網(wǎng)絡(luò)、服務(wù)器、系統(tǒng)邊界，聯(lián)合優(yōu)化，對RDMA系統(tǒng)極致性能的發(fā)揮至關(guān)重要，一系列復(fù)雜的系統(tǒng)因素，比如cache/內(nèi)存管理使用、verbs原語使用、機(jī)內(nèi)通訊等，都會(huì)影響RDMA系統(tǒng)的性能表現(xiàn)5.2 RDMA監(jiān)控和運(yùn)維
除了像傳統(tǒng)TCP/IP的秒級常態(tài)監(jiān)控外，RDMA也需要細(xì)粒度毫秒級的網(wǎng)絡(luò)監(jiān)控，同時(shí)在日常運(yùn)維中也需要對一些無損網(wǎng)絡(luò)里面的相關(guān)指標(biāo)進(jìn)行關(guān)注，如PFC、ECN、CNP、NACK等。Amazon的SRD和EFA是這方面的代表，參考A Cloud-Optimized Transport Protocol for Elastic and Scalable HPC，IEEE Mirco 20207、業(yè)界RDMA部署經(jīng)驗(yàn)分享7.1 微軟的RDMA部署經(jīng)驗(yàn)
微軟是全球最早大規(guī)模部署RoCEv2的公司，他們系統(tǒng)介紹了他們在大規(guī)模部署、運(yùn)維RoCEv2時(shí)遇到的問題，如transport livelock、PFC deadlock、PFC pause storm和slow-receiver symptom等，參考RDMA over Commodity Ethernet at Scale，SIGCOMM 2016。這篇文章信息量很大，干貨很多，也很清晰，建議認(rèn)真閱讀。7.2 阿里巴巴的RDMA在存儲(chǔ)業(yè)務(wù)上的部署經(jīng)驗(yàn)
阿里系統(tǒng)介紹了他們在存儲(chǔ)集群Pangu上部署、運(yùn)維RDMA時(shí)遇到的問題以及相應(yīng)的解法，參考 When Cloud Storage Meets RDMA，NSDI 2021。相比微軟的文章，這篇文章干貨相對較少。作為網(wǎng)絡(luò)領(lǐng)域近年來新興的一個(gè)技術(shù)方向，RDMA自誕生以來，在AI訓(xùn)練和高性能存儲(chǔ)領(lǐng)域體現(xiàn)了巨大的潛力，給應(yīng)用和業(yè)務(wù)帶來了真金白銀的收益。未來，RDMA能力如何從pod級別到全網(wǎng)級別、RDMA業(yè)務(wù)系統(tǒng)如何進(jìn)行性能優(yōu)化以最大化利用RDMA的性能優(yōu)勢、存量應(yīng)用如何能盡量無縫遷移至RDMA、完整的RDMA系統(tǒng)的診斷和監(jiān)測能力如何低開銷輕量級實(shí)現(xiàn)，都是亟待解決的有價(jià)值問題。下載鏈接：
RDMA技術(shù)專題匯總（1）
RDMA技術(shù)專題匯總（2）
超融合數(shù)據(jù)中心網(wǎng)絡(luò)
中國聯(lián)通的開放網(wǎng)絡(luò)研究與實(shí)踐
中國聯(lián)通開放硬件網(wǎng)絡(luò)設(shè)備白皮書
1、掘金云數(shù)據(jù)中心白盒化趨勢.pdf2、商用交換芯片SDN支持現(xiàn)狀分析.pdf3、未來網(wǎng)絡(luò)白皮書——白盒交換機(jī)技術(shù)白皮書.pdf4、協(xié)議無關(guān)交換機(jī)架構(gòu)技術(shù)與應(yīng)用白皮書.pdf5、中國聯(lián)通開放硬件網(wǎng)絡(luò)設(shè)備白皮書.pdf6、中興通訊CO重構(gòu)技術(shù)白皮書.pdf來源：全棧云技術(shù)架構(gòu)，加入全棧云技術(shù)知識星球下載全部資料。
???????????????? ?END ?????????????????
轉(zhuǎn)載申明：轉(zhuǎn)載本號文章請注明作者和來源，本號發(fā)布文章若存在版權(quán)等問題，請留言聯(lián)系處理，謝謝。
推薦閱讀
更多架構(gòu)相關(guān)技術(shù)知識總結(jié)請參考“架構(gòu)師全店鋪技術(shù)資料打包”相關(guān)電子書(37本技術(shù)資料打包匯總詳情可通過“閱讀原文”獲取)。
全店內(nèi)容持續(xù)更新，現(xiàn)下單“全店鋪技術(shù)資料打包(全)”，后續(xù)可享全店內(nèi)容更新“免費(fèi)”贈(zèng)閱，價(jià)格僅收198元(原總價(jià)350元)。
溫馨提示：
掃描二維碼關(guān)注公眾號，點(diǎn)擊閱讀原文鏈接獲取“架構(gòu)師技術(shù)全店資料打包匯總(全)”電子書資料詳情。
