《云数据中心网络与SDN：技术架构与实现》——2.2.2　操作系统级开放

2.2.2　操作系统级开放

说完了芯片，再来看操作系统。白盒的操作系统（Network OS，NOS）目前主要的选手有Cumulus、Pica8、Pluribus和BigSwitch。Cumulus的Cumulus Linux是基于Linux + 传统的协议栈，主要业务是直接卖交换机OS给ODM。Pica8的PicOS是基于Linux+OVS的，商业模式是与ODM的硬件进行捆——绑，不过Pica8自己也在做盒子。Pluribus的Netvisor是基于自己的一套虚拟化平台，主要业务是卖自己的盒子，和ODM也有一些合作。BigSwitch的SwitchLight是基于Linux + Indigo（一个开源的OpenFlow Agent），商业模式是开源交换机OS，其收入主要来自于控制器，BigSwitch自己并不卖盒子，而是选择与ODM进行合作。

这里有必要对白盒的概念做一个澄清。很多人认为白盒就是指OpenFlow交换机，或者认为白盒就是什么控制逻辑都没有的瘦转发设备。其实白盒的定义不是这样的，Wiki上对White-Box的解释是“a white box is a personal computer or server without a well-known brand name”。对于服务器来说，就是卖给用户裸机，用户愿意用Windows还是Linux可以自己去选，但是装不了MAC。类比到交换机上去理解，就是交换机出厂时不会预装其他任何软件，交换机上安装什么操作系统是用户可以自己选择的，不过可选的操作系统只能是白盒操作系统，用户想装Cisco的IOS肯定是不行的。至于白盒的操作系统里是不是支持OpenFlow，实际上是不做要求的，也可能只有传统的协议栈。大家做久了似乎发现，白盒的关键并不在于是不是OpenFlow，这完全是看用户喜好的，因此以往靠OpenFlow起家的BigSwitch和Pica8都在集成传统协议栈，而专注于传统网络的Cumulus和Pluribus也对OVSDB提供了支持。不过，如果是Cisco自己在原有的IOS上集成了一个OpenFlow Agent，那肯定是算不上白盒的。图2-7来自于BigSwitch，它很好地解释了前面这段话的内容。进一步来说，白盒并不一定要和SDN挂钩，它只要求转控分离，可编程是锦上添花，对集中式控制不做要求。

图2-7　白盒交换机与传统网络设备、SDN设备的对比

1. ONL

有人获利就肯定有人想着开源。由于BigSwitch主要的卖点是在自己的控制器，因此为了建立生态就顺手把SwitchLight贡献给了OCP，并起了一个响亮的名字叫作Open Network Linux（ONL）。ONL和普通的Linux发行版又有什么区别呢？可以说ONL是Debian Wheezy的加强版，增加了一些和白盒交换机相关的功能，比如对一些外围器件（风扇、电源、USB、LED）的适配、SFP（SFP+）的管理，对ONIE（后面会提到）的支持等，并且将上述功能抽象出了一层接口叫作ONLP，供基于ONL的平台管理应用进行调用。对于转发应用，虽然BigSwitch自己是一直在推OpenFlow的，但是ONL并没有要求转发应用一定是OpenFlow的，ASIC也没有绑定任何Vendor的ASIC。如果想要用Broadcom的芯片，就在ONL上装OpenNSL或者OF-DPA；如果想要多支持厂商的，就再集成SAI。另外，ONL还希望可以做到CPU架构无关（比如x86、PowerPC或者是ARM）。从ONL的设计理念可以看到，ONL确实是奔着通用的NOS去的。

2. FBOSS

FBOSS是Facebook自家白盒交换机上的应用集，主要包括三部分：第一部分是和芯片打交道的程序，为其他应用程序提供芯片的抽象；第二部分是自动化类的程序，分为配置、监测和排错三大类；第三部分是控制类的程序，比如BGP等。Facebook只开源了FBOSS中很小的一部分，即图2-8中的FBOSS Agent，FBOSS Agent运行在Broadcom的OpenNSL之上，提供对于Trident中L2/L3/VLAN表的进一步抽象，然后向上提供Thrift接口供其他程序调用。另外，FBOSS Agent还包括了对于一些底层控制信令（如ARP/DHCP/LLDP）的处理。对于未开源的那部分，Facebook的说法是自动化和控制类应用都是和自己的网络密切相关的，拿到别的地方也不一定适用。除了FBOSS Agent以外，Facebook还开源了主板的控制程序OpenBMC，BMC是主板上用于做主板管理的专用芯片，和主板上大部分的器件都有连接，通过OpenBMC可以随时获取主板的状态，比如主板温度。

图2-8　Facebook开放出来的FBOSS

3. SONiC

SONiC（Software for Open Networking in the Cloud）是微软在OCP里面提到的应用软件集，据说已经被应用到了Azure的生产网络中。图2-9中绿色的部分是SONiC开放出来的，主要包括基于SAI的和芯片打交道的程序以及外围器件（如风扇、LED等）的管理接口。基于SAI的和芯片打交道的程序，可以理解成和FBOSS Agent中为OpenNSL做的抽象层是一样的。外围器件（如风扇、LED）的管理接口，可以理解成和ONL提供的ONLP是一样的。深色阴影部分是已有的开源项目（如Quagga/lldpd等），SONiC利用这些项目与浅色阴影部分进行了组装。可以看到，和Facebook开源FBOSS的思路一样，微软开放的SONiC也没有涉及自家交换机上的应用，Quagga的功能毕竟有限，而且原生Quagga的性能是否足以胜任大规模生产网络的协议栈，这个事情恐怕还是要打上问号的。实际上，SONiC做了对外围器件的管理，也做了数据库和SNMP，不再单纯是一个应用层面的东西了，虽然SONiC的说法是要运行在ONL之上，但怎么看SONiC都是在往通用NOS的路子上走。

4. OS 10与OpenSwitch

Dell的OS 10也是一个基于原生Linux的通用NOS平台。Dell的策略和微软有些相似，OS 10开源了外围器件的管理接口，还有基于SAI的ASIC的控制接口，但是像自动化、协议栈这种企业级的应用并没有开放出来，如图2-10所示。

OpenSwitch是HPE贡献给Linux基金会的开源NOS。OpenSwitch和OpenvSwitch仅有一个字母之差。HPE最开始为OpenSwitch做的OPS版本也是基于OpenvSwitch的，不过定位于白盒交换机上的NOS。OPS（图2-11）中为OVS扩展了很多新的东西，包括L2/L3的传统协议栈，ASIC的驱动与抽象，外围器件的适配与管理，不同RESTful、Ansible等不同的北向接口，等等。OPS为OVSDB扩展了很多的Schema，用于传统的协议栈和白盒的管理。扩展后的OVSDB负责各种状态的发布订阅，以驱动不同应用间的通信。OPS中路由协议栈这部分最初用的是Quagga，拓扑发现用的lldpd，Lacp这一块是HPE自己贡献的。2016年10月，HPE宣布不再维护OpenSwitch的代码，将其转交给了Dell和SnapRoute，由Dell负责OS，由SnapRoute负责协议栈。之后，OpenSwitch转向OPX版本（图2-12），架构上开始向Dell的OS 10靠拢，OPS版本不再进行维护。