十几年前，谷歌发现传统的网络架构无论是硬件还是软件，都无法满足其带宽需求和数据中心分布式计算基础设施的规模。秉着 “没有人做就自己做” 的精神，谷歌开始构建自己的网络硬件和软件，将数据中心中所有的服务器连接在一起，为其分布式计算和存储系统提供动力。

2015年，谷歌在SIGCOMM会议上发表论文《Jupiter Rising: A Decade of Clos Topologies and Centralized Control in Google’s Datacenter Network》，详细地阐述了谷歌过去多年在数据中心网络的创新和演进。

该论文写道：“我们意识到现有的商业解决方案无法满足我们的规模、管理和成本要求。因此，我们决定构建自己的定制数据中心网络硬件和软件，可以通过Clos 拓扑和当时新兴（约 2003 年）的商业交换芯片将集群结构扩展到任意大小。”

此后，谷歌开始了自研之旅。2005年，谷歌设计了第一代数据中心网络，名为Firehose 1.0。一年后，第二代Fierhose 1.1并真正部署在了谷歌数据中心的网络中。随后，第三代Watchtower、第四代Saturn被推出。2012年，谷歌第五代数据中心网络Jupiter引入了SDN技术并且使用了OpenFlow。

从谷歌此前发布的数据中可以看到，2012年推出时，Jupiter使用了16x40G的交换芯片，整个网络带宽达到了1.3P。

今年，谷歌在SIGCOMM会议上发表了《Jupiter Evolving: Transforming Google’s Datacenter Network via Optical Circuit Switches and Software-Defined Networking》，更新了Juniper的最新进展。

接下来我们先简单回顾下谷歌的前四代数据中心网络，它们经历了哪些更迭？在当时又引起了怎样的市场波动？

谷歌数据中心网络的历代更迭

第一代：“Firehose 1.0”

2005年谷歌推出了第一代网络架构Firehose1.0，第一代的目标是使用具有双通道带宽的 1Gbps 交换器芯片（Bisection BandWidth）来为 10K 服务器提供网络服务。网络拓扑如下图所示。

网络一共分为五层。最上层是高性能架顶式交换机（ToR），ToR交换机的上方是2×10G，下方是24×1G。第二、三、四层交换机上方和下方均是4×10G接口，第五层交换机只有下方有8×10G接口。第四层和第五层组成一个骨干块，每层交换机数量分别为8台和4台。每个骨干块有32×10G个接口，分别连接到32个汇聚块的32个上方端口，因此系统的带宽可以达到32×4×8×10G=10T的带宽。这就构成了整个FH1.0的拓扑。

但是该网络存在着一些问题，导致Firehose 1.0 并没有正式投入使用，但这给谷歌之后的设计带来了经验以及新的发展思路。

第二代：“Firehose 1.1”

2006年，对第一代系统改进后，第二代Fierhose 1.1被推出。对于 FH 1.1，谷歌主要改进了高性能架顶式ToR交换机。Firehose 1.1 TOR 是一个 1U 48x1G+4x10G 交换机，带有自己的控制平面 CPU（内部有 2 个 24x1G+4x10G互连芯片）。

为了稳妥起见，谷歌采用了与传统的厂商设备网络同时存在的方式去部署Firehose 1.1，如下图所示。

第三代：“Watchtower”

FH1.1的实际部署取得了非常积极的效果，但其部署时需要额外的铜质光缆。结合前两次的经验，谷歌在2008年设计推出了第三代架构Watchtower。

另外，为了降低部署的复杂度，谷歌使用了捆绑光纤的技术，得到了诸多的好处，如下图所示。

相比于之前的 Firehose 1.1，谷歌的第三代网络 Watchtower 最大的创新点在于使用了当时最新的 16x10G 的交换芯片，比上一代的接口数量提高了两倍。每个底盘新增了两个线卡的插槽，系统最高可以达到82T的带宽。

第四代：“Saturn”

第四代 Saturn 架构的诞生是为了迎合日益增长的服务器数量和带宽需求，因此这一代中交换机使用了更加先进的24x10G交换芯片到高性能机架式ToR交换机中。

每一个Saturn底盘支持12个线卡，能提供288个端口的无阻塞交换能力。接入服务器需要的带宽可以配置为2Gbps或者5Gbps，另外服务器最大可以获取10Gbps的带宽，而系统的总带宽也提高到207T。

Saturn架构之后就是本文将重点介绍的Jupiter架构。多年已过，Jupiter架构有了哪些新的突破？

不断进击的Jupiter

2012年，谷歌推出了Jupiter，引入了SDN技术并且使用了OpenFlow，架构如下图所示。

骨干块（Spine Block）分为两层，上层包含四组，每组向下提供32x40G的连接。下层包含8组，同时向上层和下层提供128x40G的接口。因此一个骨干块可以提供128x40G的带宽。汇聚块由8个Middle Block(MB)构成，MB的实际大小如上图所示，每个汇聚块向上通过256x40G的接口与骨干块相连。

