当网络传输协议SRD遇上DPU

网络
SRD 实际工作的关键不在于协议,而在于它在硬件中的实现方式。换种说法,就目前而言,SRD 仅在使用 AWS Nitro DPU 时才有效。

What?

SRD(Scalable Reliable Datagram,可扩展的可靠数据报文),是AWS年推出的协议,旨在解决亚马逊的云性能挑战。它是专为AWS数据中心网络设计的、基于Nitro芯片、为提高HPC性能实现的一种高吞吐、低延迟的网络传输协议。

SRD 不保留数据包顺序,而是通过尽可能多的网络路径发送数据包,同时避免路径过载。为了最大限度地减少抖动并确保对网络拥塞波动的最快响应,在 AWS 自研的 Nitro chip 中实施 SRD。

SRD 由 EC2 主机上的 HPC/ML 框架通过 AWS EFA(Elastic Fabric Adapter,弹性结构适配器)内核旁路接口使用。

SRD的特点:

  • 不保留数据包顺序,交给上层消息传递层处理
  • 通过尽可能多的网络路径发包,利用ECMP标准,发端控制数据包封装来控制ECMP路径选择,实现多路径的负载平衡
  • 自有拥塞控制算法,基于每个连接动态速率限制,结合RTT(Round Trip Time)飞行时间来检测拥塞,可快速从丢包或链路故障中恢复
  • 由于无序发包以及不支持分段,SRD传输时所需要的QP(队列对)显著减少

Why?

为什么不是TCP?

TCP 是 IP 网络中可靠数据传输的主要手段,自诞生以来一直很好地服务于 Internet,并且仍然是大多数通信的最佳协议。但是,它不适合对延迟敏感的处理,TCP 在数据中心最好的往返延迟差不多是 25us,因拥塞(或链路故障)等待导致的异常值可以是 50 ms,甚至数秒,带来这些延迟的主要原因是TCP丢包之后的重传机制。另外,TCP传输是一对一的连接,就算解决了时延的问题,也难在故障时重新快速连线。

TCP 是通用协议,没有针对HPC场景进行优化,早在2020 年,AWS 已经提出需要移除TCP。

为什么不是RoCE?

InfiniBand 是一种用于高性能计算的流行的高吞吐量低延迟互连,它支持内核旁路和传输卸载。RoCE(RDMA over Converged Ethernet),也称为 InfiniBand over Ethernet,允许在以太网上运行 InfiniBand 传输,理论上可以提供 AWS 数据中心中 TCP 的替代方案。

EFA 主机接口与 InfiniBand/RoCE 接口非常相似。但是 InfiniBand 传输不适合 AWS 可扩展性要求。原因之一是 RoCE 需要 PFC(优先级流量控制),这在大型网络上是不可行的,因为它会造成队头阻塞、拥塞扩散和偶尔的死锁。PFC 更适合比 AWS 规模小的数据中心。此外,即使使用 PFC,RoCE 在拥塞(类似于 TCP)和次优拥塞控制下仍会遭受 ECMP(等价多路径路由)冲突。

为什么是SRD?

SRD是专为AWS设计的可靠的、高性能的、低延迟的网络传输。这是数据中心网络数据传输的一次重大改进。SRD受InfiniBand可靠数据报的启发,结合大规模的云计算场景下的工作负载,SRD也经过了很多的更改和改进。SRD利用了云计算的资源和特点(例如AWS的复杂多路径主干网络)来支持新的传输策略,为其在紧耦合的工作负载中发挥价值。

任何真实的网络中都会出现丢包、拥塞阻塞等一系列问题。这不是说每天会发生一次的事情,而是一直在发生。

大多数协议(如 TCP)是按顺序发送数据包,这意味着单个数据包丢失会扰乱队列中所有数据包的准时到达(这种效应称为“队头阻塞”)。而这实际上会对丢包恢复和吞吐量产生巨大影响。

SRD 的创新在于有意通过多个路径分别发包,虽然包到达后通常是乱序的,但AWS实现了在接收处以极快的速度进行重新排序,最终在充分利用网络吞吐能力的基础上,极大地降低了传输延迟。

SRD 可以一次性将构成数据块的所有数据包推送到所有可能路径,这意味着SRD不会受到队头阻塞的影响,可以更快地从丢包场景中恢复过来,保持高吞吐量。

