Google在过去十几年绝对是数据中心的发展上面是走在最前列的，在数据中心网络的发展上面绝对也是前列的，在2015年的时候Google把他们之前的数据中心的网络发展历史在SigComm上面公布了，我们今天可以来看看Google可以公开的老东西能给我们什么启发。原文戳这里：https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/43837.pdf

第一点，基于市场上已有的switch的材料来建立的multi-stage Clos topologies是可以支持一个很大的数据中心的网络需求的。

第二点，很多传统的，去中心化的，可以兼容各种不同的设置的数据中心内部网络对于Google来说绝对是太复杂了（这里潜台词是Cisco卖的东西很多功能Google用不到）。对于Google来说，它的数据中心都是提前计划好的，而且只有一个客户，就是Google自己。在这个前提下，把网络简中心化是有优势的。

第三，Google自己设计的网络硬件和软件让他们可以支撑跨集群（inter cluster，我这个瞎翻译的）跟跨地域（wide-area，也是瞎翻的）的网络。这几个点在开头都讲到比较含糊，后面会具体解释每一个点是什么意思。

导言

网络在云计算的时代对于数据中心来说是非常重要的。对于Google来说，每12～15个月数据中心内的网络流量会翻倍。为什么需求增长这么快呢？

数据的大小在变，互联网上有很多的照片／视频。处理这些数据的算法在处理的时候需要帮运的数据就变得更多了网络服务如果可以拿到更多的数据，更多的特征的话，返回给用户的结果会更好公司内部的各种服务也会分享不同的数据，比如搜索跟广告

十年前，Google发现了传统的数据中心的网络能力其实基本上就是卡在一个点上面：市面上能买到的最大的switch是多大。这些switch都能支持各种各样的协议，而且也不对数据中心的设置有任何的假设，而不是像数据中心里面所有的网络都是可以提前设置好的。很多市面上switch能够提供的功能对于Google来说是无用的，而且还特别地贵。

这些swtich还有一个问题就是在传统的WAN互联网结构里面，每一个swtich挂掉问题都是不好的，所以这些市面上的switch都为了高可用性做了不同的牺牲。如果如果网络硬件便宜而且每个link挂掉代价没有那么大，那么就不需要为了高可用性做什么牺牲，况且需要支持的网络协议也没有那么多了。

Google在设计网络的时候遵守了下面几个大的原则：

Clos Topology：一种multistage circuit stage network，具体解释戳这里：Clos network - Wikipedia 。它的好处就是在扩张的时候基本上可以扩张到随意大小，只限制在故障方面的考量跟具体能够控制这么多个switch。虽然这个设计抗故障能力很强，但是在fibre fanout还有在多个代价差不多的路线上面去做routing这两个方面还是有挑战的。Merchant Silicon：所有的网络硬件层面的设计用的都是市面上已有的解决方案，来做这个switch，而且紧跟市面上最好的网络硬件的发展，及时更新。Centralized control protocols：因为设计理念基于Clos topology，在管理层面变得非常的复杂，这时候这些switch的控制就需要一个特定的系统来总体的统筹了。

背景介绍

04年的时候Google里面的网络设计是长这样的

这个图片里面的CR／Cluster Router就是当时市面上最贵最好的swtich，512 ports of 1GE。每个rack里面的机器都是连到Top of the rack，然后ToR再跟CR沟通。这种网络架构最大的问题就是如果某一种服务需要很多的网络用量，那么必须确保绝大部分的网络都是在一个rack里面进行的，不然每个CR中间只有2*10G，是不够所有人一起用的。这种设计在ToR跟CR之间我们叫over subscribed。这个设计还有一个副作用就是每个集群必须要大，足够大来确保集群跟集群之间不需要网络沟通，这样等于是数据中心在设计的时候必须配合网络，不过大集群当然还有其他的考量，比如电流。

如果这些机器是一个储存服务，那么这个我们需要确保储存的数据不能在一个rack／集群上面，不然会出现correlated failure。但是如果要分散数据的话，就会需要用跟多的CR层面的网络，所以储存类服务需要常常跟其他的rack去沟通。

这个设计在当时是符合Google的内部需求的，但是总体的速度和价格还是不尽人意。每个host网络最多能用100Mbps，丢包率也是很高（没说具体多高）。如果要增加带宽那么价格就会增加。这个时候他们了解到了现有的网络设计是没有办法继续扩张的，所以Google开始往Clos topologies上面移：

Google当时遇到的最大的问题有下面几个

这个到后面我们会一个一个来解答。Paper里面还提到了市面上还有几个可替换的解决方案比如HyperX， Dcell，BCube和Jellyfish，这个大家有兴趣的话可以去看看这个paper的reference。

Google内部网络设计的进化史

