Jupiter Rising: A Decade of Clos Topologies and Centralized Control in Google’s Datacenter Network

Arjun Singh, Joon Ong, Amit Agarwal, Glen Anderson, Ashby Armistead, Roy Bannon, Seb Boving, Gaurav Desai, Bob Felderman, Paulie Germano, Anand Kanagala, Jeff Provost, Jason Simmons, Eiichi Tanda, Jim Wanderer, Urs Hölzle, Stephen Stuart, and Amin Vahdat Google, Inc. jupiter-sigcomm@google.com

A1 主要贡献

本文回顾了过去十年间，Google为克服数据中心网络在成本、运营复杂性和规模限制方面的问题而采取的策略。论文详细介绍了五代数据中心网络的发展历程，这些网络的设计统一遵循了三个核心主题：

1. 采用多级Clos拓扑：使用商用交换芯片构建多级Clos拓扑，能够以经济高效的方式部署楼宇规模的网络。这种拓扑结构通过增加网络层级可以扩展到几乎任意大小，并且内置了大量的路径多样性和冗余，单个元件的故障对整体容量影响较小。
2. 采用中心化控制机制：对于单一运营商、预先规划的数据中心网络而言，通用的、复杂的去中心化网络路由和管理协议显得过于冗杂。为此，Google构建了一个中心化的控制机制，该机制基于一个全局配置，并将其推送到所有数据中心交换机。这种方法将数据中心网络视为一个整体，而不是数百个必须动态发现信息的自治交换机的集合，从而简化了控制和管理协议，预示了现代软件定义网络（SDN）的许多原则。
3. 模块化硬件设计与简洁鲁棒的软件：通过模块化的硬件设计和简洁、鲁棒的软件，该设计不仅支持数据中心内部网络，还能复用于集群间网络和广域网（WAN）的部署。

基于这些原则，Google的数据中心网络已在全球数十个站点部署，在十年内容量扩展了100倍，双向带宽超过1Pbps。数据中心网络带宽需求每12-15个月翻一番（如图1所示），这主要由日益增大的数据集、需要访问更多数据的Web服务以及共享大量数据的共存应用所驱动。十年前，传统的数据中心网络架构（如图2所示）成本高昂、运维复杂，且最大规模受限于高端交换机的成本和容量，这些交换机的许多特性（如硬件支持多种协议、大型路由表）对于数据中心环境并非必需，反而增加了成本和复杂性。Google通过采用类似于用商用服务器阵列横向扩展计算能力的方法，成功地对网络进行了扩展。

A3 背景知识与设计原则

基础设施的增长驱动力。我们基础设施的巨大增长率是我们数据中心网络工作的关键动机。图1显示了自2008年以来的服务器总通信速率。在此期间，流量增长了50倍，大约每年翻一番。远程存储访问【索引7，Windows Azure Storage: a highly available cloud storage service with strong consistency+2011+SOSP】、【索引14，The Google file system+2003+ACM SIGOPS Operating Systems Review】、大规模数据处理【索引10，MapReduce: simplified data processing on large clusters+2008+Communications of the ACM】、【索引18，Dryad: distributed data-parallel programs from sequential building blocks+2007+ACM SIGOPS Operating Systems Review】以及交互式Web服务【索引4，Web search for a planet: The Google cluster architecture+2003+Micro, Ieee】共同驱动了我们的带宽需求。

2004年的传统集群网络架构。在2004年，我们部署了类似于【索引5，The datacenter as a computer: An introduction to the design of warehouse-scale machines+2009+Synthesis lectures on computer architecture】的传统集群网络。图2描绘了这种“四柱式”集群架构。我们采用了当时密度最高的以太网交换机，即512个1GE端口的交换机，来构建网络的骨干（CRs或集群路由器）。每个机架顶部（ToR）交换机连接到所有四个集群路由器，以实现规模扩展和容错。每个ToR下有多达40台服务器，这种方法支持每个集群多达2万台服务器。然而，高带宽应用必须局限在单个ToR下，以避免严重超额订购的ToR上行链路。部署大型集群对我们的服务非常重要，因为许多关联应用（如生成搜索索引、Web搜索和广告服务）能从高带宽通信中受益。此外，更大的集群通过减少因资源分散在多个小集群而无法调度作业的“搁浅”情况，显著提高了作业调度的“箱柜打包”效率。

集群规模对可用性的重要性。最大集群规模的重要性还有一个更深层次的原因。电力是以层级方式分配的，粒度从楼宇、兆瓦级发电机到物理数据中心行。每个层级都代表一个故障和维护单元。为了保证可用性，集群调度会有意将作业分散到多个行。同样，存储系统所需的冗余度部分取决于因电力事件可能同时发生故障的集群比例。因此，更大的集群能够在满足多样性要求的同时，降低存储开销并实现更高效的作业调度。

缺乏流量局部性。在集群中运行存储需要机架和电力的多样性，以避免相关性故障。因此，为了保证弹性，集群数据应该分布在集群的故障域中。然而，这种分布自然地消除了局部性，并推动了对整个集群统一带宽的需求。因此，我们的集群流量在存储布局和作业调度方面几乎没有局部性，如图3所示。对于一个有12个服务器块（机架组）的代表性集群，我们展示了流向远程块的流量比例。如果流量在集群中均匀分布，我们预计11/12的流量（92%）会流向其他块。图3显示了中位数块的分布大致如此，只有中等程度的偏差。

传统架构的性能与成本瓶颈。虽然我们传统的集群网络架构在很大程度上满足了我们的规模需求，但在整体性能和成本方面却有所欠缺。每台主机的带宽被严重限制在平均100Mbps。与incast【索引8，Understanding TCP incast throughput collapse in datacenter networks+2009+WREN】和outcast【索引21，The TCP Outcast Problem: Exposing Unfairness in Data Center Networks+2012+NSDI】相关的丢包是严重的痛点。增加每台服务器的带宽会大幅增加每台服务器的成本并减小集群规模。

构建自定义网络的决策。我们意识到现有的商业解决方案无法满足我们在规模、管理和成本上的要求。因此，我们决定构建自己的定制数据中心网络硬件和软件。我们的出发点是一个关键洞见：我们可以利用Clos拓扑（图4）和当时（约2003年）新兴的商用交换芯片产业【索引12，Data center switch architecture in the age of merchant silicon+2009+HOT Interconnects】，将集群网络扩展到几乎任意大小。表1总结了我们在构建和管理楼宇规模网络时面临的一些高级挑战。

