RDMA over Commodity Ethernet at Scale (I)

Abstract

在过去一年半的时间，我们已经使用RoCEv2来支持一些微软高可靠性、延迟敏感的服务。本篇论文讲述了在此过程中遇到的挑战以及解决方案。为了把RoCEv2扩展到VLAN之外，我们设计了一个基于DSCP的优先级流量控制机制（PFC）来确保大规模部署。我们已经解决了很多安全挑战，比如PFC-减少死锁、RDMA传输livelock以及NIC PFC暂停帧风暴问题。我们也建立了监控和管理系统来确保RDMA按照预期的方式工作运行。我们的经验表明，大规模运行RoCEv2的安全和可扩展问题都可以被解决，RDMA可以代替TCP进行内部数据中心通信，并且可以实现低延迟、低CPU开销、高吞吐量。

传统TCP/IP仍然占据主导地位，但是不能满足新一代DC工作负载的需求，有两个原因：传统TCP/IP的CPU负载太高，传统TCP/IP延迟太高。

1.  Introduction

随着线上服务和云计算的快速发展，大规模数据中心（DC）被建立在世界各处。连接DC中的服务器需要高速、可扩展的数据中心网络。DCN的建立需要商用交换机和网卡。最先进的DCN必须支持DC中任何两个服务器之间Gb/s或更高的吞吐量。

在当今数据中心网络中，TCP/IP仍然是主导的传输/网络协议栈，但是传统TCP/IP协议栈并不能满足新一代DC工作负载的需求，有两个原因：

1） OS内核中的数据包操作带来的CPU开销仍然很高，尽管做了很多硬件和软件上的优化，比如卸载校验和、LSO、RSS和适度中断。在我们数据中心中的测量结果显示，用8个TCP连接以40Gb/s发送chew up6% 聚合CPU时间，才一个32核Intel Xeon E5-2690 Windows 2012R2 服务器。使用8个TCP连接到达40Gb/s需要12%聚合的CPU时间，现代的数据中心是无法忍受这种高CPU开销的。

2） 许多当代DC应用，比如Search，对网络延迟都是高度灵敏的。TCP不能提供需要的低延迟，即使平均流量负载是适当的，有两个原因。第一，内核软件产生的延迟有几十毫秒；第二，由于网络拥塞，会有数据丢包现象出现，尽管很少，但并没有在我们的数据中心中消失，这时因为数据中心固有的突发性。TCP通过超时或者快速重传来恢复正常，而这两种情况中，都有很大的延迟。

本篇论文总结了部署RcCEv2和RDMA以解决以上提出的在微软数据中心的问题的经验，RDMA是一种在不中断CPU操作的前提下可以访问远程系统的方法，RDMA广泛应用于高性能计算中，以Infiniband为架构，RoCEv2支持RDMA实现在以太网上，而不是Infiniband。

和TCP不同，RDMA需要一个无损网络，也就是说，交换机中的缓冲区溢出不能引发数据包丢失，RoCEv2使用PFC来实现无损网络。

我们注意到，VLAN标签被典型用于鉴别混合RDMA/TCP部署中的支持PFC的流量。我们将讨论，这种解决方案不会出现在我们的环境中。因此。我们提出了基于PFC的DSCP（Differentiated Services Code Point）概念，把RDMA从二层VLAN扩展到三层IP。

我们的RDMA部署已经顺利运行了一年半，支持了微软的一些高可靠、延迟敏感的线上服务。经验表明，通过改进RoCEv2的设计、解决不同的安全问题、建立需要的管理和监控功能，我们可以使用商用以太网，把RDMA安全地部署在大规模数据中心中。

2.  Background

我们的数据中心网络是一个基于以太网的多层Clos网络。20-40个服务器连接到一个top-of-rack（ToR，顶层机架）交换机，数十个ToR连接到叶子交换机层。叶子交换机反过来连接到数十到上百个Spine交换机层上。大多数链路是40Gb/s，我们计划在不久的将来更新到50GbE和100GbE，所有的交换机都是使用IP路由。