下图是Google每个世代的网络架构的参数：

Firehose 1.0一开始设计的时候主要就是为了能够支持在一个10k机器的集群里面，每个host有1Gbps的nonblocking bisection bandwidth（看最右一栏Bisection BW从2T变成了10T）。这个时代的最大的问题在于ToR Switch的基数比较低，每一对ToR之间的link断了之后这两个rack之间是不能沟通的，虽然能跟其他rack沟通。下图是Firehose 1.0的具体设计

Google当时在服务器设计端比较有经验，所以试过把switching的硬件通过PCI-E插到服务器上面。但是服务器常常挂掉／要被换，如果是负责routing的服务器挂掉的话整个rack都断网；由于这些缺陷Firehose 1.0从来没有进到production。

Firehose 1.1: First Production Clos

1.1 跟1.0差别在于，swtiching的逻辑不再是基于某一个服务器的了，而被放到了分开的一个盒子里面。用来控制这些网卡的网络是完全跟服务器的网络分离的。1.1也为了确保整体每个rack的网络over subscription不超过两倍，每两个ToR被绑在了一起。每个ToR有4*10G跟48*1G的link，这里面两条10G的link是连在fabric上面的，另外两条link连到了被绑定的ToR上面，每次每个机器的网络可以四条都用。Stage 2／3的swtich是全部都连在一起的，而不是分开的两个block。下图是1.1具体的设置

对于这个设计来说，连网线也是一大挑战，Google当时的线主要是14米长，所以连的时候要事先计划好，所以还特地设计了100米的光纤让连线变得更容易。

Watchtower: Global Deployment

Firehose 1.1的反响不错，但是当时没有把所有的集群都移到firehose上面。接下来继续在Google内部推的网络叫Watchtower，主要差别在于解决之前连线的麻烦跟启用新一代16*10G的switch芯片。新一代的chasis跟内部设计长这样

大姐可以看到内部很多linecard都事先连接好了。新一代的watchtower也用fibre bundling来减少要连的线的数量，下图可以看到很多密密麻麻的线都变成一条大粗线了，而且还更便宜。

新一代的网络还是很贵，而且不是所有的服务需要那么多的网络的。为了减少开支，每次deploy的时候会先把bisection BW减半，如果还有更高的需求的话会再把线连上，这样可以减少光纤的开支。

Saturn: Fabric Scaling and 10G Servers

Saturn 主要差别是用了新的24x10G的硬件，以及更大的chasis跟密度更高。

Jupiter: A 40G Datacenter-scale Fabric

Junpiter最大的进步在于要让整个数据中心内部的交流都是同样的bandwidth，这样可以在网络层面消除在一个数据中心里面的软件需要考虑网络架构的问题，所以要不Saturn的fabric大6倍。而且因为网络的scale变得比以前大得多了，整体网络设计的时候需要更多考虑在系统故障的时候要如何处理。这一代网络的硬件从24*10G变成了40*10G，而且现在所有的aggregation block都连上了spine block

每个硬件的分割大小是一个Centauri chasis，里面有四个16*40G的硬件，这个分割大小比watchtower要小，但是比firehose要大。这里还要注意为了确保spine block上有足够的冗余，有两个是没有连上的，不是图片出了问题。

从这一代网络开始，Google内部的很多软件是不需要考虑网络的locality的问题了，因为整个数据中心的网络都是平的。这个绝对是划时代的网络架构。

外部链接

这里段是描述Google如何处理集群之间的网络，时间线在Watchtower跟Saturn之间，因为Jupiter这一代已经没有每个集群的网络分割了。当时有四个不同的选择可以让这个集群里面的机器连上外部的网络：

他们最后选择了第四个，这个选择对于他们来说跟安全，因为不想所有的spine block都连到外网上面。

每个集群跟每个建筑物之间的网络都是跟之前的类似的层级

软件控制

一开始设计控制这些网络硬件的软件的时候就有一个问题，到底是用传统的，去中心化的OSPF/IS-IS/BGP这类算法来控制，还是中心化的通过定制的软件来控制这些硬件。传统的去中心化的算法最大的好处就是大家都知道而且稳定。Google最后还是决定用定制的软件来控制，主要是因为下面几个因素

传统的算法不好控制多条相同代价的线路十年前没有什么特别好的开源的routing解决方案需要改动很多东西才能让Google自己设计的硬件去兼容不同的routing protocol这些去中心化的protocol常常需要用到broadcast，在上百个甚至上千个switch的情况下这些broadcast是相当高的间接费用需要能够直接的控制这些switches

那Google内部网络的routing具体是怎么做到呢？这个routing算法叫firepath，具体有下面几个步骤

