首页 > 编程知识 正文

无损网络ROCE,哪些网卡支持roce

时间:2023-05-04 06:58:51 阅读:109449 作者:3405

RDMA RDMA (远程直接数据访问)是为了解决网络传送中服务器侧的数据处理延迟而发生的,不使用CPU,直接从一个主机或服务器的存储器直接访问另一个主机或服务器的存储器释放CPU以执行必要的任务,例如执行APP应用程序和处理大量数据。 这样可以提高带宽,减少延迟、抖动和CPU消耗。

RDMA和TCP/IP模式的映像。 与传统的网络传输机制相比,RDMA不需要操作系统和TCP/IP协议栈的干预。 RDMA的内核旁路机制允许直接读写APP应用程序和网卡之间的数据,将服务器内的数据传输延迟降低到1us以下。 同时,RDMA的存储器零复制机制允许接收侧直接从发送侧的存储器读取数据,从而大大减少CPU的负担并提高CPU的效率。

RDMA网络类型目前大致有三种RDMA网络,分别是Infiniband、RoCE、iWARP。 其中,Infiniband是专门为RDMA设计的网络,从硬件层面保证了可靠的传输。 RoCE和iWARP都是基于以太网的RDMA技术,支持合适的verbs接口。

InfiniBand InfiniBand (直译为“无限带宽”技术,简称IB )是一种高性能计算计算机网络通信标准,具有极高的吞吐量和极低的延迟,与计算机InfiniBand还用作服务器与存储系统之间的直接或交换互连,以及存储系统之间的互连。

由于该方案是对物理链路层、网络层、传输层进行重新设计,是RDMA的第一个部署方案,所以使用专用的InfiniBand交换机建立物理隔离的专用网络成本较高,但性能最好。

iWARP的目的是让主流以太网支持RDMA,将InfiniBand移植到TCP/IP协议栈中,使用TCP协议保证无丢包,但缺点是TCP开销大此外,RoCE支持多播,但iWARP还没有相关的标准定义。

ROCE ROCE (RDMAoverconvergedethernet )是infinibandtradeassociation (ibta )标准中定义的网络协议,可以通过以太网使用rdma

该方案的目的也是让主流的以太网支持RDMA。 网络端使用PFC确保在拥塞时没有丢包,网卡端使用DCQCN的拥塞控制算法进一步缓解拥塞。 该拥塞算法需要网络侧支持ECN标签。 传统的以太网经过PFC和ECN的加持进化成为无损以太网,大大提高了在无损以太网上运行RDMA的性能。 简而言之,它可以看作是一种RDMA技术的应用,将数据中心、云、存储和虚拟化环境超级融合在一起。

RoCE版本RoCEv2版本已经是当前的主流版本,RoCEv1版本很少被提及。

最初由IBTA实施并标准化,RoCE假设为双层协议。 实际上,ibtalayer1和layer2字段将被替换为相应的以太网字段。 具体而言,用2层LRH置换以太网MAC报头和帧检查序列。 “EtherType”字段指示有效载荷封装了RoCE协议。 该协议在第2层或更高层实现了IBTA协议。 IBTA网络管理(子网管理器)也由标准以太网双层管理协议代替。

该方法的优点是易于实现,可严格分层,并保留通道接口上方的APP应用层API。 缺点是由于广播域和子网之间的IP分配限制的复杂性,导致了第2层以太网部署的可扩展性限制。 此外,某些交换机可能会以比普通IP包慢的异常路径传输RoCE包。 由于这些限制,RoCE将在第3层(可路由)环境中运行。 幸运的是,通过RoCE框架的简单扩展,可以轻松地在三层网络上传输。

如下图所示,支持第3层的RoCE协议继续(tack )以使得以标准IP网络报头代替可选的第(L3 )全局路由报头(GRH ),并将其作为第4层有效载荷的无状态封装这是RoCE非常自然的扩展,因为三层报头已经基于IP地址,所以这种替换非常简单。 UDP封装是L4分组的标准类型,其是目前主流的数据级别封装,使得路由器能够有效地传输。

简言之,当前RDMA在以太网上的传输协议是RoCEv2,RoCEv2是基于无连接协议的UDP协议

RoCE具有CPU使用率低的优点。 您可以访问远程交换机或服务器的内存,而无需占用远程服务器的CPU周期,从而充分利用可用带宽并提高可扩展性。 零拷贝:将数据发送到远程缓冲区并接收数据。 效率: RoCE改善了延迟和吞吐量,大大提高了网络性能。 降低成本: RoCE使企业能够处理大量数据,而无需购买新设备或更换以太网基础架构,从而大幅节省资本支出。 RoCEv2网络的关键点为了发挥RDMA的真正性能,突破数据中心大规模分布式系统的网络性能瓶颈,需要为RDMA构建丢包无损的网络环境

