时至今日，谷歌在2015年公布的成果，“利用SDN将广域网带宽利用率提升至接近100%”，仍然是SDN的一个标杆案列，也是难以逾越的巅峰。但事实上，当时使用的SDN控制器Onix，早已退出了历史舞台。

在今年的NSDI会议上，谷歌发表论文，详细阐述了其第二代SDN控制器Orion的设计原则、整体架构和在生产网络中的应用情况。

尽管是最近才发表的论文，但Orion已经在现网中运行了四年，可谓是“久经考验”。

今天这篇文章会分为几个部分，包括介绍谷歌网络的整体情况，回顾第一代SDN控制器Onix，简要阐述谷歌新一代SDN控制器Orion的情况和几个重要的设计考虑。

谷歌网络情况简介

如图所示，谷歌的网络主要分成三大部分，B4、B2（也叫Espresso）以及Jupiter。

其中B4是谷歌的数据中心互联网络，连接了谷歌全球的数据中心。B2是谷歌面向互联网的网络，负责将用户业务从全球各地的POP点引入到数据中心。而Jupiter，则是谷歌数据中心的内部网络。

这里再补充谈一下谷歌网络承载的业务流量属性。

直到现在，很多运营商专家都表示谷歌的流量基本是自有业务，因此可控性好，更适合SDN。而运营商网络的流量情况，则过于复杂。

事实上，随着谷歌产品线的扩展，尤其是云服务业务的增长，谷歌网络内的流量不可预测性也在不断提升。很大一部分流量，已经不再是自有业务。

谷歌的第一代SDN

谷歌的第一代SDN控制器Onix，总的来说有这么几点值得注意：

一是Onix本身是合作研发而非自研，二是Onix的引入是一个循序渐进的过程，三是Onix是一个单体（molonithic）程序。

Onix的研发是Nicara、NEC和谷歌合作进行的，甚至Nicara的专家还扮演了非常重要的角色。但到了Orion，从论文上看，作者已经是清一色的谷歌员工。可以说谷歌的网络团队在这几年中是在飞速成长的。

Onix投产的过程，也是循序渐进的，大概花了三年完成切换。

第一阶段是2010年开始引入openflow交换机，但新交换机对外的表现和传统交换机一样，只是网络协议运算在controller而不是设备本身完成。第二阶段是一个漫长的流量切换过程。直到2012年开始，流量才完全切换到openflow网络。

Onix作为一个单体程序，其很多固有局限性基本无法解决，这也是Orion出现的理由。

单体程序在稳定性和开发速度上，都存在很大的劣势。以谷歌的实力发布一个新版本都需要5个月，这个节奏和业务发展是明显不相称的。

微服务版本的Orion上线后，两周就可以发布一个版本，并且还有望提升到一周。分布式程序稳定性大增，控制器完全崩溃的几率变得更小。

Orion的整体情况

Orion本身的工作模式，一个词总结，就是调和（reconciliation）。

一方面，Orion接收网络管理方（人或者上层应用）的意图并层层翻译。另一方面，不断地感知当前网络的实际运行状态，然后将网络的运行状态逐渐调整向管理方意图靠拢。

从设计的根本原理上看，和Kubernetes的原理几乎一致。

而从架构上看，Orion则是一个典型的微服务应用。

最上层是各种具体的网络应用，如负责域内算路的Routing Engine以及负责BGP广播的Raven等。

中间的核心层主要实现了控制器的通用功能，包括一个集中的NIB数据库（兼具消息队列功能）和负责处理配置、拓扑及流表生成的管理器，以及用于和路由器通信的OFE。

各个模块之间都是微服务，主要通过NIB承载的消息进行交互，这也很好的保障了故障隔离性及开发的可协调性。

值得注意的是，Orion控制的所有路由器均只有openflow协议栈，没有传统协议栈，包括BGP信息的广播和接收，都是在控制器上完成，可以说彻底实现了SDN化。

当然，出于安全性的考虑，Orion并不是一点集中的控制器，而是分域部署的。这在牺牲一些全局性带来的优势（如算路更优，流表更新更快等）的同时，也最大程度确保了网络的健壮性。

Orion的设计考虑

作为面向超大规模生产网络的控制器，意图驱动（intent-based）是必然选择。

谷歌表示宏观的意图远比细锁的过程更稳定，更不容易出错。因此Orion本身就被设计为一个逐层翻译和细化意图的控制器，最终会将管理人员的意图翻译为交换机可识别的openflow原语（primitives）。

Orion处理故障的原则也非常值得学习：对于小问题积极处理，对于大问题则直接躺平（不干涉数据面状态）。

如图所示，一个数据流自顶向下的三层路由器网络中，如果感知到2个路由器损坏，则Orion会牵引流量绕开损坏的路由器，这就是fail-closed。

而如果感知到四个路由器都损坏了，则Orion不会再做任何操作，保持数据面当前状态，也就是fail-static。

这是因为一方面小问题Orion可以在不影响现网流量的情况下进行处理，但大问题的处理则会严重影响现有业务；另一方面数据面出现大问题的几率其实很小，更大的可能是管理通道或者控制器本身出现问题，因此感知到大面积故障误报的可能性很大。

最后一点是关于管理通道的问题。

一般认为带外管理因为具有单独的管理通道，会是更可靠的方式。但管理通道本身也可能损坏，且大量网元均通过带外管理也会产生巨大的成本。

因此，Orion采用了带内管理和带外管理相结合的方式：一方面只对重要设备进行带外管理，这样节省了大量成本；另一方面带内管理和带外管理互为备份，避免管理通道的损坏导致网元彻底脱管。

结语

网络运营，追求的无非是安全和高效。

SDN本身就是为了高效而生的，经过业界多年的实践，这一点已经没有太大的争议，其效率的提升是实实在在的。而现在争议最大的，主要聚焦在安全和实施成本上。

考虑到网络的自然迭代，成本其实不是问题，逐步转型就好。谷歌也不是一夜之间把路由器都替换掉的。

而安全方面，我想谷歌的论文以及业界的其他实践，已经解答了很多技术上的问题。剩下的问题，更多是意识层面的：是靠算法调度流量更安全，还是深夜的双人割接更安全？是靠经验反复分析、层层把关的割接报告更可靠，还是软件自动计算的drain analysis更准确？

这些问题的答案并不是那么显然，因为安全的定义其实是很复杂的。

这几年来，在网络智能化上，笔者也做了一些微小的工作。总的来说，遇到的困难不少，取得的成果也不算大。但我仍然坚信，SDN就是未来。毕竟，梦想还是要有的。