欢迎莅临 IEEE HotICN 中文社区,IEEE HotICN 国际学术会议网站: https://hoticn.com, https://hoticn.cn。

Jupiter Evolving: Transforming Google’s Datacenter Network via Optical Circuit Switches and Software-Defined Networking

未分类 杨, 宗霖

https://dl.acm.org/doi/10.1145/3544216.3544265

一、研究背景与动机:数据中心网络的持续演进挑战

近年来,大量应用和服务迁移至云数据中心,由此带来的需求增长推动了云计算、存储以及网络技术的持续演进。尽管网络技术(如电交换机的端口密度、单端口容量、收发器比特率)每隔几年就会取得进步,但将这些新技术整合到高可用性大规模网络中仍然充满挑战。

云基础设施的增长是渐进式的,通常一次只增加一个机架甚至一台服务器。因此,填满一个最初空置的建筑需要数月甚至数年。一旦初始填满,基础设施又会继续渐进式演进。通常,对于网络生命周期内将要迁入或迁出的服务器、存储、加速器或服务类型,并没有预先的蓝图。指数级增长和不断变化的业务需求意味着,最周密的计划也会很快过时和低效,使得增量式自适应演进成为必然。

这篇来自 Google 的论文展示了 Jupiter 数据中心网络近十年的演进历程和生产经验。在此期间,Jupiter 实现了 5倍 的速度和容量提升、30% 的资本支出降低、41% 的功耗降低,同时支持增量部署和技术刷新,且全程服务于实时生产流量。

二、核心问题:Clos 架构的脊层瓶颈

计算和存储基础设施的增量刷新相对简单:在数据中心的数百或数千个机架中,排空一个机架的容量并用新一代硬件替换即可。然而,网络基础设施的增量刷新更具挑战性,因为 Clos 架构需要预先为整个网络构建至少脊层(Spine Layer)。这样做不幸地将数据中心可用带宽限制在脊层部署时可用的网络技术速度。

考虑一个通用的三层 Clos 网络,包括带有架顶交换机(ToR)的机架、连接机架的聚合块(Aggregation Block)和连接聚合块的脊块(Spine Block)。传统的 Clos 方法需要在第一天就以当时的技术预先构建最大规模的脊层。使用 40Gbps 技术时,每个脊块支持 20Tbps 的突发带宽。当下一代 100Gbps 技术可用时,新的聚合块可以支持 51.2Tbps 的突发带宽,但这些块会被限制在预先存在的脊块的 40Gbps 链路速度,将每个聚合块的容量降至 20Tbps。

Jupiter Evolving: Transforming Google’s Datacenter Network via Optical Circuit Switches and Software-Defined Networking插图

图一、三层 Clos 网络架构:展示了机架、聚合块和 40Gbps 脊块的连接关系。所有脊层在第一天部署,第二天部署的块用蓝色标出,第 N 天部署的块用红色标出。来自 100Gbps 聚合块的链路因 40Gbps 脊层而被降速。

三、创新方案:基于光电路交换的直连拓扑

Google 提出了一种全新的端到端设计,引入光电路交换机(Optical Circuit Switches, OCS),将 Jupiter 从 Clos 拓扑转变为块级直连拓扑(Direct-Connect Topology),彻底消除了脊层交换层及其相关挑战,使 Jupiter 能够增量整合 40Gbps、100Gbps、200Gbps 及更高的网络速度。

3.1 数据中心互连层(DCNI)

Jupiter 引入了一个光交换数据中心网络互连层(DCNI)来连接各个块。该层使用基于 MEMS(微机电系统)的光电路交换机,实现块间链路的快速、可靠和高效重新条带化(Restriping)。通过重新条带化,可以在增量添加聚合块和脊块的同时,保持所有聚合块之间的全突发带宽。

Jupiter Evolving: Transforming Google’s Datacenter Network via Optical Circuit Switches and Software-Defined Networking插图1

图二、光交换层 DCNI 架构:顶部展示了 DCNI 层如何在 Jupiter 中实现增量扩展,同时在聚合块之间实现全突发带宽;底部展示了逻辑拓扑。DCNI 层使用光电路交换机(OCS)实现,允许在添加新块时对网络进行增量重新布线。

