当前位置：首页 > NSDI > 正文

【NSDI 2022】RDC：边缘拓扑可配置的高能效数据中心网络拥塞缓解方法

NSDI
2022-10-18
2113
更新：2023-01-04 21:41:40

# 摘要

**无机架数据中心(RDC)**是一种新型的网络架构，从逻辑上消除了传统数据中心的机架边界及其带来的低效。随着现代应用程序产生越来越多的机架间流量，传统架构面临在Core交换机处的竞争、机架间带宽利用不均衡以及更长的网络路径。RDC通过允许服务器在运行时逻辑上跨越机架边界来解决这些限制。我们的设计通过在ToR交换机和服务器之间的网络边缘插入电路交换机，并通过重新配置电路来根据流量模式跨机架重新组合服务器来实现这一点。我们在硬件测试平台和数据包级仿真中对RDC进行了广泛的评估，结果表明，RDC可以将4:1的超额订阅网络的实际应用速度提高1.78∼3.9倍、大规模仿真提高10倍；此外，与传统的非阻塞网络相比，RDC的每瓦性能好2.4倍。

# **1、引言**

在过去十年中，数据中心网络(DCN)的重要性导致了一系列DCN架构方案。尽管这些方案对核心网有着相互竞争的设计，但对网络边缘的设计是相似的：服务器组织在机架中。核心网(network core)连接多个机架，每个机架承载数十台服务器，这些服务器通过机架顶部(ToR)交换机连接。标准化机架实现了统一的电源和冷却，并显著节省了空间和电缆。这种基于机架的拓扑和连接模式在现有DCN架构的设计中根深蒂固。

虽然机架内的流量不会出现拥塞，但由于核心网中的超额订阅，机架间的流量通常不得不争夺带宽。同时，机架间的流量在数据中心工作负载中不断增加。首先，由于资源碎片、大规模作业、容错的特定应用程序放置约束和基于服务的机架组织，越来越多的DCN流量正在逃离机架边界，例如，一个机架可以托管存储服务器，另一个机架可以托管缓存服务器。其次，离开pod的流量也在增加。例如，web前端集群可能需要从数据库集群检索数据或将作业提交到Hadoop集群。

因此，高效处理跨机架流量的需求激发了许多方法；但他们有一个共同点——他们将机架设计(即连接数十台服务器的ToR交换机)视为输入条件。首先，非阻塞网络及其替代方案旨在扩大核心网的容量。然而，由于基于CMOS的电路交换机的扩展限制，在保持数据中心功率预算的同时构建这样的网络具有挑战性。其次，机架级可配置网络通过额外的电缆、激光器或天线在通信最密集的机架之间增加额外带宽，以缓解核心瓶颈。然而，额外路径的数量通常是有限的，这限制了性能的提高。第三，更智能的作业放置和执行策略也可以通过根据作业的流量模式安排作业来减少机架间流量。然而，如果流量模式在运行时波动，或者如果应用程序指示放置并强制流量跨机架，则这些放置解决方案无法很好地执行。

本文研究了设计空间中的一个互补点，我们称之为无机架数据中心(RDC)架构。它在逻辑上消除了固定的拓扑机架边界，同时保留了基于机架的设计的优点，例如有组织的电源和冷却，以及空间效率。在RDC中，服务器仍然安装在物理机架上，但它们不会静态绑定到任何ToR交换机。相反，它们可以逻辑地从一个ToR移动到另一个ToR。这是通过使用电路交换机(CS)实现的，可以动态重新配置这些交换机以形成不同的连接模式。换句话说，服务器保持不动，但电路变化可能会将其转移到不同的拓扑位置。因此，这种新的体系结构不适用于任何静态配置，因此可以根据需要对彼此通信频繁的服务器进行分组，并在模式再次更改时对其进行重新分组。RDC支持的这种动态服务器重组在许多常见的现实场景中带来了性能优势(详见第2节)。

我们做出了以下贡献：1)一种称为RDC的新型架构，可以重新配置该架构，以同一逻辑连接不同机架下的服务器，而不管物理机架边界如何；2)低延迟RDC控制平面和算法，根据流量模式不断优化RDC拓扑；3)在测试床和仿真环境中的RDC原型，证明RDC将4:1超额订阅网络的性能对于实际应用提高了1.78∼3.9倍，对于大规模仿真性能提高大于10倍；此外，与传统的非阻塞网络相比，RDC的每瓦性能好2.4倍。

# **2、动机**

RDC的动机是当今数据中心固有的机架边界导致的效率低下。RDC支持动态拓扑重新配置以重组服务器，从而提高现代工作负载的性能。我们建议使用电路交换技术实现RDC。

## **2.1 机架尺寸的固有限制**

今天的DCN作为基本单元组织在物理机架中。机架内的通信通过ToR交换机进行，与跨机架的通信相比，具有更低的延迟和更高的吞吐量。该机架边界由两种趋势组合而成。首先，应用程序正在变得数据密集型。DNN训练、迭代机器学习、HPC、大数据框架(MapReduce、Spark、HDFS)和许多其他工作负载需要广泛的数据通信。其次，领域特定加速器(GPU、TPU)和非易失性存储器(NVM)的出现进一步将主要瓶颈从计算转移到网络IO。这些趋势的趋同导致需要尽可能最大化机架级性能。Broadcom的Tomahawk-4 64x400 Gbps是当今市场上市面上最快的以太网交换机专用集成电路，仅支持数十台服务器的机架边界，同时保持最大的机架级性能。几年前，有人提出End-of-Row架构作为替代方案，将多个低端口速度服务器机架连接到高基数(high-radix)边缘交换机，以形成更大的逻辑机架。然而，高基数交换在高端口速度下是不可行的：400 Gbps端口现在很常见，以太网标准正在发展到TB级。因此，在可预见的未来，数十台服务器的物理机架边界将继续存在。需要新的解决方案来缓解机架间级瓶颈。

## **2.2 机架边界引入瓶颈**