相关工作概述。为简洁起见，本文省略了相关工作的详细讨论。然而，我们的拓扑方法、对商用芯片的依赖以及在多路径上的负载均衡与同期的研究【索引2，A scalable, commodity data center network architecture+2008+ACM SIGCOMM】、【索引15，VL2: a scalable and flexible data center network+2009+ACM SIGCOMM】非常相似。除了概述我们网络的演进，我们还进一步描述了集群间网络、网络管理问题，并详细介绍了我们的控制协议。我们运行在交换机嵌入式处理器上的中心化控制协议也与后续软件定义网络（SDN）【索引13，The Road to SDN: An Intellectual History of Programmable Networks+2013+ACM Queue】的大量工作有关。基于我们在数据中心的经验，我们后来将SDN应用于我们的广域网（WAN）【索引19，B4: Experience with a globally-deployed software defined WAN+2013+ACM SIGCOMM】。对于WAN，由于流量工程和BGP路由协议需要更密集的CPU计算，我们将控制协议从我们最初在数据中心部署时能够利用的嵌入式CPU控制器转移到了具有更充裕CPU的外部服务器上。

其他网络拓扑。最近关于替代网络拓扑的研究，如HyperX【索引1，HyperX: topology, routing, and packaging of efficient large-scale networks+2009+SC】、Dcell【索引17，Dcell: a scalable and fault-tolerant network structure for data centers+2008+ACM SIGCOMM】、BCube【索引16，BCube: A high performance, server-centric network architecture for modular data centers+2009+ACM SIGCOMM】和Jellyfish【索引22，Jellyfish: Networking Data Centers Randomly+2012+NSDI】，为均匀随机通信模式提供了更高效的带宽。然而，到目前为止，我们发现这些拓扑的优势不足以弥补其在布线、管理和路由方面的挑战和复杂性。

A2 方法细节

3. 网络演进

表2总结了我们集群网络的多代发展。

Table 1: 我们面临的高级挑战及应对方法总结。

Table 2: 多代数据中心网络。（B）表示阻塞，（NB）表示无阻塞。

3.1 Firehose 1.0

设计目标与拓扑结构。在我们最初的方法Firehose 1.0（或FH1.0）中，名义上的目标是为1万台服务器提供每台1Gbps的无阻塞双向带宽。图5详细说明了FH1.0的拓扑结构。我们的起点是使用8x10G交换机作为网络核心，4x10G交换机作为ToR。核心交换机在除最顶层外的所有层级都配置为4x10G端口朝上，4x10G端口朝下；最顶层则所有8x10G端口都朝下。ToR交换机向核心提供2x10GE端口，并有24x1GE南向端口，其中20个1GE端口连接到服务器。每个汇聚块承载16个ToR（320台机器），并向32个骨干块提供32x10G端口。每个骨干块有32x10G端口朝向32个汇聚块，最终形成一个可扩展至1万台机器的网络，每台机器平均带宽为1G。

主要缺陷。该拓扑的一个关键缺点是ToR交换机的基数较低，这在链路故障时会引发问题。如果一个源ToR的左侧上行链路和目的ToR的右侧上行链路在平均修复时间（MTTR）窗口内都发生故障，那么这些ToR上的机器之间将无法通信，尽管它们仍能与其他机器通信——这是一种应用无法很好处理的非传递性断连。

硬件实现的挑战与失败。由于我们没有构建交换机的经验，但有构建服务器的经验，我们尝试通过PCI板将交换网络集成到服务器中（见图5右上角插图）。然而，服务器的正常运行时间并不理想。服务器崩溃和升级的频率比预期的要高，重启时间也很长。由服务器故障引起的网络中断问题尤其严重，特别是对于那些承载ToR、连接多个其他服务器到拓扑第一层的服务器。最终，服务器到服务器连接的布线复杂性、电气可靠性问题、可用性以及我们首次涉足交换机领域的普遍问题，导致这项努力从未承载过生产流量。尽管如此，我们内部认为FH1.0是一项里程碑式的工作。没有它和相关的学习经验，后续的努力是不可能实现的。

3.2 Firehose 1.1: 首个生产级Clos网络

架构改进。我们首个生产部署的定制数据中心集群网络被称为Firehose 1.1（或FH1.1），它是FH1.0架构的一个变体。我们从FH1.0中学到，不应使用常规服务器来承载交换芯片。因此，我们构建了定制的机箱，该机箱以Compact PCI机箱为标准，每个机箱包含6个独立的线卡和一个专用的单板计算机（SBC）通过PCI来控制这些线卡。如图6中的插图所示。核心机箱不包含任何用于互连交换芯片的背板。所有端口都连接到在数据中心地面上布线的外部铜缆。这些线卡是FH1.0中用于第2-5层的板卡的不同形态。我们还建立了一个独立的带外控制平面网络（CPN）来配置和管理核心的SBC。

拓扑优化。FH1.1的拓扑是FH1.0中使用拓扑的变体。虽然骨干块与FH1.0相同，但图6所示的边缘汇聚块有几处不同。我们使用两个4x10G+24x1G的交换芯片，在板上通过2x10G链路侧向连接作为ToR。最终配置的ToR交换机拥有4x10G上行链路和48x1G到服务器的链路。ToR是作为独立的1RU交换机开发的，每个都有自己的CPU控制器。为了扩展到2万台机器并保持最多2:1的超额订购，我们决定将两个ToR交换机配对。每个ToR的4x10G上行链路中，两个连接到核心，两个侧向连接到配对的ToR。来自一个ToR下机器的流量可以使用所有四个上行链路突发到核心，尽管在竞争情况下带宽会较低。汇聚块内的第2层和第3层交换机被布线在一个单一的块中（而不是FH1.0中的两个不相交的块），其配置类似于扁平邻里网络（Flat Neighborhood Network）【索引11，KLAT2’s flat neighborhood network+2000+Extreme Linux track in the 4th Annual Linux Showcase】。每个ToR下最多40台机器，FH1.1的汇聚块可以扩展到640台机器，超额订购率为2:1。汇聚块的这些变化使得Firehose 1.1能够扩展到2倍的机器数量，并且对链路故障的鲁棒性远超FH1.0。

布线挑战与解决方案。FH1.1的铜缆互连是一个重大挑战。图7展示了生产部署中的机箱。构建、测试和部署网络是劳动密集型且容易出错的。我们使用的CX4电缆有14米的长度限制，这要求多级拓扑的每个组件都必须经过精心布局。最长的距离通常在我们的ToR和Firehose交换基础设施的下一层之间。为了提高可部署性，我们研究了一个解决方案，即仅在拓扑的这一层使用光纤。我们与供应商合作开发了定制的电/光/电（EOE）电缆用于这种互连。图7右下角的橙色电缆就是一根EOE电缆，能够跨越100米，而其右侧笨重的CX4电缆只能达到14米。

风险规避与部署策略。在生产环境中部署一个未经证实的新网络技术用于我们的关键任务应用是一个主要担忧。为了降低风险，我们将Firehose 1.1与我们遗留的四柱式集群网络一同部署，如图8所示。我们维持了一个简单的配置：ToR将默认流量转发到四柱式集群（例如，用于连接外部集群/数据中心），而更具体的集群内流量则使用到Firehose 1.1的上行链路。由于我们的四柱式集群使用1G链路，我们只需要保留四个1GE的ToR端口。我们还构建了一个“红色大按钮”故障安全机制，以便在发生灾难性故障时配置ToR避开Firehose上行链路。