3.2 多代际互操作性

聚合块和脊块是部署单元,通常采用当天最具成本和性能竞争力的网络技术。然而,由于数据中心的生命周期远超过一项技术的竞争周期,在单个网络中部署多代技术是不可避免的。Jupiter 需要允许多代交换芯片和链路速度在模块化块中共存和互操作。

在聚合块接口使用粗波分复用 4 通道(CWDM4)光模块是实现异构网络中跨链路代际简单互操作性的关键。得益于这种互操作性,Jupiter 能够增量演进并将异构性作为常态:约 2/3 的网络中至少有两代聚合块

Jupiter Evolving: Transforming Google’s Datacenter Network via Optical Circuit Switches and Software-Defined Networking插图2

图三、使用环形器的 Tx/Rx 双工和跨代 cWDM 光学互操作:展示了如何通过环形器实现收发双工,以及不同代际的粗波分复用光学设备如何与 OCS 互操作。

3.3 降低光交换成本的策略

Google 采用了多种技术来降低光交换层的成本:

  • 使用环形器将 OCS 端口减半:使用光学环形器将 Tx 和 Rx 双工到单根光纤中,将所需的 OCS 端口和光纤数量减半。
  • 增量端口扩展:聚合块的总流量取决于块中部署的计算和存储容量、应用的网络带宽强度以及块内流量的本地性程度。Jupiter 最初只配置一半的 DCNI 端口光学设备,支持稍后在实时网络上进行端口扩展。
  • DCNI 的增量部署:DCNI 不预先部署最大规模,而是支持在实时网络上以 1/8→1/4→1/2→全尺寸的三个增量进行部署和扩展。

3.4 直连架构的优势

多租户和建筑级网络具有相对可预测的流量模式,其不确定性远未达到最坏情况的置换流量,消除了对 Clos 拓扑所支持的最坏情况置换流量非阻塞转发的需求。基于这些观察,Google 从拓扑中移除了脊块,转而采用由流量工程拓扑工程共同优化的直连网络。

直连架构还消除了与脊块相关的成本和功耗。这种结构性运营成本降低尤为重要,因为升级到最新一代硬件在性能和功耗归一化成本方面的回报递减。

Jupiter Evolving: Transforming Google’s Datacenter Network via Optical Circuit Switches and Software-Defined Networking插图3

图四、功耗归一化带宽的递减回报:展示了连续几代交换机和光学设备的功耗(pJ/b)相对于 40Gbps 一代的归一化值。

四、直连 Jupiter 架构详解

Jupiter 的新架构通过 DCNI 层将聚合块直接相互连接。初始网络可以仅用两个块构建,然后再扩展。块之间的直接逻辑链路由三部分组成:从每个块到 OCS 的物理块到 OCS 链路,以及连接这些链路的 OCS 交叉连接。得益于 OCS,逻辑链路可以以编程方式动态形成。

Jupiter Evolving: Transforming Google’s Datacenter Network via Optical Circuit Switches and Software-Defined Networking插图4

图五、增量可部署的 Jupiter 直连拓扑网络:展示了动态流量和拓扑工程的工作原理。①:初始添加聚合块 A、B,各有 512 条上行链路。②:添加块 C。拓扑工程形成均匀网格拓扑以匹配均匀的稳态需求矩阵。③:流量工程根据更细粒度的需求调整 WCMP 权重。④:添加块 D(仅部分机架)。⑤:块 D 扩展至 512 条上行链路。⑥:块 C、D 刷新至 200G 链路速度。

4.1 逻辑拓扑

对于同构块速度和端口数,采用均匀网格互连块;每对块之间有相等(相差不超过一)数量的直接逻辑链路。均匀拓扑允许任何块对仅使用直接和单跳间接路径就能突发到块的全出口带宽。

对于不同端口数的同构块,链路数量与它们端口数的乘积成比例。例如,两个 512 端口块之间的链路数量是两个 256 端口块之间的 4 倍。

Jupiter Evolving: Transforming Google’s Datacenter Network via Optical Circuit Switches and Software-Defined Networking插图5

