解析Google数据中心架构设计.docx

解析Google数据中心架构设计.docx

《解析Google数据中心架构设计.docx》由会员分享，可在线阅读，更多相关《解析Google数据中心架构设计.docx（17页珍藏版）》请在冰豆网上搜索。

解析Google数据中心架构设计

解析Google数据中心架构设计

ExperiencewithaGlobally-DeployedSoftwareDefinedWAN

导读：

Google首次将其数据中心广域网（WAN）的设计和三年部署经验完整地公之于众。

为什么Google要用SoftwareDefinedNetworking（SDN）？

如何把SDN渐进地部署到现有的数据中心？

透过论文，我们能窥见Google全球数据中心网络的冰山一角。

1.流量的巨大浪费

众所周知，网络流量总有高峰和低谷，高峰流量可达平均流量的2~3倍。

为了保证高峰期的带宽需求，只好预先购买大量的带宽和价格高昂的高端路由设备，而平均用量只有30%~40%。

这大大提高了数据中心的成本。

这种浪费是必然的吗？

Google观察到，数据中心中的流量是有不同优先级的：

∙用户数据拷贝 到远程数据中心，以保证数据可用性和持久性。

这个数据量最小，对延迟最敏感，优先级最高。

∙远程存储访问 进行MapReduce之类的分布式计算。

∙大规模数据同步 以同步多个数据中心之间的状态。

这个流量最大，对延迟不敏感，优先级最低。

Google发现高优先级流量仅占总流量的10%~15%。

只要能区分出高优先级和低优先级流量，保证高优先级流量以低延迟到达，让低优先级流量把空余流量挤满，数据中心的广域网连接（WANlink）就能达到接近100%的利用率。

要做到这个，需要几方面的配合：

∙应用（Application）需要提前预估所需要的带宽。

由于数据中心是Google自家的，各种服务所需的带宽都可以预估出来。

∙低优先级应用需要容忍高延迟和丢包，并根据可用带宽自适应发送速度。

∙需要一个中心控制系统来分配带宽。

这是本文讨论的重点。

2.WhySDN?

计算机网络刚兴起时，都是插一根线连到交换机上，手工配置路由规则。

在学校机房之类网络不复杂的情况下，时至如今也是这么做的。

但是，只要增加一个新设备，就得钻进机房折腾半天；如果一个旧设备坏了，就会出现大面积的网络瘫痪。

广域网络的维护者们很快就不能忍受了，于是就诞生了分布式、自组织的路由协议BGP、ISIS、OSPF等。

为什么设计成这样呢？

有两方面原因。

首先，七八十年代广域网络刚刚兴起时，网络交换设备很不稳定，三天两头挂掉，如果是个中心服务器分配资源，那么整个网络就会三天两头瘫痪。

其次，Internet是多家参与的，是Stanford愿意听MIT指挥，还是MIT愿意听Stanford指挥？

今天，在数据中心里，这两个问题都不复存在。

首先，现在的网络交换设备和服务器足够稳定，而且有Paxos等成熟的分布式一致性协议可以保证“中心服务器”几乎不会挂掉。

其次，数据中心的规模足够大，一个大型数据中心可以有5000台交换机（switch），20万台服务器，与七八十年代整个Internet的规模已经相当了。

数据中心是公司自家的，想怎么搞就怎么搞。

因此，SoftwareDefinedNetworking（SDN）应运而生。

以OpenFlow为代表，SDN把分散自主的路由控制集中起来，路由器按照controller指定的规则对packet进行匹配，并执行相应动作。

这样，controller就可以利用整个网络的拓扑信息和来自application的需求信息计算出一组接近全局最优的路由规则。

这种CentralizedTrafficEngineering（TE）有几个好处：

∙使用非最短路的包转发机制，将应用的优先级纳入资源分配的考虑中；

∙当连接或交换机出现故障，或者应用的需求发生变化时，动态地重新分配带宽，快速收敛；

∙在较高的层次上指定规则，例如（我随便编的）Gmail的流量不经过天朝。

3.Design

3.1.Overview

∙交换机硬件是Google定制的，负责转发流量，不运行复杂的控制软件。

∙OpenFlowController（OFC）根据网络控制应用的指令和交换机事件，维护网络状态。

∙CentralTEServer是整个网络逻辑上的中心控制器。

∙第一条虚线上面是Central TE （TrafficEngineering）Server。

∙一二两条虚线之间是每个数据中心（Site）的控制器，被称为NetworkControlServer（NCS），其上运行着OpenFlowController（OFC）集群，使用Paxos协议选出一个master，其他都是热备（hotstandby）。