3.3 Watchtower: 全球部署

经验总结与设计动机。我们对Firehose 1.1的部署经验大体上是积极的。我们证明了服务可以享受到比传统架构多得多的带宽，而且单位带宽成本更低。Firehose 1.1在少数几个集群中投入生产，并一直运行到最近。Firehose 1.1的主要缺点是外部铜缆布线带来的部署挑战。

新一代架构Watchtower。我们利用这些经验设计了我们的第三代集群网络Watchtower。其核心思想是利用下一代商用交换芯片（16x10G）来构建一个带背板的传统交换机机箱。图9展示了半机架宽的Watchtower机箱及其内部拓扑和布线。Watchtower由八个线卡组成，每个线卡上有三个交换芯片。每个线卡上的两个芯片有一半的端口朝外，总共提供16x10GE SFP+端口。所有三个芯片也连接到一个背板，用于端口间的连接。如图9所示，Watchtower的部署比早期的Firehose部署要容易得多。交换芯片更高的带宽密度也使我们能够构建更大规模的网络，并为单个服务器提供更多带宽，这随着服务器核心数量的不断增加而成为必需。

部署复杂性的降低。光纤捆绑进一步降低了Watchtower集群的布线复杂性。图10展示了没有进行任何电缆捆绑的Watchtower网络部署。需要从每个机箱位置拉出不同长度的单根光纤，导致显著的部署开销。下图展示了捆绑如何能大幅降低复杂性。我们在每个机架部署两个机箱，并将两个机架并置。然后，我们可以将电缆束拉到并置机架的中点，每个束在那里被分成两部分，分别送往每个机架，再进一步分到每个机箱。

Table 3: Watchtower中电缆捆绑的好处。

光纤捆绑的成本效益。最后，以束为单位制造光纤比单根制造更具成本效益。电缆捆绑帮助我们将光纤成本（资本支出+运营支出）降低了近40%，并将Watchtower网络的启动时间加快了数周。表3总结了捆绑带来的成本节约。

外部连接。图10也描绘了我们如何开始将集群网络连接到外部的集群间网络。我们将在第4节详细讨论。

成本优化：减配部署。尽管Watchtower集群网络比任何可购买的方案都要便宜得多且规模更大，但其绝对成本仍然相当可观。我们利用两个观察来进一步优化成本。首先，不同集群的带宽需求存在自然差异。其次，我们网络的主要成本在于光模块和相关的光纤。因此，我们使Watchtower网络支持减配部署（depopulated deployment），即最初只部署最大双向带宽的50%。重要的是，随着减配集群的带宽需求增长，我们可以在原地将其完全配置到100%的双向带宽。图11显示了两种减配交换机、光模块和光纤的高层选项(A)和(B)，减配部分用红色表示。(A)通过减配一半的S2交换机以及所有连接到这些S2交换机的光纤和光模块来实现50%的容量。(B)则减配一半的S3交换机及相关的光纤和光模块。对于相同的网络容量，(A)显示的减配元件数量是(B)的两倍。

减配方案的选择。(A)要求所有骨干S3机箱都预先部署，即使边缘汇聚块可能是逐步部署的，这导致了更高的初始成本。(B)的初始成本则更为平缓，因为并非所有骨干机箱都需在初期部署。与(A)相比，(B)的另一个优势是每个ToR的突发带宽是其两倍。在Watchtower和Saturn（第3.4节）网络中，我们选择了方案(A)，因为它最大化了成本节约。对于Jupiter网络（第3.5节），我们转向了方案(B)，因为随着我们向楼宇规模网络发展，部署整个骨干的初始成本增加，而更高ToR带宽的好处也变得更加明显。

3.4 Saturn: 网络扩展与10G服务器

设计目标与构建模块。Saturn是我们集群架构的下一次迭代。主要目标是应对服务器带宽需求的持续增长，并进一步扩大最大集群规模。Saturn由24x10G的商用芯片构建块构成。一个Saturn机箱支持12个线卡，提供一个288端口的无阻塞交换机。这些机箱与新的Pluto单芯片ToR交换机配合使用；见图12。

配置与性能。在默认配置中，Pluto支持20台服务器，并为集群网络配置了4x10G链路，为每台服务器提供平均2 Gbps的带宽。对于带宽需求更高的服务器，我们可以将Pluto ToR配置为8x10G上行链路和16x10G到服务器的链路，为每台服务器提供5 Gbps的带宽。重要的是，服务器首次能够以10Gbps的速率在整个网络中进行突发传输。

3.5 Jupiter: 40G数据中心规模的网络

设计动机与需求。随着每台服务器的带宽需求持续增长，对数据中心内所有集群提供统一带宽的需求也日益增加。随着支持40G的密集商用芯片的出现，我们可以考虑将我们的Clos网络扩展到整个数据中心，从而整合集群间网络层。这可能为应用调度提供前所未有的计算和存储资源池。关键的是，维护单元可以保持得足够小，相对于网络规模而言，使得大多数应用现在可以对网络维护窗口不敏感，这与前几代网络不同。

Jupiter的挑战。我们的下一代数据中心网络Jupiter，需要扩展到比我们现有最大网络大6倍以上的规模。与之前的迭代不同，我们设定了增量部署新网络技术的要求，因为资源搁浅和停机时间的成本太高。通过简单地整体替换现有集群来升级网络会搁浅已在生产中的主机。对于Jupiter，新技术需要能够就地引入网络。因此，网络必须支持异构的硬件和速度。由于其庞大的规模，网络中的事件（计划内和计划外）预计会更加频繁，要求Jupiter能够对这些事件做出稳健而优雅的反应。

构建块的选择。在Jupiter的规模下，我们必须通过独立的构建块来设计网络。然而，构建块的大小是一个关键的讨论点。一个极端是Firehose的方法，即每个交换芯片都在数据中心地面上与其他芯片布线。另一个极端是，我们可以走Watchtower和Saturn网络的路子——即，用当前的商用芯片构建尽可能大的无阻塞、两级机箱，并在网络中将该机箱用于各种角色。

Jupiter第一代架构。对于第一代Jupiter（图13），我们在构建块大小上选择了一条中间路线。我们的部署单元是一个Centauri机箱，这是一个4RU的机箱，容纳两个线卡，每个线卡上有两个交换芯片，各有16x40G端口，由一个独立的CPU线卡控制。每个端口可以配置为4x10G或40G模式。这些芯片之间没有背板数据连接；所有端口都在机箱的前面板上。