**1、作业分散在机架上**。如果机架资源分散，作业可能会分布在机架上。这部分是因为集群调度器在本地将资源分配给自己的作业；此外，动态作业调度确保机架资源并非总是整齐地打包。这种资源碎片化导致机架间流量过大，由于超额订阅，机架间流量争夺带宽。

**2、具有动态流量模式的工作负载**。许多数据密集型应用程序(例如DNN训练、HPC)由多个阶段组成，每个阶段具有不同但可预测的流量模式。例如，分布式矩阵乘法(DMM)在每次迭代中在不同的服务器子集之间广播(一对多)和移动(一对一)业务模式(图8(e))。当这些作业在集群中共存时，整体组合流量模式将动态地、可预测地发生变化。对于此类工作负载，静态作业分配不足以同时定位所有通信模式。

**3、具有放置约束的应用**。应用程序可能有意将其实例分布在不同机架上，以平衡负载，以减少同步功耗峰值，或实现容错。例如，为了提高弹性，一些分布式存储系统(如HDFS)需要在不同的机架上放置至少一个副本。这些要求导致了通过设计跨越机架边界的放置约束。

**4、出Pod流量不均衡**。在大型数据中心中，机架间的通信模式通常是不均衡的，每个机架的机架外通信需求是不同的。例如，来自前端服务器的流量中只有7.3%是跨机架的，而缓存服务器的流量为40.7%。在操作上，数据中心倾向于根据服务器类型对服务器进行分组。因此，上述机架外流量需求的异构性将使一些机架的上行链路高度拥塞(例如缓存)，而其他机架仍有未使用的带宽(例如前端)。

## **2.3 脸书跟踪分析：案例研究**

**方法**。我们使用了Facebook发布的一个公共数据集，其中包含在一天内从其生产数据中心收集的数据包级跟踪。跟踪是从“前端”、“数据库”和“Hadoop”集群收集的，以1:30K的速率采样，每个数据包包含关于源服务器和目标服务器的信息。为了了解消除机架边界的好处，我们使用第3节中介绍的算法将不同机架的服务器重新组合为“逻辑”机架，仿真了无机架设计。我们有两个主要发现。

**观察结果#1：机架间流量密集**。从跟踪中的第一个观察结果是，大多数流量都会跨越pod中的机架边界。图1(a)显示了在2分钟的时间间隔内收集的具有74个机架的前端Pod内的流量模式热力图。如果机架i中的一台服务器向机架j中的另一台服务器发送更多流量，则热力图中的像素(i，j)将变暗。机架内流量出现在对角线上(即，i=j)。分散的点表明，流量不表现出机架局部性。事实上，此热力图中96.26%的流量是机架间流量，而不是机架内流量。数据库跟踪也存在类似的趋势：92.89%的流量是机架间的，但是机架内的。Hadoop trace具有更多的机架内流量，但仍有52.49%的流量是机架间而不是机架内。

**含义#1：重新组合服务器可以提高局部性**。图1(b)显示了根据通信强度在不同机架下重新组合服务器时的热力图，仿真了RDC的预期效果。在这里，大多数流量位于对角线上，机架间流量显著减少到38.4%。假设一个4:1的超额订阅网络，过去的机架间流量现在享有2.82倍的更高带宽。对于数据库和Hadoop跟踪，重组后的机架间流量比分别为28.4%和41.6%。

**观察结果#2：出Pod流量不均衡**。另一个值得注意的趋势是出Pod流量严重失衡。图1(c)根据机架在20分钟间隔内发送的出Pod流量(流量跟踪：数据库)对机架进行排序，其中X轴是机架ID，Y轴是(标准化的)出Pod流量。正如我们所看到的，前11个机架占了Pod外流量的近50%，几乎一半的机架从未跨Pod发送流量。因此，ToR交换机的一些上行链路被大量利用，而其他链路几乎总是空闲的。负载不均衡，定义为max(Li)/avg(Li)，其中Li是机架i的出Pod流量，高达4.17。我们在其他跟踪上发现了定性相似的结果。

**含义#2：对服务器分组可以缓解负载不均衡**。图1(d)显示了如果服务器可以重新分组的结果。在仿真的RDC网络中，机架之间的机架间流量负载平衡更加均匀，负载不均衡值达到1.14。此外，Pod外流量的聚合带宽增加到以前带宽的1.79倍。这将更好地利用ToR上行链路，并避免由于不均衡导致任何特定链路拥塞。

## **2.4 RDC的好处**

在应用级需求和基于跟踪的分析的驱动下，我们提出了无机架数据中心(RDC)的概念，该概念在逻辑上消除了物理机架边界，同时保持了高速机架级性能。在RDC中，服务器安装在同一“物理机架”上，共享电源和冷却系统，但可以在逻辑上跨ToR交换机移动。我们将同一ToR服务的新服务器组称为“逻辑机架”。图2说明了RDC由于服务器重组而带来的好处。

**1、缓解资源碎片化的影响**。RDC可以通过在同一逻辑机架下重新定位流量大的服务器组来减少资源碎片的影响，从而减少机架间的流量。RDC可以完全本地化可能打包在一个逻辑机架中的较小作业，如图2(a)左侧的作业。即使对于无法打包在一个逻辑机架内的较大作业，RDC也通过以下方式对其优化：(1)将尽可能多的流量本地化到逻辑机架，如图2(a)右侧的作业；和(2)最小化所有作业的总体机架间流量，使核心带宽由必须跨越机架边界的更少流量共享。

**2、优化动态**流量模式**。RDC支持的动态服务器重组能力可以优化具有可变但可预测流量模式的应用程序。具有如图2(b)所示的变化模式。RDC能够动态更改拓扑并最小化所有模式的机架间流量。