每个switch都会自带一些数据来表达一开始设计的时候这个数据中心的网络拓扑具体是怎样的。通过跟邻居来沟通现在具体的拓扑是什么。每个switch都会跟一个中心化的服务器沟通现在它的邻居的状态如何，中心化的服务器会处理现在所有switch汇报的信息然后再返回给所有switch最新的状态switch会根据中心化的服务器的信息，在本地计算现在应该如何routeBGP是在网络的边缘用的，跟外部沟通然后返回给中心服务器外部的状态当然，这里提到的Firepath master是有冗余的，有master election。

这个firepath具体架构长这样

设置管理

在这么多switch的情况下设置管理也是不小的一个难点。Google对网络设置的理念就是：把整个大的网络当成一个static fabric，里面有已经设置好功能的switch，而不是一个有hierarchy的网络架构。

在管理switch的时候，Google把它当成一个非常普通的机器来对待：有警报，有logging，还可以管理image。下图是Google在08到09年各种不同的switch的故障原因

为了帮助网络人员维护，他们还改动了traceroute跟icmp让这些工具了解Google内部的网络架构，这样更容易知道哪里出了问题

经验之谈

Google的网络硬件利用率达到25%的时候会开始变慢，这里面有各种这样的问题

网络利用本身比较burstyswitches的缓冲不够大ToR的uplink本身就是为了省钱而有over subscriptionflow hashing做的不够好，特别是有故障的时候

他们用了几个方案来解决这些问题

设置QoS，重要的网络优先级高在inter cluster的时候服务器端的tcp被设置的不会塞满switch的缓存在早起的网络硬件里面，确保每个rack不会超过自己over sunbscribed的网络太多用explicit congestion notification如果有软件真的需要很多网络，改uplink的数量每个硬件层面上的内存都是共享的，把这个共享机制改成动态的，这样忙的网络可以用跟多的内存改动hashing来确保负载均衡是有效的

这些东西让整个网络在25% utilize的时候丢包从1%降到了0.01%。

虽然停机出现的不多，但是这个网络系统还是出现过停机的状况，主要是因为

控制软件在大的scale下出问题老旧硬件暴露出之前没暴露出的问题设置错误（好吧这条我服气。。）

好啦，这里原文都讲完啦，接下来是我自己的理解跟观察。基本上最底层的网络芯片Google是不做的，估计是broadcom的芯片，跟Cisco那些硬件在芯片层面是没有差别的。这里Google为什么能够做成，他们很重要要考虑的事情其实是两点，数据中心网络的重要性和业界能给出的解决方案到底能让Google有多满意。

为什么数据中心的网络这么重要，我自己的观察是因为这是少有的在数据中心里面还可以有长足进步的维度。现在基本上单核的CPU速度进化已经不快了，当然总体CPU的速度还是在提升；内存这几年价格爆炸，基本上加内存也实际了；Flash这几年价格也没便宜下来；更不要说xpoint或者silicon photonic这些Intel没边的科技了。这时候有一个可以有长足进步可能的网络层就变得尤为重要。

业界能给出的解决方案基本上说白了就是Cisco卖的东西能不能符合需求。在这数据爆炸的年代，向前问说的，这个在现有的数据中心里面是不够用的。Google对网络的需求是PB级别的，那么这个时候就不是买上千个Cisco的swtich这么简单的事情了。当然，这个对于Cisco来说也不是最核心的生意，因为世界上像Google一样需要这么大的客户不多，思科现有的解决方案对于大部分公司来说还是相当好的。所以其实Google开心，Cisco也无所谓，因为两个没有直接的竞争关系。

总体来说想要用CPU换内存或者拿内存换CPU来加速软件都是比较困难的决定。而且现在很多时候大家在意的不是一个机子要花费多少钱，而是这个数据中心电力供应能支撑多少机器，所以基本上在拿多少电力能换多少计算在未来几年是不会有什么特别的惊喜了。但是网络层就不一样了，数据中心内的网络的增长的速度过去这几年是爆发性的。而且最重要的是说网络层面的加速目前还是物理性的，如果真的需要加更快的速度可以通过连接更多的线，这些线未必会消耗多少电力，但是在数据中心其他维度的增长收到限制的时候，我们更多要思考的是这个网络速度上面的爆发能够给我们带来什么，这就是为什么我们要关心数据中心网络方面的发展。当年网络层面的紧张造就了MapReduce，现在网络和内存层面的富余造就了Dremel／Presto以及各类stream processing的解决方案，这个都是不同时代的产物，而网络就是划分这个时代的最重要的因素之一。之后在内存不涨，CPU不涨，储存不涨而网络层面继续增长的时代，我很期待还会有什么怪物系统出现，打烂我的三观。

最后再提一句，原文在这里 https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/43837.pdf ，有错误求留言轻喷～

相关标签：