Jupiter拓扑细节。我们将Centauri交换机用作ToR交换机，其中4个芯片中的每一个都服务于一个机器子网。在一种ToR配置中，我们将每个芯片配置为48x10G到服务器和16x10G到网络核心。服务器首次可以在生产环境中配置40G的突发带宽（见表2）。四个Centauri组成一个中间块（Middle Block, MB），用于汇聚块。一个MB的逻辑拓扑是一个两级阻塞网络，有256x10G链路可用于ToR连接，64x40G链路可通过骨干连接到网络的其余部分。每个ToR芯片通过双冗余的10G链路连接到八个这样的MB。双冗余有助于在常见的单链路故障或维护情况下快速重新收敛。每个汇聚块向骨干块提供512x40G（全配置）或256x40G（减配）链路。Jupiter在骨干块中使用六个Centauri，向汇聚块提供128x40G端口。我们将Jupiter的规模限制在64个汇聚块，以便在最大规模下每个骨干块和汇聚块对之间有双冗余链路，再次是为了在单链路故障时实现局部重新收敛。

部署与规模。如图14所示，我们在一个网络机架中部署四个MB。类似地，一个骨干网络机架容纳两个预先布线的骨干块。数据中心地面的布线工作包括在这些网络机架之间以及连接到服务器机架顶部的ToR交换机之间连接光纤束。在其最大配置下，Jupiter支持服务器之间1.3 Pbps的双向带宽。

4. 外部连接

4.1 WCC: 淘汰集群路由器

背景与动机。在本节中，我们描述了如何利用现有的集群网络构建块来提高我们集群间网络 fabric 的性能和鲁棒性。从时间上看，这项工作发生在Watchtower和Saturn之间。在最初几个Watchtower部署中，所有集群网络都是作为“搭售式”网络部署的，与遗留网络共存（图8）。时间和经验缓解了安全方面的担忧，使得天平倾向于减少部署两个并行网络所带来的运营复杂性、成本和性能限制。在跨集群迁移服务或复制大型搜索索引时，限制ToR出集群的突发带宽尤其具有限制性。

设计目标与方案选择。因此，我们的下一个目标是通过将网络 fabric 直接连接到集群间网络层的集群边界路由器（Cluster Border Routers, CBRs）来淘汰集群路由器（CRs）。这项工作内部称为WCC。图15展示了外部连接的各种选择：i) 从每个ToR预留一些链路，ii) 在每个汇聚块预留端口，iii) 在每个骨干块预留端口，iv) 构建一个单独的汇聚块用于外部连接。注意i)与我们在Firehose 1.1中的方法类似。此外，假设采用最短路径路由，选项i)和ii)都无法提高外部突发带宽。然而，选项iii)和iv)为每个汇聚块提供了整个外部带宽池。我们选择了选项iv)，因为我们希望有一个独立的交换机层与外部路由器对等，而不是将对等功能分散到整个骨干交换机集合中。我们认为这种方法更安全，因为我们想限制外部配置更改的影响范围，并且它限制了我们需要将内部IGP（第5.2节）与外部路由协议集成的地方。

实现细节。根据经验，我们分配了约10%的集群内总带宽用于外部连接，使用一到三个汇聚块。这些汇聚块在物理和拓扑上与用于ToR连接的汇聚块相同。然而，我们将通常用于ToR连接的端口重新分配用于连接到外部网络。我们在这些块中的每个CBR交换机和外部交换机之间配置了并行链路作为链路聚合组（LAGs）或中继。我们在CBR和集群间网络交换机之间使用标准的外部BGP（eBGP）路由。CBR交换机通过BGP从外部对等体学习默认路由，并通过我们的集群内IGP协议Firepath（第5.2节）重新分发该路由。

成果。WCC使集群网络能够真正独立，并为集群间的大容量数据传输解锁了高吞吐量。此外，CBR交换机的模块化硬件和软件在我们的网络层次结构中的多种用例中找到了应用。

4.2 集群间网络

背景与动机。我们在同一栋建筑内署多个集群，在同一园区内部署多栋建筑。考虑到物理距离与网络成本之间的关系，我们的作业调度和资源分配基础设施利用园区级和建筑级的局部性，将松散关联的服务尽可能地就近部署。为WCC开发的CBR使得集群能够以巨大的带宽连接到集群间网络。在Watchtower网络中，每个汇聚块支持2.56Tbps的外部连接，在Saturn网络中支持5.76Tbps。然而，我们的外部网络层仍然基于昂贵且端口受限的供应商设备。我们网络 fabric 演进的第三步涉及替换基于供应商的集群间交换。我们的方法，Freedome，旨在以比现有解决方案更低的成本，在建筑内和园内实现海量的集群间带宽。

Freedome架构。我们利用在集群路由器（第5.2.5节）中开发的BGP能力，构建了能够在集群间和园区内连接层都使用BGP的两级网络 fabric。见图16。我们将一组路由器配置成称为Freedome块的单元，如上图所示。每个块暴露的南向端口（面向集群）是北向端口（面向层次结构中的下一级）的8倍。每个块有两种交换机角色：Freedome边缘路由器提供南向端口，而Freedome边界路由器提供北向端口。Freedome块使用eBGP连接到南北向的对等体。我们在每个块内部使用iBGP，并将边界路由器配置为路由反射器【索引6，Bgp route reflection: An alternative to full mesh internal bgp (ibgp)+2006+RFC 4456】。

数据中心与园区级Freedome。一个数据中心Freedome通常由4个独立的块组成，用于连接同一数据中心建筑内的多个集群。同一建筑内的本地集群间流量将从源集群的CBR层传输到数据中心Freedome，通常停留在边缘路由器层，最后到达目标集群的CBR层。我们将Freedome边界路由器的端口连接到北向的园区连接层。图16左下图描绘了一个数据中心Freedome。我们为一栋建筑内的流量配置的带宽是同一园区内建筑间流量带宽的8倍。

递归设计与优势。递归地，一个园区Freedome也通常由4个独立的Freedome块组成，用于连接南向的多个数据中心Freedome和北向的WAN连接层。图16右下图描绘了一个园区Freedome。部署独立的块对于在Freedome上保持性能至关重要，因为每个块可以独立地停止服务或排空流量，并进行升级，总容量下降仅为25%。一旦我们为园区网络推出了Freedome，BGP路由器也将在我们的WAN部署中找到应用【索引19，B4: Experience with a globally-deployed software defined WAN+2013+ACM SIGCOMM】。

5. 软件控制

5.1 讨论

控制平面设计的权衡。当我们着手为我们的网络硬件构建控制平面时，我们面临以下高层权衡：是部署传统的去中心化路由协议（如OSPF/IS-IS/BGP）来管理我们的网络，还是构建一个定制的控制平面来利用我们集群网络的一些独有特性和同质性。传统路由协议的优势在于其经过验证且鲁棒。

选择自研控制平面的原因。我们选择构建自己的控制平面有几个原因。首先，也是最重要的一点，当时现有的路由协议对多路径、等价路由转发的支持并不好。其次，十年前没有高质量的开源路由协议栈。此外，修改我们的硬件交换机协议栈以将在线运行的控制协议报文隧道传输到协议进程的工作量巨大。第三，我们担心在我们计划的规模（成百上千个交换元件）的网络中运行基于广播的路由协议会产生巨大的协议开销。像OSPF区域【索引20，OSPF Version 2+1998+STD 54, RFC 2328】这样的扩展技术似乎难以配置和理解【索引23，OSPF Areas Considered Harmful+2003+IETF Internet Draft】。第四，网络可管理性是一个关键问题，维护数百个独立的交换机协议栈和BGP配置等似乎令人望而生畏。