**3、适应应用程序放置约束**。如图2(c)所示，RDC可以在本地化流量的同时满足应用程序级约束。例如，HDFS总是要求在不同的机架上放置至少一个数据块副本。通过将不同机架中的服务器重新组合到一个逻辑机架中，RDC可以将副本放置到不同的物理机架上，但位于同一个“逻辑”机架内，这提供了更高的带宽，同时也满足HDFS的副本放置策略。

**4、平衡出Pod流量**。RDC能够根据服务器的出站流量需求重新组合服务器，并平衡链路利用率，从而缓解瓶颈。在图2(d)中，根据出Pod流量需求改变分组后，不均衡比已从1.5降至1。

## **2.5 实现RDC**

电路交换机(CS, Circuit switch)广泛用于提供端点之间的可配置连接，这非常适合我们上面讨论的RDC的服务器重组功能。RDC的一个实现是用一个CS连接pod内的所有服务器和所有ToR交换机。或者，RDC还可以使用多个端口数较小的CS来形成分布式可配置的服务器到ToR的结构/fabric。

RDC可以潜在地利用任何类型的CS技术，包括光学和电路交换机。然而，在高数据速率下，光收发器是标准接口。因此，为了实现长期可持续性，我们考虑了各种光电路交换(OCS，optical circuit switching)技术。目前有几种OCS技术可用，如3D/2D MEMS、AWGR等。基本上，OCS不执行数据包级处理，并使用镜像旋转、衍射等转发光子束，这导致了一些固有的优势，例如a)不可知数据速率(或调制格式)，b)可忽略的功耗，c)由于没有缓冲而可忽略的转发延迟，和d)OCS端口不需要收发器。此外，不同的OCS技术可以提供非常快速的切换。例如，基于2D MEMS的OCS提供微秒交换机，具有最新可调谐收发器的AWGR交换机可以提供纳秒交换机。此外，OCS是高度可靠的，由于其简单性，大多没有固件错误和软件错误配置。

# **3、RDC架构**

## **3.1 连接结构**

RDC通过在服务器和ToR交换机之间的边缘层插入一个或多个电路交换机(CS)，改变了传统的多层Clos拓扑，因此服务器可以通过电路重新配置连接到不同的ToR交换机。网络的聚合层和核心层保持不变。每个电路交换机都有一些端口连接到pod内的每个ToR交换机，以保证服务器可以连接到任何ToR交换机。对于1-CS RDC pod，只要每个ToR交换机下的服务器数量相同，就可以无约束地对服务器进行分组。如果在一个pod中使用多个电路交换机，额外的连接约束是，并非一个电路交换机下的所有服务器都可以连接到同一个ToR。通过这种设计，RDC最大限度地提高了更改服务器ToR连接的灵活性，允许在同一ToR下本地化通信最密集的服务器，并享受线速率吞吐量。

图3(a)显示了RDC Pod的示例。对于具有m个机架和每个机架n个服务器的pod，所有电路交换机总共应提供2mn个端口，以链接服务器和ToR交换机。例如，一个具有32台服务器的16机架的pod可以构建为具有1024个端口的1个电路交换机或k个交换机，每个具有1024/ k个端口的。图3(b)给出了插入多个电路交换机以及如何重新配置以重新组合服务器的详细示例。对于具有k个电路交换机的pod，每个ToR下的n/k个服务器连接到一个电路交换机，因此原始拓扑可以将每个服务器保持在其自己的物理ToR交换机下。

直观地说，如果我们增加CS的数量，设计将变得更加分布式，这将使其与特定CS技术的端口数可用性脱钩；同时，跨ToR移动服务器的灵活性略有降低。为了阐明这种权衡，我们对服务器和ToR交换机之间不同数量的CS进行了基于跟踪的分析。为了找到有效的服务器重组，我们制定了一个整数线性规划(ILP)，该规划在给定多个CS产生的约束的情况下使流量本地化最大化(更多细节见第4.3节)。为了进行分析，我们考虑了一个RDC pod，其中有16个ToR和每个ToR 32个服务器，在ToR级别上有4:1的超额订阅。我们将CS的数量从1变到8，并将其性能与静态4:1超额订阅网络进行比较。图4显示了从“Inside the social network’s (datacenter) network”文章中生成的流级缓存流量跟踪的这些架构的流完成时间(FCT)的箱线图。我们观察到，在不同的CS配置中，RDC的潜在优势仍然很高，这验证了我们分布式设计的有效性。

## **3.2  RDC控制器**

今天的数据中心是由模块化Pod构建的，其中Pod通常承载一种类型的服务。RDC同样将pod视为基本单元，并使用每个pod的网络控制器来管理pod内的分组交换机和电路交换机。控制器根据流量模式以秒或更长的时间尺度重新配置网络。它有两种操作模式：它可以在主动模式下直接接收来自应用程序的流量需求或命令，或者在被动模式下被动监测来自分组交换机的流量统计信息。

我们在图5中说明了这两种模式的工作流程。控制器1)首先通过查询TOR上的流量计数器来收集流量统计信息，或者被动地从应用程序接收信息；2)确定具有特定优化目标的优化拓扑(第4节)；3)生成一组新路由，并将其预安装在分组交换机上；4)最后向电路交换机发送电路重配置请求，同时激活分组交换机上的新路由规则。前两个步骤用作RDC控制平面(稍后在第4节中讨论)，而后两个步骤配置数据平面(在第3.3节中讨论)。注意，由于电路重新配置延迟，只有最后一步会引起少量干扰。

## **3.3 路由**

在传统DCN中，转发规则是基于IP前缀聚合的。在RDC中，这种聚合不起作用，因为服务器没有固定位置。相反，RDC在分组交换机上使用每Pod平面IP寻址和精确匹配规则。通过更新路由规则捕获拓扑变化。这些规则更新仅适用于Pod内路由，因为跨Pod的路由机制保持不变。

在RDC pod中，每个ToR都有一个用于其机架中每个服务器IP的流表条目，以及一个用于机架外其他地址的默认条目。每个ToR使用ECMP在其上行链路上将流量平均分配到其他机架。所有Agg交换机具有相同的转发表：每个目标IP一个条目。