为什么拥挤1. 收敛比

在进行数据中心网络体系结构设计时,出于成本和收入的考虑,通常会采用非对称的带宽设计。 也就是说,上下行链路带宽不一致,交换机的收敛比简单地说就是总输入带宽除以总输出带宽。

也就是说,如果当前连接的服务器的上行数据包的总速度超过上行链路的总带宽,上行端口将发生拥塞。

2. ECMP

目前,数据中心网络多采用结构体系结构,采用ECMP构建

条等价负载均衡的链路,通过设置扰动因子并HASH选择一条链路来转发是简单的,但这个过程中却没有考虑到所选链路本身是否有拥塞。ECMP并没有拥塞感知的机制,只是将流分散到不同的链路上转发,对于已经产生拥塞的链路来说,很可能加剧链路的拥塞。
3. TCP Incast
TCP Incast是Many-to-One的通信模式,在数据中心云化的大趋势下这种通信模式常常发生,尤其是那些以Scale-Out方式实现的分布式存储和计算应用,包括Hadoop、MapReduce、HDFS等。
例如,当一个Parent Server向一组节点(服务器集群或存储集群)发起一个请求时,集群中的节点都会同时收到该请求,并且几乎同时做出响应,同时向一台机器(Parent Server)发送TCP数据流,从而产生了一个“微突发流”,使得交换机上连接Parent Server的出端口缓存不足,造成拥塞。
正如前面所说,RDMA和TCP不同,它需要一个无损网络。对于普通的微突发流量,交换机的Buffer缓冲区可以起到一定作用,在缓冲区将突发的报文进行列队等待,但由于增加交换机Buffer容量的成本非常高,所以它所能起到的作用是有限的,一旦缓冲区列队的报文过多,仍旧会产生丢包。
为了实现端到端的无损转发,避免因为交换机中的Buffer缓冲区溢出而引发的数据包丢失,交换机必须引入其他机制,如:

流量控制QoS拥塞控制 流量控制 Pause帧

Pause帧机制是Ethernet (802.3)的一个标准,在以太网链路的点到点邻接,接收者发送Pause帧让发送者停止发送数据,以保护缓存溢出、丢包。Pause帧在很多场景会有问题,所以不建议使用。
例如,H-J链路承载了F-G和X-Y的流量,如果A-F都发送流量到G,导致G被打满(但H-J还有充足带宽)那么SW1向SW2发送Pause帧,减少了H-J的流量势必会影响到X-Y的流量。这就是个问题了。

另外在超融合网络里,FCoE和LAN流量共享一条链路,存储阵列发送的Pause也会使LAN的流量停止。这也是个问题。

PFC(802.1Qbb)

PFC是Pause帧的一个扩展,暂停帧包含802.1p优先级的8位掩码,可以针对某一个队列发送Pause帧。

水线

在博通的XGS系列芯片中,有一块缓存管理单元MMU(简称缓存),存放已收到但没转发走的报文,并给入口和出口都计数:“0/1的入口和0/2的出口,都用了1个cell”(cell是缓存资源的最小单位)。
缓存会给每个入口和出口设置一个上限,超过这个上限就不能再使用cell缓存报文了。上限以下还画了很多其它的水线,同时对每一个出口和入口进行进一步细分,可以按照队列进行统计限额其中入方向。入方向上,细分了PG-Guaranteed大小、PG-Share大小、Headroom大小;出方向上,细分了Queue-Guaranteed大小,Queue-Share大小(如下图所示,这里我们不考虑端口,只考虑队列)。

►PG-Guaranteed和Queue-Guaranteed是保证缓存,这部分是独享的,即使不用,别的队列也不能抢占使用。
►PG-Share和Queue-Share使用的是共享缓存,因为动态水线的缘故,它们的大小不固定,如果很多队列都在用,那平分一下,每个队列的水线就都很小。另外,PG-Share还有另一个重要的作用:PFC发送的临界点,也称为xoff水线,只要到达该水线,PFC就会从这个口发出去,回落一些后,才恢复正常。在无损队列中,我们希望在缓存丢包前,能触发PFC进行反压,所以在任何情况下,都应该入口PG-Share先到达水线,出口Queue-Share永远不能到达水线(PG-Share到达会发PFC,Queue-Share到达会丢包)。
►Headroom是一个特殊的水线,只有在无损队列中才能发挥其作用。设想一下,PFC发出去以后,流量真的能瞬间停下来么?答案是不能的!因为线缆中还有一部分数据,而且七七八八的转发处理时间也要算进去。所以Headroom空间就是用来做这个的。