∙二三两条虚线之间是交换机（switch），运行着OpenFlowAgent（OFA），接受OFC的指令并将TE规则写到硬件flow-table里。

（这幅图里的细节读完本文就明白了）

3.2.SwitchDesign

Google定制的128口交换机由24个16口10Gbps通用交换机芯片制成。

（在本文中，“交换机”和“路由器”是通用的。

需要说明工作在MAC层还是IP层时，会加定语layer-2或layer-3）拓扑结构见下图。

蓝色的芯片是对外插线的，绿色的芯片充当背板（backplane）。

如果发往蓝色芯片的packet目标MAC地址在同一块蓝色芯片上，就“内部解决”；如果不是，则发往背板，绿色芯片发到目标地址所对应的蓝色芯片。

交换机上运行着用户态进程OFA（OpenFlowAgent），连接到远程的OFC（OpenFlowController），接受OpenFlow命令，转发合适的packet和连接状态到OFC。

例如，BGP协议的packet会被转发到OFC上，在OFC上运行BGP协议栈。

3.3.Routing

∙RIB:

RoutingInformationBase，路由所需要的网络拓扑、路由规则等

∙Quagga:

Google采用的开源BGP/ISIS协议实现

∙RAP:

RoutingApplicationProxy，负责OFA与OFC之间的互联

如上图所示，Quagga路由协议栈中的RIB保存着路由规则，如发往某个子网的包要从某两个端口选一个出去。

数据中心网络中一个packet一般会有多条路线可走，一方面提高冗余度，一方面充分利用带宽，常用的协议是EqualCostMultiplePath（ECMP），即如果有多条最短路，就从其中随机选一条走。

在OFC中，RIB被分解为Flows和Groups。

要理解这个拆分的必要性，先要理解网络交换设备是怎样工作的。

现代网络交换设备的核心是match-actiontable。

Match部分就是ContentAddressableMemory（CAM），所有条目可以并行地匹配，匹配结果经过Mux选出优先级最高的一条；Action则是对数据包进行的动作，比如修改包头、减少TTL、送到哪个端口、丢弃数据包。

对路由规则来说，仅支持精确匹配的CAM是不够的，需要更高级的TCAM，匹配规则支持bit-mask，也就是被mask的位不论是0还是1都算匹配。

例如需要匹配192.168.0.0/24，前24位精确匹配，最后8位设为掩码即可。

在OFC中，Flows对应着Match部分，匹配得出Action规则编号；Groups对应着Action部分，采用交换机中现有的ECMPHash支持，随机选择一个出口。

4.TE算法

4.1.优化目标

系统管理员首先决定每个应用在每对数据中心之间所需的带宽和优先级，这就形成了一系列 {Sourcesite,Destsite,Priority,Requiredbandwidth} 四元组（此处为了便于理解，对原论文进行了修改）。

将这些四元组按照 {Sourcesite,Destsite,Priority} 分组，把所需带宽加起来，就形成了一系列 FlowGroup（FG）。

每个FG由四元组 {Sourcesite,Destsite,Priority,Bandwidth} 表征。

TEOptimization的目标是 max-minfairness，就是在公平的前提下满足尽可能多的需求。

由于未必可以满足所有需求，就要给“尽可能多”和“公平”下个定义。

我们认为，客户的满意度是跟提供的带宽成正比的，也是跟优先级成反比的（优先级越高，就越不容易被满足）；如果已经提供了所有要求的带宽，则满意度不再提高。

在此假设基础上，引入 fairshare 的概念，两个FlowGroup如果fairshare相同，就认为这两个客户的满意度相同，是公平的。

例子：

App1需要15G带宽，优先级为10；App2需要5G带宽，优先级为1；App3带宽多多益善（无上限），优先级为0.5。

TEOptimization算法分下面三步：

∙TunnelSelection:

选择每个FG可能走的几条路线（tunnel）

∙TunnelGroupGeneration:

给FG分配带宽

∙TunnelGroupQuantization:

将带宽离散化到硬件可以实现的粒度

4.2.选路

TunnelSelection：

利用Yen算法[2]，选出 k 条最短路，k 是一个常量。

例如下面的网络拓扑，取 k =3：

FG[1]:

A→B

∙T[1][1]=A→B

∙T[1][2]=A→C→B

∙T[1][3]=A→D→C→B

FG[2]:

A→C

∙T[2][1]=A→C

∙T[2][2]=A→B→C

∙T[2][3]=A→D→C

在此为爱钻牛角尖的童鞋送上算法描述：

#dist:

adjacentmatrixofnodedistances

#S:

sourcenode

#T:

targetnode

#K:

pathnum

#return:

amatrix,eachrowisapath

defK_shortest_paths（dist,S,T,K）:

A=[]

A[0]=shortest_path（S,T）

forkinrange（1,K）:

distcopy=copy（dist）

foriinrange（0,len（A[0]））:

nodeA=A[k-1][i]

forjinrange（0,k-1）:

nodeB=A[j][i]

if（nodeA==nodeB）:

distcopy[nodeA][nodeB]=inf

candidate[i]=A[0:

i]+shortest_path（distcopy,nodeA,T）

A[k]=thepathwithminimumlengthforallcandidate[i]

returnA

#standardalgorithmtofindshortestpath

#return:

alist,shortestpathfromStoT

defshortest_path（dist,S,T）:

pass

4.3.分配流量

TunnelGroupGeneration:

根据流量需求和优先级分配流量。

（论文中没有算法描述，我自己整理了一下。

由于有些名词用中文写出来很别扭，就用英文了）

∙InitializeeachFGwiththeirmostpreferredtunnels.

∙Allocatebandwidthbygivingequalfairsharetoeachpreferredtunnel.

∙Freezetunnelscontaininganybottleneckedlink.

∙Ifeverytunnelisfrozen,oreveryFGisfullysatisfied,finish.

∙Selectthemostpreferrednon-frozentunnelforeachnon-satisfiedFG,goto2.

继续上面的例子：

4.4.流量离散化

TunnelGroupQuantization:

由于硬件支持的流量控制不能无限精细，需要对上一步计算出的流量进行离散化。

求最优解是个整数规划问题，很难快速求解。

因此论文使用了贪心算法。

∙Downquantize（round）eachsplit.

∙Addaremainingquantatoanon-frozentunnelthatmakesthesolutionmax-minfair（withminimumfairshare）.

∙Iftherearestillremainingquantas,goto2.

继续上面的例子：

4.5.离散化会降低性能吗

上图展示了离散化对性能的影响，这里的ThroughputDelta是相对优化之前而言的，越大越好。

可以看到，当流量分配粒度达到1/16后，再提高精细程度，就没有太多作用了。

在Google最终的实现中，tunnel个数（前面的 k）设置为4，分配粒度为1/4。

至于为什么这么设置，youaskme,Iaskwho。

5.TE实现

5.1.Tunneling

∙EncapSwitch是连接终端机器的边界路由器，它们将IPpacket封装起来，包上路由专用的sourceip和destinationip。

∙TransitSwitch是中间传输路由器，它们只接受经过EncapSwitch封装的IPpacket，并在数据中心之间进行路由。

∙DecapSwitch是连接终端机器的边界路由器，其实跟EncapSwitch是同一批机器。

它们将被封装的IPpacket剥掉一层皮，送给终端机器。

5.2.TEasOverlay

SDN“一步到位”的做法是设计一种统一的、集中式的服务，囊括路由和TrafficEngineering。

但这样的协议研发过程会很长。

另外，万一出问题了，大家就都上不了Google了。

在这个问题上，Google又发扬了“小步快走”的敏捷开发思想，把TE和传统路由两个系统并行运行，TE的优先级高于传统路由，这样SDN就可以逐步部署到各个数据中心，让越来越多的流量从传统路由转移到TE系统。

同时，如果TE系统出现问题，随时可以关闭TE，回到传统路由。

上图是GoogleSDN所承载的流量变化曲线。

每个交换机都有两张路由表，LPM（LongestPrefixMatch）Table由基于最短路径的传统路由协议（BGP/ISIS）维护。

ACLTable是TE使用的路由表，优先级高于LPM，也就是LPM和ACL都匹配出条目时，ACL说的算。

上图的例子是EncapSwitch。

匹配结果是一个MultipathTableIndex和可选条数，也就是从Index开始的这么多条规则中根据Hash值选出一条规则。

这条规则写明了出口（port）和路径（tunnel），再从路径表（EncapTunnelTable）里查到要被封装到IPpacket头部的sourceIP和destIP。

对于TransitSwitch，就不需要路径表了。

5.3.操作依赖

一次TE变更可能涉及多个交换机的插入/删除规则操作，而这些操作不能以任意的顺序进行，否则就有可能出现丢包。

因此有了两条规则：

∙在修改TunnelGroup和FlowGroup之前，先在所有受影响的数据中心建立好tunnel

∙在所有引用某tunnel的条目被删除之前，不能删除这个tunnel

为了在有网络延迟和数据包乱序（reordering）的情况下保证依赖关系，中心TE服务器为每个事务（session）中的有序操作分配递增的序列号。