TOR和Agg上的流条目当拓扑发生变化时，这两个交换机都需要更新。对于TOR，只需要更改下行流量的规则；上行流量的默认ECMP条目保持不变。因此，对于具有m个机架和每个机架n个服务器的RDC pod，拓扑变化可能导致TOR上的n个规则更新和Agg交换机上的m×n更新，规模大约在数百到1000之间。在OpenFlow交换机上更新这些规则可能需要100ms到1s以上。以前的工作已经开发了两阶段提交方法，以减少更新期间的中断，该方法首先用新的路由规则填充交换机，然后在入口交换机上翻转数据包版本。然而，这种方法无法避免瞬态中的数据包丢失，如更改数据包版本规则。这是因为在入口交换机上更新数据包版本规则需要两个规则更改：删除旧规则和安装新规则，因此不是原子性的。我们在Quanta T3048-LY2R OpenFlow交换机上的测量表明，瞬态周期可能持续0.5ms。

在RDC中，交换机不是更改数据包版本，而是执行二进制更改，从VLAN标记数据包到不标记数据包，反之亦然。VLAN标记的数据包将匹配一组规则，并将VLAN标记作为匹配字段，而没有VLAN标记的数据包将匹配一组更一般的没有VLAN ID的规则。通过这种方式，添加和删除单个VLAN标记规则实现了与更改数据包版本相同的目标，但操作是原子性的，可以避免数据包丢失(更多详细信息请参见§A.1)我们将这种更新方法应用于ToR和Agg交换机，但仅标记或不标记ToR交换机上的数据包。只有在网络范围内填充了新的转发规则时，才执行标记翻转操作。VLAN标签翻转操作需要在多个ToR上同时执行；这种网络范围的更改可以使用众所周知的SDN时间同步和一致更新技术来执行，因此可以同步更改并以原子方式生效。

## **3.4 讨论**

**减少路径长度**：除了第2节中提到的吞吐量优势外，将主机定位在同一逻辑机架下将有效减少平均路径长度(在第5.2节中评估)，从而减少网络延迟。因此，低延迟应用程序和分类系统也可能受益于RDC的设计。

**ToR故障处理**：在传统数据中心中，ToR故障会断开机架中所有服务器的连接。ToR故障由多主服务器处理到其他几个ToR，或通过在多个ToR下复制应用程序来处理。但在RDC中，服务器不与任何特定的ToR绑定，故障ToR下的服务器可以迁移到正常的ToR。为了托管重新定位的服务器，我们可以在每个ToR上保留一些“空闲”端口用于恢复，或者安装一组备份ToR。具体来说，对于具有m个机架和每个机架n个服务器的RDC机架，我们只需要每个ToR(或总的来说是n个端口)的n/m自由端口来从任何单个ToR故障中恢复，这会带来较低的额外成本和复杂性。

**CS故障处理**：一般来说，电路交换机非常可靠。商用OCS产品的平均无故障时间(MTBF)超过28.5年，并配有冗余控制处理器。然而，如果发生CS故障，由于RDC的连接结构，在每个ToR下，只有一小部分服务器将均匀断开连接。CS最常见的故障模式是断电。为了缓解这种情况，可以为CS使用多个冗余电源。为了进一步保护，可以使用备用电池，因为CS只消耗几十瓦的电量，备用电池已经走了很长的路了。

# **4、RDC控制算法**

RDC有一个通用框架来支持各种拓扑优化算法，分两种模式收集流量需求矩阵和计算重配置计划。

## **4.1 主动模式RDC**

RDC的主动模式允许应用程序通过带有两个API的RPC显式调用RDC控制器：1)应用程序可以报告**流量需求矩阵**以请求重新配置。除了需求矩阵，RDC控制器还将要求应用程序从第4.3节中描述的算法中指定一种拓扑优化算法。在收到请求后，RDC控制器将使用指定的算法计算最优拓扑，并相应地进行重新配置。2)**原始配置命令**也可以直接从应用程序发出。对于这种方法，描述新电路连接的格式化数据将发送到控制器，以便控制器可以绕过最佳拓扑的计算，并直接使用接收到的配置来启动重新配置。应用程序发送原始配置计划的另一个好处是，由于应用程序提前知道未来的网络需求，因此它支持网络感知作业放置和调度。

有几种情况下，应用程序可以受益于将其意图通告到RDC控制器：1)在应用程序有意将其部署分布在不同机架上的情况下，例如，为了容错或为了减少同步功耗峰值，在传统架构中，机架间通信模式是不可避免的。然而，在RDC中，此类应用程序可以请求将相关服务器逻辑分组在一起。2)由于碎片，集群应用程序可能会从多个机架分配资源。通过将这些碎片化的资源聚合到同一个逻辑机架，RDC提高了带宽并减少了平均延迟。3)当应用程序的流量模式发生变化时(例如，分布式矩阵乘法(DMM)算法以不断变化的流量模式进行迭代)，它们可以在下一阶段开始之前请求重新配置，以确保整个作业的局部性。4)最后但并非最不重要的一点是，RDC可以依赖应用程序报告的出Pod流量需求来平衡不同ToR上行链路上的负载。

我们在第5.1节中评估了三种不同的应用程序，以展示主动模式RDC的性能，包括HDFS、Memcached和DMM。

## **4.2 被动模式RDC**

RDC的被动模式不需要修改应用程序；它在一个时期内收集网络的流量统计数据，并根据统计数据和网络运营商指定的第4.3节中的一种优化算法，为下一个时期重新配置网络的优化拓扑。

