3.9 电量和热量问题
除了性能和成本，数据中心设计的另一个主要问题是功耗。在数据中心中，构成互连网络较高层的交换机通常消耗数千瓦的电力，在一个大规模的数据中心中，互连网络的电力需求可达数百千瓦。几乎同样重要的是交换机的散热问题。企业级交换机产生大量的热量，因此需要专用的冷却系统。
在本节中，我们将分析我们架构中的电力需求和散热，并将其与其他典型方案进行比较。我们的分析基于交换机数据表中报告的数字，尽管我们承认，这些报告的值由不同的供应商以不同的方式测量得到，因此可能并不总是反映部署中的系统特征。
为了比较每类交换机的功率需求，我们在交换机可支持的总带宽(以 Gbps 为单位)对交换机的总功耗和散热进行了归一化。图 6 绘制了三个不同交换机模型的平均值。我们可以看到，当带宽归一化时，10 GigE 交换机(x 轴上的最后 3 个)每 Gbps 消耗大约是商用 GigE 交换机两倍的瓦数，耗散大约三倍的热量。
最后，我们还计算了一个可支持约 27k 台主机的互连线的预估总功耗和散热。在分层设计中，我们使用了 576 台 ProCurve 2900 边缘交换机和 54 台 BigIron RX-32 交换机(汇聚层 36 台，核心层 18 台)。胖树结构采用了 2880 台 Netgear GSM 7252 交换机。我们能够使用更便宜的 NetGear 交换机，因为我们在胖树互连中不需要 10 GigE 的上行链路(存在于 ProCurve)。图 7 显示，虽然我们的架构采用了更多的单台交换机，但功耗和散热都优于当前的数据中心设计，功耗降低 56.6%，散热减少 56.5%。当然， 实际的功耗和散热必须在部署时进行测量；我们把这样的研究留作正在进行的工作。
4. 实现
为了验证本文描述的通信架构，我们构建了一个简单的转发算法原型。使用 NetFPGA 实现了一个原型系统。NetFPGA 包含一个利用 TCAM 的 IPv4 路由器实现。如 3.4 节所述，我们适当地修改了路由表查找例程。我们的修改总共不到100行代码，并且没有引入可测量的额外查找延迟，支持我们的观点，即我们提出的修改可以合并到现有的交换机。
为了进行更大规模的评估，我们还使用 Click 构建了一个原型，这是本文评估的重点。。Click 是一个模块化的软件路由器架构，支持实验路由器设计的实现。Click 路由是一个由称为元件的数据包处理模块组成的图，这些模块执行路由表查找或递减数据包的 TTL 等任务。当连接在一起时，Click 元件可以在软件中执行复杂的路由功能和协议。
4.1 两级表
我们构建了一个新的 Click 元件，TwoLevelTable，它实现了 3.3 节中描述的两级路由表的思想。这个元件有一个输入，两个或多个输出。路由表的内容使用输入文件初始化，该文件给出了所有的前缀和后缀。对于每个数据包，TwoLevelTable 元件查找最长匹配的第一级前缀。如果该前缀是终止的，它将立即在该前缀的端口上转发数据包。否则，它将在二级表上执行右旋最长匹配后缀搜索，并在相应的端口上转发。
该元件可以取代 [21] 中提供的符合标准的 IP 路由器配置示例的中央路由表元件。我们生成了一个类似的 4 端口版本的 IP 路由器，在所有端口上增加了带宽限制元素，以模拟链路饱和容量。
4.2 流分类
为了提供 3.6 节中描述的流分类功能，我们来介绍具有一个输入、两个或多个输出的Click 元件流分类器的实现。根据输入报文的源 IP 地址和目标 IP 地址进行简单的流分类，使得相同源和目标的后续报文从同一个端口输出(避免报文乱序)。元件增加了一个目标，即最小化其最高负载和最低负载输出端口之间聚合流容量的差异。
即使预先知道各条流的大小，该问题也是 NP 难装箱优化问题的一个变体。然而，流的大小实际上是未知的，这使得求解问题更加困难。我们遵循算法 3 中概述的贪婪启发式算法。每隔几秒钟，如果需要，启发式尝试切换最多 3 条流的输出端口，以最小化其输出端口的聚合流容量的差异。
回想一下，FlowClassifier 元件是用于流量扩散的两级表的替代方案。使用这些元件的网络采用普通的路由表。例如，一台上层 pod 交换机的路由表中包含了分配给该 pod 的所有子网前缀。然而，此外，我们添加了一个 /0 前缀来匹配所有剩余的需要均匀向上扩散到核心层的 pod 间流量。所有仅与该前缀匹配的数据包都被定向到 FlowClassifier 的输入。该分类器试图根据所描述的启发式方法在其输出之间均匀地分配 pod 间输出流，其输出直接连接到核心交换机。核心交换机不需要分类器，路由表保持不变。
请注意，这个解决方案有软性状态，它不是正确性所必需的，仅用作性能优化。这种分类器偶尔会造成干扰，因为少数的流可能会周期性地重新排列，可能导致数据包ç重排。然而，它也能适应动态变化的数据流大小，并且从长远来看是“公平的”。
4.3 流调度
如第 3.7 节所述，我们实现了元件 FlowReporter，它驻留在所有边缘交换机中，检测大于给定阈值的输出流。它定期向中央调度器发送这些活跃大数据流的通知。
FlowScheduler 元件从边缘交换机接收活跃大数据流的通知，并试图为它们找到无竞争的路径。为此，它保存了网络中所有连接的二进制状态，以及先前放置的流的列表。对于任何新的大流，调度器都会在源主机和目标主机之间的所有等价路径中执行线性搜索，以找到路径组件都没有预留的路径。找到这样的路径后，流调度器将所有组件连接标记为预留，并向相关的 pod 交换机发送该流路径的通知。我们还修改了pod 交换机，以处理来自调度器的端口重新分配消息。
调度器维护两个主要的数据结构:网络中所有连接的二进制数组(总共 4∗k∗(k/2)2 条连接)，以及先前放置的流及其分配的路径的哈希表。搜索新的流布局平均需要 2 * （k / 2)2 次内存访问，使得调度器的空间复杂度为 O(k3)，时间复杂度为 O(k2)。k 的典型值(每台交换机的端口数)为 48，使这两个值都可以管理，如第 5.3 节中所量化。
5. 评估
为了测量该设计的总双工带宽，生成了一套通信映射的基准套件，以评估使用 TwoLevelTable 交换机、FlowClassifier 和 FlowScheduler 的 4 端口胖树的性能。我们将这些方法与标准分层树进行了比较，其超分比为 3.6:1，类似与当前数据中心设计
5.1 实验描述
在 4 端口胖树中，有 16 台主机、4 个 pod(每个 pod 有 4 台交换机)和 4 台核心交换机。因此，总共有 20 台交换机和 16 台终端主机(对于更大的集群，交换机的数量将小于主机的数量)。我们将这 36 个元件复用到 10 台物理机器上，由一条具有 1 Gigabit 以太网链路的 48 端口 ProCurve 2900 交换机连接。这些机器有 2.33GHz 的双核 Intel Xeon cpu, 4096KB 缓存和 4GB RAM，运行 Debian GNU/Linux 2.6.17.3。每台 pod 交换机托管在一台机器上；每个 pod 的主机都托管在一台机器上；剩下的两台机器分别运行两台核心交换机。交换机和主机都是 Click 配置，运行在用户级别。网络中所有 Click 元件之间的虚拟链路带宽限制为 96Mbit/s，以确保配置不受 CPU 限制。
分层树形网络的对比情况，有 4 台机器，每台机器运行 4 台主机，每台机器运行 4 台 pod 交换机，并有一条额外的上行链路。4 台 pod 交换机连接到运行在专用机上的 4 端口核心交换机。为了实现从 pod 交换机到核心交换机的上行链路 3.6:1 超分配置，这些链路的带宽被限制为 106.67Mbit/s，所有其他链路的带宽都被限制为 96Mbit/s。
每台主机输出的流量恒定为 96Mbit/s。我们测量输入流量的速率。对于所有的双向通信映射，所有主机的最小输入流量总和就是网络的有效双工带宽。
5.2 基准套件
我们根据以下策略生成通信对，并增加限制，即任何主机仅接收来自一台主机的流量(即，映射为 1 对 1):
- Random ：主机以均匀概率发送给网络中的其他主机。
- Stride(i)：索引为 x 的主机发送到索引为（x + i）mod 16 的主机。
- Staggered Prob (SubnetP, PodP)：主机将以 SubnetP 的概率发送到其子网中的另一台主机，以 PodP 的概率发送到其 pod，以 1 − SubnetP − PodP 的概率发送到其他任何主机。
- Inter-pod Incoming：多个 pod 发送到同一 pod 中的不同主机，并且都恰好选择相同的核心交换机。该核心交换机到目标 pod 的连接将过载。这种情况下的最坏情况本地超分比为 (k − 1) : 1。
- Same-ID Outgoing：同一子网中的主机发送到网络中其他任意不同主机，使目标主机具有相同的主机 ID 字节。静态路由技术强制它们采用相同的向上输出端口。这种情况下的最坏情况超分比为 (k/2) : 1。这是 FlowClassifier 预计可以最大程度提高性能的情况。
5.3 结果
表 2 显示了上述实验的结果。这些结果是基准测试 5 次运行/排列的平均值，每次持续 1 分钟。如预期的那样，对于任何 pod 间通信模式，传统树会饱和到核心交换机的链路，因此在这种情况下，所有主机的实际带宽约为理想带宽的 28%。通信对彼此间越接近，树的性能越好。
两级表交换机在随机通信模式下实现了理想双工带宽的大约 75%。这可以用表的静态性质来解释；任何给定子网上的两台主机有 50% 的几率发送到具有相同主机 ID 的主机，在这种情况下，它们的总吞吐量减半，因为它们都被转发到同一输出端口。使得两者的期望值都为 75%。预计随着 k 的增加，两级表的随机通信性能会提高，因为随着 k 的增加，多条流在单个链路上发生碰撞的可能性会降低。两级表的内部流入情况给出了 50% 的双工带宽；然而，相同 ID 输出效应进一步被核心路由器中的拥塞所加剧。
由于动态流分配和重新分配，流分类器在所有情况下都优于传统树和两级表，最坏情况下双工带宽约为 75%。然而，它仍然不完美，因为它避免的拥塞类型完全是局部的；由于上游一两跳处所做的路由决策，可能会在核心交换机处造成拥塞。这种次优路由产生是因为交换机仅本地知识可用。
另一方面，FlowScheduler 基于全局知识并尝试将大数据流分配到不相交的路径上，从而在随机通信映射中实现了理想双工带宽的 93%，并在所有基准测试中都优于所有其他方案。使用具有所有活跃大数据流和所有连接状态知识的集中调度，对于大型任意网络可能是不可行的，但是胖树拓扑的规律性大大简化了寻找无冲突路径的过程。
在另一个测试中，表 3 显示了在配置适当的 2.33 GHz 商用 PC 上运行中央调度程序时的时间和空间要求。对于不同的 k，我们生成了虚假的放置请求（每台主机一个），以测量处理放置请求的平均时间和维护连接状态和流状态数据结构所需的总内存。对于一个包含27k 台主机的网络，调度程序需要 5.6MB 的内存，并且可以在不到 0.8ms 的时间内放置一条数据流。
6. 封装
胖树拓扑用于集群互连的一个缺点是需要大量的电缆来连接所有的机器。使用 10 GigE 交换机进行聚合的一个微不足道的好处是，向上层传输相同带宽所需电缆数量减少 10 倍。在我们提出的胖树拓扑中，既不利用 10 GigE 链路也不利用交换机，因为非商用部件会增加成本，更重要的是，因为胖树拓扑严重依赖于层次中每层多台交换机的大扇出来实现其伸缩性能。
承认增加布线开销是胖树拓扑固有的，在本节中，我们考虑一些组装技术来减轻这种开销。总之，我们提出的组装技术消除了大部分所需的外部布线，并减少了所需电缆的总长度，从而简化了集群管理并降低了总成本。此外，这种方法允许网络的增量部署。
在最大容量 27,648 节点集群的背景下，提出了我们的方法，该集群利用 48 端口以太网交换机作为胖树的构建模块。这种设计可以推广到不同大小的集群。我们从单个 pod 的设计开始，它们构成了大型集群的复制单元，见图 8。每个 pod 包括 576 台计算机和 48 个独立 48 端口 GigE 交换机。为简单起见，假设每台终端主机占用一个机架单元（1RU），并且单个机架可以容纳 48 台计算机。因此，每个 pod 由 12 个机架组成，每个机架有 48 台计算机。
将构成 pod 的、胖树前两层的 48 台交换机放置在一个集中的机架中。但是，假设能够将48 台交换机打包成一个单一的整体单元，具有 1,152 个面向用户的端口。我们称之为 pod 交换机。其中 576 个端口直接连接到 pod 中的计算机，对应于边缘连接。另外 576 个端口扇出到胖树核心层中 576 台交换机中的一个端口。请注意，以这种方式打包的 48 台交换机实际上具有 2,304 个总端口（48 * 48）。另外 1,152 个端口在 pod 交换机内部接线，以解决 pod 边缘和聚合层之间所需的互连（见图 3）。
进一步将组成胖树顶部的 576 台必需核心交换机分布在各个 pod 中。假设总共有 48 个 pod ，每个 pod 将容纳 12 台必需的核心交换机。从每台 pod 交换机扇出到核心层的 576根电缆中，有 12 根将直接连接到放置在同一 pod 的核心交换机上。其余电缆每 12 一组扇出到远程 pod 中的核心交换机。请注意，电缆每 12 一组从 pod 移动到 pod，并且以 每 48 一组从机架移动到 pod 交换机，这为适当的“电缆封装”提供了额外的机会，以减少布线的复杂性。
最后，最小化电缆总长度也是一个重要的考虑因素。为此，围绕 pod 交换机在两个维度上放置机架，如图 8 所示（我们不考虑三维数据中心布局）。相比于在一个 pod 中“水平” 布局的单个机架，这样做将减少电缆长度。同样，将 pod 布置在 7×7 的网格中（空缺一个位置）以容纳所有 48 个 pod 。再次，这种网格布局将减少 pod 间布线到适当核心交换机的距离，，并将支持电缆长度和包装的一些标准化，以支持 pod 间的连接。
我们还考虑了一种不将交换机集中到一个机架中的替代设计。在这种方法中，每个机架将分配两台 48 端口交换机。主机每 24 一组连接到交换机。这种方法的优点是主机连接到第一跳交换机所需的电缆更短，并且如果机架适当的内部封装，可以完全消除这些电缆。我们放弃了这种方法，因为我们会失去消除每个 pod 内连接边缘层和聚合层的 576 根电缆的机会。这些电缆需要穿过每个 pod 的 12 个机架，大大增加了复杂性。
7. 相关工作
我们在数据中心网络架构方面的工作必然建立在许多相关领域的工作基础上。也许与我们的努力最密切相关的是建立可伸缩互连的各种努力，主要来自超级计算机和大规模并行处理（MPP）社区。许多 MPP 互连都组织成胖树，包括 Thinking Machines 和 SGI 的系统。Thinking Machine 采用伪随机转发决策来执行胖树连接之间的负载平衡。虽然这种方法实现了良好的负载平衡，但它容易发生数据包重排。Myrinet 交换机也采用胖树拓扑，并且一直受到基于集群的超级计算机的欢迎。Myrinet 采用基于预定拓扑知识的源路由，启用直通低延迟交换机实现。主机还负责通过测量往返延迟来在可用路由之间进行负载均衡。相对于所有这些工作，我们专注于利用商用以太网交换机来互连大规模集群，展示适当的路由和封装技术。
InfiniBand 是高性能计算环境中流行的互连，并且目前正在迁移到数据中心环境。 InfiniBand 还使用 Clos 拓扑的变体来实现可伸缩带宽。例如，Sun 最近宣布了一款 3,456 端口 InfiniBand 交换机，该交换机由 720 台 24 端口 InfiniBand 交换机组成，排列成 5 级胖树。但是，InfiniBand 强加了自己的 1-4 层协议，使得 以太网/IP/TCP 在某些设置中更具吸引力，特别是随着 10Gbps 以太网价格的不断下降。
另一个流行的 MPP 互连拓扑是 Torus，例如 BlueGene/L 和 Cray XT3。Torus 直接将处理器与 k 维格子中的一些邻居相互连接。维数决定了源和目标地之间预期的跳数。在 MPP 环境中，Torus 的优点是没有任何专用的交换元件，以及电气上更简单的点对点连接。在集群环境中，Torus 的布线复杂性很快变得难以承受，并且卸载所有路由和转发功能到商用主机/操作系统通常是不切实际的。
我们提出的转发技术与现有的路由技术，如 OSPF2 和等价多路径（ECMP）相关。我们提出多路径利用胖树拓扑的特定属性来实现良好性能。相对于我们的工作，ECMP 提出了三类无状态转发算法：（i）轮询和随机化；（ii）区域拆分，其中特定前缀被拆分为两个较大掩码长度的前缀；以及（iii）一种散列技术，它根据源地址和目标地址将流拆分到一组输出端口。第一种方法会遇到潜在的数据包重排问题，对 TCP 尤其有问题。第二种方法可能导致路由前缀数量激增。在具有 25,000 台主机的网络中，需要大约 600,000 个路由表条目。除了增加成本外，这种规模的表查找也会产生巨大延迟。因此，当前企业级路由器最多允许 16 路 ECMP 路由。最后一种方法在进行分配决策时不考虑流带宽，即使简单的通信模式也会很快超分。
8. 结论
带宽越来越成为大规模集群可伸缩性的瓶颈。现有解决这一瓶颈的解决方案围绕着交换机层次结构，顶层的交换机昂贵，非商用化。在任何给定时间点，高端交换机的端口密度都会限制整个集群的大小，同时产生高昂的成本。在本文中，我们提出了一种数据中心通信架构，利用商用以太网交换机为大规模集群提供可伸缩带宽。以胖树为基础构建拓扑，然后提出技术来执行可伸缩路由，同时保持与以太网、IP 和 TCP 的后向兼容性。
总体而言，我们发现我们能够以比现有技术显著更低的成本提供可伸缩带宽。虽然还需要进一步的工作来完全验证我们的方法，但我们相信更多的商用交换机有可能在数据中心取代高端交换机，就像商用 PC 集群取代了高端计算环境中的超级计算机一样。
原文：A Scalable, Commodity Data Center Network Architecture
本文作者 ： cyningsun
本文地址 ： https://www.cyningsun.com/05-10-2023/a-scalable-commodity-data-center-network-architecture-cn.html
版权声明 ：本博客所有文章除特别声明外，均采用 CC BY-NC-ND 3.0 CN 许可协议。转载请注明出处！