我们的中心化方法。我们的方法是由在一个大规模多路径的、基本静态的拓扑上进行路由的需求驱动的。每个交换机根据其在网络中的位置都有一个预定义的角色，并且可以据此进行配置。一个中心化的解决方案，即由一个路由控制器收集动态的链路状态信息，并通过一个可靠的带外控制平面网络（CPN）将此链路状态重新分发给所有交换机，从计算和通信的角度来看，似乎要简单和高效得多。然后，交换机可以根据相对于推送给所有交换机的已知静态拓扑的当前链路状态来计算转发表。

将网络视为一个整体。总的来说，我们将数据中心网络视为一个拥有数万个端口的单一网络 fabric，而不是一个由数百个必须动态发现网络信息的自治交换机组成的集合。当时，我们受到了具有中心化管理器的大规模分布式存储系统【索引14，The Google file system+2003+ACM SIGOPS Operating Systems Review】成功的启发。我们的设计为Jupiter数据中心网络和Google的B4 WAN【索引19，B4: Experience with a globally-deployed software defined WAN+2013+ACM SIGCOMM】的控制架构提供了信息。Jupiter控制架构的细节超出了本文的范围。

5.2 路由

我们现在介绍Firepath的关键组件，这是我们为Firehose、Watchtower和Saturn网络设计的路由架构。其中一些组件预示了现代软件定义网络的一些原则，特别是在使用逻辑上集中的状态和控制方面。首先，所有交换机都配置了基线或预期的拓扑。交换机通过成对的邻居发现来学习实际的配置和链路状态。接下来，路由过程是每个交换机将其本地连接视图与一个中心化的Firepath主节点交换，该主节点将全局链路状态重新分发给所有交换机。交换机根据当前的网络拓扑视图在本地计算转发表。为了保持鲁棒性，我们实现了一个Firepath主节点选举协议。最后，我们仅在网络的边缘利用标准的BGP进行路由交换，通过Firepath重新分发BGP学习到的路由。

5.2.1 邻居发现以验证连接性

问题与解决方案。构建一个拥有数千根电缆的网络不可避免地会导致多处布线错误。此外，正确布线的链路在维护（如更换线卡）后可能会被错误地重新连接。允许流量使用错误布线的链路可能导致转发环路。单向故障或产生高误包率的链路也应被避免并安排更换。为了解决这些问题，我们开发了邻居发现（Neighbor Discovery, ND），一个在线的活跃度和对端正确性检查协议。

ND工作原理。邻居发现（ND）使用配置的集群拓扑视图以及交换机的本地ID来确定其本地端口的预期对端ID。它定期交换其本地端口ID、预期对端端口ID、发现的对端端口ID和链路错误信号。这样做使得链路两端的ND能够验证布线是否正确。

与系统集成。每个交换机嵌入式协议栈上的接口管理器（Interface Manager, IFM）模块持续监控每个端口的ND状态，只有当端口同时处于PHY UP和ND UP状态时，才向路由进程声明端口为UP。线卡上的LED灯显示每个端口的ND状态，以帮助现场进行物理调试。我们的监控基础设施也收集并在各种仪表板上显示所有链路状态。ND也作为一个保活协议，以确保对端存活且功能正常。如果远程软件崩溃或关闭，对端的ND实例最终会向接口管理器报告故障，接口管理器进而会向路由进程声明接口为DOWN。

5.2.2 Firepath

基本架构。我们通过一个定制的内部网关协议（IGP）——Firepath，支持一直到ToR的第3层路由。每个ToR实现一个第2层子网，即一个ToR下的所有机器都属于同一个广播域。分配给ToR的L3子网是对齐的，以便于在商用芯片有限的转发表中进行聚合。

中心化状态分发与分布式计算。Firepath实现了中心化的拓扑状态分发，但转发表计算是分布式的，它有两个主要组件。一个Firepath客户端运行在每个网络交换机上，一组冗余的Firepath主节点运行在选定的一部分骨干交换机上。客户端通过控制平面网络（CPN）与选举出的主节点通信。图17显示了Firepath客户端与交换机协议栈其余部分之间的交互。图18说明了各种路由组件之间的协议消息交换。

工作流程。启动时，每个客户端加载整个网络的静态拓扑，称为集群配置。每个客户端从嵌入式协议栈的接口管理器收集其本地接口的状态，并将此状态传输给主节点。主节点构建一个带有单调递增版本号的链路状态数据库（LSD），并通过CPN上的UDP/IP多播分发给所有客户端。在初始的完整更新之后，后续的LSD只包含与前一状态的差异。整个网络的LSD可以容纳在64KB的负载内。收到LSD更新后，每个客户端计算带有多路径等价路由（ECMP）的最短路径转发，并对其交换机本地的硬件转发表进行编程。为了防止客户端不堪重负，主节点会限制它发送给客户端的LSD变化数量。

同步与保活。主节点还与客户端维护一个保活协议。它定期发送带有其主节点ID和当前LSD版本号的心跳消息。如果一个客户端与主节点失去同步，例如，错过了LSD消息，它会请求一个完整的LSD更新。

5.2.3 路径多样性与故障收敛

收敛机制。为了在接口状态变化时快速收敛，每个客户端在收到LSD更新后会独立计算新的路由解决方案并更新转发表。由于客户端在收敛期间不进行协调，网络在从旧状态转换到新状态时可能会经历短暂的丢包。然而，假设网络抖动是暂时的，所有交换机最终都会基于一个全局一致的网络状态视图进行操作。

收敛时间。表4显示了围绕组件故障进行路由的反应时间。由于路径多样性高，大多数故障只需要局部收敛，即故障点附近的元件通常有多个其他可行的下一跳到达最终目的地。交换机的嵌入式协议栈可以快速地从包含受影响链路的ECMP组中修剪掉故障的链路/下一跳。ToR-S2链路故障需要非局部收敛，因此需要更长的时间。在这种情况下，所有S3机箱必须为受影响ToR交换机的IP前缀避开一个特定的S2机箱。如果ToR有多个链路连接到一个S2机箱，即使这种情况也可以优化。

事件频率。Firepath的LSD更新包含了由于计划内和计划外网络事件引起的路由变化。在一个典型的集群中（来自图3），这类事件的频率约为每月2000次，每天70次，或每小时3次。

Table 4: Saturn集群中的收敛时间总结。

5.2.4 Firepath主节点冗余协议

重要性与设计。中心化的Firepath主节点是Firepath系统中的一个关键组件。它收集和分发接口状态，并通过一个保活协议同步Firepath客户端。为了保证可用性，我们在预先选择的骨干交换机上运行冗余的主节点实例。交换机通过它们的静态配置知道候选主节点。

