【IT168 评论】 软件定义网络受到网络工程师和行业媒体的高度关注，但很少有SDN部署实例。在为数不多的部署实例中就包括谷歌，这家搜索巨头在2013年开放网络峰会上介绍了其软件定义网络细节，让我们去看看。
谷歌运行着一个庞大的网络，在2010年Arbor Networks公司在其研究中总结道：“如果谷歌是一个互联网服务供应商，它将是发展最快的全球第三大网络运营商。只有两家公司比谷歌贡献更多的跨域流量，这两家供应商都承载着谷歌庞大的流量。”
在开放网络峰会上，谷歌杰出工程师Amin Vahdat介绍了谷歌如何结合Quagga开源软件以及OpenFlow来优化其数据中心互连，他还介绍了谷歌在其内部数据中心使用OpenFlow的细节信息，谷歌称其SDN网络为“B4”。
谷歌为何选择SDN？
Vahdat指出，谷歌后端(东西)网络的增长迅速超越了其前端面向用户的网络。这种增长非常昂贵，因为网络并不能像存储和计算一样以符合成本效益的方式来扩展。计算和存储的运营成本会随着规模的扩展而更加便宜，但网络并不是如此。
Vahdat介绍了谷歌选择软件定义网络的理由。首先，通过从软件分离硬件，该公司可以基于所需的功能选择硬件，同时能够对软件时间线进行创新和部署。其次，它提供逻辑上的集中控制，这将会更具确定性、更高效以及更容错。第三，自动化允许谷歌分离、监控、管理和操作。所有这些元素能够提供灵活性以及创新性。
在这个项目开始时，谷歌使用商用芯片建立了自己的交换机(见图片)。谷歌构建自己的硬件，因为当时市场上并没有硬件能够满足其需求。
▲B4网络硬件
Vahdat并没有提到现在市场上是否存在满足于谷歌部署SDN硬件需求的交换机，这通常涉及供应商固件升级到纳入OpenFlow代理。
然而，Vahdat指出，虽然OpenFlow并不是且仍然部署完美的协议，但谷歌将继续使用OpenFlow用于流量实例，因为它受到各种厂商的支持。笔者认为，这意味着谷歌并不打算推出其自己的硬件，并且，OpenFlow支持将会是未来硬件购买的采购要求。
谷歌B4网络的混合迁移分三个阶段
Vahdat接着讨论了谷歌的SDN迁移路径，从完全分布式的单片控制和数据平面硬件架构转移到物理分散的(尽管逻辑上集中)控制平面架构。
谷歌B4网络的混合迁移分三个阶段进行：
▲传统混合SDN部署
▲混合综合SDN部署
▲最终：混合SDN部署
在下面的图中，你可以看到，谷歌已经在交换机旁边部署了网络控制器服务器(NCS)，这个NCS包含针对一定数量网络元素的提取的控制平面。这些交换机运行具有低水平控制的OpenFlow代理，所有真正重要的元件运行在外部服务器(但仍位于同一位置)的一套控制器上，NCS是32核服务器。
▲B4架构
在NCS上面是OpenFlow控制器，用于高可用性故障切换。Vahdat谈到的主要应用程序是流量工程应用程序—将政策实例化到控制协议，包括BGP、ISIS和OpenFlow。
作者总结
笔者对谷歌的混合部署战略很感兴趣。这笔者看来，在对网络状态的丢失和机械地继续转发数据包方面，谷歌相当受限。网络可能会回落到低优先级，实例化流量规则。流量表中，不符合流量规则的数据包将会流入到正常的转发管道或者预先安装的捕捉全部的流量规则，来到达出口网关。虽然自定义转发将会回落到最短路径或者静态路径，但它会保持流量转发，直到控制元件恢复。
这些图表明控制元件是按照多层层次来部署。分层和模块化是我们现在扩展大型网络的方法。通过将NIB(网络信息库)分成模块，谷歌的方法类似于现在的网络架构从每个数据平面减去专用控制平面的方法。这些模块然后可在所有模块中再分发哈希表和NIB，并提供整体视图。
作者：来源：51CTO | 2013年07月25日 10:41:03
ZDNET网络频道 07月25日 综合消息：Google使用Openflow技术来部署自己的数据中心网络的传说由来已久，但是一直没机会看到资料介绍相关的情况，今天终于看到了一个google的PPT文档，介绍它的部署情况，不算太详细，但已经足以透露不少信息了。闲来无事，分析一下，这个文档透露了以下信息：
1.Google的Openflow目前看起来仅仅用于WAN网络，包括面向Internet的和他们的不同数据中心之间的网络，貌似还没涉及到一个数据中心内部的网络。我觉得这是很明智的，内部的更复杂，可以一步一步来。
2.Google所用的Openflow交换机是定制的交换机，这些交换机所用的芯片都是商业ASIC，这意味着什么呢?意味着转发面的实现并不是使用标准的Openflow Spec的方式，而是TTP的方式，即向上提供Openflow标准接口，但是芯片转发面并不是用标准的openflow流表，而是组合使用传统表项(Mac, IP, ACL等)包装出Openflow flow来，估计做了不少扩展。(关于这第二点,这个PPT没提，是我从另外一个Nick McKeown写的paper看到的，那个paper提到了一句话，说google的Openflow交换机使用了商业ASIC)
3.Google这个网络架构是标准的SDN的架构，使用集中化controller，controller之上运行了很多application，包括一些标准网络协议，他们明确提到的包括OSFP, BGP, ISIS，这些路由协议都来自于开源的quagga协议栈(也就是商业协议栈ZebOS的前身，现在仍在维护中)。
4.Google在这个事情上展现出了其强大的软件实力，他们用软件模拟了完整的数据中心网络，可以模拟任意拓扑，并且也仿真了交换机和交换芯片，用于模拟网络测试，同时完成了复杂的应用程序和控制器来控制网络。
交换机还支持Hitless upgrade，也就是说在线升级软件，应该说Google的网络模型别人也能模仿，但是这种强大的软件实力就不是别人轻易能模仿的了的，BTW他们的交换机的OS是Linux。
5.他们的部署分为三个阶段，第一阶段是2010年春天完成的，把Openflow交换机引入到网络里面，但是这个时候Openflow交换机对同网络中的其它非Openflow设备表项的就像是传统交换机一样，只是网络协议都是在controller上完成的，外部行为来看表现的仍然像传统网络。第二阶段是到2011年中完成，这个阶段引入更多流量到Openflow网络中，并且开始引入SDN管理，让网络开始向SDN网络演变。第三个阶段在2012年初完成，整个WAN backbone网络完全切换到了Openflow网络，引入了Traffic Engineering，完全靠Openflow来规划流量路径，对网络流量进行极大的优化。看的出来，他们使用Openflow，最主要做的事情就是Traffice Engineering，优化转发路径，其它的相对次要。
6.他们目前已经看到该网络带来的一些好处包括：网络带宽利用率大大提高，网络更稳定，管理简化了，Cost降低了，其它好处有待于进一步观察。
7.但是他们认为Openflow的部分潜在机会机已经得到验证和肯定，包括对整个网络的视图可以看得很清楚，可以更好地来做Traffice Engineering从而更好的进行流量管控和规划，更好的路由规划，能够清楚地了解网络里面发生了什么事情，包括monitering, alert。
8.他们也总结除了Openflow仍然需要提高改进的地方，包括OF协议仍然不成熟，Master的选举和Control plane的责任划分仍有很多挑战，对于大型网络flow的programming会速度比较慢，到底哪些功能要留在交换机上哪些要移走还没有一个很科学的划分，但是他们认为，这些问题都是可以克服的。
9.最后他们得出了几个结论： Openflow is ready for real-world use. SDN is ready for real-world use. Google的数据中心WAN网络已经成功地基于Openflow搭建起来了。
总的看来，Google的报告对SDN和Openflow是正面的，积极向上的，用经济术语来说，是重大利好。
联系客服
