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

PAGE 2 解析Google数据中心架构设计 Experience with a Globally-Deployed Software Defined WAN  目 录 TOC \o 1-3 \h \z \u 1. 流量的巨大浪费 3 2. Why SDN? 4 3. Design 5 3.1. Overview 5 3.2. Switch Design 6 3.3. Routing 7 4. TE 算法 9 4.1. 优化目标 9 4.2. 选路 10 4.3. 分配流量 12 4.4. 流量离散化 12 4.5. 离散化会降低性能吗 13 5. TE 实现 14 5.1. Tunneling 14 5.2. TE as Overlay 15 5.3. 操作依赖 17 6. 部署效果 18 6.1. 统计 18 6.2. 错误恢复 18 6.3. 优化效果 19 6.4. 一次事故 20 7. 结语 22  导读：Google 首次将其数据中心广域网 (WAN) 的设计和三年部署经验完整地公之于众。为什么 Google 要用 Software Defined Networking (SDN)？如何把 SDN 渐进地部署到现有的数据中心？透过论文，我们能窥见 Google 全球数据中心网络的冰山一角。 流量的巨大浪费 众所周知，网络流量总有高峰和低谷，高峰流量可达平均流量的 2~3 倍。为了保证高峰期的带宽需求，只好预先购买大量的带宽和价格高昂的高端路由设备，而平均用量只有 30%~40%。这大大提高了数据中心的成本。 这种浪费是必然的吗？Google 观察到，数据中心中的流量是有不同优先级的： 用户数据拷贝?到远程数据中心，以保证数据可用性和持久性。这个数据量最小，对延迟最敏感，优先级最高。 远程存储访问?进行 MapReduce 之类的分布式计算。 大规模数据同步?以同步多个数据中心之间的状态。这个流量最大，对延迟不敏感，优先级最低。 Google 发现高优先级流量仅占总流量的 10%~15%。只要能区分出高优先级和低优先级流量，保证高优先级流量以低延迟到达，让低优先级流量把空余流量挤满，数据中心的广域网连接（WAN link）就能达到接近 100% 的利用率。要做到这个，需要几方面的配合： 应用（Application）需要提前预估所需要的带宽。由于数据中心是 Google 自家的，各种服务所需的带宽都可以预估出来。 低优先级应用需要容忍高延迟和丢包，并根据可用带宽自适应发送速度。 需要一个中心控制系统来分配带宽。这是本文讨论的重点。 Why SDN? 计算机网络刚兴起时，都是插一根线连到交换机上，手工配置路由规则。在学校机房之类网络不复杂的情况下，时至如今也是这么做的。但是，只要增加一个新设备，就得钻进机房折腾半天；如果一个旧设备坏了，就会出现大面积的网络瘫痪。广域网络的维护者们很快就不能忍受了，于是就诞生了分布式、自组织的路由协议 BGP、ISIS、OSPF 等。 为什么设计成这样呢？有两方面原因。首先，七八十年代广域网络刚刚兴起时，网络交换设备很不稳定，三天两头挂掉，如果是个中心服务器分配资源，那么整个网络就会三天两头瘫痪。其次，Internet 是多家参与的，是 Stanford 愿意听 MIT 指挥，还是 MIT 愿意听 Stanford 指挥？ 今天，在数据中心里，这两个问题都不复存在。首先，现在的网络交换设备和服务器足够稳定，而且有 Paxos 等成熟的分布式一致性协议可以保证“中心服务器”几乎不会挂掉。其次，数据中心的规模足够大，一个大型数据中心可以有 5000 台交换机（switch），20 万台服务器，与七八十年代整个 Internet 的规模已经相当了。数据中心是公司自家的，想怎么搞就怎么搞。 因此，Software Defined Networking (SDN) 应运而生。以 OpenFlow 为代表，SDN 把分散自主的路由控制集中起来，路由器按照 controller 指定的规则对 packet 进行匹配，并执行相应动作。这样，controller 就可以利用整个网络的拓扑信息和来自 application 的需求信息计算出一组接近全局最优的路由规则。这种 Centralized Traffic Engineering (TE) 有几个好处： 使用非最短路的包转发机制，将应用的优先级纳入资源分配的考虑中； 当连接或交换机出现故障，或者应用的需求发生变化时，动态地重新分配带宽，快速收敛； 在较高的层次上指定规则，例如（我随便编的）Gmail 的流量