AWS 用于弹性可扩展 HPC 的云优化传输协议

ゝ一世哀愁。 2023-10-06 23:22 45阅读 0赞

## 目录 ##

#### 文章目录 ####

*  目录
 *  声明
 *  前言
 *  摘要
 *  概述
 *   *  为什么不是 TCP
     *  为什么不是 RoCE
 *  我们的方法

## 声明 ##

论文精度系列文章，是笔者个人对论文内容的私有解读，可能会在部分引用的基础上进行大量的个人理解与阐述，很可能会歪解论文原本的含义，因此推荐读者阅读论文原文，下方会提供地址链接。

## 前言 ##

*  论文：
    
     *  https://aijishu.com/a/1060000000255945
     *  https://www.modb.pro/db/193519

## 摘要 ##

AWS 对网络进行了重新梳理，以提供 HPC 应用程序所需的持续低延迟，同时保持公共云的优势：可扩展性、按需弹性容量、成本效益以及快速采用更新的 CPU 和 GPU。

我们构建了一个新的网络传输协议，可扩展的可靠数据报（SRD，Scalable Reliable Datagram），旨在利用现代商业化的多租户数据中心网络（具有大量网络路径），同时克服它们的局限性（负载不平衡和无关流冲突时的不一致延迟）。

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

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

## 概述 ##

云计算的主要好处之一是按照需要，瞬间提供和取消配置的资源。这与传统的 HPC 截然不同，传统的 HPC 是定制的（需要数月或数年），因为其成本和容量限制，HPC 通常是难以获取的。使用定制系统进行 HPC 的主要原因之一是构建高性能网络并在应用程序之间共享的挑战。在云计算环境中，使用 InfiniBand 等专用硬件或专用于 HPC 工作负载的商用硬件都非常昂贵、难以扩展且难以快速发展。

AWS 选择使用现有 AWS 网络（从 100Gbps 开始）为客户提供经济实惠的超级计算，并添加了新的 HPC 优化网络接口，作为 AWS Nitro 卡提供的网络功能的扩展。

正如预期的那样，在共享网络上运行 HPC 流量会带来一系列挑战。AWS 使用商用以太网交换机来构建具有 ECMP（等价多路径）路由的高基数折叠 CLOS 拓扑。ECMP 通常用于使用流哈希在可用路径上静态地对流进行条带化。流到路径的这种静态映射有利于保持 TCP 的每个流的顺序，但它不考虑当前的网络利用率或流率。

哈希冲突会导致某些链路上出现 “热点”，从而导致路径间负载分布不均匀、数据包丢失、吞吐量降低和尾部延迟高（如 Al-Fares 等人、Ghorbani 等人、Handley 等人、Hopps 等人和 Vanini 等人在文章中广泛研究的那样)。即使在过度配置的网络中，大量流量也可能影响不相关的应用程序。

数据包延迟和数据包丢弃会干扰 HPC/ML 应用程序的低延迟要求，从而降低扩展效率。延迟异常值对这些应用程序具有深远的影响，因为它们通常遵循批量同步并行编程模型，计算的周期之后是整个集群的批量同步。单个异常值将使整个集群等待，阿姆达尔定律决定了可扩展性。

### 为什么不是 TCP ###

TCP 是 IP 网络中可靠数据传输的主要手段，它自诞生以来一直很好地服务于 Internet，并且仍然是大多数通信的最佳协议。但是，它不适合对延迟敏感的处理。对于 TCP 在数据中心，而最好情况的往返延迟差不多是 25us，因拥塞（或链路故障）的等待时间异常值可以是 50 ms，甚至数秒，即使当替代无拥塞网络路径之间的任何地方可用。这些异常值的主要原因之一是丢失 TCP 数据包的重传：TCP 被迫保持重传所以超时很多，这也解释了操作系统延迟问题。

### 为什么不是 RoCE ###

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

我们考虑了 RoCEv2 支持，EFA 主机接口与 InfiniBand/RoCE 接口非常相似。但是，我们发现 InfiniBand 传输不适合 AWS 可扩展性要求。原因之一是 RoCE 需要 PFC（优先级流量控制），这在大型网络上是不可行的，因为它会造成队头阻塞、拥塞扩散和偶尔的死锁。

郭在文章中描述了一种大规模 PFC 问题的解决方案，但它明确依赖于比 AWS 数据中心小得多的数据中心规模。此外，即使使用 PFC，RoCE 在拥塞（类似于 TCP）和次优拥塞控制下仍会遭受 ECMP 冲突。

## 我们的方法 ##

由于 TCP 和其他传输协议都不能提供我们需要的性能级别，因此在我们使用的网络中，我们选择设计自己的网络传输协议。

SRD（可扩展的可靠数据报）针对超大规模数据中心进行了优化：它提供跨多个路径的负载平衡以及从数据包丢失或链路故障中快速恢复。它利用商用以太网交换机上的标准 ECMP 功能并解决其局限性：发送方通过操纵数据包封装来控制 ECMP 路径选择。SRD 采用专门的拥塞控制算法，通过将排队保持在最低限度，有助于进一步降低丢包的机会并最大限度地减少重传时间。

我们做出了一个有点不寻常的 “协议保证” 选择：SRD 提供可靠但乱序的交付，并将次序恢复留给上层。我们发现严格的有序交付通常是不必要的，强制执行它只会造成队列头部阻塞、增加延迟并减少带宽。例如：如果使用相同的消息标签，消息传递接口（MPI）标记的消息必须按顺序传递。因此，当网络中的并行导致数据包无序到达时，我们将消息顺序恢复留给上层，因为它对所需的排序语义有更好的理解。

我们选择在 AWS Nitro 卡中实施 SRD 可靠性层。我们的目标是让 SRD 尽可能靠近物理网络层，并避免主机操作系统和管理程序注入的性能噪音。这允许快速适应网络行为：快速重传并迅速减速以响应队列建立。

*  图 1 不使用和使用 EFA 的 HPC 堆栈  
    ![在这里插入图片描述][f5daa94a368e4759bf7319ddfb1003b8.png]

SRD 作为 EFA PCIe 设备公开给主机。EFA 是 Amazon EC2 实例（即虚拟和裸机服务器）的网络接口，使客户能够在 AWS 上大规模运行紧密耦合的应用程序。特别是，EFA 支持运行 HPC 应用程序和 ML 分布式训练，目前支持多种 MPI 实现：OpenMPI、Intel MPI 和 MVAPICH，以及 NCCL。如图 1 所示，EFA 提供了一个 “用户空间驱动程序”，它利用操作系统绕过硬件接口来增强实例间通信的性能（减少延迟、抖动、避免 OS 系统调用、并减少内存副本），这是扩展这些应用程序的关键。

[f5daa94a368e4759bf7319ddfb1003b8.png]: https://img-blog.csdnimg.cn/f5daa94a368e4759bf7319ddfb1003b8.png