阿里云是如何使用RDMA技術

作者：李豪 ? ? RDMA(remote direct memory access)即遠端直接內存訪問，是一種高性能網絡通信技術，具有高帶寬、低延遲、無CPU消耗等優點。RDMA相比TCP在性能方面有明顯的優勢，但在編程復雜度上RDMA verbs卻比TCP socket復雜一個數量級。 ? 開源社區和各大云廠商在RDMA通信庫方面都有不少嘗試，今天我們精讀阿里云的RDMA通信庫論文X-RDMA: Effective RDMA Middleware in Large-scale Production Environments，來看看阿里云是如何使用RDMA技術的。 ?

? 01 摘要和背景介紹

? (2019年)RDMA技術在數據中心越來越受歡迎，當前最新的ConnectX-6 Infiniband網卡可以支持200Gbps的帶寬和極低的延遲（0.6微妙）。RDMA技術也在越來越多的系統中得到應用，比如KV存儲、文件系統、圖計算等。 ? 但是在規模生產環境中，RDMA的實際收益還不夠明顯，一個重要原因是RDMA編程復雜性太高，想用好它很難，RDMA verbs編程有一堆的新概念（QP，MR，PD，RQ，SQ，CQ，……），這根傳統socket編程迥異。想要直接把已有應用直接遷移到RDMA更是不可能。 ? 使用RDMA需要解決以下問題： ?

問題定位困難

大規模集群中存在性能抖動和擁塞

大消息會增加incast擁塞概率

本文分享我們關于大規模RDMA部署的經驗，以及如何啟發我們設計出RDMA通信中間件X-RDMA。X-RDMA很多功能是業務需求推動的，比如穩健性、高效的資源管理以及用于調試和性能調整的便捷工具。 ? X-RDMA已經在阿里大量使用近兩年（16年至今），幾乎所有的基于RDMA的應用都在使用X-RDMA，包括云數據庫和存儲系統。X-RDMA收益如下： ?

網絡吞吐提升24%

網絡延遲降低5%（相比于ucx-am-rc）

RDMA的編程模型

原生以太網無法滿足我們的網絡性能要求，而RDMA可以提供： ?

超低延遲(2微秒)

高吞吐

零拷貝

不經過內核

因此RDMA可以降低傳統TCP協議棧的1. 上下文切換開銷，2. 協議處理開銷，3. 數據拷貝開銷。 ? RDMA提供RC、UD、RD等多種連接，同時提供兩類數據語義： ?

單邊語義：Write/Read/Atomic，這類語義不需要對端CPU參與。

雙邊語義：Send/Recv，這類語義跟傳統以太網有些相似，需要對端CPU配合做一些事情（但不需要CPU做協議棧處理）。

RDMA verbs編程有一堆的新概念，跟socket編程迥異。使用verbs編寫一個簡單的echo server/client程序需要200行以上，流程十分繁瑣。 ?

阿里的數據中心網絡部署

阿里數據中心網絡是基于以太網的clos網絡，由三層交換機組成，分別是spine、leaf、ToR，拓撲如下： ?

? 每個ToR下面有40個節點，每臺機器有一張雙口網卡，上聯兩臺ToR。 ?

阿里的RDMA使用場景

RDMA有三種實現方式： ?

Infiniband

RoCE/RoCEv2

iWARP

目前數據中心廣泛使用的是RoCEv2，RoCEv2依賴PFC保證網絡無損，同時通過DCQCN做到端到端的擁塞的控制。 ? 本論文主要介紹三個阿里有代表性的應用：ESSD、XDB、PolarDB。Pangu一個阿里云開發的高可靠、高可用、高性能的分布式文件系統，類似于Ceph。Pangu中每個服務器上有兩個核心組件：block server和chunk server。 ? block server從前端接收數據（ESSD、XDB等），然后將數據以三副本形式分發給不同機器上的chunck server。block server和chunk server通過RDMA進行fullmesh通信。

? 02 大規模生產環境遇到的問題 ? 大規模生產環境使用RDMA主要遇到以下問題： ? RDMA編程復雜：verbs編程比socket編程復雜很多，一個簡單的ping-pong程序RDMA需要200行代碼，而socket只需要50行。 ? RDMA可擴展性挑戰：主要體現在幾個方面：a. RDMA資源占用會隨著集群規模增加，比如連接數和內存的占用。Pangu中每個block server上有N個線程，每個chunk server上有M個線程，而每兩個線程之間都要建立fullmesh的鏈接，換算下來每個chunk server的內存占用為： ? ?