FMRP协议。Firepath主节点冗余协议（FMRP）处理主节点选举以及活动主节点和备份主节点之间的记账工作。活动主节点与备份主节点保持保活，并确保当前的LSD在CPN FMRP多播组上与备份主节点同步。启动时，一个主节点进入Init状态，使其LSD无效并等待听到现有主节点的消息。如果它听到了现有主节点的保活消息，它就进入备份状态。否则，它进入选举状态，向其他主节点候选者广播选举请求。通常，选举的获胜者是拥有最新LSD版本的主节点。或者，抢占模式会严格根据优先级（如最高的IP地址）来选举主节点。新选举出的主节点进入主节点状态。

鲁棒性。FMRP在生产环境中多年来在多个集群中表现出鲁棒性。由于主节点选举是粘性的，一个行为不当的主节点候选者不会导致主节点变更和网络抖动。在罕见的CPN分区情况下，可能会出现多主节点的情况，这会立即提醒网络操作员进行手动干预。

5.2.5 集群边界路由器

与BGP集成。我们的集群网络通过BGP与外部网络对等。为此，我们在CBR上将BGP协议栈与Firepath集成。这种集成有两个关键方面：i) 使CBR上的BGP协议栈能够与外部BGP发言者进行带内通信，以及ii) 支持BGP协议栈与Firepath之间的路由交换。图17B显示了BGP协议栈、Firepath以及交换机内核和嵌入式协议栈之间的交互。

实现细节。对于i)，我们为每个运行eBGP的外部中继接口创建了一个Linux网络设备（netdev）。如图18所示，BGP协议数据包在带内链路上流动；我们使用嵌入式协议栈的数据包I/O引擎将这些控制数据包通过netdevs路由到运行在嵌入式协议栈上的BGP协议栈。对于ii)，CBR上的一个代理进程在BGP和Firepath之间交换路由。这个进程将集群内路由从Firepath导出到BGP RIB，并从BGP RIB中获取集群间路由，将它们重新分发到Firepath中。我们做了一个简化的假设，即为外部BGP通告将路由汇总到cluster-prefix，并为Firepath使用/0默认路由。这样，Firepath只管理所有出站流量的一条路由，假设所有CBR对于离开集群的流量都是可行的。反之，我们假设从外部网络到达集群的任何部分，所有CBR都是可行的。Clos网络固有的丰富路径多样性使得这两个简化的假设成为可能。

5.3 配置与管理

接下来，我们描述在Jupiter之前我们对集群网络配置和管理的方法。我们的主要目标是在整个机群中尽可能快地制造计算集群和网络 fabric。因此，我们倾向于简单性和可复现性而非灵活性。我们只支持有限数量的网络参数，用于生成各组部署网络所需的所有信息，并构建了简单的工具和流程来操作网络。结果，该系统很容易被负责建设数据中心的广泛技术和非技术支持人员所采用。

5.3.1 配置生成方法

核心策略。我们的关键策略是自上而下地将整个集群网络视为一个由具有预分配角色的交换机组成的单一静态 fabric，而不是自下而上地将其视为一个由独立配置并组装成 fabric 的交换机集合。我们还限制了集群级别的选择数量，基本上提供了一个基于集群预期最大规模以及可用机箱类型的简单菜单，包括 fabric 尺寸和选项。

配置生成流水线。配置系统是一个流水线，它接受基本集群级参数的规范，如骨干网的规模、集群的基础IP前缀以及ToR列表及其机架索引。然后它为各个运营团队生成一组输出文件：i) 为供应链运营提供的简化物料清单；ii) 为数据中心运营提供的机架布局细节、电缆捆绑和端口映射；iii) 为网络运营提供的CPN设计和交换机寻址细节（例如，DNS）；iv) 对网络和监控数据库及系统的更新；v) 为交换机提供的通用 fabric 配置文件；以及vi) 用于提供图形视图以审计逻辑拓扑和集群规范的摘要数据。

配置分发。我们将一个单一的、整体的集群配置分发给集群中的所有交换机（机箱和ToR）。每个交换机只需提取其相关部分。这样做简化了配置生成，但每次集群配置更改时，每个交换机都必须用新的配置进行更新。由于集群配置不经常更改，这种额外的开销并不显著，而且通常是必要的，因为Firepath需要全局拓扑状态。

5.3.2 交换机管理方法

简化管理。我们在交换机上设计了一个简单的管理系统。我们不需要大多数标准的网络管理协议。相反，我们专注于与我们现有的服务器管理基础设施集成的协议。我们受益于不在服务器和网络基础设施之间划定任意界限；实际上，我们着手使交换机对机群的其余部分基本上看起来像普通机器。例子包括镜像管理和安装、大规模监控、系统日志收集和全局警报。

CMAL接口与配置更新。嵌入式协议栈为外部系统管理设备导出了一个单一的通用管理访问层（Common Management Access Layer, CMAL）接口。我们将管理更新限制为排空或禁用特定端口。由于每个交换机上运行着多个软件组件，它们必须同时接受一个新的交换机配置。因此，我们采用了一个标准的两阶段验证-提交协议，由CMAL在交换机上协调各组件来部署新的交换机配置。

状态检索与监控。管理客户端通过一个简单的API检索交换机状态。重要的服务包括一个供操作员读取交换机状态以进行调试的本地CLI，一个支持遗留SNMP监控的最小SNMP代理，以及一个将数据导出到网络和机器监控系统的特定监控代理。最后一个客户端使我们能够重用为管理我们服务器机队而构建的所有可扩展的监控、警报、时间序列数据库（TSDB）系统，节省了大量工作。图19展示了2008-2009年9个月期间在我们集群中观察到的监控/警报类型的样本分解。机箱线卡故障的高发率是由于特定版本的商用芯片上的内存错误，并不反映线卡故障率的趋势。

5.3.3 Fabric 运营与管理

** leveraging现有基础设施**。对于 fabric 的运营和管理，我们延续了利用为管理和运营服务器机群而构建的现有可扩展基础设施的主题。我们构建了能够感知整个网络 fabric 的额外工具，从而在我们的管理软件中隐藏了复杂性。因此，我们可以专注于开发少数真正特定于我们大规模网络部署的工具，包括链路/交换机资格认证、fabric 扩展/升级以及大规模网络故障排除。同样重要的是，与Google的网络运营团队密切合作，在引入每个主要网络 fabric 代次之前提供培训，加快了每种技术在整个机群中的推广速度。

软件升级策略。图20总结了我们进行 fabric 软件升级的方法。我们不选择在交换机上支持在线固件升级，而是利用 fabric 的冗余性进行升级。我们希望 fabric 容量的下降不超过25%。该图显示了在Clos拓扑中分多步升级 fabric 机箱的两种方法。左图将所有机箱分为四组。升级红色组时，虚线红色的链路被禁用。然而，该图表明 fabric 容量下降到56.25% (75%*75%)。右图显示了一个更平滑但更耗时的升级过程，涉及八组。一次升级一台交换机会花费太长时间。

