技术盛宴丨如何为RDMA构建无损网络

我们为什么需要无损网络

看过前面几期的技术文章，相信大家对RDMA(Remote Direct Memory Access，远程直接数据存取)和无损网络有了一定的认识，也许大家会问为什么我们需要RDMA？为什么我们需要无损网络？这些先进的技术究竟能给我们带来什么好处？

只从网络层面来看可能无法得出令人满意的答案，下面分别从前端业务和后端应用，简单列举几个例子，相信大家可以从中解开疑惑。

首先想说的是互联网中大量的在线业务，例如在线搜索、购物、直播等，它需要以非常快的速度对高频率的用户请求做出应答，数据中心内任何一个环节导致延迟，都会对终端用户的访问体验造成极大的影响，从而影响其流量、口碑、活跃用户等。

还有在机器学习和AI的技术趋势下，对计算能力的需求是呈几何级数上升的，为了满足日益复杂的神经网络和深度学习模型，数据中心会存在大量的分布式计算集群，但大量并行程序的通讯延迟，则会极大影响整个计算过程的效率。

另外为了解决数据中心内爆炸式增长的数据存储和读取效率问题，利用以太网融合组网的分布式存储越来越受到欢迎。但因为存储网络中数据流以大象流为主，所以一旦因拥塞造成丢包，将会引发大象流重传，不仅降低效率，还会加重拥塞。

所以从前端用户的体验和后端应用的效率来看，眼下对于数据中心网络的要求是：延迟越低越好，效率越高越好。

为了降低数据中心内部网络延迟，提高处理效率，RDMA技术应运而生，通过允许用户态的应用程序直接读取和写入远程内存，而无需CPU介入多次拷贝内存，并可绕过内核直接向网卡写数据，实现了高吞吐量、超低时延和低CPU开销的效果。

当前RDMA在以太网上的传输协议是RoCEv2，RoCEv2是基于无连接协议的UDP协议，相比面向连接的TCP协议，UDP协议更加快速、占用CPU资源更少，但其不像TCP协议那样有滑动窗口、确认应答等机制来实现可靠传输，一旦出现丢包，依靠上层应用检查到了再做重传，会大大降低RDMA的传输效率。

所以要想发挥出RDMA真正的性能，突破数据中心大规模分布式系统的网络性能瓶颈，势必要为RDMA 搭建一套不丢包的无损网络环境，而实现不丢包的关键就是解决网络拥塞。

为什么会产生拥塞

产生拥塞的原因有很多，下面列举了在数据中心场景里比较关键也是比较常见的三点原因：

收敛比

进行数据中心网络架构设计时，从成本和收益两方面来考虑，多数会采取非对称带宽设计，即上下行链路带宽不一致，交换机的收敛比简单说就是总的输入带宽除以总的输出带宽。以我们的万兆交换机RG-S6220-48XS6QXS-H为例，下行可供服务器输入的带宽是48*10G=480G，上行输出的带宽是

6*40G=240G，整机收敛比为2:1。而25G交换机RG-S6510-48VS8CQ，下行可供服务器输入的带宽是48*25G=1200G，上行输出的带宽是8*100G=800G，整机收敛比是1.5:1。

也就是说，当下联的服务器上行发包总速率超过上行链路总带宽时，就会在上行口出现拥塞。

ECMP

当前数据中心网络多采用Fabric架构，并采用ECMP来构建多条等价负载均衡的链路，通过设置扰动因子并HASH选择一条链路来转发是简单的，但这个过程中却没有考虑到所选链路本身是否有拥塞。ECMP 并没有拥塞感知的机制，只是将流分散到不同的链路上转发，对于已经产生拥塞的链路来说，很可能加剧链路的拥塞。

TCP Incast

TCP Incast是Many-to-One的通信模式，在数据中心云化的大趋势下这种通信模式常常发生，尤其是那些以Scale-Out方式实现的分布式存储和计算应用，包括Hadoop、MapReduce、HDFS等。

例如，当一个Parent Server向一组节点（服务器集群或存储集群）发起一个请求时，集群中的节点都会同时收到该请求，并且几乎同时做出响应，很多节点同时向一台机器（Parent Server）发送TCP数据流，从而产生了一个“微突发流”，使得交换机上连接Parent Server的出端口缓存不足，造成拥塞。

▲TCP Incast流量模型

正如前面所说，RDMA和TCP不同，它需要一个无损网络。对于普通的微突发流量，交换机的Buffer 缓冲区可以起到一定作用，在缓冲区将突发的报文进行列队等待，但由于增加交换机Buffer容量的成本非常高，所以它所能起到的作用是有限的，一旦缓冲区列队的报文过多，仍旧会产生丢包。

为了实现端到端的无损转发，避免因为交换机中的Buffer缓冲区溢出而引发的数据包丢失，交换机必须引入其他机制，如流量控制，通过对链路上流量的控制，减少对交换机Buffer的压力，来规避丢包的产生。

PFC如何实现流控

IEEE 802.1Qbb（Priority-based Flow Control，基于优先级的流量控制）简称PFC，是IEEE数据中心桥接（Data Center Bridge）协议族中的一个技术，是流量控制的增强版。

说PFC之前，我们可以先看一下IEEE 802.3X（Flow Control）流控的机制：当接收者没有能力处理接

收到的报文时，为了防止报文被丢弃，接收者需要通知报文的发送者暂时停止发送报文。

如下图所示，端口G0/1和G0/2以1Gbps速率转发报文时，端口F0/1将发生拥塞。为避免报文丢失，开启端口G0/1和G0/2的Flow Control功能。

▲端口产生拥塞的打流模型

当F0/1在转发报文出现拥塞时，交换机B会在端口缓冲区中排队报文，当拥塞超过一定阈值时，端口G0/2向G0/1发PAUSE帧，通知G0/1暂时停止发送报文。

G0/1接收到PAUSE帧后暂时停止向G0/2发送报文。暂停时间长短信息由PAUSE帧所携带。交换机A 会在这个超时范围内等待，或者直到收到一个Timeout值为0的控制帧后再继续发送。

IEEE 802.3X协议存在一个缺点：一旦链路被暂停，发送方就不能再发送任何数据包，如果是因为某些优先级较低的数据流引发的暂停，结果却让该链路上其他更高优先级的数据流也一起被暂停了，其实是得不偿失的。

如下图中报文解析所示，PFC在基础流控IEEE 802.3X基础上进行扩展，允许在一条以太网链路上创建8个虚拟通道，并为每条虚拟通道指定相应优先级，允许单独暂停和重启其中任意一条虚拟通道，同时允许其它虚拟通道的流量无中断通过。