**流量统计**。RDC控制器定期从TOR中提取流量计数器。流计数器将流的5元组(13字节)与8字节计数器值相关联，因此总共有21个字节。传统上，交换机内存约束是维护每流计数器的主要问题，但随着交换机SRAM大小的不断增长，这种约束正在逐渐放松。最新的交换机ASIC具有50-100MB的SRAM，可以存储数百万个流状态。由于最近的DCN测量工作表明，每台服务器的并发流数量约为数百到1000，因此RDC中的每个ToR将需要数万个流计数器，假设每个机架有数十个服务器。例如，假设RDC机架有16个机架，每个机架有32个服务器，计数器拉取周期为10s，控制通道带宽使用率约为8.6Mbps，这足够低，是可行的。

**需求估计算法**。以前的工作表明，数据中心工作负载表现出一定程度的稳定性，RDC同样依赖于这种稳定性来根据历史数据估计流量需求。但是，ToR交换机上观察到的流量受当前拓扑结构的影响，因此估计真实的流量需求，即当流量不受核心网制约时的流量需求非常重要。在之前的工作Hedera中已经研究了缓解这种观察偏差，我们采用了类似的启发式方法。

流量可能会受到网络或应用程序本身的阻碍。我们称第一类流为弹性流，第二类流为非弹性流，RDC只考虑弹性流。启发式方法是从观察到的流量矩阵中删除大小小于其公平份额的流量。其余的流被视为弹性流，RDC通过计算其理想带宽份额(即，如果它们仅受到主机NIC容量的限制时其带宽份额)作为估计需求来校准计数器中的潜在偏差。Hedera是一种计算网络中每个流的最大-最小公平共享率的算法。它执行多次迭代，首先增加源的流量容量(不大于源主机容量)，然后减少每个目标主机上的超出容量(扩大的流量容量之和减去实际NIC容量)，直到流量的容量收敛。图6显示了仅以一次迭代结束的简单需求估计示例(更多详细信息请参见§A.3)。收敛后，将估计的流量需求聚合为服务器到服务器的流量矩阵，以进行重新配置。该需求估计算法的有效性在第5.4节中进行了评估。

## **4.3 拓扑优化算法**

RDC支持一系列拓扑优化和重新配置算法。

**1、流量定位算法**在主动或被动获取流量需求后，重新配置网络，以定位机架间流量。定位算法的目标是最小化新拓扑的逻辑机架上的流量需求。基于这一目标，定位算法可以表述为整数线性规划(ILP)问题，如§A.4所述。然而，寻找最优解是NP困难的，因此我们为1-CS RDC提供了具有平衡图划分的启发式替代方案，并为§A.4中讨论的多CS RDC提供了一个简化算法。启发式算法可以在几十毫秒内找到高质量的重新分组计划，如表2所示。

**2、上行链路负载平衡算法**将pod流量分布在ToR交换机上进行负载平衡，缓解了过度订阅上行链路上的潜在拥塞。上行链路负载平衡(ULB)的目标是最小化来自一个机架的最大出Pod流量。我们在§A.2中提供了形式化问题公式和更快的启发式算法。

**3、混合优化算法**可以在RDC中开发，以本地化机架间流量，同时平衡机架外流量，例如，混合工作负载或应用程序。为了实现这一目标，该问题的目标是最小化alpha*T+beta*R时，其中T是机架内的总机架间通信需求，R是跨TOR的机架外流量的最大量，alpha和beta是各自的权重。

**4、特定场景优化**允许应用程序或网络运营商定义自己的优化算法，以将服务器重新组合到逻辑机架中。应用程序能够定义自己的目标函数，并添加更多特定于应用程序的约束。

# **5、实现和评估**

我们使用试验台实验和数据包级仿真进行综合评估。我们的实验集中在几个方面：a)RDC在HDF中的实际应用、Memcached和基于MPI的分布式矩阵乘法(DMM)作为用例，b)大规模延迟和吞吐量改进的数据包级仿真，c)包装、功率和资本成本分析，以及d)RDC上的微基准，包括无中断控制环路延迟。

**试验台**。我们的RDC原型由16台服务器和4个ToR交换机组成，分别位于4个逻辑机架、一个Agg交换机和一个电路交换机；图7显示了我们的硬件测试平台。在两个48端口Quanta T3048-LY2R交换机上模拟了ToR交换机。每个ToR交换机有四个下行链路连接到服务器，一个上行链路连接到Agg交换机，形成4:1的超额订阅。我们可以通过将上行链路的数量增加到4来调整此比率，以仿真非阻塞网络。Agg交换机是一个单独的OpenFlow交换机。OCS是一个192端口的Glimmerglass 3D-MEMS交换机，交换机延迟为8.5毫秒。这也可以用其他类型的OCS替代。每台服务器有六个3.5 GHz双超线程CPU核和128 GB RAM，在Linux 3.16.5上运行TCP CUBIC。除第5.2节中的大规模仿真外，我们的大多数实验结果都是在该试验台上获得的。

**数据包级仿真器**。为了仿真更广泛的实验设置，我们开发了基于htsim的包级仿真器，用于评估MPTCP和NDP。该仿真器全面实现了TCP流量控制和拥塞控制算法，并支持ECMP。我们仿真了8.5毫秒的保守电路重新配置延迟，这是我们的测试平台3D-MEMS交换机实现的。如第2.5节所述，存在速度更快的电路交换技术，可以进一步提高RDC的性能。请注意，只有正在重新配置的电路才会发生中断；所有其他电路继续工作。如果在重新配置期间飞行的数据包穿过中断的链路，它们将被丢弃，未发送的数据包将在服务器上缓冲。我们仿真了一个RDC Pod，其中有512台服务器，每个机架32台服务器，总共16个机架。16个ToR交换机使用可调的超额认购率连接到单个Agg交换机。通过仿真获得第5.2节中的结果。

## **5.1 实际应用**

首先，我们展示了RDC如何针对每个用例提高实际应用程序的性能。

**HDFS**。我们建立了一个HDFS集群，其中4个机架上有16个数据节点，1个namenode，复制因子为3，块大小为256 MB。所有数据块都缓存在RAM磁盘中，以防止硬盘成为瓶颈。这16个客户端分别对16个HDFS文件发起并发写请求。根据默认HDFS数据块放置策略，当将数据块写入数据节点时，该块的副本将放置在原始副本的同一机架上，另一副本放置在远程机架上以实现弹性(图8(a))。因此，写入操作生成机架内流和机架间流。