图六、多级逻辑拓扑分解示意图:从上到下,从块级图开始,将其分解为 4 个因子(每个对应 25% 的故障域),最后映射到 OCS。当块级图变化时(如拓扑工程),在每级分解中最小化新因子和当前因子之间的差异。

五、流量与拓扑工程

5.1 控制平面设计

Orion 是 Jupiter 的 SDN 控制平面,负责编程数据平面交换机以实现所需的流量分配。Orion 通过将路由功能分为两级来实现高可用性:

  • 第一级:每个聚合块是一个单独的 Orion 域,路由引擎(RE)提供块内连接
  • 第二级:负责聚合块之间的链路,将这些链路分为四个互斥的颜色,每个颜色由独立的 Orion 域控制
Jupiter Evolving: Transforming Google’s Datacenter Network via Optical Circuit Switches and Software-Defined Networking插图6

图七、Orion 控制和网络管理系统:展示了网络模型、操作工作流、拓扑工程控制器、网络操作 API 系统以及 IBR-C Orion 域和聚合块 Orion 域之间的关系。

5.2 非最短路径路由

传统 Clos 拓扑通过脊层的上下路由自然支持负载均衡。然而,直连拓扑对于 n 个块之间的最坏情况置换流量,在最短路径转发下是 n:1 超额订阅的。将最坏情况流量的超额订阅比降至 2:1 需要非最短路径转发。

Jupiter 将流量工程限制为 1 跳(单中转)路径,因为有界路径长度对于基于延迟的拥塞控制(如 Swift)很重要。通过将源流量和中转流量隔离到两个虚拟路由和转发(VRF)表中来消除路由环路。

5.3 流量感知路由

最初采用类似于 Valiant 负载均衡(VLB)的需求无关路由,根据路径容量在所有可用路径(直接和中转)上分配流量。然而,在这种方案下,每个块以 2:1 超额订阅比运行,对于高利用率块来说太大了。

为防止此类块的过度订阅并提高整体网络吞吐量,基于实时流量数据优化不同路径的权重。从每台服务器收集流量测量数据,聚合形成每 30 秒的块级流量矩阵。基于此流量矩阵流,维护用于 WCMP 优化的预测流量矩阵

Jupiter Evolving: Transforming Google’s Datacenter Network via Optical Circuit Switches and Software-Defined Networking插图7

图八、两种路由方案对比:(a) 预测 MLU 为 0.5,需求仅放在直接路径上。(b) 预测 MLU 为 0.5,但需求在直接和中转路径之间平均分配。当 A 和 B 之间的实际需求为 4 单位时,(b) 更鲁棒,实现 MLU 0.75,而 (a) 达到 MLU 1.0。

5.4 可变对冲(Variable Hedging)

设计了一种称为可变对冲的方案,允许在解决方案连续体的不同点上操作。这个连续体的两端分别是:以最小 MLU 和 stretch 拟合预测流量的优化,以及需求无关的 VLB 式解决方案。不同的对冲水平在正确预测下的最优性和误预测下的鲁棒性之间有不同的权衡。

5.5 拓扑工程

在同构速度网络中,均匀网格拓扑足以支持生产中观察到的流量模式。然而,仍然希望将拓扑与流量矩阵对齐以减少 stretch 并防止尾部突发行为。

在异构速度网络中,均匀网格拓扑可能因与低速对等方配对而导致太多链路降速,降低网络的整体吞吐量。

Jupiter Evolving: Transforming Google’s Datacenter Network via Optical Circuit Switches and Software-Defined Networking插图8

图九、异构网络中流量感知拓扑的优势:A 和 B 是 200Gbps 块,C 是 100Gbps。流量无关拓扑无法满足需求:A 的聚合需求为 80Tbps,而 A 的聚合带宽仅为 75Tbps。流量感知拓扑可以在 200Gbps 块之间分配更多链路(300)以提升 A 的聚合带宽。

5.6 流量与拓扑工程的节奏

流量工程是响应拓扑和流量变化的内部控制循环,粒度为 O(秒) 到 O(分钟)。拓扑工程的外部循环慢得多,不响应故障或排空,生效新逻辑拓扑需要 O(小时)。

