走近google基于sdn的b4网络.docx
《走近google基于sdn的b4网络.docx》由会员分享，可在线阅读，更多相关《走近google基于sdn的b4网络.docx（10页珍藏版）》请在冰豆网上搜索。
走近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网络的改造方法，充分考虑了其网络的一些特性以及想要达到的主要目标，一切都围绕这几个事实或者期望。
GoogleB4网络的绝大多数的流量都是来自数据中心之间的数据同步应用，这些应用希望给它们的带宽越大越好，但是可以容忍偶尔的拥塞丢包、链路不通以及高延时。
Google再强大，数据中心的数量也是有限的，这个特点意味着Controller的scalability的压力相对小很多。
Google能够控制应用数据以及每个数据中心的边界网络，希望通过控制应用数据的优先级和网络边缘的突发流量（Burst）来优化路径，缓解带宽压力，而不是靠无限制地增大出口带宽。
这个网络必须要考虑成本，虽然Google富可敌国，但其WAN网的数据流量每天都在增加，无法承受无止境的设备成本的增加，所以必须想办法降低成本。
Google的部署分为三个阶段。
第一阶段在2010年春天完成，把OpenFlow交换机引入到网络里面，但这时OpenFlow交换机对同网络中的其他非OpenFlow设备表现得就像是传统交换机一样，只是网络协议都是在Controller上完成的，外部行为来看表现得仍然像传统网络。
第二阶段是到2011年中完成，这个阶段引入更多流量到OpenFlow网络中，并且开始引入SDN管理，让网络开始向SDN网络演变。
第三个阶段在2012年初完成，整个B4网络完全切换到了OpenFlow网络，引入了流量工程，完全靠OpenFlow来规划流量路径，对网络流量进行极大的优化。
为了对这个方案进行充分测试，Google运用了其强大的软件能力，用软件模拟了整个B4网络拓扑和流量。
图1B4SDN网络整体架构图
具体实现
虽然该网络的应用场景相对简单，但用来控制该网络的这套系统并不简单，它充分体现了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这里要稍微介绍一下，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，跟其他数据中心WAN里面的设备之间运行iBGP。
OnixController收到下面交换机送上来的路由协议报文以及链路状态变化通知时，自己并不处理，而是通过RAP把它送给Quagga协议栈。
Controller会把它所管理的所有交换机的端口信息都通过RAP告诉Quagga，Quagga协议栈管理了所有这些端口。
Quagga协议计算出来的路由会在Controller里面保留一份（放在一个叫NIB的数据库里面，即NetworkInformationBase，类似于传统路由中的RIB，而NIB是Onix里面的概念），同时会下发到交换机中。
路由的下一跳可以是ECMP，即有多个等价下一跳，通过Hash选择一个出口。
这是最标准的传统路由转发。
它的路由架构图如图2所示。
图2B4SDN网络路由架构图
跑在Controller上面的另外一个应用程序叫TEAgent，跟全局的Gateway通信。
每个OpenFlow交换机的链路状态（包括带宽信息）会通过TEAgent送给全局的Gateway，Gateway汇总后，送给TEServer进行路径计算。
第三层：
全局控制层
第三层中，全局的TEServer通过SDNGateway从各个数据中心的控制器收集链路信息，从而掌握路径信息。
这些路径被以IP-In-IPTunnel的方式创建而不是TE最经常使用的MPLSTunnel，通过Gateway到OnixController，最终下发到交换机中。
当一个新的业务数据要开始传输时，应用程序会评估该应用所需要耗用的带宽，为它选择一条最优路径（如负载最轻的但非最短路径虽不丢包但延时大），然后把这个应用对应的流，通过Controller安装到交换机中，并跟选择的路径绑定在一起，从而整体上使链路带宽利用率达到最优。
对带宽的分配和路径的计算是Google本次网络改造的主要目标也是亮点所在，所以值得深入分析一下。
我反复研究了一下Google的这一套逻辑，理出大概的思路，分享如下。
最理想的情况下，当然是能够基于特定应用程序来分配带宽，但那样的话会导致流表项是一个天文数字，既不可能也无必要。
Google的做法很聪明：
基于｛源数据中心，目的数据中心，QoS｝来维护流表项，因为同一类应用程序的QoS优先级（DSCP）都是一样的，所以这样做就等同于为所有的从一个数据中心发往另外一个数据中心的同类别的数据汇聚成一条流。
注意：
单条流的出口并不是一个端口，而是一个ECMP组，芯片转发时，会从ECMP组里面根据Hash选取一条路径转发出去。
划分出流之后，根据管理员配置的权重、优先级等参数，使用一个叫做bandwidth的函数计算出要为这条流分配多少带宽。
为了公平起见，带宽分配是有最小带宽和最大带宽的，既不会饱死，也不会饿死。
TE算法有两个输入源，一个是Controller通过SDNGateway报上来的拓扑和链路情况，另一个就是bandwidth函数的输出结果。
TE算法要考虑多种因素，不仅仅是需要多少带宽这么简单。
TEServer将计算出来的每个流映射到哪个tunnel，并且分配多少带宽的信息通过SDNGateway下发到Controller，再由Controller安装到交换机的TE转发表中（ACL），这些转发表项的优先级高于LPM路由表。
图3是Google的TE架构图。
有心的读者可能会注意到，既然有了TE，那还用BGP路由协议干什么？
没错，TE和BGP都可以为一条流生成转发路径，但TE生成的路径放在ACL表，BGP生成的放在路由表（LPM），进来的报文如果匹配到ACL表项，会优先使用ACL，匹配不到才会用路由表的结果。
一台交换机既要处理从内部发到别的数据中心的数据，又要处理从别的数据中心发到本地数据中心内部的数据。
对于前者，需要使用ACLFlow表来进行匹配查找，将报文封装在Tunnel里面转发去，转发路径是TE指定的，是最优路径。
而对于后者，则是解封装之后直接根据LPM路由表转发。
还有路过的报文（从一个数据中心经过本数据中心到另外一个数据中心），这种报文也是通过路由表转发。
这种基于优先级的OpenFlow转发表项的设计还有一个很大的好处，就是TE和传统路由转发可以独立存在，这也是为什么B4网络改造可以分阶段进行的原因。
开始可以先用传统路由表，后面再把TE叠加上来。
而且，就算是以后不想用TE时，也可以直接把TE给禁掉就行了，不需要对网络做任何的改造。
图3B4SDN网络TE架构图
SDNGateway的作用
这里架构中有一个角色是SDNGateway，为什么要有这个角色呢？
它对TEServer抽象出了OpenFlow和交换机的实现细节，对TEServer来说看不到OpenFlow协议以及交换机具体实现。
Controller报上来的链路状态、带宽、流信息经过它的抽象之后送给TEServer。
TEServer下发的转发表项信息经过SDNGateway的翻译之后，通过Controller送给交换机，安装到芯片转发表中。
B4网络改造效果
经过改造之后，据说链路带宽利用率提高了3倍以上，接近100%，链路成本大大降低，这应该算是最大的成效了，也是当初最主要的目标，现在看来目标是完成了。
另外的收获还包括网络更稳定，对路径失效的反应更快，管理大大简化，也不再需要交换机使用大的包缓存，对交换机的要求降低。
Google认为OpenFlow的能力已得到验证和肯定，包括对整个网络的视图可以看得很清楚，可以更好地来做TrafficeEngineering，从而更好地进行流量管控和规划，更好地路由规划，能够清楚地了解网络里面发生了什么事情，包括监控和报警。
按照Google的话说，超出了其最初的期望。
该案例对SDN的积极意义
Google这个基于SDN的网络改造项目影响非常大，对SDN的推广有着良好的示范作用，所以是ONF官网上仅有的两个用户案例之一（另外一个是NEC的一个医院网络的基于SDN的网络虚拟化改造案例）。
这个案例亮点极多，总结如下。
1.这是第一个公开的使用分布式Controller的SDN应用案例，让更多的人了解到分布式Controller如何协同工作，以及工作的效果如何。
2.这是第一个公开的用于数据中心互联的SDN案例，它证明了即使是在Google这种规模的网络中，SDN也完全适用，尽管这不能证明SDN在数据中心内部也能用，但至少可以证明它可以用于大型网络。
只要技术得当，可扩展性问题也完全可以解决。
3.QoS。
流量工程一直是很多数据中心以及运营商网络的重点之一，Google这个案例给大家做了一个很好的示范。
事实上，据我了解，在Google之后，又有不少数据中心使用SDN技术来解决数据中心互联的流量工程问题，比如美国的Vello公司跟国内的盛科网络合作推出的数据互联方案就是其中之一，虽然没有Google的这么复杂，但也足以满足其客户的需要。
4.这个案例也向大家演示了如何在SDN环境中运行传统的路由协议，让大家了解到，SDN也并不都是静态配置的，仍然会有动态协议。
XX文库-让每个人平等地提升自我5.在这个案例中，软件起到了决定性的作用，从应用程序到控制器，再到路由协议以及整个网络的模拟测试平台，都离不开Google强大的软件能力。
它充分展示了SDN时代，软件对网络的巨大影响力以及它所带来的巨大价值。
Google的OpenFlow交换机使用了TTP的方式而不是标准的OpenFlow流表，但在接口上仍然遵循OpenFlow的要求，它有力地证明了要支持SDN，或者说要支持OpenFlow，并不一定需要专门的OpenFlow芯片。
包装一下现有的芯片，就可以解决大部分问题，就算有些问题还不能解决，在现有的芯片基础上做一下优化就可以了，而不需要推翻现有芯片架构，重新设计一颗所谓的OpenFlow芯片。
6.这个案例实现了Controller之间的选举机制，OpenFlow标准本身并没有定义如何选举。
这个案例在这方面做了尝试。
OpenFlow的挑战
作为一次完整的全方位的实践，当然不能只总结好的东西，也总结了OpenFlow仍然需要提高改进的地方，包括OpenFlow协议仍然不成熟，MasterController（或者说leader）的选举和控制面的责任划分仍有很多挑战，对于大型网络流表项的下发会速度比较慢，到底哪些功能要留在交换机上、哪些要移走还没有一个很科学的划分。
但Google认为，这些问题都是可以克服的。
Google技术不走寻常路的特点也体现在它基于OpenFlow搭建的数据中心WAN网络（B4）中。
虽然Google已在SIGCOMM上公布了自己的B4网络技术细节，但很多人认为太深奥。
本文将从专业的角度，深入B4网络的各个层次，用通俗易懂的语言对其进行全面解读。
升级会员 