OpenFlowController维护当前最大的session序列号，拒绝任何比它小的session序列号。

TE服务器如果被OFC拒绝，将在超时后重试这个操作。

6.部署效果

6.1.统计

∙每分钟13次拓扑变化

∙去除维护造成的更新，每分钟0.2次拓扑变化

∙拓扑中的边添加/删除事件，一天7次（TE算法运行在拓扑聚合后的视图上。

两个数据中心之间可能有上百条link，把它们聚合成一条容量巨大的link。

）

这方面的经验是：

∙拓扑聚合明显降低了路径颠簸和系统负载

∙即使有拓扑聚合，每天也会发生好几次边的删除

∙WANlink对端口颠簸（反复变化）很敏感，用中心化的动态管理收效较好

6.2.错误恢复

在数据中心，设备、线路损坏是常有的事，因此错误的影响范围和恢复速度很重要。

由上表可见，单条线路损坏只会中断连接4毫秒，因为受影响的两台交换机会立即更新ECMP表；一个EncapSwitch损坏会使周边的交换机都更新ECMP表，比单条线路损坏多耗时一些。

但临近EncapSwitch的TransitSwitch挂掉就不好玩了，因为EncapSwitch里有个封装路径表（EncapTunnelTable），这个表是中心维护的，出现故障后邻近的EncapSwitch要汇报给OFC，OFC汇报给全球中心的TEServer（高延迟啊），TEServer再按照操作依赖的顺序，逐个通知受影响的EncapSwitch修改路径。

由于这种操作很慢，需要100ms，整个恢复事务需要3300ms才能完成。

OFC、TEServer的故障都没有影响，首先因为它们使用了Paxos分布式一致性协议，其次即使全都挂掉了，也只是不能修改网络拓扑结构，不会影响已有的网络通信。

由于前面提到的TEasOverlay，关闭TE时，整个网络会回到基于最短路径的传统路由协议，因此也不会造成网络中断。

6.3.优化效果

（a）是平均带宽使用率，可以看到带宽使用率平均可达95%。

（b）是丢包率，其中占10%~15%比例（红线）的高优先级packet几乎没有丢包（蓝色），而低优先级packet有较多的丢包（绿色）。

如果低优先级应用使用通常的TCP协议，在这么高的丢包率下很难高效工作。

因此传输层协议也是要特殊设计的，不过论文并未透露。

6.4.一次事故

Google的SDN系统曾经出现一次重大事故。

过程是这样的：

∙一个新加入的交换机被不小心配置成了跟原有交换机一样的ID。

∙两个ID相同的交换机分别发送ISISLinkStatePacket，收到的其他交换机感觉很奇怪，怎么这两份拓扑完全不一样呢？

这两个ID相同的交换机都坚持自己的观察是正确的，导致网络中出现洪泛。

∙TE控制信令要从OFC发给OFA，被网络阻塞了，造成了长达400MB的等待队列。

∙ISISHellomessage（心跳包）也因为长队列而阻塞了，交换机们都认为周围的交换机挂掉了。

不过TE流量仍然正常运行，因为它的优先级高于传统路由。

∙此时，由于网络拥塞，TEServer无法建立新的tunnel。

雪上加霜的是，TE依赖机制要求序列号较小的操作成功后才能进行下一个操作（见上文），建立新tunnel更是不可能了。

因此，任何网络拓扑变化或设备故障都会导致受影响的网络仍在使用已经不能用的tunnel。

前面有统计数字，每分钟都会发生拓扑变化，因此这个问题是很严重的。

∙系统运维人员当时并不知道问题的根源，于是就重启了OFC。

不幸的是，这一重启，触发了OFC中未发现的一个bug，在低优先级流量很大时不能自启动。

文中说，这次故障有几个经验/教训：

∙OFC与OFA之间通信的可扩展性和可靠性很重要。

∙OFA的硬件编程操作应该是异步并行的。

∙应该加入更多系统监控措施，以发现故障前期的警告。

∙当TE连接中断时，不会修改现有的路由表。

这是一种fail-safe的措施，保证这次故障中已经建立的tunnel没有被破坏。

∙TEServer需要处理OFC无响应的情况。

如果有的OFC挂掉了，与其禁止所有新建tunnel的操作，不如先让其中一部分运转起来。

7.结语

比起SIGCOMM2013中其他数据中心方面的论文，本论文是唯一一篇经过广泛实践检验的。

尽管文中的算法和思想都很朴素，但充分体现了工程领域中不得不做的tradeoff。

不得不说，Google还是数据中心方面的老大，不鸣则已，一鸣惊人啊