众所周知,P99尾部延迟代表着只有1%的请求被允许变慢,但这也恰恰反映了网络中所有丢包、重传和拥塞带来的最终性能体现,更能够说明“真实”的网络情况。SRD能够让P99 尾延迟直线下降(大约 10 倍)。

SRD的主要功能包括:

  • 乱序交付:取消按顺序传递消息的约束,消除了队头阻塞,AWS在EFA用户空间软件堆栈中实现了数据包重排序处理引擎
  • 等价多路径路由(ECMP):两个EFA实例之间可能有数百条路径,通过使用大型多路径网络的一致性流哈希的属性和SRD对网络状况的快速反应能力,可以找到消息的最有效路径。数据包喷涂(Packet Spraying)可防止出现拥塞热点,并可以从网络故障中快速无感地恢复
  • 快速的丢包响应:SRD对丢包的响应比任何高层级的协议都快得多。偶尔的丢包,特别是对于长时间运行的HPC应用程序,是正常网络操作的一部分,不是异常情况
  • 可扩展的传输卸载:使用SRD,与其他可靠协议(如InfiniBand可靠连接IBRC)不同,一个进程可以创建并使用一个队列对与任何数量的对等方进行通信

How

SRD 实际工作的关键不在于协议,而在于它在硬件中的实现方式。换种说法,就目前而言,SRD 仅在使用 AWS Nitro DPU 时才有效。

SRD乱序交付的数据包需要重新排序才能被操作系统读取,而处理混乱的数据包流显然不能指望“日理万机”的 CPU。即便真通过CPU 来完全负责 SRD 协议并重新组装数据包流,无疑是高射炮打蚊子——大材小用,那会使系统一直忙于处理不应该花费太多时间的事情,而根本无法真正做到性能的提升。

在SRD这一不寻常的“协议保证”下,当网络中的并行导致数据包无序到达时,AWS将消息顺序恢复留给上层,因为它对所需的排序语义有更好的理解,并选择在AWS Nitro卡中实施SRD可靠性层。其目标是让SRD尽可能靠近物理网络层,并避免主机操作系统和管理程序注入的性能噪音。这允许快速适应网络行为:快速重传并迅速减速以响应队列建立。

AWS说他们希望数据包在“栈上”重新组装,他们实际上是在说希望 DPU 在将数据包返回给系统之前,完成将各个部分重新组合在一起的工作。系统本身并不知道数据包是乱序的。系统甚至不知道数据包是如何到达的。它只知道它在其他地方发送了数据并且没有错误地到达。

这里的关键就是 DPU。AWS SRD 仅适用于 AWS 中配置了 Nitro 的系统。现在不少使用AWS的服务器都安装和配置了这种额外的硬件,其价值在于启用此功能将能够提高性能。用户需要在自己的服务器上专门启用它,如果需要与未启用 SRD 或未配置 Nitro DPU 的设备通信,就不会得到相应的性能提升。

至于很多人关心的SRD未来是否会开源,只能说让我们拭目以待吧!

责任编辑:赵宁宁 来源: SDNLAB
相关推荐

2016-10-21 15:57:39

Rust编辑语言Fedora

2013-05-22 09:33:09

交互设计设计时间

2022-02-24 16:15:16

OpenHarmon鸿蒙OpenEuler

2011-08-24 10:31:01

网络协议SLIPPPP

2017-06-28 11:34:55

锐捷 医疗 物联网

2017-08-18 14:47:31

DDD微服务架构

2015-01-07 15:49:21

大数据SSD

2017-05-16 14:38:25

2009-03-21 16:43:29

SOA虚拟化IT

2016-10-21 09:45:20

RustFedoraJava

2013-08-22 11:08:27

大数据商业只能Hadoop

2013-11-08 09:15:32

大数据平板电脑

2022-06-27 13:56:10

设计模式缓存分布式系统

2011-03-16 14:51:35

2017-09-11 13:55:30

前端JavaScript物联网

2019-11-19 09:54:59

NBA机器学习数据

2020-12-22 09:31:43

区块链安全食品

2020-03-05 16:35:06

人脸识别口罩人工智能

2010-06-09 12:28:34

网络传输协议

2012-02-03 14:06:34

Node.js
点赞
收藏

51CTO技术栈公众号