基于仿真结果,发现块级拓扑重配置频率超过每几周一次的收益有限。这主要有两个原因:1)关于吞吐量,大多数流量变化可以通过路由充分处理;2)更频繁的拓扑重配置要有益,需要能够生成比长期预测更准确的短期流量预测。

六、实时网络重新布线

常见的网络操作(连接/断开整个块或其额外端口、适应拓扑工程的成比例直接连接、甚至将网络从 Clos 转换为直连)都遵循相同的模式。得益于 OCS,交叉连接可以使用软件配置快速可靠地编程,带来巨大的运营优势。

Jupiter Evolving: Transforming Google’s Datacenter Network via Optical Circuit Switches and Software-Defined Networking插图9

图十、添加两个聚合块的重新布线示意图:(a) 逻辑拓扑的变化。(b) 交叉连接的相应变化。

Jupiter Evolving: Transforming Google’s Datacenter Network via Optical Circuit Switches and Software-Defined Networking插图10

图十一、增量重新布线实现图十的变化(第9页第2张图):边标签显示双向链路数量。增量重新布线在所有步骤中保持至少 10 单位的双向容量(约 83%)。

重新布线期间的安全考虑

  • 维护生产流量 SLO:依赖于在网络所有切分处维护足够容量以避免严重拥塞和丢包
  • 避免跨独立故障域的相关故障:限制操作的影响范围

七、实验评估

7.1 流量特征

生产流量矩阵有两个显著特点:

  1. 块间流量最好用重力模型描述
  2. 不同块的负载变化显著

定义聚合块的归一化峰值负载(NPOL)为峰值负载归一化到该块容量。变异系数在十个网络中范围从 32% 到 56%,表明所有网络中都存在可用于中转流量的大量空闲带宽。

7.2 直连网络的最优吞吐量和 Stretch

Jupiter Evolving: Transforming Google’s Datacenter Network via Optical Circuit Switches and Software-Defined Networking插图11

图十二、10 个网络中均匀直连与拓扑工程直连的最优吞吐量和 Stretch:吞吐量归一化到假设完美高速脊层的上界。均匀直连拓扑在大多数网络中实现最大吞吐量;流量感知拓扑在两个异构速度网络中进一步将吞吐量提升到上界。

7.3 仿真结果

Jupiter Evolving: Transforming Google’s Datacenter Network via Optical Circuit Switches and Software-Defined Networking插图12

图十三、不同流量和拓扑工程配置下的 MLU 时间序列:归一化到完美流量知识下的路由和拓扑的峰值 MLU。VLB 大部分时间无法支持流量;在流量感知路由下,较大对冲减少平均 MLU 并消除大部分尖峰;拓扑工程可以同时降低 MLU 和 stretch。

7.4 生产经验

指标Clos 到均匀直连均匀到拓扑工程直连
Min RTT 50p-6.89%-11.02%
Min RTT 99p-7.00%-16.01%
FCT(小流)50p-5.77%-12.37%
FCT(小流)99p-24.22%p>0.05
FCT(大流)50p-10.29%p>0.05
传输速率 99p36.35%13.76%

表一、传输指标变化:1)Clos 到均匀直连拓扑转换(stretch 从 2 降至 1.72);2)均匀到拓扑工程直连转换(stretch 从 1.64 降至 1.04)。

使用 OCS 的网络重新布线:OCS 相比手动配线架(PP)在中位数提供 9.6 倍加速,平均 3 倍加速。

7.5 成本模型

Jupiter Evolving: Transforming Google’s Datacenter Network via Optical Circuit Switches and Software-Defined Networking插图13

图十四、网络成本模型的分层组件:展示了 Clos 和直连变体的成本模型组件。

当前 Jupiter PoR 架构的资本支出成本是基线的 70%。直连(消除脊块)和使用环形器带来的节省超过了使用 OCS 替代配线架的额外成本。

功耗的归一化成本是基线的 59%。大部分功耗降低来自移除脊层交换机及相关光学设备。环形器是无源的,无功耗;OCS 功耗可忽略。

喜欢 (0)