2015 年，谷歌Jupiter 数据中心网络扩展到了 30000 多台服务器，每台服务器的连接速度统一为 40Gb/s，支持超过 1Pb/秒的总带宽。

现如今，Jupiter 支持超过 6Pb/秒的数据中心带宽。谷歌利用三个想法实现了该性能和规模：

• 软件定义网络 (SDN)：一种逻辑上集中和分层的控制平面，用于对数据中心网络中的数千个交换芯片进行编程和管理。
• Clos 拓扑：一种多级电路交换拓扑，理论上，通过添加多个层级，它的大小可以任意改变。
• 商用交换芯片：用于融合存储和数据网络的具有成本效益的商用以太网交换组件。

通过建立在这三个支柱之上，Jupiter 的架构方法支持了分布式系统架构的巨变，并为整个行业如何构建和管理数据中心网络奠定了基础。

然而，超大规模数据中心仍然存在两个主要挑战。首先，数据中心网络需要以整个机房的规模部署，可能是40MW或更多的基础设施。此外，部署在大楼里的服务器和存储设备总是在不断发展，例如从40Gb/s到100Gb/s到200Gb/s，再到今天的400Gb/s本机网络互连。因此，数据中心网络需要动态发展。

如下图所示，Clos拓扑结构需要Spine层对可能连接到它的最快设备有一致性的支持。部署一个机房规模的、基于Clos的数据中心网络意味着需要预先部署一个非常大的Spine层，设备需要具备当前最新一代的网络速度。这是因为Clos拓扑结构本质上需要从汇聚层块1到Spine层的all-to-all全扇出，逐步增加Spine将需要重新为整个数据中心布线。想要加入更快速率的新设备的一种方法是更换整个Spine层，但这是不现实的，因为机房有数百个独立的交换机机架和数以万计的光纤对贯穿整个大楼。

图：带200Gb/s端口速度的新汇聚块（绿色）与3个原有的100Gb/s端口速度的Spine块（蓝色）和1个新的200Gb/s端口速度的Spine块（绿色）相连。在这个模型中，只有新汇聚块和新Spine块间25%的链接是以200Gb/s的速度运行。

谷歌通过开发并在Jupiter架构中引入光路交换机（OCS）打破了这一僵局。光路交换机通过两组可在两个维度上旋转的微机电系统（MEMS）镜面，动态地将光纤输入端口映射到输出端口，从而实现任意的端口对端口的映射。

图：单个OCS设备通过MEMS镜面将N个输入光纤映射到N个输出光纤的过程

通过在数据中心交换机之间引入OCS中间层，可以为数据中心网络创建任意的逻辑拓扑结构，如下图所示。

图：汇聚层块通过光纤连接到OCS交换机。通过配置每个OCS交换机来连接输入和输出光纤的排列组合，可以实现不同逻辑拓扑结构。

虽然数十年来的传统观点认为OCS技术在商业上是不可行的，但谷歌经过多年的努力，设计并建造了Apollo OCS。谷歌将光路交换 (OCS) 和波分复用 (WDM) 深度集成到Jupiter中， OCS 与SDN 架构的结合实现了新的功能：支持使用异构技术构建增量网络；具有更高的性能和更低的延迟、成本和功耗；实时应用优先级和通信模式以及零停机的升级。同时，Jupiter 还将流量完成时间减少了 10% ，提高了 30% 的吞吐量，降低了 40% 的功耗，减少了 30% 的成本。

Jupiter较此前增加了许多创新点：

• 光交换机作为机房规模网络的互操作点，可以无缝支持异构技术，满足升级和各种服务要求；
• 直接采用网状的网络拓扑结构，用以实现更高的性能、更低的延迟、更低的成本和更低的功耗；
• 实时拓扑和流量工程实现网络连接和路径的同时调整，满足匹配应用优先级和通信模型的需求，还可以观察到实时维护和故障；
• 通过局部增加/减少网络容量进行Hitless网络升级，避免了对昂贵且繁琐的 “所有服务退出 “式的升级的需要，这种升级以前需要迁移数百个客户和服务以便延长机房的停机时间。

在这个流量爆炸的时代，数据中心对于带宽的需求增长迅速，谷歌在数据中心网络发展方面走在了前列。总的来说，相较于十年前，谷歌完整地迭代重构了Jupiter数据中心网络，并在此过程中引入了许多创新。

SDNLAB后台回复【0915Jupiter】，获取2015年和2022年的论文链接

参考文献：
https://cloud.google.com/blog/topics/systems/the-evolution-of-googles-jupiter-data-center-network
http://zeepen.com/2015/12/31/20151231-dive-into-google-data-center-networks/
https://zhuanlan.zhihu.com/p/400613672
https://zhuanlan.zhihu.com/p/29945202