? b. 大規模RDMA集群存在擁塞和嚴重的incast。c. 建聯速度太慢，通過rdmacm建聯平均需要花4毫秒，而TCP只需要100微秒。 ? RDMA健壯性問題：體現在 a. RDMA單邊操作無法感知對端應用層的處理狀態，這給內存管理帶來挑戰，因為對端接收完成之前發送方的buffer不能釋放，兩邊配合不好會導致RNR出現。b. RDMA無法感知通信的對端是否還活著（這一點跟TCP很不同，TCP會有內核做鏈接?；?，RDMA是kernel by pass的，即使對端掛了，本地也不會受到任何通知），這會導致鏈接泄露，跟這個鏈接相關的資源也無法釋放。 ? RDMA問題排查工具缺失：RDMA沒有類似netstat和pingmesh之類的工具，也沒有類似netfilter的工具。 ? 基于以上挑戰我們設計了X-RDMA通信庫。 ? ? 03 X-RDMA設計思想

整體架構

X-RDMA有三層抽象，包含16個核心組件： ? 最上層：提供簡單的數據結構和API抽象，屏蔽RDMA verbs編程復雜性。 ? 中間層：提供1. 可靠的協議拓展（KeepAlive），2. 資源管理（qp管理，內存管理，消息管理等），3. flow control， 4. 性能分析工具（trace, statistic, config, filter, mock, monitor）等功能。 ? 底層：timer、task、fd數據結構。

?

X-RDMA API ?

線程模型

X-RDMA采用run-to-complete線程模型，從而避免了數據路徑上鎖/原子變量/系統調用的使用，代價就是所有的核心資源都是線程粒度的，即每個線程都要有單獨的內存池、鏈接池等。導致的后果就是內存占用和連接數的膨脹。但在存儲場景下為了更好的性能多使用一些資源是可以接受的。 ? 思考：存儲之外的場景適合使用R2C的設計嗎？ ? X-RDMA混合使用epoll和busy polling 來平衡CPU占用和響應速度，當有消息到來或者timer超時是切換到busy polling模式，當長時間沒有事件時則切換到epoll模式。KeepAlive和統計功能都是注冊到timer上的事件。 ?

消息模型

阿里大部分應用通信采用RPC模式，即request-response模式。X-RDMA實現了RPC的通信模式。 ? 由于RDMA操作的內存需要reg_mr，這個動作是將虛地址pin在物理內存中防止page換出，然后將頁表項也發給網卡，顯然這個動作比較耗時間。為了降低內存準備的開銷和過多的內存占用，X-RDMA將消息分成兩類分別處理，這種劃分類似于MPI中的eager和rendezvous模式： ? 小消息：小消息對延遲敏感，默認將4KB以內的消息稱為小消息。采用RDMA SEND/RECV完成收發，兩側各只需要下發一個WR，效率比較高。但是這要求接收方率先準備好接收buffer，為避免較多的內存占用，該模式只能用于小消息收發。 ? 大消息：大消息對吞吐敏感，大消息收發通過多輪協商完成，步驟如下：a. 發送方發送一個WR告知接收方有數據要發送，b. 接收方按需準備好接收buffer，c. 接收方通過RDMA READ讀取數據。 ?

每個線程的工作流

X-RDMA采用run-to-complete的線程模型，因此每個線程都有一個單獨的工作流，如下圖： ?

上圖中信息很豐富，做幾點說明： ? X-RDMA支持event模式和polling模式，可通過xrdma_get_event_fd()的方式獲取polling所需的fd，然后調用xrdma_process_event()進行事件處理。 ? X-RDMA發送消息是異步非阻塞的，因此可能有多個消息在同時發送，被稱為inflight messages，但是X-RDMA會限制inflight messages不超過CQ深度。 ? 鏈接的心跳信息依賴于timer超時事件，X-RDMA會自動發送keepAlive信息做鏈接?；?。 ?

資源管理

為了1. 提升性能，2. 降低內存占用，3. 縮短建聯時間，X-RDMA為每個線程維護內存池和連接池。 ? 內存池：RDMA內存池主要是管理MR(memory region)，由于網卡可以管理的MR數量是有限的，因此過多的MR不僅可能會導致性能下降，甚至會導致超過網卡MR上限而無法注冊新內存，因此X-RDMA采用4MB的粒度來注冊MR，以此來降低MR的數量。 ? 連接池：RDMA建聯比TCP建聯耗時更長(4ms VS. 100us)，X-RDMA為每個線程維護一個qp cache來降低建聯開銷。如果一個鏈接斷開，則會把qp設置為IBV_QPS_RESET狀態，并放到qp cache中，以便后續復用。 ? X-RDMA沒有使用CM建聯，而是自己實現的一套帶外建聯，論文評估章節有說明。 ? ? 04 RDMA協議拓展 ? X-RDMA從以下幾個方面對RDMA做了拓展：

