猎户座:谷歌的下一代SDN控制器

时至今日,谷歌在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就是未来。毕竟,梦想还是要有的。

发表评论

您的电子邮箱地址不会被公开。

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据