当前位置：首页 > RDMA > 正文

工业级大规模RDMA技术杂谈

RDMA
2022-10-17
2864
更新：2022-10-21 06:52:35

> 作者：梦豪-thu
>
> 来源：https://zhuanlan.zhihu.com/p/510323418

> 近期打算提纲挈领地整理一下工业界已经使用起来或有潜力使用起来的大规模RDMA相关技术，供大家参考，也为自己梳理一下脉络。里面每一章甚至每一节的内容都可以单独写成一篇文章，待后续点赞情况和评论情况再进行更新，也欢迎学界和业界的各位同行朋友批评指正，多提宝贵意见。
>
> 注：此技术杂谈面向有一定网络和系统基础的同学。

## 1 RDMA基本概念

本章主要介绍**3种RDMA协议**（InfiniBand、RoCE(v2)、iWARP）、**RDMA和TCP的异同**（Protocol Offload、Zero Copy、OS by-pass）、**RDMA传输原语**（Send、Receive、RDMA Read、RDMA Write，Atomic），**传输类型**（RC、UC、UD）和**核心基础概念**（e.g., SR、RR、CQ、MR、MW、PD），参考RDMA Aware Networks Programming User Manual

可以参考我搞的一个简单的[RDMA Toturial](https://link.zhihu.com/?target=https%3A//github.com/zhangmenghao/RDMA-Tutorial)

## 2 大规模RDMA的关键网络技术

为了让上层业务能充分利用RDMA带来的高性能能力，RDMA需要正确配置、使用一系列关键网络技术，并根据业务场景的需求，做相应的调整和优化。本章主要介绍网络层次的关键技术，如**拥塞控制算法**、**无损网络到有损网络的演进**、**RDMA多路径传输**等。这些都是网络同学必须了解甚至熟练掌握的技术。

### 2.1 RDMA拥塞控制算法

经典RDMA需要配置Priority Flow Control (PFC)来保证不丢包，进而形成无损网络以实现高性能。然而，PFC是一种粗粒度机制。它以端口（或端口加优先级）级别运行，不区分流。这可能会导致拥堵蔓延现象（congestion-spreading），进而有不公平现象、受害者流、PFC deadlock、PFC storm等一系列性能问题。缓解PFC缺陷的根本性方案是使用一个流级别（per-flow）的拥塞控制算法。**拥塞控制算法的本质是，网络路径上的交换机对流量拥塞情况进行标记，携带拥塞标记信号的报文到达接收者后，再被传回发送者由其根据网络拥塞情况进行调速，确保既要避免网络过度拥塞，又要充分地利用网络带宽**（当然不同场景对公平性的要求不尽相同，有些场景需要对所有流公平对待，有些场景希望对小流友好一些）。在RDMA中，由于主机侧的传输层协议大部分位于网卡上，因为调速基本都是在网卡上进行的。要想让业务/应用能够真正RDMA的高性能优势，设计、使用和配置符合业务场景需求的拥塞控制算法是重中之重。

l DCQCN算法：目前Mellanox网卡支持的主要拥塞控制算法，由微软和Mellanox联合研发，在交换机上以ECN为拥塞标记信号，发送者在主机网卡侧根据ECN标记情况来推测网络拥塞情况，实现了一种基于速率（rate-based）的调速方法，是目前Mellanox RDMA网卡商业上直接可用、使用最为广泛的拥塞控制算法。算法主要思想参考[Congestion Control for Large-Scale RDMA Deployments，SIGCOMM 2015](https://link.zhihu.com/?target=https%3A//conferences.sigcomm.org/sigcomm/2015/pdf/papers/p523.pdf)

l TIMELY和Swift算法：Google数据中心中使用的拥塞控制算法，交换机不需要做额外的支持，发送者在主机网卡上对端到端往返延迟（RTT）进行测量，基于RTT的变化进行梯度计算，进而根据梯度实现了基于速率（rate-based）的调速方法。目前主要是在Google内部使用，依赖于Google的自研网卡。算法思想参考[TIMELY: RTT-based Congestion Control for the Datacenter，SIGCOMM 2016](https://link.zhihu.com/?target=https%3A//conferences.sigcomm.org/sigcomm/2015/pdf/papers/p537.pdf)和[Swift: Delay is Simple and Effective for Congestion Control in the Datacenter，SIGCOMM 2020](https://link.zhihu.com/?target=https%3A//dl.acm.org/doi/pdf/10.1145/3387514.3406591)

l HPCC算法：阿里网络研究团队研发出的拥塞控制算法，使用INT携带网络拥塞情况，发送者在主机网卡侧实现了一种基于窗口（window-based）的调速方法。受限于INT的精度、网卡实现的复杂性和对可编程交换机的依赖，HPCC目前应该只是停留在论文阶段，未有大规模部署。算法思想参考[HPCC: High Precision Congestion Control，SIGCOMM 2019](https://link.zhihu.com/?target=https%3A//dl.acm.org/doi/pdf/10.1145/3341302.3342085)

- 其他网卡的算法：Broadcom RDMA网卡上拥塞控制算法采取了类似于DCTCP算法的变种，算法具体可以参考[Data Center TCP (DCTCP)，SIGCOMM](https://link.zhihu.com/?target=https%3A//people.csail.mit.edu/alizadeh/papers/dctcp-sigcomm10.pdf)，这里不再详细描述。

### 2.2 无损网络（Lossless）到有损网络（Lossy）的演进

传统的RDMA跑在InfiniBand（IB）网络上，IB链路层使用逐跳的、基于credit的流控，丢包非常罕见。而在数据中心中，RDMA则需要跑在三层IP网络之上，即RoCEv2。RoCEv2保留了IB传输层，但是使用IP和UDP封装替换了IB的网络层，其中IP层用来路由，UDP层用来进行ECMP。**由于历史性的RDMA网卡（e.g., CX-3, CX-4, CX-5）的传输层处理丢包很不高效，如接收端会丢弃所有的out-of-order packets、发送端需要重传上一个acked packet后的所有packets（go-back-N机制），RoCEv2需要无损网络（Lossless）来保证高性能**。无损网络的核心是在交换机和网卡上使能Priority Flow Control (PFC)。**PFC允许以太网交换机通过强制直接上游实体（另一个交换机或主机网卡）暂停数据传输来避免缓冲区溢出**。然而，PFC是一种粗粒度机制。**它以端口（或端口加优先级）级别运行，不区分流。这可能会导致拥堵蔓延现象（congestion-spreading），进而有不公平现象、受害者流、PFC deadlock、PFC storm等一系列性能问题**。尽管有一系列拥塞控制算法（如2.1所讲）来缓解PFC带来的问题，但是PFC并不能从根本上消除。这是因为在一个端到端路径中，拥塞标记信号需要先经过数跳交换机到达接受者，再被CNP携带着穿越数跳交换机回到发送者，发送者才能降低自己的发送速率，这中间需要至少一个端到端往返时间（RTT）。而在这个往返时间内，发送者可能仍然在提高发送速率，PFC仍然可能会被触发。尤其在规模更大、跳数较多的网络中，PFC的问题仍然会出现，给网络运营带来了较大的稳定性风险。

随着新一代RDMA网卡（e.g., CX-6, CX-7）片上资源的增加，不依赖于PFC的RoCEv2网络成为了可能。相比于上一代的RDMA网卡，新一代的RDMA网卡上在片上实现了**更为高效的丢包恢复机制**和**更好的端到端流控来约束in-flight数据包**，从而让Lossy的性能有潜力不输于Lossless！这也将有潜力把RDMA推广到规模更大、跳数更多的网络中。核心思想参考[Revisiting Network Support for RDMA，SIGCOMM 2018](https://link.zhihu.com/?target=https%3A//dl.acm.org/doi/pdf/10.1145/3230543.3230557)

### 2.3 RDMA多路径传输

在RDMA的大规模组网中，常常基于Fat-Tree的Clos架构进行组网，从而接入更多的服务器。基于Fat-Tree的Clos架构的基本理念是使用大量的商用交换机，在服务器之间构造出多个等价路径（multiple path），进而形成大规模的无阻塞网络。但是在实际流量的路径选择时，交换机只是对流（flow）进行Equal Cost Multi-Path（ECMP）实现负载均衡，当流的数目比较少且大流较多时，往往会造成路径冲撞，进而导致链路带宽无法被充分利用。这里面的本质原因是因为ECMP是一个无状态的局部决策，当流的数量比较少且大流较多时，很容易hash到同一个路径上。尤其在有网络链路发生故障时，会导致基于Fat-Tree的Clos架构的不对称性，进而造成业务性能较大程度的下降。

为了缓解这一问题，目前主要有以下几种思路：

l 采取Multi-path RDMA的思路，即以数据包为粒度把一个流分散到多个等价路径上，再在网卡硬件上实现大部分的Multi-path传输层逻辑，如拥塞感知的流量切分、解决接收端乱序等问题。具体思想参考微软亚研院的工作[Multi-Path Transport for RDMA in Datacenters，NSDI 2018](https://link.zhihu.com/?target=https%3A//www.usenix.org/conference/nsdi18/presentation/lu)

l 仍然是采用把一个流分散到多个等价路径上，形成多个subflow（e.g., flowlet, flowcell），来实现更好的均衡性进而提高多链路的利用率。但是，这里不再在接收端的硬件网卡上解决乱序（out-of-order）问题，而是把这一功能放到软件层，如网卡驱动或者通讯库里面，具体思想参考亚马逊的[SRD](https://link.zhihu.com/?target=https%3A//ieeexplore.ieee.org/document/9167399)。

l 根据业务场景特性和流量模型特性，进行智能路由选路。如在AI训练的场景中，由于流量模型具有所有流大小相同、同时发起同时结束的属性，可以采用类似阿里[ACCL](https://link.zhihu.com/?target=https%3A//ieeexplore.ieee.org/document/9462480/)的思路，进行基于源端口的有序规划，实现基于探测的拥塞感知的路由控制算法。

## 3 RDMA虚拟化

RDMA虚拟化主要用于想将RDMA用到云上的场景，代表性工作有微软的[FreeFlow: Software-based Virtual RDMA Networking for Containerized Clouds，NSDI 2019](https://link.zhihu.com/?target=https%3A//www.usenix.org/conference/nsdi19/presentation/kim)和华为的[MasQ: RDMA for Virtual Private Cloud，SIGCOMM 2020](https://link.zhihu.com/?target=http%3A//staff.ustc.edu.cn/~bhua/publications/MasQ.pdf)。

## 4 RDMA通讯库

为了让上层业务更好的使用RDMA带来的高性能，业务需要在通讯中间件上做出一定程度的适配。这一章主要介绍RDMA在**机器学习训练**和**高性能存储**两个领域的通讯中间件情况。这部分需要网络同学和业务同学共同努力，才能拿到更好的效果。

### 4.1 RDMA在机器学习训练领域的应用

（1）集合通讯库

RDMA服务于机器学习训练业务主要体现在各种集合通讯库上，以NVIDIA的[NCCL](https://link.zhihu.com/?target=https%3A//docs.nvidia.com/deeplearning/nccl/user-guide/docs/index.html)通讯库最具有代表性，当然Facebook也搞出了一个[Gloo](https://link.zhihu.com/?target=https%3A//github.com/facebookincubator/gloo)通讯库。各家大厂也搞出了一些变种，以满足自己AI训练框架的特殊需求：

l Google：[https://github.com/google/nccl-fastsocket](https://link.zhihu.com/?target=https%3A//github.com/google/nccl-fastsocket)

l Microsoft：[https://github.com/microsoft/msccl](https://link.zhihu.com/?target=https%3A//github.com/microsoft/msccl)

l facebook：[https://github.com/facebookincubator/gloo](https://link.zhihu.com/?target=https%3A//github.com/facebookincubator/gloo)

l AWS：[https://github.com/aws/aws-ofi-nccl](https://link.zhihu.com/?target=https%3A//github.com/aws/aws-ofi-nccl)

l 华为：[HCCL - Atlas Data Center Solution V100R020C00 中心训练解决方案概述 01 - 华为](https://link.zhihu.com/?target=https%3A//support.huawei.com/enterprise/zh/doc/EDOC1100150042/f16c35b5)

l 阿里巴巴：[ACCL](https://link.zhihu.com/?target=https%3A//ieeexplore.ieee.org/document/9462480/)

（2）GPU-Direct-RDMA（GDR）

### 4.2 RDMA在存储领域的应用

（1）通讯中间件

RDMA应用于存储领域也需要通讯中间件，可以参考阿里的[X-RDMA: Effective RDMA Middleware in Large-scale Production Environments，CLUSTER 2019](https://link.zhihu.com/?target=https%3A//ieeexplore.ieee.org/document/8891004)

（2）NVMe-over-Fabric（NVMe-oF）

### 4.3 在AI、存储等业务场景充分发挥RDMA潜力的小tips

如何在不同的业务场景、结合应用的独特特性，充分发挥RDMA的性能优势也是一个很大的课题。这里面有一系列编程上、verbs使用上的技巧，也有一大批文章去针对各类应用做针对性优化。

l Using One-Sided RDMA Reads to Build a Fast, CPU-Efﬁcient Key-Value Store，ATC 2013

l [Using RDMA Efﬁciently for Key-Value Services，SIGCOMM 2014](https://link.zhihu.com/?target=https%3A//dl.acm.org/doi/pdf/10.1145/2619239.2626299)，如何根据key-value store的特性更加合理地使用RDMA原语，让其在RDMA网络上能降低延迟和提高吞吐

l [FaRM: Fast Remote Memory，NSDI 2014](https://link.zhihu.com/?target=https%3A//www.usenix.org/conference/nsdi14/technical-sessions/dragojevi%C4%87)

l [Fast In-memory Transaction Processing using RDMA and HTM，SOSP 2015](https://link.zhihu.com/?target=https%3A//ipads.se.sjtu.edu.cn/_media/publications/drtm-sosp15.pdf)

l Octopus: an RDMA-enabled Distributed Persistent Memory File System，ATC 2017

l 未完待补充...

## 5 RDMA性能优化、监控和运维

### 5.1 RDMA性能优化

相比于传统TCP/IP，目前RDMA基本都使用在对网络性能有极致需求的场景。因此，在业务使用RDMA时，与传统TCP/IP往往有以下几个区别：一是为了追求高性能，业务在使用RDMA时往往会打破以前的分层架构，业务的通讯逻辑多直接使用网卡提供的verbs原语，导致业务代码、通讯代码等耦合在一起，很难去分开；这不像传统的TCP/IP，业务多基于内核协议栈提供的socket来进行编程。二是在追求极致性能时，服务器内部的PCIe通讯、操作系统调度开销等瓶颈常常会显露出来，而这些问题在传统TCP/IP下没有这么严重。这两个区别，给RDMA业务系统的性能异常诊断、定位和优化带来了很大的挑战。

为了了解应用/业务的流量模型是否会触发RDMA系统的异常性能行为，字节跳动设计了Collie工具，来帮助开发者自动发现和定位基于RDMA的业务/应用系统的性能异常。Collie使用改进的模拟退火算法，把RDMA相关的性能和诊断计数器引导向极端区域，从而来发现会导致性能异常的流量模型。具体思想可以见[Collie: Finding Performance Anomalies in RDMA Subsystems，NSDI 2022](https://link.zhihu.com/?target=https%3A//www.usenix.org/system/files/nsdi22-paper-kong.pdf)

此外，在日常的工作中，我个人也总结了一些性能优化的经验：

（1）网卡（服务器端）是RDMA业务系统正常工作、拿到性能收益的关键

l 网卡承载了RDMA功能里面最复杂的部分，包括RDMA verbs、rkey校验、地址映射、RDMA传输层协议（go-back-N，congestion control）；而交换机的功能则相对简单（PFC、ECN）

l 网卡上的资源非常受限，需要使用服务器的DRAM来存储它的数据结构，而只是用自己的本地DRAM作为cache；而cache管理非常复杂，经常会引入性能问题（e.g.，cache换入换出引发slow-receiver symptom）

（2）打破网络、服务器、系统边界，联合优化，对RDMA系统极致性能的发挥至关重要，一系列复杂的系统因素，比如cache/内存管理使用、verbs原语使用、机内通讯等，都会影响RDMA系统的性能表现

### 5.2 RDMA监控和运维

除了像传统TCP/IP的秒级常态监控外，RDMA也需要细粒度毫秒级的网络监控，同时在日常运维中也需要对一些无损网络里面的相关指标进行关注，如PFC、ECN、CNP、NACK等。

## 6 业界类RDMA思路

Amazon的SRD和EFA是这方面的代表，参考[A Cloud-Optimized Transport Protocol for Elastic and Scalable HPC，IEEE Mirco 2020](https://link.zhihu.com/?target=https%3A//ieeexplore.ieee.org/document/9167399)

## 7 业界RDMA部署经验分享

### 7.1 微软的RDMA部署经验

微软是全球最早大规模部署RoCEv2的公司，他们系统介绍了他们在大规模部署、运维RoCEv2时遇到的问题，如transport livelock、PFC deadlock、PFC pause storm和slow-receiver symptom等，参考[RDMA over Commodity Ethernet at Scale，SIGCOMM 2016](https://link.zhihu.com/?target=https%3A//www.microsoft.com/en-us/research/wp-content/uploads/2016/11/rdma_sigcomm2016.pdf)。这篇文章信息量很大，干货很多，也很清晰，建议认真阅读。

### 7.2 阿里巴巴的RDMA在存储业务上的部署经验

阿里系统介绍了他们在存储集群Pangu上部署、运维RDMA时遇到的问题以及相应的解法，参考 [When Cloud Storage Meets RDMA，NSDI 2021](https://link.zhihu.com/?target=https%3A//www.usenix.org/conference/nsdi21/presentation/gao)。相比微软的文章，这篇文章干货相对较少。

## 8 RDMA技术总结与展望

作为网络领域近年来新兴的一个技术方向，RDMA自诞生以来，在AI训练和高性能存储领域体现了巨大的潜力，给应用和业务带来了真金白银的收益。未来，RDMA能力如何从pod级别到全网级别、RDMA业务系统如何进行性能优化以最大化利用RDMA的性能优势、存量应用如何能尽量无缝迁移至RDMA、完整的RDMA系统的诊断和监测能力如何低开销轻量级实现，都是亟待解决的有价值问题。

声明：本文素材来源于网络，仅供学习使用，如有侵权请联系网站删除(ngdcn_admin@163.com)。

> 声明：本文素材来源于网络，仅供学习使用，如有侵权请联系网站删除(ngdcn_admin@163.com)。

RDMA