KeepAlive

Seq-Ack Window

Flow Control

KeepAlive

TCP/IP協議棧會由內核發送心跳消息檢查鏈接是否存活，但RDMA協議棧沒有內核參與，因此無法由內核自動發送心跳信息。鏈接?；顧z查時必須的，因為有很多的原因會導致鏈接泄露。當一個鏈接在S毫秒內沒有沒有和對端通信時，X-RDMA會觸發KeepAlive機制，通過RDMA Write探測鏈接是否存活，Write的payload是零字節，如果對端還存活，網卡會自動恢復ACK報文。 ?

Seq-Ack Window

X-RDMA的seq-ack window機制主要出于以下考量： ? 網卡的ack只能保證數據已經到達對端，但并不能保證接收側的應用程序已經處理了這些數據報文。 ? 發送小消息時X-RDMA需要接收方提前準備好接收buffer，如果消息數量很多而接收方的buffer數量不足，則會導致RNR（request not ready），這不僅會導致性能下降，甚至會導致鏈接斷開。 ? 通過X-RDMA的seq-ack window機制可以避免RNR出現，具體做法是：收發兩邊分別有一個緩存in-flight請求的ring buffer窗口，窗口大小設置為IO depth。每次發送數據時（RDMA Write/Send）X-RDMA都會將seq-ack編號通過RDMA immediate Data發送給對方。具體算法如下圖：

Flow Control

在大規模incast場景下DCQCN并不能很好的工作，具體體現在： ? DCQCN是一種被動控制，在CC起作用之前可能已經出現了性能下降（比如ECN報文還沒有返回，交換機buffer就已經出現了丟包）。 ? 根據觀察，incast導致CNP和PFC會導致網絡性能和健壯性的下降。 ? X-RDMA通過1. 消息分片和2. 消息排隊 來協助DCQCN緩解網絡擁塞。 ? 消息分片：對于大的請求，X-RDMA會把請求按照64KB的粒度進行切分，然后逐片發送。以避免大消息對網卡的阻塞。 ? 消息排隊：X-RDMA限制同時能發起的WR請求數量為N，多出來的請求放到隊列里排隊。 ? 上述兩種流控算法均實現X-RDMA通信庫里，對網卡硬件沒有限制。 ? ? 05 性能和問題分析框架 ? X-RDMA提供了眾多工具和機制定位各種類型的bug，分析工具如下圖：

Tracing

X-RDMA數據通路有兩種模式，分別是： ?

bare-data模式：直接發送用戶的原始數據，不做任何的鏈路追蹤。

req-res模式：會在用戶的數據之前加入header，通過header記錄必要的信息，用于tracing和問題定位。通過該機制可以計算出網絡的RTT。

X-RDMA的tracing功能還可用于： ?

定位網絡擁塞

發現慢polling：通過記錄兩次polling之間的時間差，發現慢polling。通常這可能是由于用戶工作線程有比較耗時的操作所致。

發現執行較慢的代碼片

Monitoring

我們提供三種工具彌補RDMA工具不足的問題，分別是： ?

XR-Stat：對標TCP的netstat

XR-Ping：對標TCP的ping，以及RDMA自己的rping（rping功能太簡單了）

XR-Perf：用于做RDMA性能和壓力測試。

性能調優

X-RDMA通信庫有很多參數可以調整，可分為兩類：1. 運行時動態可調的（通過XR-adm命令控制），以及2. 啟動程序是可配置的，具體如下表：

? 06 性能評估 ? 目前（2017）阿里有超過4000臺服務器部署了X-RDMA，使用RoCEv2協議。最大的一個RDMA集群有4個子集群，每個子集群有256個節點，每個節點有一張雙口的25Gbps Mellanox ConnectX4-Lx網卡（總共50Gbps）。 ? ? 07 讀后總結 ? 本文介紹了阿里X-RDMA的核心設計思想，包含線程模型、消息模型、資源管理、心跳檢測、Flow Control等各個維度，對用好RDMA以及設計新的RDMA通信庫有很好的參考價值。其Run-to-Complete線程模型大大降低了X-RDMA自身的設計和編程復雜性，在存儲等典型場景下有很不錯的效果。 ? 美中不足的是X-RDMA沒有公開代碼，文中介紹的很多細節和工具無法進一步了解。 ? 論文鏈接： https://ieeexplore.ieee.org/document/8891004 ? 【投稿】：SDNLAB原創文章獎勵計劃

審核編輯：黃飛

?