UCloud高性能RoCE网络设计

电商、直播等业务要求以非常快的速度完成请求应答，计算和存储的飞速提高也在推动HPC、分布式训练集群、超融合等新应用的普及，网络变成制约性能的主要因素之一。为此，我们设计了低开销高性能的RoCE网络，构建了低时延、无损的大型以太网数据中心，作为RDMA等技术的底层基石，也为UCloud未来的物理网络建设打下了良好基础。

一、低开销高性能的无损网络选型

普通的内网进行数据包交互时，通常会使用系统级的TCP/IP协议栈或者是DPDK技术，这两种方案都是依靠软件进行协议栈解封装的，对系统的CPU有不少消耗。而有一种方案：RDMA，可以直接使用网卡进行协议栈解封装，无需消耗系统CPU，能有效降低数据处理的延时。

RDMA并没有规定全部的协议栈，比如物理链路层、网络层、传输层每个字段长什么样，如何使用，但对无损网络有相当高的要求：

– 不轻易丢包，重传带来的延时非常大。

– 吞吐量巨大，跑满最好。

– 延时越低越好，100us都嫌长。

依据上述要求，主流的网络方案有三种：

图：主流的RDMA网络方案

 

① InfiniBand： 该方案重新设计了物理链路层、网络层、传输层，是RDMA最初的部署方案，所以要使用专用的InfiniBand交换机做物理隔离的专网，成本较大，但性能表现最优；

② iWARP： 该方案的目的是让主流的以太网支持RDMA，将InfiniBand移植到TCP/IP协议栈，使用TCP协议保证无丢包，但缺点在于TCP开销较大，且算法复杂，所以性能表现较差；

③ RoCEv2： 该方案的目的也是让主流的以太网支持RDMA（RoCEv1版本已很少提及了）。网络侧使用PFC保证拥塞时不丢包，网卡侧又使用DCQCN的拥塞控制算法进一步减缓拥塞（该拥塞算法需要网络侧支持ECN标记），传统的以太网经过PFC和ECN的加持进化成为无损以太网，在无损以太网上运行RDMA性能大大增强。

RoCEv2（后文简称RoCE）方案的成熟案例较多，我们也选用了该方案进行研究。但RoCE方案仍存在一些问题，如PFC压制的不公平性、PFC传递带来的死锁风险、过多的调参、ECN标记的滞后性（ECN概率标记是软件轮询机制）等，是需要我们解决完善的。

二、网络设计的目标

要把RoCE搬到经典的数据中心网络上，这可不是一件容易的事儿。

当前数据中心是常见的CLOS架构，LCS是汇聚交换机，LAS是TOR交换机。如果RoCE直接运行在这上面，问题是显而易见的：例如出现Incast事件时，转发不了的报文会被存放在交换机缓存中，但缓存也不是无限大的，如果存满了，这个数据包就丢掉了，很明显这种丢包频率肯定不能被RDMA所接受。

图：CLOS架构示意

 

上面只是举了一个简单的例子，实际上出现的问题要更复杂一些。在设计之前，需要先明确好我们的目标是什么，做到有的放矢。

简单来讲我们的目标就是：

– 在各种流量模型下，网络带宽要能跑满；

– 缓存使用要尽可能低；

– 极限情况下缓存使用满了也不能丢包。

总结来说，为了让RoCE跑在已有的网络上，我们需要从三个方面下手：
① QOS设计：指队列、调度、整形等一系列的转发动作，相对独立。

② 无损设计：是RDMA的要求之一，使用PFC技术实现。无损是一种基本保障，含义是在最拥塞的情况下也能保证其可用性，让上层应用可以放心发送数据，不必担心丢包的风险（所以说PFC并不是降速的手段）。

③ 拥塞控制设计：使用DCQCN技术实现。拥塞控制是满足基本保障前提下的进一步优化，含义是在开始拥塞的时候，就告知服务器两端，使其从源端开始降速，从根本上解决问题。

补充一点拥塞带来的坏处：当出现拥塞后，必然要使用缓存，使用缓存后虽然不丢包了，但是带来的后果是延迟上升，而且吞吐也不能再增加一丝一毫。网络中拥塞点有很多，每一跳都可能成为拥塞点，在上图的网络中，最多会有3个拥塞点。

缓存的使用能带来多少延时？

我们按25Gbps来算，缓存25Mb的数据，大约需要1ms的时间才能发送完毕，25Mb也仅仅是3.1MB，而常见的Broadcom Trident 3芯片有32MB的缓存。

有了这三