服务器和使用大约2米的铜电缆连接到ToR交换机，ToR交换机和叶子交换机之间有10-20米的距离，leaf和spine交换机之间有200-300米。三层交换机将数以万计的服务器连接到一个数据中心，本篇论文中，我们的关注点是同一个spine交换机层下的若干服务器之间的支持RDMA。

RoCEv2：部署RoCEv2是基于技术和经济的两个原因。RoCEv2在一个Ethernet/IPv4/UDP数据包中解封装一个RDMA传输包，使得RoCEv2和我们线程的网络基础设施相兼容，基于ECMP的多路径路由需要UDP头部，目的UDP端口通常设置为4791，源UDP端口对每个QP是随机选择的。中间交换机使用标准的五元组哈希。因此，属于同一个QP的流量有相同的路径，而不同QP中的流量可以有不同的路径（甚至在同一对通信终端之间）。

PFC和buffer预留：RoCEv2使用PFC来防止缓冲区溢出。PFC标准指定了8个优先级种类，来减少head-of-line阻塞问题。但是，在我们的网络中，RDMA只能使用8个中的两个优先级。原因如下：

PFC是一个在两个以太网节点之间的逐跳协议。发送者的egress port把数据发送到接收者的ingress port，发送端口把数据包放到最多8个队列中进行排队，每个队列对应一个优先级，接收端口把数据包缓存到对应的接收队列中。在我们网络中使用的共享缓冲区的交换机中，一个接收队列被作为一个counter简单地实现，所有的数据包共享一个通用的buffer池。

一旦接收队列的长度达到了一定阈值（XOFF），交换机会发送PFC暂停帧到对应的上流egress queue。在egress队列接收到暂停帧的时候，就会停止发送数据包。暂停帧中包含了需要暂停的优先级队列和暂停时间。一旦接收队列的长度小于另一个阈值（XON），交换机会发送一个0持续时间的暂停帧给egress queue来恢复传输。XOFF的值必须能够保证没有buffer overflow，XON来保证没有缓冲区buffer underflow。（overflow表示缓冲区已满，不能再写入了，underflow表示缓冲区空的，不能读取数据）。

暂停帧到达上游egree port会消耗一定时间，交换机反应也需要一定时间，所以在这段时间内，上游流量端口会继续发送数据包，所以ingress port必须给每个优先级预留出缓冲区空间来存储“gray period”收到的数据包，这个预留的buffer叫做headroom，其大小取决于MTU、egress port的PFC反应时间，以及最重要的，发送者和接收者之间的传播时延。

传播时延取决于发送者和接收者之间的距离。在我们的网络环境中，二者的距离最大是300米。ToR和leaf交换机有shallow buffers（9MB或者12MB），我们只能给两个无损的流量类别预留充足的headroom，即使交换机支持8个流量类别。一个无损类别进行实时流量，另一个无损类别进行批量数据传输。

Need for congestion control：PFC是逐跳工作的，源和目的服务器之间可能有多跳，如果有持续的网络拥塞，PFC暂停帧会从阻塞点传播并返回到源，这就会导致诸如unfairness和victim flow的问题。

为了减少这些额外的问题，包括QCN、DCQCN和TIMELY在内的基于流量的拥塞控制机制应运而生。我们选择使用DCQCN，本质是利用ECN进行拥塞警告，之所以选择DCQCN，是因为它能直接对中间交换机的队列长度进行响应，并且所有的交换机都支持ECN。小的队列长度减少了PFC的产生和传播几率。尽管DCQCN帮助减少了PFC暂停帧的数量，但是是PFC在保护数据包不被丢弃。PFC提出了一些安全问题，正的本论文的重点内容，第4部分会进行讨论。我们相信，从本论文学到的经验教训同样适用于使用TIMELY的网络。

Coexistence of RDMA and TCP：本论文中，RDMA是为intra-DC通信设计的，而intra-DC和延迟应用仍然需要TCP，TCP使用一个不同的流量类（无损），不同的流量类别将TCP和RDMA的流量隔离开来。