故障排查。在这样一个具有高路径多样性的网络中，对行为异常的流量进行故障排查对操作员来说是令人生畏的。因此，我们将traceroute和ICMP等调试工具扩展为能够感知 fabric 拓扑。这有助于三角定位网络中可能导致流量黑洞的交换机。我们通过在集群中随机分布的服务器之间运行探测来主动检测此类异常。当探测失败时，这些服务器会自动运行traceroute并识别网络中的可疑故障。

A7 补充细节

6.1 Fabric拥塞

问题与原因。尽管我们的网络容量巨大，但当利用率接近25%时，网络仍会经历严重的拥塞丢包。我们发现有几个因素导致了拥塞：i) 流量固有的突发性导致在短时间内出现不可接受的流量，通常表现为incast【索引8，Understanding TCP incast throughput collapse in datacenter networks+2009+WREN】或outcast【索引21，The TCP Outcast Problem: Exposing Unfairness in Data Center Networks+2012+NSDI】；ii) 我们的商用交换机缓存有限，这对于我们的服务器TCP协议栈来说并非最优；iii) 网络的某些部分为了节省成本被有意地超额订购，例如ToR的上行链路；iv) 流量哈希不完美，尤其是在故障期间和流量大小变化的情况下。

缓解措施。我们使用了几种技术来缓解网络中的拥塞。首先，我们配置交换机硬件调度器根据QoS丢弃数据包。因此，在拥塞时我们会丢弃较低优先级的流量。其次，我们调整主机以限制其集群内流量的TCP拥塞窗口，以避免超出交换机芯片的小缓存。第三，对于我们早期的网络，我们在ToR上采用链路级暂停，以防止服务器流量超出超额订购的上行链路。第四，我们在交换机上启用了显式拥塞通知（ECN），并优化了主机协议栈对ECN信号的响应【索引3，Data center TCP (DCTCP)+2011+ACM SIGCOMM】。第五，我们监控应用的带宽需求与超额订购率，并可以通过部署具有四个或八个上行链路的Pluto ToR来按需提供带宽。类似地，如果网络的减配模式导致拥塞，我们可以重新填充到骨干的链路。第六，商用芯片具有所有端口共享的内存缓冲区，我们调整了这些芯片上的缓冲区共享方案，以便动态地分配不成比例的总芯片缓冲区空间来吸收暂时的流量突发。最后，我们仔细配置了交换机的哈希功能，以支持在多个网络路径上实现良好的ECMP负载均衡。

效果。我们的拥塞缓解技术带来了显著的改善。我们将一个典型Clos网络在25%平均利用率下的丢包率从1%降低到<0.01%。图21显示了一个具有10G主机的代表性Saturn集群中三个主要拥塞源的分布。最大的丢包来源是主机扇入（host fan-in）——流量从ToR扇入到某些主机。第二大来源是ToR扇入（ToR fan-in），这可能是由不完美的哈希和到特定ToR的incast通信引起的。最后，相对较小比例的丢包是由于ToR上行链路到网络的超额订购造成的。进一步改善网络拥塞响应仍然是一项持续的努力。

6.2 故障

虽然我们数据中心网络的整体可用性令人满意，但我们的故障主要分为三类，代表了生产中最常见的故障：i) 大规模下的控制软件问题；ii) 老化硬件暴露出以前未处理的故障模式；以及iii) 某些组件的错误配置。

6.2.1 大规模下的控制软件问题

故障案例。在第一个例子中，一次数据中心电力事件导致整个网络同时重启。然而，控制软件在没有手动干预的情况下未能收敛。不稳定的发生是因为我们的活跃度协议（ND）和路由计算在嵌入式交换机CPU上争夺有限的CPU资源。在整个网络重启时，路由经历了巨大的抖动，这反过来导致ND无法足够快地响应心跳消息。这进而导致路由的雪球效应，链路状态会虚假地从UP变为DOWN，然后再变回UP。我们通过手动一次只启动几个块来稳定网络。

经验教训。展望未来，我们将最坏情况下的网络重启纳入了我们的测试计划。由于最大规模的数据中心永远无法在硬件测试实验室中构建，我们启动了在虚拟化环境中大规模压力测试我们控制软件的努力。我们还仔细审查了活跃度协议中的任何计时器值，为最坏情况调整它们，同时平衡在通常情况下的较慢反应时间。最后，我们降低了共享同一CPU的非关键进程的优先级。

6.2.2 老化硬件暴露未处理的故障模式

故障案例。经过多年的部署，我们内置的网络冗余由于硬件老化而退化。例如，我们的软件对内部/背板链路故障很脆弱，导致了罕见的流量黑洞。另一个例子围绕着控制平面网络（CPN）的故障。每个网络机箱都有到CPN的双冗余链路，工作在主备模式。我们最初没有主动监控主用和备用链路的健康状况。随着时间的推移，供应商设备遭受了某些CPN链路的单向故障，暴露了我们路由协议中未处理的角落案例。

经验教训。如果对网络背板和CPN链路有适当的监控和警报，这两个问题本可以更容易地缓解。

6.2.3 组件错误配置

故障案例。一个显著的错误配置故障发生在一个Freedome网络上。回想一下，Freedome机箱运行与CBR及其集成的BGP协议栈相同的代码库。一个CLI接口支持对CBR BGP协议栈的配置。我们没有实现锁定来防止对BGP配置的同时读/写访问。在一次对Freedome块进行计划的BGP重新配置期间，一个独立的监控系统巧合地使用了相同的接口来读取正在运行的配置，而此时更改正在进行中。不幸的是，由此产生的部分配置导致了Freedome与其BGP对等体之间的不期望行为。

经验教训。我们通过快速恢复到以前的配置来缓解了这个错误。然而，它教会了我们进一步加固我们的操作工具。工具不仅要能够整体配置网络，还需要以安全、可靠和一致的方式进行配置。

A4 实验环境与结果

实验环境

本文是一篇回顾性系统论文，描述了过去十年间在Google全球数据中心部署的五代生产网络。因此，没有传统的独立“实验环境”章节。其环境和配置可总结如下：
- 硬件配置：
- 网络设备：自研的五代交换机和机箱，包括Firehose 1.0/1.1、Watchtower、Saturn和Jupiter。这些设备基于不同世代的商用交换芯片构建，端口速率从1G/10G逐步演进到40G。
- 服务器：连接到自研网络的数万台商用服务器，网卡速率从1G演进到10G/40G。
- 平台：部署在全球数十个数据中心站点，形成了楼宇规模乃至数据中心规模的网络。

• 软件配置：
  • 控制平面：自研的中心化控制软件，核心是名为Firepath的内部网关协议（IGP），以及用于主节点选举的FMRP协议和用于验证连接的ND协议。
  • 管理平面：集成了Google现有的服务器管理基础设施，包括镜像管理、大规模监控、日志收集和全局警报系统。
  • 外部协议：在网络边界（CBR）集成了标准的BGP协议栈，用于与外部网络进行路由交换。

