一个白牌厂商视角:极简交换机NOS演进史

传统的交换机操作系统(简称NOS)对大众是一个相对封闭的领域。随着白牌交换机的高速增长,NOS纷纷开源,NOS的开发者也从只有设备商工程师,扩大到互联网,运营商以及云计算的从业者。

NOS的作用是按照管理者的意志将网络中的业务在交换机上运转起来。所以NOS首先需要提供对管理者或者控制器的接口;然后需要运行协议运算,和网络中的其他交换机进行协议面的交互;第三是需要硬件接口来适配交换芯片,风扇电源等板载硬件。如下图,我们可以将NOS拆分为三个核心功能模块,以及基础架构模块。

一个白牌厂商视角:极简交换机NOS演进史

管理接口,包括传统的CLI, SNMP, WEB功能。SDN引入的Openflow, NET-CONF, OPEN Config,Restful API功能等;

协议应用模块,包括二层的协议模块STP, LLDP, M-LAG,三层的协议模块OSPF, BGP, VRRP等,以及DHCP, NTP等应用模块,SDN时代的Openflow Agent,包括OVS,;

硬件接口上包括对接交换芯片,电源,风扇的管理接口;

具备了以上三个核心功能就算是一个合适的NOS了,但给看一个NOS牛不牛,更要看“基础架构”,它是NOS骨骼和肌肉,NOS的健壮性,延展性都由它决定,NOS演进其实是这个基础架构的的演进历史。

我们将过程分割为两个阶段,第一段是思科,Juniper,Arista的巨头厂商竞争时期,这个时期核心技术集中在设备商手中,是一个技术积累的阶段;第二段是OPS, Sonic和OPX这些开源新势力的时代,喜欢玩颠覆的互联网厂商带着SDN的新需求参与了进来。

巨头之争

原始架构

一个白牌厂商视角:极简交换机NOS演进史

《Inside Cisco IOS Software Architecture》介绍的IOS架构如上图,框架里还包括软件转发的模块,可见属于非常早期版本。通过蓝色方框去剖析Cisco IOS,可以看到IOS满足了NOS的三个要素,管理接口,协议应用模块,硬件接口。但是在基础架构上还相对原始,没有将管理接口和协议应用模块分开。这个架构更多的是解决有无问题,当时的精力更多的还是在业务模块上。

模块化架构

一个白牌厂商视角:极简交换机NOS演进史

《JunOS OS for Dummies》中介绍的JunOS的架构如上图,包含管理接口,协议应用模块,硬件接口的同时提出了模块化架构的理念。

The modular architecture of Junos OS allows individual control plane processes to run in their own module (also sometimes called a daemon). Each module has specified processing resources and runs in its own protected memory space, avoiding the processing conflicts that can occur in other platforms.

同样是比较早期的架构,但是通过这个架构可以清晰的看到管理接口和其他模块是分离的,已经有一些控制和转发的分离的意思在里面,但这次演进不是革命性的,更像是从温饱到小康的进步。

数据库架构

一个白牌厂商视角:极简交换机NOS演进史

Arista的EOS的架构图如上图,EOS最牛的地方就是他的数据库架构,SysDB是一个Key-Value的内存数据库,Arista的核心亮点是能够原生的解决进程级别故障,流程如下:

一个白牌厂商视角:极简交换机NOS演进史

可以看到进程故障时候,交换芯片继续保持转发,进程恢复后从SysDB重新获取状态继续运行,该功能不但可以保障业务的稳定运行,还可以实现单进程升级功能。记得当时Arista一个典型的DEMO是将正在运行的STP KILL掉进行单进程升级,因为STP的状态都是存在SysDB里的,所以STP进行恢复工作后,业务层面可以做到不感知。

数据库架构的演进是一个重大的变革,颠覆了传统的定义数据结构,然后进程间消息通信的传统的架构。开发者可以使用类似开发通用软件的思路进行开发,而且NOS的数据可视化了,大大降低定位问题,解决问题的难度。

思科在NX-OS上同样通过Key-Value的内存数据库来实现了HA,如下图:

一个白牌厂商视角:极简交换机NOS演进史

思科的NX-OS清晰的完成了管理和协议应用分离(排名不分先后),实现了轻量级的Key-Value内存数据库完成了HA Infrastructure,思科在庞大的协议栈包袱下始终不断演进,同样令人钦佩。

新势力

SDN高速发展,白牌产业催生了一批开源开放的NOS,这些新兴的NOS站在巨人的肩膀上,都基于数据库架构,OPS选择了OVSDB,Sonic和OPX选择了Redis,OVSDB和Redis都属于Key-Value的In-memory数据库。

但这并没有让新势力满足,SDN要的是更快,更灵活,更大规模,更好扩展。巨头时期的NOS开发周期还是过长,升级还是有点不方便,用惯了动态语言的互联网开发者表示无法接受。数据中心的互联网用户对NOS最痛点的需求是如何流量无感知的完成版本迭代,以及如何更方便,更高效的进行版本升级。

数据库架构 + 容器架构

一个白牌厂商视角:极简交换机NOS演进史

做公有云的微软自然的想到通过虚拟化重构NOS,将容器技术应用到了NOS。容器技术可以简单理解为:对Linux操作系统来看是容器是一个进程,容器看自己内部是一个轻量级虚拟机。Sonic将各种进程,比如BGP运行在容器中,原生的解决了JunOS提出的模块化问题,更重要是配合数据库架构,由对单进程的升级,变成了对容器的升级,聪明的使用成熟通用的技术解决传统问题。

总结整个基础架构发展史如下图:

一个白牌厂商视角:极简交换机NOS演进史

相关推荐