目录
1. 主要内容
2015年，Google在SIGCOMM会议上发表论文《Jupiter Rising: A Decade of Clos Topologies and Centralized Control in Google’s Datacenter Network》，比较详细的阐述了Google在过去十多年中数据中心网络的创新和演进。
本文主要基于该论文对Google数据中心网络技术的发展进行分析和总结，同时给出个人理解和看法。Google的论文的主要思想如下：论文提出了Google为了克服高昂的成本、操作的复杂性、有限的规模可扩展性问题，而实施的解决方案；阐述了Google十年间逐渐发展的五代数据中心网络。主要包含三个方面的主题。
第一，利用多级互连的Clos拓扑网络技术，使得Google可以通过商业交换芯片来搭建大规模的交换网络系统。第二，传统网络中大量通用的，分布式的，非常复杂的网络路由和管理协议虽然可以支持任意的部署方式，但是这对于需要单一操作平面的数据中心网络却矫枉过正了。Google建立了中心化控制的，支持全局配置的数据中心网络。第三，模块化的硬件设计加上简单的、高可靠性的软件使得Google可以设计出同时支持数据中心内部集群间路由和外部广域网路由的系统。
Google的第五代数据中心网络Jupiter已经在全球几十个站点运行部署，网络带宽已经达到1Pbps，这比十年前提高了十多倍。Jupiter足够10万台服务器每台之间以10Gb/s交换信息，可以在十分之一秒之内读取所有美国国会图书馆的扫描数据。
2. Google创新网络技术的动机
从宏观上来说，引用[3]下面这段阐述：众所周知，计算、存储、网络是构成数据中心的三大要素。而在此前的技术进展中，计算和存储已经遭遇瓶颈，主要体现在：计算方面，随着半导体技术面临的物理障碍不可逾越，摩尔定律失效的时限日益临近，因此单个计算节点的性能提升有限，从而必须依赖于分布式计算技术，而分布式集群中节点间的网络将成为影响集群工作效率的关键；存储方面，支持管理机制和存储空间分离的分布式存储技术已经解决了存储容量的问题，但是存储I/O仍是瓶颈（高性能的Flash当前仍旧停留在缓存的范畴），因此存储性能的改进也非常依赖于网络能力的增强。因此，网络已经成为了提升大规模数据中心运行性能的关键点，是维持数据中心资源效率平衡的关键。
另外，就Google的实际发展来说，在2004年，谷歌应该早已认识到对于数据中心网络的创新是势在必行的。我觉得主要的一个原因就是网络设备成本太高；尤其是在数据中心流量不断爆炸的年代，传统网络设备的成本已经成为难以承受之轻，这导致谷歌不得不想办法革了传统网络的命。下面会具体的来分析一下。
2.1 传统的Google 数据中心内部网络架构
Google 的网络分为数据中心内部网络（IDC Network）及骨干网（Backbone Network，也可以称为WAN网）。其中WAN网按照流量方向由两张骨干网构成，分别为：第一，数据中心之间互联的网络（Inter-DC WAN，即G-scale Network），用来连接Google位于世界各地之间的数据中心，属于内部网络；第二，面向Internet用户访问的网络（Internet- facing WAN，即I-Scale Network）。
在2004年，Google数据中心内部网络的结构如图下所示。可以看到网络系统主要有两层，图的上半部分是由4个巨大的集群路由器Cluster Router1-Cluster Router4组成的骨干层；每个集群路由器之间通过2x10G的链路连接成一个环。此外，每个集群交换机还有512个1G的口，分别与网络中的512个高性能机架式交换机ToR（Top of Rack）相连，如图的下半部分。每个高性能机架式交换机ToR通过40x1G的端口连接40台服务器。由此，也可以很容易的计算出网络的总带宽为512x4=2T。
这时的谷歌数据中心网络中用的全是传统设备厂商的交换设备。据说当时谷歌的采购每次去Cisco或者Juniper家买设备的时候都是直接说：把你们家最好的设备拿给我，只要最好的！而这种最好的交换设备，一台就需要几百万甚至上千万美元。而就图1这个网络中就需要多个这样的设备，可以想象数据中心的成本是非常惊人的。
2.2 传统DCN网络成本感人
我们再来数据中心网络对流量的需求增长。由于数据中心网络对于web服务器、存储系统的实现至关重要，也是实现云计算的关键因素。数据中心网络的带宽需求逐年上升，基本上每12-15个月就会增加一倍。Google的带宽需求如图2所示。在2008年到2014年的短短6年间，谷歌的数据中心网络流量就增加了50多倍。
按照上面的分析，2004年，通过购买传统厂商的设备建设2T带宽的网络就已经需要惊人的开支，那如果要满足实际需求中带宽几十倍的增长，必然是要花费天文数字的美刀啊（每年至少得好几十亿美元啊）。所以说，谷歌显然是想尽可能摆脱传统网络设备厂商这个深坑的。
除了网络设备方面的成本高，分布式的，以盒子为中心的传统网络的管理成本也非常高。这一点是也是让全世界的网络管理的工程师们都非常抓狂的事情。
2.3 DCN网络创新的契机
上一小节从成本角度分析了谷歌进行数据中心网络创新的充足动机，这是内部原因。另一方面，由于技术的不断发展，新的技术也给谷歌创新自己数据中心网络的提供了可能。主要来说得益于有以下三方面的技术。
第一， Clos网络技术。利用多级互连的Clos拓扑网络技术，使得Google可以通过低端口数量的商业交换芯片，来搭建支持大规模的交换网络系统。这种拓扑结构也使得网络既有很好扩展性。
第二， 商业交换芯片，谷歌使用通用目的交换芯片来构建转发设备。传统的交换芯片是装在盒子里，功能丰富但是容量小，而且价格昂贵。而通用的交换芯片不仅成本更低，而且方便扩展，还可以随着芯片技术的进步而不断升级，灵活的满足逐年增长的带宽需求。
第三， 中心化的控制和管理。得益于数据中心网络具有单一管理域的特点，因为数据中心网络的拓扑结构是相对稳定的，管理上可以根据交换机的位置设置相应的转发角色。这就使得中心化的控制与管理变得非常方便。
由此，Google利用强大的软件开发能力，基于Clos网络拓扑和商用交换芯片成功研发了满足自家高带宽需求的网络转发设备，从开始的10T带宽达到1.3P的总带宽，再加上自己设计的统一控制层面，彻底了数据中心网络对传统设备厂商的一代。
3. Google数据中心网络技术
如下表所示，在2005年以前，Google还是需要依赖设备厂商提供的产品建设其数据中心网络。但是随着厂商设备不能满足Google数据中心高速发展的需求，Google在2005年开始自主研发，迄今已经演进了五代。
2005年，Google设计了第一代数据中心网络，名为Firehose 1.0，总带宽达到10T。作为原型系统，主要用来验证实现的可行性，没有实际部署到真实网络中去，但是也为Google积累了大量的经验。2006年，对第一代系统改进后，第二代Fierhose 1.1推出并真正部署在了Google数据中心的网络中，采用与传统的厂商设备网络混合的方式运行。
直到2008年，第三代Watchtower出现，利用更先进的16x10G的交换芯片，总的带宽达到82T，并逐步全面替代厂商设备。在第四代Saturn中，更强的交换下芯片使得总带宽达到207T，网络中计算节点接入首次达到10G级别，网络内部传统厂商设备至此已经被完全取代。2012年，Google第五代数据中心网络Jupiter，也是Google最新的一代的数据中心网络，引入了SDN技术并且使用了OpenFlow，网络带宽高达1.3P，这已经大大满足了Google高深增长的带宽需求
3.1 第一代Firehose1.0
从网上的资料看到，从2004年开始Google内部成立了一个小组开始研究自己的网络设备解决方案。这个方案简而言之就是用普通的民用级芯片搭建通用的硬件，然后在上面跑任何需要运行的软件。思科为不同级别的需求提供不同的硬件，并每套硬件上面都运行特定的相匹配的软件。而Google的解决方案则简单粗暴的多，所有的硬件都是相同的，面对不同的需求时解决方案的差别仅在于一起协作的硬件的数量，一个“高性能架顶式”交换机就相当于一个“集群交换机”上的一块板，性能的提升几乎等同于数量的叠加，而这些相同的硬件都可以运行任何需要运行的软件。
2015年Google推出第一代网络架构Firehose1.0（FH1.0）。FH1.0的设计目标是给10K台服务器分别提供1Gpbs的无阻塞交换带宽。网络拓扑如图3所示。网络一共分为五层。第一层是高性能架顶式交换机（Top-of-Rack，ToR），ToR交换机的上方是2×10G，下方是24×1G。第二、三、四层交换机上方和下方均是4×10G接口。第五层交换机只有下方有8×10G接口。交换机板是插在服务器上的。
第二层和第三层构的各8台交换机构成一个聚集块（Aggregation Block），每个聚集块接入16个ToR。由于每个ToR下方连接20台服务器，因此一个聚集块可以连接320台服务器。
第四层的8台交换机和第五层的4台交换机构成一个骨干块（Spine Block）。每个骨干块有32×10G个接口，分别连接到32个汇聚块的32个上方端口。这样就构成了整个FH1.0的拓扑。因此系统的带宽可以达到32×4×8×10G=10T的带宽。
该网络的缺点就是ToR交换机的基数比较低，这就会导致在链路失效时出现难以解决的问题。虽然没正式投入使用，但是这给Google后续发展提供了丰富的经验。
3.2 第二代Firehose1.1
2006年，Google实现了第二代的数据中心网络架构Fierhose 1.1。Fierhose 1.1是真正部署在了Google数据中心的网络中的Clos拓扑网络，如图4所示。
这是在第一代的基础上主要改进了高性能架顶式ToR交换机。没有把交换板挂在主机上，二是使用了定制化的兼容PCI插槽接口的硬件来实现。骨干块（Spine Block）和FH1.0是完全相同的，聚集块和ToR交换机有所改变，如图4所示。使用两个4x10G+24x1G交换芯片东西方向通过2x10G互连。总带宽依然是10T。
部署FH1.1的主要问题担忧就在于该网络是一个全新的，从未被实际检验过的网络。因此，为了稳妥起见，Firehose 1.1还是采用了与传统的厂商设备网络并肩运行的方式，如图5所示。
3.3 第三代Watchtower
FH1.1的实际部署取得的非常积极的效果，这证明了数据中心网络的服务可以通过这种全新的拓扑连接方式享受更高的带宽，同时单位带宽的成本也比传统网络低。FH1.1唯一的缺点就是部署的时候需要额外的铜质光缆。
利用前面两次的经验，Google在2008年设计推出了第三代架构Watchtower。这一代最关键的一点就是利用当时最新一代的16x10G商业交换晶片来构建交换机。
如图6所示，左上方是一个128x10G端口的Watchover底盘，内部通过8个线卡连接成无阻塞的拓扑结构（左下方所示）。四个底盘放在两个支架上，通过光纤与其他部分相连。系统最高可以达到82T的带宽。
为了降低部署的复杂度，Google把光纤捆绑成束，如图7所示。通过捆绑光纤，系统获得多方面的好处，列举如下表所示。
3.4 第四代Saturn
第四代的网络的设计目标依然是继续增加带宽和扩大规模。因此这一代中交换机使用了更加先进的24x10G交换芯片到高性能机架式ToR交换机中。如图8所示。
Saturn的底盘支持12个线卡，可以提供288个端口的无阻塞交换能力。这次接入服务器需要的带宽可以配置为2Gbps或者5Gbps。同时，也是第一次通过光纤使得服务器最大可以达到10Gbps的带宽。而系统的总带宽也提高到207T。
3.5 第五代Jupiter
Jupiter是Google最新一代的数据中心网络，它引入了SDN技术并且使用了OpenFlow，其支持的网络带宽已经达到Pbps量级，满足了大规模数据中心对网络带宽的需求。Pbps的网络速度意味着网络能够在十分之一秒内就完成美国国会图书馆藏书所有扫描内容的数据传输，达到这一量级的Google数据中心网络则可以同时支持100000台计算节点以10Gbps的网络速度通信，这个规模是非常惊人的。
Jupiter的结构如图9所示，并且首次使用了16x40G的交换芯片。骨干块分为两层，上层包含四组，每组向下提供32x40G的连接。下层包含8组，同时向上层和下层提供128x40G的接口。因此一个骨干块可以提供128x40G的带宽。
汇聚块由8个Middle Block(MB)构成，MB的实际大小如图10所示每个汇聚块向上通过256x40G的接口与骨干块相连。整个网络带宽达到了1.28Pbps。
与第一代相比，Google的第五代数据中心网络带宽已经扩展了100余倍。正如前面提到的，在从2008年7月到2014年11月的短短几年间，Google数据中心内部的服务器产生的汇聚层流量已经增长近50倍。因此，不难看出，正是Google业务的蓬勃发展驱动了其数据中心网络技术的持续演进。
4. 数据中心网络之间互连
4.1 彻底取代集群路由器CRs
在Watchtower刚开始部署的时候，使用的是图5所示的Bag-on-the-side的部署方式。可以发现网络中传统的Cluster Routers（CRs）和新的clos网络（如WatchTower）是共存的，这种渐进的部署方式设计之初是为了稳妥和安全。但是经过前三代的网络部署经验和技术积累，新的clos网络被时间证明是非常可靠的。另一方面，CRs的带宽非常有限，许多应用都需要爆发的带宽，如迁移数据服务、在cluster之间拷贝大规模的搜索索引数据等。然而CRs的性能大大限制了ToR之间需要通过CRs的流量带宽。
因此Google这时候开始考虑去除CRs，取而代之的是通过集群边界路由器（Cluster Border Routers ，CBRs)直接与外部集群网络互连。Google内部把这项计划叫做WCC。与外部互连的方式可以有4种选项，如下图11所示。第一种的连接与FH1.1很像，但是前两种都无法提供爆发的带宽。Google最终选择了第四种，因为这样与外部连接的交换机在一个独立的块上，便于管理。
在边界路由器上，Google运行标准的eBGP协议实现与外部集群网络之间的路由。通过WCC改造行动，Google自行设计的网络彻底的取代传统的网络。在这个意义上，Google自主实现了集群之间高吞吐量的数据传输，摆脱了对高性能网络设备厂商的依赖。
4.2 集群网络之间的互连
Google在同一栋楼中部署了多个集群，并且一个园区存在多个这样的大楼。WCC改造的集群边界路由器给集群之间的互连提供了大量的带宽。在Watchtower中，每个聚集块支持2.56Tbps的对外带宽，在Saturn中这一带宽更是达到了5.76Tbps。
然而这时候外部网络中的设备还是基于昂贵的、端口有限的厂商设备。所以下一步的计划就是取代这些集群之间的的交换设备。Google的目标就是通过比现在更低成本的方式，最大化同一楼中，同一个园区内的集群之间传输带宽。如图12所示展示了在集群之间和园区内部这两个层次均实现BGP路由的互连结构。图的上半部分Freedome Block（FDB）是Google配置的一些路由器集合。
一栋大楼内部数据中心的Freedome通常包含四个独立的FDB块，用于连接同一个数据中心大楼的多个集群。也就是说，同一个大楼里不同集群之间的流量通常是这样的：首先从源集群的CBR层到数据中心的Freedome，一般到达FER层，最后到达目的集群的CBR。图7左下方就描述了一栋大楼内部的数据中心的Freedom的结构，并且给一栋大楼内部的带宽是去往同意园区内其他大楼带宽的8倍。
类似的，同一个园区内部的Freedome同样由四个独立的FDB块构成，其南向的端口用于连接园区内多个的多个大楼内部数据中心的Fredome，北向的端口用于连接互联网。整个结构如图7右下方所示。
5. 网络的中心化控制
在网络的控制平面，Google没有使用传统网络的解决方案，仍然采用了自主研发的道路。主要有四个原因。首先最重要的原因是，当时存在的传统路由协议，几乎不支持同等开销下的多路径转发。第二点，当时没有高质量的开源路由协议栈。为了打通交换机线卡到处理进程之间的数据包处理通道，Google当时做了大量的工作来修改硬件交换机的协议栈。第三，Google担心基于广播的路由协议在拥有数千台交换机的大规模网络中会存在性能和管理上的天花板。比如OSPF Areas就非常难以配置与排错。第四，网络的可管理性是一个关键的因素。
由于数据中心网络中的路由都是基于具有多路径的静态拓扑，Google给每个交换机都会根据其位置预先设置一个角色。不同的交换机角色对应的预配置。整个网络有一个中心化的路由控制器，用于动态的搜集网络中的链路状态信息，然后通过可靠的控制平面网络Control Plane Network (CPN)分发给所有的交换机。路由控制器被设计得充分的的简单与高效。
交换机根据路由控制器发来的的链路状态信息计算路由表，从而实现路由功能。Google把网络中的这种三层路由协议叫做Firepath。图13展示了整Firepath组件之间的相互关系，图14说明了Firepath协议的消息类型。更多路由实现、管理和配置细节可以看原文论文的讲述，在此就不一一描述了。
总的来说，Google把整个数据中心网络当做一个具有成千上万个端口的单一结构，而不是看做由数百个独立的交换机个体组成的集合，从而在逻辑上避免了动态发现多个交换机的过程。另外，受到分布式文件系统GFS的启发，Google一如既往牛掰的给Jupiter和GoogleB4广域网设计了一个统一的控制架构。
6. 小结
在这个流量不断爆发的年代，数据中心对于带宽的需求增长迅速，而传统厂商封闭而又昂贵的网络设备必然会逐渐被更加通用、更便宜的设备所代替。Google在这方面走在了前列，展现出来了非常领先的网络技术，这也给带宽不断爆发的数据中心网络、运行商、ISP树立了榜样。而更加通用的硅交换芯片、转发设备也会有更大的市场，软件定义网络是数据中心网络不可阻挡的趋势。
相关资料
[1] 论文原文http://conferences.sigcomm.org/sigcomm/2015/pdf/papers/p183.pdf
[2] Open Network Summit 2015 Presentation - Amin Vahdat: A look inside Google’s Data Center Networks
[3] http://www.sdnlab.com/12700.html