实验结果

论文的“结果”体现在其十年的运营经验、量化数据和从真实故障中汲取的教训。
- 规模与性能演进：网络规模和带宽在十年间实现了巨大增长。
- 服务器总流量在8年内增长了50倍（图1）。
- 网络双向带宽从最初的Tbps级别增长到Jupiter的超过1.3Pbps，容量扩展了100倍（摘要，3.5节）。
- 服务器接入带宽从平均100Mbps提升到Jupiter的10Gbps（40G突发），实现了质的飞跃（表2）。
- 设计选择的量化效益：
- 光纤捆绑：在Watchtower部署中，通过捆绑光纤将成本（资本+运营）降低了近40%，并加快了数周的部署时间（表3）。
- 故障收敛：得益于高路径多样性，大多数故障（如S2-S3链路故障）能在500毫秒内实现本地收敛。非本地收敛（如ToR-S2链路故障）需要约3秒（表4）。
- 网络行为与拥塞分析：
- 流量局部性：集群流量高度非本地化，一个典型集群中约92%的流量是跨服务器块的（图3），验证了对统一带宽的需求。
- 拥塞缓解：通过一系列优化措施（QoS、TCP调优、ECN等），在25%平均利用率下，网络丢包率从1%降至低于0.01%（6.1节）。
- 拥塞来源：Saturn网络中的拥塞主要来自主机扇入（Host fan-in），其次是ToR扇入（ToR fan-in），ToR上行链路超额订购导致的丢包相对较少（图21）。
- 运营经验与故障分析：
- 事件频率：一个典型集群中，由计划内和计划外事件引发的路由变化频率约为每小时3次（5.2.3节）。
- 故障类型：生产中的故障主要分为三类：大规模下的控制软件问题、老化硬件暴露的故障模式和组件错误配置。这些真实的故障案例为后续系统设计提供了宝贵的经验教训（6.2节）。

A5 结论

本文回顾了Google在过去十年间、跨越五代产品的生产数据中心网络演进历程。为了以可接受的成本为更大规模的集群提供更多带宽，我们采用了多种互补技术。我们使用高带宽密度但功能有限的商用交换芯片构建了多级Clos拓扑。由于现有路由协议难以适应Clos拓扑，我们摒弃了传统观念，构建了一个中心化的路由控制器，该控制器利用了推送到每个数据中心交换机的预定义集群计划的全局配置。这种中心化控制的思想延伸到了我们的管理基础设施，使我们能够摒弃复杂的协议，转而采用管理服务器机群的最佳实践。我们的方法使我们能够为楼宇规模的网络提供巨大的双向带宽，并为应用带来了显著的益处。

方法细节中的引用汇总

编号	参考文献	引用段落	引用描述
[1]	Ahn, J. H., et al. HyperX: topology, routing, and packaging of efficient large-scale networks. SC 2009.	A3	讨论了替代网络拓扑，如HyperX，但因布线、管理复杂性未被采用。
[2]	Al-Fares, M., et al. A scalable, commodity data center network architecture. SIGCOMM 2008.	A3	提到本文的拓扑方法与此项同期研究相似。
[3]	Alizadeh, M., et al. Data center TCP (DCTCP). SIGCOMM 2011.	A7	作为拥塞缓解措施之一，在交换机上启用ECN并优化主机响应。
[4]	Barroso, L. A., et al. Web search for a planet: The Google cluster architecture. IEEE Micro 2003.	A3	作为驱动带宽需求的交互式Web服务的例子。
[5]	Barroso, L. A., and Holzle, U. ¨ The datacenter as a computer. 2009.	A3	描述了2004年部署的传统集群网络与此文献类似。
[6]	Bates, T., et al. Bgp route reflection. RFC 4456, 2006.	A2	在Freedome块内部，边界路由器被配置为路由反射器。
[7]	Calder, B., et al. Windows Azure Storage. SOSP 2011.	A3	作为驱动带宽需求的远程存储访问的例子。
[8]	Chen, Y., et al. Understanding TCP incast throughput collapse in datacenter networks. WREN 2009.	A3, A7	传统架构的痛点之一是incast；流量突发性导致的拥塞表现为incast。
[10]	Dean, J., and Ghemawat, S. MapReduce: simplified data processing on large clusters. CACM 2008.	A3	作为驱动带宽需求的大规模数据处理的例子。
[11]	Dietz, H. G., and Mattox, T. I. KLAT2’s flat neighborhood network. 2000.	A2	Firehose 1.1的汇聚块配置类似于扁平邻里网络。
[12]	Farrington, N., et al. Data center switch architecture in the age of merchant silicon. HOT Interconnects 2009.	A3	提到关键洞见是利用当时新兴的商用交换芯片产业。
[13]	Feamster, N., et al. The Road to SDN. ACM Queue 2013.	A1, A3	提到本文的中心化控制方法预示了现代SDN的许多原则。
[14]	Ghemawat, S., et al. The Google file system. SOSP 2003.	A3, A2	作为驱动带宽需求的远程存储访问的例子；中心化控制的设计受到了类似GFS的中心化管理器的启发。
[15]	Greenberg, A., et al. VL2: a scalable and flexible data center network. SIGCOMM 2009.	A3	提到本文的拓扑方法与此项同期研究相似。
[16]	Guo, C., et al. BCube: A high performance, server-centric network architecture. SIGCOMM 2009.	A3	讨论了替代网络拓扑，如BCube，但因布线、管理复杂性未被采用。
[17]	Guo, C., et al. Dcell: a scalable and fault-tolerant network structure for data centers. SIGCOMM 2008.	A3	讨论了替代网络拓扑，如Dcell，但因布线、管理复杂性未被采用。
[18]	Isard, M., et al. Dryad: distributed data-parallel programs from sequential building blocks. SOSP 2007.	A3	作为驱动带宽需求的大规模数据处理的例子。
[19]	Jain, S., et al. B4: Experience with a globally-deployed software defined WAN. SIGCOMM 2013.	A1, A3, A2	提到本文的设计复用于WAN部署；数据中心的SDN经验启发了B4 WAN的设计。
[20]	Moy, J. OSPF Version 2. RFC 2328, 1998.	A2	提到OSPF区域等扩展技术难以配置和理解。
[21]	Prakash, P., et al. The TCP Outcast Problem. NSDI 2012.	A3, A7	传统架构的痛点之一是outcast；流量突发性导致的拥塞表现为outcast。
[22]	Singla, A., et al. Jellyfish: Networking Data Centers Randomly. NSDI 2012.	A3	讨论了替代网络拓扑，如Jellyfish，但因布线、管理复杂性未被采用。
[23]	Thorup, M. OSPF Areas Considered Harmful. IETF Internet Draft 2003.	A2	引用此文献说明OSPF区域难以理解。