-
我们为什么需要无损网络
看过前面几期的技术文章，相信大家对
RDMA(Remote
Direct Memory Access
，远程直接数据存取
)
和无损网络有了一定的认识，也许大家会问为什么我们需要
RDMA
？为什么我们需要无损网络？这些先进的
技术究竟能给
我们带来什么好处？
只从网络层面来看可能无法得出令人满意
的答案，
下面分别从前端业务和后端应用，
简单列举几个例子，
相信大家可以从中解开疑惑。
首先想
说的是互联网中大量的在线业务，例如在线搜索、购物、直播等，它需要以非常快的速度对高频
< br>率的用户请求做出应答，数据中心内任何一个环节导致延迟，都会对终端用户的访问体验造成极大的影响，
从而影响其流量、口碑、活跃用户等。
还有在机器学习和
AI
的技术趋势下，对计算能力的需求是呈
几何级数上升的，为了满足日益复杂的神
经网络和深度学习模型，数据中心会存在大量的
分布式计算集群，但大量并行程序的通讯延迟，则会极大影
响整个计算过程的效率。
另外为了解决数据中心内爆炸式增长的数据存储和读取效率问题，
利用以太网融合组网的分布式存储越
来越受到欢迎。但因为存储网络中数据流以大象流为
主，所以一旦因拥塞造成丢包，将会引发大象流重传，
不仅降低效率，还会加重拥塞。<
/p>
所以从前端用户的体验和后端应用的效率来看，眼下对于数据中
心网络的要求是：延迟越低越好，效率
越高越好。
为了降低数据中心内部网络延迟，
提高处理效率，
RDMA
技术应运而生，
通过允许用户态的应用程序直
接读取和写入远程内存，
而无需
CPU
介入多次拷贝内存，
并可绕过内核直接向网卡写数据，
< br>实现了高吞吐量、
超低时延和低
CPU
< br>开销的效果。
当前
RDMA<
/p>
在以太网上的传输协议是
RoCEv2
，
RoCEv2
是基于
无连接协议的
UDP
协议
，相比
面向连
接的
TCP
协议
，
UDP
协议更加快速、占用
CPU
资源更少，但其不像
TCP
协议
那样有滑动窗口、确认应答等
机制来实现可靠传输，一旦出现丢包，依靠上层应用检查到
了再做重传，会大大降低
RDMA
的传输效率。
所以要想发挥出
RDMA
真
正的性能，
突破数据中心大规模分布式系统的网络性能瓶颈，
势
必要为
RDMA
搭建一套不丢包的无损网络环境，而实现不丢包
的关键就是解决网络拥塞。
为什么会产生拥塞
产生拥塞的原因有
很多，下面列举了在数据中心场景里比较关键也是比较常见的三点原因：
收敛比
进行数据中心网络架构设计时
，从成本和收益两方面来考虑，多数会采取非对称带宽设计，即上下行链
路带宽不一致，
交换机的收敛比简单说就是总的输入带宽除以总的输出带宽。以我们的万兆交换机
RG-
S6220-48XS6QXS-H
为例，下行可供服务器输入的带宽是
48*10G=480G
，上行输出的带宽是
6*40G=240G
，整机收敛比
为
2:1
。而
25G
< br>交换机
RG-S6510-48VS8CQ
，下行可供服
务器输入的带宽是
48*25G=1200G
，上行输出的带宽
是
8*100G=800G
，整机收敛比是
1.5:1
。
也就是说，当下联
的服务器上行发包总速率超过上行链路总带宽时，就会在上行口出现拥塞。
ECMP
当前数据中心网络多采用<
/p>
Fabric
架构，并采用
ECMP
来构建多条等价负载均衡的链路，通过设置扰动
因子并
HASH
选择一条链路来转发是简单的，但这个过程中却没有考虑到所选链路
本身是否有拥塞。
ECMP
并没有拥塞感知的机制，只是将流分
散到不同的链路上转发，对于已经产生拥塞的链路来说，很可能加剧链
路的拥塞。
TCP Incast
TCP Incast
是
Many-
to-One
的通信模式，在数据中心云化的大趋势下这种通信模式常常发生，尤其是<
/p>
那些以
Scale-Out
方式实现的分
布式存储和计算应用，包括
Hadoop
、
MapReduce
、
HDFS
等
。
例如，当一个
Parent
Server
向一组节点（服务器集群或存储集群）发起一个请求时
，集群中的节点都会同
时收到该请求，并且几乎同时做出响应，很多节点同时向一台机器
（
Parent Server
）发送
TCP
数据流，从而
产生了一个“微突发流”，使得交换机上连
接
Parent
Server
的出端口缓存不足，造成拥塞。
▲
TCP
Incast
流量模型
正如前面所说，
RDMA
和
TCP
不同，它需要一个无损网络。对于普通的微突发流量，交换机的
Buffer
缓冲区可以起到一定作用，在缓冲区将突发的报文进行列队等待
，但由于增加交换机
Buffer
容量的成本非常
高，所以它所能起到的作用是有限的，一旦缓冲区列队的报文过多，仍旧会产生丢包。
为了实现端到端的无损转发，
避免因为交换机中的<
/p>
Buffer
缓冲区溢出而引发的数据包丢失，
< br>交换机必须
引入其他机制，如流量控制，通过对链路上流量的控制，减少对交换机
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
和<
/p>
G0/2
的
Flow
Control
功能。
▲端口产生拥塞的打流模型
当
F0/1
在转发报文出现拥塞时，交换机
B
会在端口缓冲区中排队报文，当拥塞超过一定阈值时，端口<
/p>
G0/2
向
G0/1
发
PAUSE
帧，通知
G0/1<
/p>
暂时停止发送报文。
G0/1
接收到
PAUSE
帧后暂时停止向
G0/2
发送报文。
暂停时间长短信息由
PAUSE
帧所携带。
交换机
A
会在这个超时范围内等待，或者直到收到一个
Timeo
ut
值为
0
的控制帧后再继续发送。<
/p>
IEEE
802.3X
协议存在一个缺点：一旦链路被暂停，发送方就不能再发送任何数据包，如果是因为某些
优先级较低的数据流引发的暂停，结果却让该链路上其他更高优先级的数据流也一起被暂停了，其实是
得不
偿失的。
如下图中报文解析所示
，
PFC
在基础流控
IEEE 802
.3X
基础上进行扩展，允许在一条以太网链路上创建
8
个虚拟通道，并为每条虚拟通道指定相应优先级，允许单独暂停和重启其中任意一条虚拟通道，
同时允许
其它虚拟通道的流量无中断通过。
<
/p>
▲
PFC
协议报文结构解析
PFC
将流控的粒度
从物理端口细化到
8
个虚拟通道，分别对应
Smart
NIC
硬件上的
8<
/p>
个硬件发送队列
（这些队列命名为
Tra
ffic
Class
，分别为
TC0
,TC1,...,TC7
）
，在
RD
MA
不同的封装协议下，也有不同的映射
方式。
RoCEv1
这个协议是
将
RDMA
数据段封装到以太网数据段内，再加上以太网的头部
，因此属于二层数据包。为
了对它进行分类，只能使用
VLAN
（
IEEE
802.1q
）头部中的
PCP(Priority Code
Point)
域
3
Bits
来设置优先
级值。
▲二层以太网帧
VLAN
头部结构
RoCEv2
这个协议是将
RDMA
数据段先封装到
UDP
数据段内，加上
UDP
头部，再加上
< br>IP
头部，最后再加上以
<
/p>
太网头部，属于三层数据包。对它进行分类，既可以使用以太网
V
LAN
中的
PCP
域，也可以使用
IP
头部的
DSCP
域。
▲三层
IP
报文头部结构
简单来说，在二层网络的情况下
，
PFC
使用
VLAN
中的
PCP
位来对数据流进行区分，在三层网络的情<
/p>
况下，
PFC
既可以使用
PCP
、也可以使用
DSCP
，使得不同数据流可以享受到独立的流控制。当下数据中心
因多采用三层网络，因此使用
DSCP
比
PCP
更具有优势。
PFC
死锁
虽然
PFC
能够通过给不同队列映射不同优先级来实现基于队列
的流控，
但同时也引入了新的问题，
例如
PFC
死锁的问题。
PFC
死锁，
是指当多个交换机之间因微环路等原因同时出现拥塞
,
各自端口缓存消耗超过阈值，
而又相互
等待对方释放资源，从而导致所有交换机上的数据流都永久阻塞的一种网络状态。
正常情况下，当一台交换机的端口出现拥塞并触发
X
OFF
水线时，数据进入的方向（即下游设备）将发
送
PAUSE
帧反压，上游设备接收到
PAUSE
帧后停止发送数据，如果其本地端口缓存消耗超过阈值，则继续
向上游反压。如此一级级反压，直到网络终端服务器在
PAUSE
帧中指定
Pause Time
内暂停发送数据，从而
消除网络节点因拥塞造成的丢包。
但在特殊
情况下，例如发生链路故障或设备故障时，
BGP
路由重新收敛
期间可能会出现短暂环路，会导
致出现一个循环的缓冲区依赖。如下图所示，当
4
台交换机都达到
XOFF
水线，都同时向对端发送
PAUSE
帧，这个时候该拓扑中
所有交换机都处于停流状态，由于
PFC
的反压效应，整个网络
或部分网络的吞吐量将
变为零。
▲
PFC
死锁示意图
< br>
即使在无环网络中形成短暂环路时，也可能发生死
锁。虽然经过修复短暂环路会很快消失，但它们造成
的死锁不是暂时的，即便重启服务器
中断流量，死锁也不能自动恢复。
为了解除死锁状态，一方面
是要杜绝数据中心里的环路产生，另一方面则可以通过网络设备的死锁检测
功能来实现。
我们的
RG-S6510-48VS8CQ
上的
Deadlock
检测功能，可以检测到出现
Dead
lock
状态后的
一段时间内，忽略收到的
PFC
帧，同时对
buffer
中
的报文执行转发或丢弃的操作（默认是转发）
。
例如，定时器的监控次数可配置设置检测
10
次，每
次
10ms
内检测是否收到
PFC <
/p>
Pause
帧。若
10
< br>次
均收到则说明产生
Deadlock
< br>，对
buffer
中的报文执行默认操作，之后将设置<
/p>
100ms
作为
Recover
时间后
恢复再检测。命令如下：
priority-flow-control deadlock cos-
value 5 detect 10 recover 100
//10
次检测，
100ms
recover
。
RDMA
无损网络中利用
PFC
流控机制，实现了交换机
端口缓存溢出前暂停对端流量，阻止了丢包现象
发生，但因为需要一级一级反压，效率较
低，所以需要更高效的、端到端的流控能力。
利用
ECN
实现端到端的拥塞控制
当前的
RoCE
拥塞控制依
赖
ECN(Explicit Congestion Notification
，
显式拥塞通知
)
来运行。
ECN
最初
在
RFC 3168
中定义，
网络设备会在检测到拥塞时，
通过在
IP
头部嵌入一个拥塞指示器和在
TCP
头部嵌入一
个拥塞确认实现。
RoCEv2
标准定义了
RoCEv2
拥塞管理
(RCM)
。启用了
ECN
之后，网络设备一旦检测到
RoCEv2
流量
出现了拥塞，会在数据包的
IP
头部
ECN
域进行标记。
▲
IP
报文头
ECN
字段结构
这个拥塞指示器被目的终端节点按照
BTH(Base
Transport Header
，
存在于
< br>IB
数据段中
)
中的
FECN
拥
塞指示标识来解释意义。换句话说，当
被
ECN
标记过的数据包到达它们原本要到达的目的地时，拥塞
通知就
会被反馈给源节点，源节点再通过对有问题的
Queue
Pairs
（
QP
）进行网络数据包的
速率限制来回应拥塞通
知。
ECN
交互过程
▲
EC
N
交互过程示意图
?
发送端发送的
IP
报文标记支持
ECN
（
10<
/p>
）
；
?
交换机在队列拥塞情况下收到该报文，将
ECN
字段修改为
11
并发出，网络中其他交换机将透传；
?
接收端收到
E
CN
为
11
的报文发现拥塞，正常处理
该报文；
?
接收端产生拥塞通告，每
ms
级发送一个
CNP
（
Congestion Notification Packets
）报文，
ECN
字
段为
01<
/p>
，
要求报文不能被网络丢弃。接收端对多个被
ECN
标记为同一个
QP
的数据包
发送一个单个
CNP
即
可（格式规定见
下图）
；
?
交换机收到
CNP
报文后正常转发该报文；
< br>
?
发送端收到
ECN
标记为
01
的
CNP
报文解析后对相应的流（对应启用
ECN
的
QP
）应用速率限制算
法。
RoCEv2
的
C
NP
包格式如下：
▲
CNP
报
文结构
值得注意的是，
CNP
作为拥塞控制报文，也会存在延迟和丢包，从发送端到接收端经过
的每一跳设备、
每一条链路都会有一定的延迟，
会最终加大发送
端接收到
CNP
的时间，
而与此同时交
换机端口下的拥塞也会
逐步增多，
若发送端不能及时降速，
仍然可能造成丢包。
建议拥塞通告域的规模不要过大，
从而避免因为
ECN
控制报文交互回路的跳数过多，
而影响发送端无法及时降速，造成拥塞。
总结
RDMA
网络正是通过在网络中部署
PFC
和
ECN
功能来实现无损保障。
PFC
技
术让我们可以对链路上
RDMA
专属队列的流量进行控制，并在
交换机入口（
Ingress
port
）出现拥塞时对上游设备流量进行反压。
利用
ECN
技术我们可以实现端到端的拥塞控制，在交换机出口（
Egress p
ort
）拥塞时，对数据包做
ECN
标
记，并让流量发送端降低发送速率。
从充分发挥网络高性能转发的角度，我们一般建议通过调整
ECN
和
PFC
的
buffer
水线，让
ECN
快于
PFC
触发，即网络还是持续全速进
行数据转发，让服务器主动降低发包速率。如果还不能解决问题，再通过
PFC
让上游交换机暂停报文发送，虽然整网吞吐性能降低，但是不会产生丢包。
在数据中心网络中应用
RDMA
，
不仅要解决转发面的无损网络需求，
还要关注精细化运维，
才能应对延
迟和丢包敏感的网络环境。有关
MMU
的精细化管理技术以及基于
INT
的网络可视化技术可参考往期文章。