死锁

死锁产生的一个必要条件是CBD(环状缓存依赖),在数据中心典型的CLOS组网中,稳定状态下不会存在CBD,也没有死锁风险。
死锁问题解决的三种方法:

针对各种微环路场景,通过设计网络协议,控制收敛的现先后关系,避免出现微环路出现。对于其它未知的死锁风险,使用交换机的死锁检测功能,释放缓存(释放缓存会产生丢包,但收敛过程本身就有乱序/丢包情况)。将PG-Share的水线适当拉高,尽量使用DCQCN拥塞控制来压制流量。 QoS

1. 流分类
一般在网络边缘设备(如:TOR)根据数据包特征打上相应标记(如:DSCP),
在网络中的设备,信任标记,入相应队列。
2. 队列调度
出方向一般可以采用SP+WRR的队列调度模式,如图:
信令类绝对优先,直到队列为空,才开始转发其它队列;
RoCE类和普通流量加权轮询。

3. QoS和PFC的使用
使用QoS时不强制使用PFC。可能存在具有多个流量类别的网络,这些流量类别中没有一个需要无损(loss-less)特性
当网络中不启用QoS,交换机只有一个进方向缓存。当使用QoS,交换机会按流量分类生成多个进方向缓存。
如下图:

一般网络中有多个流量类别,则应启用QoS,为每个流量类别提供不同的服务。
例如,如果优先级3映射到TC1,并且我们在这个优先级上运行RDMA应用程序,我们希望TC1是无损的(TC1缓冲区上没有丢弃)。因此,我们将在优先级3上启用PFC。

拥塞控制 ECN

网络中间的交换机必须支持ECN功能。
在DSCP的后两位做ECN,Not-ECT “00”表示不支持ECT(ECN-capable Transport);CE“11”表示发生拥塞;ECT(1)“01”一般是发送端设置,ECT(0)“10”一般是接收端设置(两者也可以互换,也就是“10”在发送端设置,“01”在接收端设置)。其实ECT(0)和ECT(1)两个编码就是一个互相验证的机制。

拥塞控制流程

RoCE拥塞控制流程图:

1 发送端必须设置ECN,ECT标记为10;
2 RoCEv2报文进入网络设备,当然网络设备必须也支持ECN;
3 网络设备在拥塞的情况下会检查ECN位,并开启CE bit(11),而不是直接丢包;
4 报文从网络设备到接收端时,ECN为11
5 接收端会对开启CE位的RoCE的报文过滤,触发事件然后做正常流处理;
6-7 接收端针对每个QP(Queue Pair)产生的拥塞做汇聚,在几微秒内将一个CN(Congestion
Notification)报文发给发送端。报文ECN设置为01;
8 接收端到网络设备的CNP报文;
9 CNP报文封在UDP里,网络设备在处理CNP报文和普通IP报文一样;

10 发送端收到CNP报文并过滤ECN 01,然后对相应流做相应算法限制速率。

简单总结:发送方叫Reaction Point,简称RP;接收方叫Notification Point,简称NP;中间交换机叫 Congestion Point,简称CP。发送方(RP)以最高速开始发送,沿途过程中如果有拥塞,会被标记ECN显示拥塞,当这个被标记的报文转发到接收方(NP)的时候,接收方(NP)会回应一个CNP报文,通知发送方(RP)。收到CNP报文的发送方(RP),就会开始降速。当发送方没有收到CNP报文时,就开始又提速了。

DCQCN

RoCE使用的拥塞控制算法是DCQCN非常复杂,《Congestion Control for Large-Scale RDMA Deployments》这篇论文很详细地描述了该算法。DCQCN算法中,对RP、NP和CP都有很多参数可以调节。

参考:
https://www.sohu.com/a/258041228_100289134
https://zhuanlan.zhihu.com/p/103231705
https://community.mellanox.com/s/article/roce-v2-considerations#jive_content_id_What_is_RoCE
https://community.mellanox.com/s/article/understanding-rocev2-congestion-management
https://community.mellanox.com/s/article/network-considerations-for-global-pause–pfc-and-qos-with-mellanox-switches-and-adapters

版权声明:该文观点仅代表作者本人。处理文章:请发送邮件至 三1五14八八95#扣扣.com 举报,一经查实,本站将立刻删除。