HDFS可以通过使用主动RDC和网络感知副本放置来定位所有机架间通信(用于存储副本)。图8(b)显示了RDC的性能增益，并将其与非阻塞网络(NBLK)和先进的以带宽为中心的副本放置解决方案Sinbad进行了比较。Sinbad跟踪在最近一段时间内到达副本的路径和链路，并将下一个副本分配给最近一段时间内利用率最低的路径。因此，Sinbad不会减少跨机架流量，但可以通过负载平衡来缓解网络链路上的瓶颈，如图8(a)所示。具体来说，它检测传输机架间副本的流量不均衡，旨在大致平等地利用所有链路，即每个机架承载一个副本。在结果中，我们可以看到，Sinbad提高了HDFS写入的总时间，但仍然不如NBLK网络。相反，RDC允许HDF直接重组（regroup）服务器。此外，使用新拓扑，HDFS可以更改副本放置方案，以将所有流量保持在逻辑机架内，但同时满足容错约束，如图8(a)所示。与原始拓扑和放置策略相比，具有RDC的HDFS实现了与NBLK网络相似的性能，将总时间平均减少到0.59倍。

**Memcached**。然后，我们在两个机架上配置了Memcached服务器，并从另外两个机架发出读/写请求。这模拟了一个pod中的客户端访问另一个pod中的缓存服务器的场景。我们的工作负载有a)20万个键值对均匀分布在8台服务器上，b)99%/1%的读写比，以及c)512字节的键和10 KB的值。与之前的工作类似，我们采用了偏度为0.99的Zipfian查询键Key分布，这导致在服务器机架上负载不均衡率为∼1.8。

通过将热键均匀地重新分配到每个ToR上的服务器，RDC平均将查询吞吐量提高了1.78倍并将中值延迟降低到0.48倍，如图8(c)-(d)所示。这些改进接近于无阻塞网络可以实现的功能。RDC还显著减少了尾部延迟，网络拥塞是其主要原因。由于在基线设置中，当多个热键同时位于同一机架中时，即使整体上行链路利用率较低，ToR上行链路也很容易拥塞。相反，RDC可以观察热键引起的流量模式，并将托管这些密钥的服务器分布到不同的机架。这降低了峰值上行链路利用率。

**OpenMPI** **DMM**。我们在4个机架上建立了一个16节点的OpenMPI集群，并实现了一种常用的DMM算法，包含64个进程。矩阵分为64个块(子矩阵)。每台服务器有4个进程，形成8×8的进程布局。然后在每次迭代中，它执行“广播移位乘法”循环，其中过程a)按行广播子矩阵，b)按列移位子矩阵，c)乘法子矩阵，如图8(e)所示。我们考虑进程的三种放置方式：1)图9(a)：按行放置(没有用于广播的跨机架通信)，2)图9(b)：按列放置(无移位跨机架通信)和3)图9(c)：考虑跨机架的广播和移位通信，以混合方式放置。

通过在DMM期间为不同阶段动态配置拓扑，RDC缩短了通信时间和端到端执行时间。图8(f)表明，与静态4:1超额订阅网络相比，RDC将放置1、2和3的整体通信时间分别提高了3.9倍，2.3倍和1.26倍，实现了与NBLK网络几乎相同的性能。由于应用程序具有不断变化的流量模式，因此没有任何静态进程布局始终是最优的。在这三种布局中，布局3联合最小化了DMM中两种通信模式的跨机架流量，优于其他两种策略。

## **5.2 大规模性能**

接下来，我们使用数据包级仿真器在数据中心规模上评估被动RDC Pod。我们的基线是a)静态非阻塞网络(NBLK)，b)具有4:1超额订阅(4:1-o.s.)的静态网络，c)具有未来流量需求信息的RDC(理想RDC)，d)在整个流量跟踪上仅应用RDC的重新配置算法一次的4:1-o.s.网络(一次性RDC)。e) 除了4:1-o.s.网络(在性能方面类似于Firefly和ProjecToR)之外，还有一种类似C-Through的混合网络，具有16个4:1/1:1超额订阅的可配置电路ToR对链路。f) 一种新的电路核心网络RotorNet，其上行链路带宽为4:1/1:1超额订阅。注：C-Through具有与RDC相同的电路切换延迟，并在电路停机期间在TOR处缓冲数据包。

我们使用了来自Facebook的缓存、Web和Hadoop流量跟踪。由于原始跟踪不包含流级信息，我们根据“Inside the social network’s (datacenter) network”中的采样数据包跟踪生成流级流量。具体来说，我们从跟踪中推断流的源/目标服务器，并根据同一张脸书中的图6和14仿真流大小和到达时间。缓存工作负载的平均流大小为680 KB，其中87%为机架间。Web工作负载的平均大小为63 KB，有96%的相互访问。对于Hadoop工作负载，平均大小为67.18 KB，但机架间流量仅占60%。所有流量跟踪在仿真中持续30s，RDC的重新配置周期为1s。

