走近Google基于SDN的B4网络

湖南省电子信息产业门户--星光电子网如果要问当前最著名、最有影响力的基于SDN技术搭建的商用网络是哪个，我想大多数人都会投票给Google的B4网络，一方面因为Google本身的名气，另一方面也是因为Google在这个网络的搭建上投入大、周期长，最后的验证效果也很好，是为数不多的大型SDN商用案例，而且非常成功，是充分利用了SDN优点（特别是OpenFlow协议）的案例。背景介绍Google的网络分为数据中心内部网络（IDCNetwork）及骨干网（BackboneNetwork，也可以称为WAN网）。其中WAN网按照流量方向由两张骨干网构成，分别为：第一，数据中心之间互联的网络（Inter-DCWAN，即G-scaleNetwork），用来连接Google位于世界各地之间的数据中心，属于内部网络；第二，面向Internet用户访问的网络（Internet-facingWAN，即I-ScaleNetwork）。Google选择使用SDN来改造数据中心之间互联的WAN网（即G-scaleNetwork），因为这个网络相对简单，设备类型以及功能比较单一，而且WAN网链路成本高昂（比如很多海底光缆），所以对WAN网的改造无论建设成本、运营成本收益都非常显著。他们把这个网络称为B4（我在网上搜了一下也没找到该名字的由来）。Google的数据中心之间传输的数据可以分为三大类：1.用户数据备份，包括视频、图片、语音和文字等；2.远程跨数据中心存储访问，例如计算资源和存储资源分布在不同的数据中心；3.大规模的数据同步（为了分布式访问，负载分担）。这三大类从前往后数据量依次变大，对延时的敏感度依次降低，优先级依次变低。这些都是B4网络改造中涉及到的流量工程（TE，TrafficEngineering）部分所要考虑的因素。促使Google使用SDN改造WAN网的最大原因是当前连接WAN网的链路带宽利用率很低。GoogleWAN网的出口设备有上百条对外链路，分成很多的ECMP负载均衡组，在这些均衡组内的多条链路之间用的是基于静态Hash的负载均衡方式。由于静态Hash的方式并不能做到完全均衡，为了避免很大的流量都被分发到同一个链路上导致丢包，Google不得不使用过量链路，提供比实际需要多得多的带宽。这导致实际链路带宽利用率只有30%~40%，且仍不可避免有的链路很空，有的链路产生拥塞，设备必须支持很大的包缓存，成本太高，而且也无法对上文中不同的数据区别对待。从一个数据中心到另外一个数据中心，中间可以经过不同的数据中心，比如可以是A→B→D，也可以是A→C→D，也许有的时候B很忙，C很空，路径不是最优。除此之外，增加网络可见性、稳定性，简化管理，希望靠应用程序来控制网络，都是本次网络改造的动机之一。以上原因也决定了Google这个基于SDN的网络，最主要的应用是流量工程，最主要的控制手段是软件应用程序。Google对B4网络的改造方法，充分考虑了其网络的一些特性以及想要达到的主要目标，一切都围绕这几个事实或者期望。湖南省电子信息产业门户--星光电子网网络的绝大多数的流量都是来自数据中心之间的数据同步应用，这些应用希望给它们的带宽越大越好，但是可以容忍偶尔的拥塞丢包、链路不通以及高延时。Google再强大，数据中心的数量也是有限的，这个特点意味着Controller的scalability的压力相对小很多。Google能够控制应用数据以及每个数据中心的边界网络，希望通过控制应用数据的优先级和网络边缘的突发流量（Burst）来优化路径，缓解带宽压力，而不是靠无限制地增大出口带宽。这个网络必须要考虑成本，虽然Google富可敌国，但其WAN网的数据流量每天都在增加，无法承受无止境的设备成本的增加，所以必须想办法降低成本。Google的部署分为三个阶段。第一阶段在2010年春天完成，把OpenFlow交换机引入到网络里面，但这时OpenFlow交换机对同网络中的其他非OpenFlow设备表现得就像是传统交换机一样，只是网络协议都是在Controller上完成的，外部行为来看表现得仍然像传统网络。第二阶段是到2011年中完成，这个阶段引入更多流量到OpenFlow网络中，并且开始引入SDN管理，让网络开始向SDN网络演变。第三个阶段在2012年初完成，整个B4网络完全切换到了OpenFlow网络，引入了流量工程，完全靠OpenFlow来规划流量路径，对网络流量进行极大的优化。为了对这个方案进行充分测试，Google运用了其强大的软件能力，用软件模拟了整个B4网络拓扑和流量。湖南省电子信息产业门户--星光电子网网络整体架构图具体实现虽然该网络的应用场景相对简单，但用来控制该网络的这套系统并不简单，它充分体现了Google强大的软件能力。这个网络一共分为三个层次，分别是物理设备层（SwitchHardware）、局部网络控制层（SiteControllers）和全局控制层（Global）。一个Site就是一个数据中心。第一层的物理交换机和第二层的Controller在每个数据中心的内部出口的地方都有部署，而第三层的SDN网关和TE服务器则是在一个全局统一的控制地。第一层：物理设备层第一层的物理交换机是Google自己设计并请ODM厂商代工的，用了24颗16×10Gb的芯片，搭建了一个128个10Gb端口的交换机。交换机里面运行了OpenFlow协议，但它并非仅仅使用一般的OpenFlow交换机最常使用的ACL表，而是用了TTP的方式，包括ACL表、路由表和Tunnel表等。但向上提供的是OpenFlow接口，只是内部做了包装。这些交换机会把BGP/IS-IS协议报文送到Controller去供Controller处理。湖南省电子信息产业门户--星光电子网这里要稍微介绍一下，TTP是ONF的FAWG工作组提出的一个在现有芯片架构基础上包装出OpenFlow接口的一个折中方案。TTP是TableTypingPatterns的缩写，中文不知道怎么翻译能比较精确地表达它的本意，但TTP想要达到的目的是很清楚的，就是要利用现有芯片的处理逻辑和表项来组合出OpenFlow想要达到的功能，当然不可能是所有功能，只能是部分。在2013年，ONF觉得TTP这个名字含义不够清晰，无法望文生义，所以他们又给它改了个名字叫NDM（NegotiabableData-planeModel），即可协商的数据转发面模型。我认为这个名字比TTP好多了，不仅因为我能翻译出来，更重要的是这个名字中的三个单词都能体现方案的精髓。NDM其实是定义了一个框架，基于这个框架，允许厂商基于实际的应用需求和现有的芯片架构来定义很多种不同的转发模型，每种模型可以涉及到多张表，匹配不同的字段，基于查找结果执行不同的动作。由于是基于现有的芯片，所以无论匹配的字段还是执行的动作都是有限制的，不能随心所欲。关于NDM有很多东西可以讲，但不是本文重点，这里略过不表。不过，我认为也许NDM将是OpenFlow的最终方案，它将大大推动OpenFlow以及SDN的发展。第二层：局部网络控制层在我看来，第二层最复杂。第二层在每个数据中心出口并不是只有一台服务器，而是有一个服务器集群，每个服务器上都运行了一个Controller，一台交换机可以连接到多个Controller，但其中只有一个处于工作状态。一个Controller可以控制多台交换机，一个名叫Paxos的程序用来进行leader选举（即选出工作状态的Controller）。从文档的描述来看，貌似这种选举不是基于Controller的，而是基于功能的。也就是说对于控制功能A，可能选举Controller1为leader；而对于控制功能B，则有可能选举Controller2为leader。这里说的leader就是OpenFlow标准里面的master。Google用的Controller是基于分布式的OnixController改造来的。Onix是Nicira、Google、NEC和Berkerly大学的一些人一起参与设计的，由Nicira主导。这是一个分布式架构的Controller模型，被设计用来控制大型网络，具有很强的可扩展性。它通过引入ControlLogic（控制逻辑，可以认为是特殊的应用程序）、Controller和物理设备三层架构，每个Controller只控制部分物理设备，并且只发送汇聚过后的信息到逻辑控制服务器，逻辑控制服务器了解全网的拓扑情况，来达到分布式控制的目的，从而使整个方案具有高度可扩展性。显而易见，这个架构非常适合Google的网络，对每个特定的控制功能（比如TE或者Route），每个site有一组Controller（逻辑上是一个）用来控制该数据中心WAN网的交换机，而一个中心控制服务器运行控制逻辑来协调所有数据中心的所有Controller。在Controller之上跑了两个应用，一个叫RAP，是RoutingApplicationProxy的意思，作为SDN应用跟Quagga通信。Quagga是一个开源的三层路由协议栈，支持很多路由协议，Google用到了BGP和IS-IS。其中跟数据中心内部的路由器运行eBGP，跟其他数湖南省电子信息产业门户--星光电子网。OnixController收到下面交换机送上来的路由协议报文以及链路状态变化通知时，自己并不处理，而是通过RAP把它送给Quagga协议栈。Controller会把它所管理的所有交换机的端口信息都通过RAP告诉Quagga，Quagga协议栈管理了所有这些端口。Quagga协议计算出来的路由会在Controller里面保留一份（放在一个叫NIB的数据库里面，即NetworkInformationBase，类似于传统路由中的RIB，而NIB是Onix里面的概念），同时会下发到交换机中。路由的下一跳可以是ECMP，即有多个等价下一跳，通过Hash选择一个出口。这是最标准的传统路由转发。它的路由架构图如图2所示。图2B4SDN网络路由架构图湖南省电子信息产业门户--星光电子网，跟全局的Gateway通信。每个OpenFlow交换机的链路状态（包括带宽信息）会通过TEAgent送给全局的Gateway，Gateway汇总后，送给TEServer进行路径计算。第三层：全局控制层第三层中，全局的TEServer通过SDNGateway从各个数据中心的控制器收集链路信息，从而掌握路径信息。这些路径被以IP-In-IPTunnel的方式创建而不是TE最经常使用的MPLSTunnel，通过Gateway到OnixController，最终下发到交换机中。当一个新的业务数据要开始传输时，应用程序会评估该应用所需要耗用的带宽，为它选择一条最优路径（如负载最轻的但非最短路径虽不丢包但延时大），然后把这个应用对应的流，通过Controller安装到交换机中，并跟选择的路径绑定在一起，从而整体上使链路带宽利用率达到最优。对带宽的分配和路径的计算是Google本次网络改造的主要目标也是亮点所在，所以值得深入分析一下。我反复研究了一下Google的这一套逻辑，理出大概的思路，分享如下。最理想的情况下，当然是能够基于特定应用程序来分配带宽，但那样的话会导致流表项是一个天文数字，既不可能也无必要。Google的做法很聪明：基于｛源数据中心，目的数据中心，QoS｝来维护流表项，因为同一类应用程序的QoS优先级（DSCP）都是一样的，所以这样做就等同于为所有的从一个数据中心发往另外一个数据中心的同类别的数据汇聚成一条流。注意：单条流的出口并不