这篇文章最初发表在 NVIDIA 技术博客上。
甲骨文是世界上顶级的云服务提供商之一，支持超过 22000 名客户，报告每季度收入接近 40 亿美元，年增长率超过 40% 。Oracle Cloud Infrastructure（ OCI ）正以更快的速度增长，为每个工作负载提供完整的云基础设施。
OCI 在过去 18 个月内增加了 11 个地区，目前提供 41 个区域，支持托管、内部部署、混合和多云部署。它使客户能够在可扩展的体系结构上混合运行定制的第三方 ISV 和 Oracle 应用程序。OCI 提供可扩展的网络和工具，以支持安全性、可观察性、合规性和成本管理。
OCI 的一个独特之处在于，它能够提供高性能计算（ HPC ）、 Oracle Exadata 和自主数据库，以及基于 GPU 的人工智能和机器学习（ ML ）应用程序，其快速的基础设施即服务（ IaaS ）性能与专用的本地基础设施相媲美。支持远程直接内存访问（ RDMA ）的可扩展、低延迟网络是提供这种高性能的关键组件。有关更多详细信息，请参阅First Principles: Building a High-Performance Network in the Public Cloud.
HPC 和 GPU 驱动计算的网络化挑战
HPC 应用程序、 GPU 驱动的人工智能工作负载和 Exadata 上的 Oracle 自治数据库的一个共同点是，它们都作为分布式工作负载运行。数据处理同时发生在多个节点上，使用几十到数千个 CPU 和 GPU 。这些节点必须相互通信，在多阶段问题解决中共享中间结果，使用千兆字节到千兆字节的存储来访问公共数据，并且经常将分布式计算的结果组合成一个有凝聚力的解决方案。
这些应用程序需要高吞吐量和低延迟来跨节点通信，以快速解决问题。阿姆达尔定律指出，并行化任务的速度受到任务本身串行且无法并行化的程度的限制。在节点之间传输信息所需的时间量增加了任务固有的串行时间，因为节点必须等待数据传输完成，以及任务中最慢的节点完成，然后才能开始作业的下一个可并行部分。
因此，集群网络的性能变得至关重要，优化的网络可以使分布式计算集群比在较慢的网络上运行的相同计算资源更快地交付结果。这节省了时间，加快了作业完成并降低了成本。
什么是 RDMA ？
RDMA 是远程直接内存访问，这是在不同机器之间传输数据的最有效方式。它可以使服务器或存储设备在不需要额外副本并且不中断主机 CPU 的情况下，通过网络进行通信和共享数据。它用于人工智能、大数据和其他分布式技术计算工作负载。
传统的网络会多次中断 CPU ，并在数据从应用程序通过操作系统内核传输到适配器，然后在接收端备份堆栈时，对正在传输的数据进行多个拷贝。 RDMA 在每一端只使用一个数据副本，通常绕过内核，将数据直接放入接收机器的内存中，而不会中断 CPU 。
此过程可以降低网络上的延迟和吞吐量，并减少服务器和存储系统的 CPU 利用率。如今，大多数 HPC 、技术计算和人工智能应用都可以通过 RDMA 来加速。有关更多详细信息，请参阅RDMA 如何成为快速网络的燃料。
什么是 InfiniBand ？
InfiniBand 是一种无损网络，专为 HPC 、 AI 、大数据和其他分布式计算工作负载优化。它通常支持数据中心网络和 RDMA 的最高可用带宽（目前每个连接 400 Gbps ），使机器能够在不中断主机的情况下进行通信和共享数据 CPU 。
InfiniBand 适配器从 CPU 卸载网络和数据移动任务，并具有优化、高效的网络堆栈，使 CPU GPU 和存储能够快速高效地移动数据。 InfiniBand 适配器和交换机还可以在网络中执行特定的计算和数据聚合任务，主要围绕消息传递接口（ MPI ）集体操作。
这种网络内计算可以加快分布式应用程序的速度，从而实现更快的问题解决。它还可以释放服务器 CPU 核心，提高能源效率。InfiniBand 还可以自动平衡流量负载，并围绕断开的链路重新路由连接。
因此，许多专门用于 AI 、 HPC 、大数据或其他科学计算的计算集群在 InfiniBand 网络上运行，以提供尽可能高的性能和效率。当分布式计算性能是首要任务，并且可以接受采用专门的网络适配器、交换机和管理堆栈时， InfiniBand 是首选网络。但由于其他原因，数据中心可能会选择运行以太网而不是 InfiniBand 。
什么是 RoCE ？
聚合以太网上的 RDMA（RoCE）是一种开放标准，允许通过以太网进行远程直接内存访问和网络卸载。目前最流行的实现是 RoCEv2，它使用运行在 UDP（第 4 层）和 IP（第 3 层）之上的 InfiniBand 通信层，这些层运行在高速以太网（第 2 层）连接之上。
它还支持远程直接内存访问、零拷贝数据传输以及在移动数据时绕过 CPU 。在以太网上使用 IP 协议使 RoCEv2 能够在标准以太网上路由。 RoCE 为以太网带来了 InfiniBand 的许多优势。 RoCEv2 通过以太网上的 UDP 和 IP 协议运行 InfiniBand 传输层。 iWARP 在以太网上的 TCP 协议之上运行 iWARP 协议，但由于性能和实现方面的挑战，未能获得广泛采用（图 1 ）。
图 1 。 NVIDIA InfiniBand 在 InfiniBand 网络上运行 InfiniBand 传输层
RoCE 网络如何解决可扩展性问题？
RoCE 在数据包丢失率非常低的网络上运行效率最高。传统上，小型 RoCE 网络使用基于 IEEE 802 . 1Qbb 规范的优先级流控制（ PFC ）来使网络无损。如果任何目的地太忙而无法处理所有传入流量，它会向下一个上游交换机端口发送一个暂停帧，该交换机会在暂停帧中指定的时间内保持流量。
如果需要，交换机还可以向结构中的下一个交换机发送暂停帧，并最终发送到业务流的发起方。这种流控制避免了端口缓冲区在任何主机或交换机上溢出，并防止了数据包丢失。您可以使用 PFC 管理多达八个流量类，每个类都有自己的流和暂停，与其他类不同。
然而， PFC 有一些局限性。它仅在开放系统互连（ OSI ） 7 层模型的第 2 层（以太网）级别运行，因此无法跨不同的子网工作。虽然一个子网可能有数千或数百万个节点，但一个典型的子网仅限于 254 个 IP 地址，并且由数据中心内的几个机架（通常是一个机架）组成，这对于大型分布式应用程序来说是不可扩展的。
PFC 在粗粒度端口级别上运行，无法区分共享该端口的流。此外，如果在多级交换机结构中使用 PFC ，则一个流的一个目标交换机上的拥塞可能会扩散到多个交换机，并阻止与拥塞流共享一个端口的不相关流量。解决方案通常是实现一种形式的拥塞控制。
大型 RoCE 网络的拥塞管理
TCP 协议包括对基于丢弃的数据包的拥塞管理的支持。当端点或交换机被流量淹没时，它会丢弃一些数据包。当发送器未能从发送的数据中接收到确认时，发送器会认为数据包是由于网络拥塞而丢失的，从而降低其传输速率，并重新发送可能丢失的数据。
这种拥塞管理方案不适用于以太网上的 RDMA （因此也不适用于 RoCE ）。 RoCE 不使用 TCP ，并且等待数据包超时然后重新传输丢失数据的过程引入了太多的延迟以及延迟或抖动的太多可变性，以实现高效的 RoCE 操作。
大型 RoCE 网络通常实现一种更为主动的拥塞控制机制，称为显式拥塞通知（ ECN ），当网络中发生拥塞时，交换机会对分组进行标记。标记的分组会提醒接收端即将发生拥塞，接收端会使用拥塞通知分组或 CNP 来提醒发送端。收到 CNP 之后，发送端就会知道应该减慢传输速率，直到流路径准备好处理更高速率的业务为止。
拥塞控制跨 OSI 模型的第 3 层工作，因此它跨不同的子网工作，并可扩展到数千个节点。但是，它需要对支持 RoCE 流量的交换机和适配器进行设置更改。交换机何时标记数据包的拥塞、发送方停止发送数据的速度以及发送方恢复高速传输的积极性等实现细节对于确定 RoCE 网络的可扩展性和性能都至关重要。
图 2 :当交换机队列变满时， ECN 将传出数据包标记为 CE –经历拥塞。流接收方接收数据包并通知发送方放慢传输速度
其他基于以太网的拥塞控制算法包括量化拥塞通知（ QCN ）和数据中心 TCP （ DCTCP ）。在 QCN 中，交换机直接向流发送器通知潜在拥塞的级别，但该机制仅在 L2 上起作用。因此，它不能跨多个子网工作。 DCTCP 使用发送方的网络接口卡（ NIC ）来测量特殊数据包的往返时间（ RTT ），以估计存在多少拥塞以及发送方必须在多大程度上减慢数据传输。
但是， DCTCP 缺乏在不存在拥塞时快速启动或恢复发送数据的快速启动选项，给主机 CPU 带来了沉重的负载，并且没有良好的机制让接收器与发送器通信。无论如何， DCTCP 需要 TCP ，因此它不能与 RoCE 一起使用。
使用具有更新 RDMA 功能的小型 RoCE 网络 ConnectX SmartNICs 来自 NVIDIA 或更新版本的 NVIDIA BlueField DPUs，可以使用 Zero Touch RoCE（ZTR）实现卓越的 RoCE 性能，而无需在交换机上设置 PFC 或 ECN，从而大大简化了网络设置。然而，ZTR 的最初部署仅限于小型 RoCE 网络集群，使用 RTT 进行拥塞通知的更具可扩展性的 ZTR 版本仍处于验证阶段。
OCI 如何实现可扩展 RoCE 网络
OCI 确定某些云工作负载需要 RDMA 才能获得最大性能。其中包括人工智能、 HPC 、 Exadata 、自主数据库和其他 GPU 驱动的应用程序。在以太网上的两个标准化 RDMA 选项中，他们选择 RoCE 是因为它的性能和更广泛的采用。
RoCE 实现需要扩展到跨包含数千个节点的集群运行，并提供持续的低延迟，以确保为云客户提供卓越的体验。
经过大量的研究、测试和精心设计，OCI 决定基于 数据中心量化拥塞通知（DC-QCN）算法，优化针对不同 RoCE 加速应用程序工作负载的解决方案。OCI DC-QCN 以 ECN 为基础，最少使用 PFC。
图 3 。 OCI-RoCE 网络在整个网络结构中使用 ECN ，加上仅在主机和 ToR 交换机之间使用有限数量的单向 PFC
RoCE 的独立网络
OCI 为 RoCE 流量建立了一个单独的网络，因为 RDMA 网络的需求往往与常规数据中心网络不同。不同类型的应用程序流量、拥塞控制和路由协议都喜欢有自己的队列。每个 NIC 通常只支持八个流量类， RDMA 和非 RDMA 工作负载的 NIC 和交换机配置设置以及固件可能不同。出于这些原因，为 RoCE 流量和 RoCE 加速应用程序提供单独的以太网是有意义的。
在边缘有限地使用 PFC
OCI 仅在网络边缘单向地实现了有限级别的 PFC 。如果端点的 NIC 缓冲区已满，端点可以要求机架顶部（ ToR ）交换机暂停传输。但是， ToR 开关从不要求端点暂停并且不通过 pause 请求网络上的叶交换机或主干交换机。如果传入的业务流量暂时超过接收器处理和缓冲数据的能力，则该过程防止线路头阻塞和拥塞扩展。
ECN 机制确保很少需要 PFC 。在 ECN 反馈机制激活时接收节点的 NIC 缓冲区暂时溢出的罕见情况下， PFC 使接收节点能够短暂暂停传入数据流，直到发送器接收到 CNP 并降低其传输速率。
从这个意义上说，您可以使用 PFC 作为最后的保护措施，以防止网络边缘（端点）的缓冲区溢出和数据包丢失。 OCI 设想，使用下一代 ConnectX SmartNIC ，您可能不需要 PFC ，即使是在网络边缘。
多种拥塞控制
OCI 确定，对于不同的工作负载，他们至少需要 DC-QCN 中的三个定制拥塞控制配置文件。即使在需要 RDMA 网络的分布式应用程序的世界中，需求也因以下类别而异：
- 对延迟敏感，需要持续的低延迟吞吐量
- 灵敏、高吞吐量
- 混合，需要低延迟和高吞吐量之间的平衡
自定义拥塞控制的主要设置是概率P（范围从 0 到 1 ）交换机基于队列阈值 K 将 ECN 标记添加到传出数据包min和 Kmax。P当交换机队列不忙时，从 0 开始，这意味着它没有拥塞的机会。
当端口队列达到 Kmin时, P上升到 0 以上，增加了任何数据包被标记为 ECN 的机会。当队列填充到值 K max 时，P设置为 Pmax（通常为 1 ），这意味着该交换机上该流的每个传出数据包都标记有 ECN 。不同的 DC-QCN 简档通常具有无拥塞范围，其中P为 0 ，这是一个潜在的拥塞范围，其中P介于 0 和 1 之间，以及拥塞范围，其中P是 1 。
一组更激进的阈值具有更低的 Pmin和 Pmax，导致更早的 ECN 分组标记和更低的延迟，但也可能导致更低的最大吞吐量。一组松弛的阈值具有更高的 Pmin和 Pmax，用 ECN 标记更少的数据包，导致一些更高的延迟，但也导致更高的吞吐量。
图 4 右侧是 OCI 工作负载的三个示例： HPC 、 Oracle 自治数据库和 Exadata 云服务，以及 GPU 工作负载。这些服务使用不同的 RoCE 拥塞控制配置文件。 HPC 工作负载对延迟敏感，并放弃一些吞吐量以保证更低的延迟。因此， Kmin和 Kmax相同且低（攻击性），并且在低排队量下，它们用 ECN 标记所有数据包的 100% 。
大多数 GPU 工作负载在延迟方面更宽容，但需要最大吞吐量。随着缓冲区从 K 倾斜， DC-QCN 配置文件逐渐标记更多的数据包Kmin至 Kmax并将这些值设置得相对较高，以使交换机缓冲区在向流端点发出它们变慢的信号之前更接近满。
对于自主数据库和 Exadata 云服务工作负载，所需的延迟和带宽平衡介于两者之间。标记或增加P值在 K 之间逐渐增加Kmin和 Kmax，但是这些值被设置为比 GPU 工作负载更低的阈值。
图 4 。 OCI 将 DC-QCN 设置为使用不同的 Kmin和 KmaxECN 数据包标记的阈值，从而针对不同的工作负载优化 RoCE 网络上的网络行为
有了这些设置，一旦队列达到 K ， HPC 流就会获得 100% 的 ECN 数据包标记min级别（此处与 K 相同max) 用于早期和积极的拥塞控制参与。 Oracle 自治数据库和 Exadata 流看到适度早期的 ECN 标记，但只有一部分数据包被标记，直到缓冲区达到 Kmax数量
其他 GPU 工作负载具有更高的 Kmin设置为直到交换机队列相对较满时才开始 ECN 标记，并且只有当队列接近满时才会进行 100%ECN 标记。不同的工作负载获得所需的自定义拥塞控制设置，以提供延迟和吞吐量的理想平衡，从而实现最大的应用程序性能。
利用先进的网络硬件
RoCE 网络实现高性能的一个重要因素是所使用的网卡类型。 NIC 将包括 RDMA 在内的网络堆栈卸载到专用芯片，以减轻 CPU 和 GPU 的工作负荷。 OCI 使用 ConnectX SmartNICs，在 TCP 和 RoCE 流量方面具有市场领先的网络性能。
这些 SmartNIC 还支持快速的 PFC 和 ECN 反应时间，用于检测带有 ECN 标记的数据包或 PFC 暂停帧、发送 CNP 以及响应拥塞通知向下和向上调整数据传输速率。
NVIDIA 长期以来一直是 RDMA 、 PFC 、 ECN 和 DC-QCN 技术开发和支持领域的领导者，也是高性能 GPU 和 GPU ‘连接领域的领导者。 ConnectX 中的高级 RoCE 卸载实现了 OCI 网络上更高的吞吐量和更低的延迟，其快速、基于硬件的 ECN 反应时间有助于确保 DC-QCN 平稳运行。
通过在专用 RoCE 网络上实现优化的拥塞控制方案，再加上本地化 PFC 、多个拥塞控制配置文件和 NVIDIA 网络适配器的组合， OCI 构建了一个非常可扩展的集群网络。它非常适合分布式工作负载，如 AI 和 ML 、 HPC 和 Oracle 自治数据库，并提供接近 InfiniBand 网络所能实现的高吞吐量和低延迟性能。
强调数据位置
通过优化集群网络性能， OCI 还管理数据位置以最大限度地减少延迟。由于 RoCE 连接的集群规模很大，通常跨越多个数据中心机架和大厅，即使在 100 、 200 和 400 Gbps 网络连接的时代，光速也没有改变，更长的电缆会导致更高的延迟。
到数据中心不同大厅的连接需要经过更多的交换机，每个交换机跳跃都会增加一些纳秒的连接延迟。 OCI 与其客户和作业调度程序共享服务器位置信息，因此他们可以调度作业以使用网络中彼此靠近的服务器和 GPU 。
例如 NVIDIA Collective Communication Library（ NCCL ）可以获取 OCI 网络拓扑和服务器位置信息，并相应地调度 GPU 工作。因此，计算和存储连接可以通过更少的交换机跳数和更短的电缆长度，以减少集群内的平均延迟。
它还减少了向主干交换机发送的流量，简化了流量路由和负载平衡决策。 OCI 还与交换机供应商合作，使交换机更能感知负载，从而可以将流路由到不那么繁忙的连接。每个交换机通常在网络上有两个上下连接，为任何流启用多个数据路径。
结论
通过投资于一个专用 RoCE 网络，该网络具有 DC-QCN 、高级 ConnectX NIC 和自定义拥塞控制配置文件的优化实现， OCI 提供了一个高度可扩展的集群，支持许多不同工作负载和应用程序的加速计算。 OCI 集群网络同时提供高吞吐量和低延迟。对于小型集群，往返时间的一半的延迟可能只有 2 微秒。对于大型集群，延迟通常在 4 微秒以下。对于超大的超星系团，延迟在 4-8 微秒的范围内，大多数流量的延迟都在这个范围的低端。
Oracle Cluster Infrastructure 使用一种创新的方法在以太网上为大量分布式工作负载提供可扩展的 RDMA 供电的网络，为客户提供更高的性能和价值。
有关详细信息，请参阅以下资源：