图10显示了使用三种跟踪的RDC和基线的流完成时间(FCT)的箱线图。我们观察到，与4:1-o.s.网络相比，RDC将中值FCT降低了一个数量级以上。一次应用RDC的流量定位算法可以在中值FCT上带来一些改进，但不如RDC和NBLK显著，因为流量模式在仿真过程中会发生变化。我们发现，性能提高的一个根本原因是由于TCP动力学，严重的机架间拥塞会导致连续的数据包丢失，并且TCP在增加其发送速率时变得非常保守。更重要的是，我们观察到，具有未来流量需求知识的RDC性能始终接近非阻塞网络，这再次证明了无机架网络的威力。在没有未来知识的情况下，RDC仍然可以通过稍长的中值FCT实现与NBLK类似的性能，因为缓存工作负载在秒的时间尺度上基本稳定，类似于原始跟踪中的数据库工作负载。对于其他方案，C-Through的平均FCT至少比RDC高3.21倍。因为尽管C-Through增加了额外的机架间带宽，但它仅为16个ToR对提供。由于推动我们的RDC设计的流量跟踪有超过16个密集通信的ToR对(参见图1中的热力图)，即使在增加16个额外链路的带宽后，C-Through也无法缓解机架间拥塞。4:1-o.s. RotorNet的总上行链路带宽与RDC相同，但其性能比RDC差得多。非阻塞RotorNet在缓存和Web跟踪上分别比RDC慢2倍和2.17倍；仅对于Hadoop跟踪，它可以将RDC的平均FCT减少到0.576×。由于RotorNet在每个ToR对之间提供了专用链路，因此如果某些ToR对之间的流量出现偏差，则无法实现最佳性能。因此，只有Hadoop跟踪在非阻塞RotorNet上具有更好的性能，Hadoop跟踪只有60%的机架间，并且在不同的ToR之间分布相当均匀。

图11(a)显示了在每个周期/epoch中被重新定位的服务器的平均数量在不同的跟踪中是不同的。占空比是光网络中的一个重要指标，用于表示光链路启动并可用于传输的时间百分比。假设每秒重新配置一次，RDC的最低电路占空比理论上为99.2%(关于停机/downtime的详细信息，见第5.4节)；由于实际上并非所有服务器都将重新定位，因此所有传输的平均电路占空比可能高达99.83%。图11(b)显示了RDC、C-Through和NBLK的路径长度分布。(两个C-Through设置具有相同的分布；NBLK、4:1-o.s.和RotorNet也具有相同的分布)。机架内流在所有网络中的路径长度为2；机架间流在RDC、NBLK和4:1-o.s.中具有路径长度4；对于电路路径，C-Through路径长度可会发生变化——对于电路径为3，正常的分组交换路径为4。总的来说，RDC本地化了70%以上的机架间流量，并实现了0.75×C-Through和0.65×NBLK的平均路径长度。

## **5.3 包装、功率和资本成本**

**包装/Packaging**。图12显示了RDC Pod的包装设计，它与传统Pod有所不同。RDC有一个中央交换机机架，专用于托管TOR，Agg交换机和OCS。服务器机架通过光纤束连接到OCS，以减少布线复杂性。在中央机架上，TOR分别使用短光纤和电缆分别连接到OCS和Agg交换机。Agg交换机提供与pod外部核心交换机类似的连接，就像在传统数据中心中一样。为了确保集中交换机放置具有与传统交换机放置类似的可靠性，使用了备用电源。与现有的模块化数据中心类似，RDC通过添加RDC Pod来支持增量扩展。

**功率和资本成本建模**。通过比较RDC和NBLK在400 Gbps数据速率下的功率和资本成本，我们表明RDC更经济。它们都由以下类型的网络组件组成：a)400 Gbps以太网端口，b)400 Gbps光收发器，c)机架间双工单模光纤(平均长度10m)，d)机架内双工单模光纤(平均长度3m)，e)400 Gbps直连电缆(平均长度3m)和f)OCS端口。NBLK网络可以使用DAC直接连接服务器到下行链路，而RDC需要光缆以及服务器端和ToR端的光收发器来连接其间的OCS。

我们假设RDC在ToR水平上有一个xp:1的超额订阅。图13显示了一个4-pod RDC网络(共16台服务器)，其中包含组件级详细信息(其中xp=2)，并显示了用于查找网络中组件计数的控制方程。根据我们的建模，假设服务器和POD的数量相同，RDC和NBLK网络的相对组件数仅取决于xp。表1显示了不同组件的最近功率和成本值以及RDC和NBLK网络(400 Gbps)的相对计数。一方面，网络组件的功耗值是基本的，并在数据表中有详细记录。另一方面，组件成本可能会因销售量而变化，由于我们没有专有的行业定价数据，我们根据所有组件的现成零售定价(换句话说，最坏情况或无折扣定价)进行“尽力”计算，因此至少它在某种程度上是客观和公正的。我们认为每个端口的OCS成本为400美元，最坏情况下的价格取自微软最近发布的一篇文章“Beyond the mega-data center: networking multi-data center regions”。读者应意识到这种定价假设的局限性，并将资本成本结果仅作为一般指导。

如图13中的控制方程所示，xp:1 RDC网络具有s个服务器，s个ToR下行链路端口、s/xp个ToR上行链路端口、s/xp个Agg交换机下行链路端口，s/xp个Agg交换机上行链路端口和s/xp个核心交换机端口；总共具有(s+4s/xp)个以太网端口。考虑具有相同数量服务器和POD的传统NBLK(胖树)网络，其中每层的以太网交换机端口数量与服务器数量相同。这导致总共5s个以太网端口(在RDC中使用xp=1)。因此，相对以太网端口数为(1+4/xp)到5(见表1)。类似的计算也可以应用于其他组件。

**功率效率**。考虑到400 Gbps的数据速率，4:1-o.s. RDC网络比NBLK网络功耗低2:29倍。如图14(a)所示，与NBLK相比，RDC在不同网络负载的不同业务模式下显著提高了每瓦特的性能(中值FCT)。我们使用五种不同的生产跟踪，即缓存、Web、Hadoop、DCTCP和VL2。对于中值FCT，与NBLK相比，RDC每瓦性能提高了2.1~2.4倍。RDC还显著降低了网络的功耗，因为它在核心中需要更少的耗电分组交换机。RDC边缘的光电路交换机消耗的功率非常小，因为它仅使用反射镜旋转或衍射来引导入射光子束。

**资本成本**。我们再次强调，读者应将此“尽力”成本分析仅作为一般指导。一个4:1-o.s. RDC网络的成本比一个400 Gbps的NBLK网络低1.4倍。使用相同的五条生产跟踪，与NBLK相比我们观察到RDC具有1.3~1.5倍的性能改善(FCT中值)，如图14(b)所示。我们还估计了每个端口的OCS成本，这将使4:1-o.s. RDC具有与NBLK相同的每美元性能：其范围从1000美元到1300美元。

## **5.4 DRC重新配置**

为了更深入地理解RDC，我们将此分析分解为需求估计算法的有效性研究、重配置前的无中断控制回路以及重配置期间的硬件瞬态。

**需求估计算法的有效性**。为了证明我们的需求估计算法的有效性，我们通过对流量定位的深入研究，研究了我们的启发式算法如何与连续的拓扑重配置相互作用。

我们使用与第5.2节相同的数据包级仿真来说明这种需求估计技术。对于每次仿真，RDC根据第4.3节中详述的算法，每10秒进行一次流量定位并重新配置拓扑。弹性流的发送方和接收方是根据所选的业务模式确定的，而非弹性流是由随机选择的发送方和接收方生成的，数据速率小于10Mbps。非弹性流和弹性流的数量之比为10:1。除了三种跟踪衍生的流量模式——缓存、Web和Hadoop，我们还测试了三种合成跟踪，如下所示。在整个仿真过程中，每个流量模式保持不变。

- **随机/Random**：每个主机i以均匀随机概率向其他主机之一发送流；

- **洗牌/Shuffle**：我将每个主机发送到一组包含31个其他主机的索引(i+j∗16) %num_host；j in [1:31]；

- **条带/Stride**：每个主机i向另一个主机发送一个流，索引为(i+32)%num_hosts；

图15显示了所有服务器对在五个连续重新配置阶段的平均需求估计误差。我们观察到，虽然初始需求估计误差可能较高(10%)，但随着网络重新配置以适应后续时刻的流量模式，误差会减小。在第一个时刻，许多弹性流阻塞了过度订阅的核心网。

因此，它们的流计数器可能很小，并且可能被误认为是非弹性流。然而，随着RDC调整拓扑以定位已识别的弹性流，跨机架传输的弹性流更少，核心网中的拥塞减少，从而正确识别更多弹性流。例如，由于Stride模式中的弹性流最终都定位在机架内，因此这些弹性流的需求估计误差几乎降为零。因此，我们可以看到，Hedera技术非常适合RDC重新配置拓扑以适应流量模式，有助于提高下一个时期需求估计的准确性。

**无中断控制回路**。接下来，我们评估RDC控制回路的延迟，它包括四个部分：1) 收集流量计数器，2)估计流量需求，3)计算新拓扑，以及4)修改转发规则。这种延迟将影响RDC对不断变化的流量模式的响应速度。注意，被动RDC使用所有四个组件；对于使用流量需求矩阵的主动RDC，只执行步骤3和4；对于具有直接配置命令的主动RDC，只需要最后一步。

为了获得这些结果，我们使用不同数量的机架进行了一组实验，每个机架有32台服务器，使用Facebook跟踪的流量模式。ToR交换机连接到单个Agg交换机。由于我们的测试平台只有四个ToR交换机，因此我们使用服务器仿真了更多ToR交换机，并确保每个服务器在收集计数器和安装路由规则方面具有与物理ToR交换机相同的延迟。ToR交换机和Agg的转发规则数量分别为32个和32个*机架数。该数量根据流量模式而变化，并且可能在不同的交换机中有所不同。整体规则安装延迟由最慢的交换机决定，该交换机具有最多的更改数。

表2分解了流量定位(TL)和上行链路负载平衡(ULB)用例的控制环路延迟。总的来说，被动RDC在重新配置之前的无中断控制环路延迟对于TL为612.6ms，对于ULB为77.4ms，这与最先进的流量工程技术在类似的时间尺度上。然而，主动RDC可以将该控制环路延迟分别减少到147.6 ms和70.6 ms。由于RDC旨在在大时间尺度(例如秒或更长)下重新配置网络，因此该控制回路足够有效，具有实用性。注意，以上所有数字都是通过我们自己的测试平台获得的。使用尖端的高性能交换机硬件，可以进一步减少延迟，以支持更频繁的重新配置。

**重配置瞬态**。必须注意的是，RDC中的电路重新配置仅在需要时发生，并且在绝大多数情况下，电路持续处于活动状态。当电路发生重新配置时，该电路确实会发生瞬态中断。例如，随着具有亚纳秒波长交换机的可调谐激光器的制造，AWGR和基于星形耦合器的OCS变得越来越流行。考虑到400 Gbps的链路速度和1 ns的切换延迟，在瞬态阶段，只有50字节的流量将被缓冲或丢弃。此外，基于2D-MEMS的OCS可用，具有几微秒的重新配置延迟。即使在我们的测试平台中OCS相对较慢，我们的实验也表明RDC提供了很大的性能优势。

# **结论**

无机架数据中心(RDC)是一种新型的网络架构，它在逻辑上消除了静态机架边界，使用电路交换实现了边缘的拓扑可配置性。在这种架构中，不同物理机架中的服务器可以在运行时根据流量模式分组到同一个逻辑组中。通过协同设计网络架构和控制系统，RDC可以使广泛的实际数据中心工作负载受益。我们通过测试台和仿真设置进行的评估表明，RDC为实际应用程序带来了巨大的性能优势。

**参考文献**：Weitao Wang, Dingming Wu, Sushovan Das, Afsaneh Rahbar, Ang Chen, T. S. Eugene Ng , "RDC: Energy-Efficient Data Center Network Congestion Relief with Topological Reconfigurability at the Edge", in NSDI'22.

> <span style="font-style: italic;">声明：本文素材来源于网络，仅供学习使用，如有侵权请联系网站删除(ngdcn_admin@163.com)。由于本人水平有限，如有纰漏，请以参考文献文章为准。</span>

<font color=red>**欢迎扫码关注微信公众号“网络技术风云汇”，更快速接收更多网络技术咨询。**</font>