SONiC开源社区生态背后的开放网络革命引擎
在数据中心里,数以万计的服务器由无数的交换机连接起来,构成了一个高带宽、低延迟的网络。众所周知,云计算业务对于可靠性有非常高的要求,这要求网络的运维人员,必须对交换机做到高度的可控制、可管理,能够时刻了解网络发生了什么,在出现故障的时候必须快速定位和排除故障。此外,新的云计算业务,也对交换机不断提出新的功能需求,这就要求网络的开发人员能在短时内实现新的交换机功能并部署上线。
在这些新的挑战和要求面前,传统交换机厂商的设备已经显得越来越力不从心,因此,各大云计算厂商纷纷开始了自己的交换机自研之旅。
什么是SONiC?
作为OCP合作项目的一部分,微软在2016年OCP峰会上发布了交换机操作系统开源项目SONiC (Software for Open Networking in the Cloud)。该项目利用交换机抽象接口(Switch Abstraction Interface, SAI)为不同的交换芯片提供了统一的管理和操作接口,并将交换机软件分解为多个容器模块,来加速软件的迭代开发(如图1)。SONiC得到了很多云计算、交换机和芯片厂商的响应,目前的开源社区成员包括微软、阿里巴巴、腾讯这样的云计算厂商以及Mellanox、思科、Arista、Asterfusion这样的交换机和芯片厂商。
SONiC之所以在众多开源网络操作系统中脱颖而出(AT&T的dNOS,Facebook的FBOSS),我想主要有如下几个原因:
- 微软云计算做出的成绩有目共睹,因此SONiC也就有了业界最佳实践。
- 众多第三方开源工具的使用。容器化可以类比于浏览器模式的插件化,这样很多第三方工具可以很方面的集成到SONiC中,而不需要对系统做很大的更改。即插即用模式非常符合目前的软件潮流,意味着开放的精神。(图1)中Applications标注的就是用户工具,比如LAG,LLDP, BGP等。
SONiC的亮点
SAI接口和容器化是SONiC的两个突出的亮点。SAI使得SONiC可以兼容不同芯片的设备,且芯片驱动只需要提供接口,并不需要开源同时也保证了芯片驱动的封闭性。
容器化使得SONiC可以充分利用现有的开源软件,比如redis, Quagga/FRR, GoBGP等,通过内核/redis-db来实现各个容器之间的通信,同时保证各个第三方组件的相对独立,便于对容器进行控制,也可以很快的兼容新的特性。当然,SONiC本身是完全开源的,最开始是微软开源出来,放在Azure下维护,最终SONiC被移交给了Linux基金会管理,开源生态越来越成熟,独立性也越来越强,不再依赖于某一个厂商。
SAI
交换机抽象接口(Switch Abstraction Interface, SAI)作为SONiC架构的基石,解决了传统网络设备软硬件深度绑定的痛点,并定义了一套标准化的API接口(如端口管理、路由表操作、ACL配置等),屏蔽了不同ASIC芯片(如Broadcom、NVIDIA Mellanox、Barefoot)的底层差异。开发者无需关注硬件具体实现,只需调用SAI接口即可控制转发行为,实现“一次开发,多芯片运行”。通过SAI,SONiC可无缝适配多厂商ASIC芯片。
容器化
传统的设备操作系统是单一系统,各个协议通过多线程或者多进程交互,因此需要定义交互的协议类型,报文格式,比较常见是私有协议,或者基于Linux各种Socket的标准底层协议。这种实现要求各个协议之间数据格式是相一致的,因此也只有设备上自己开发的软件能够实现。而容器化是将各个协议使用容器的方式聚合(典型的是docker),容器之间通过操作系统的接口实现交互,因此各个容器之间是弱连接,这样便于容器之间的软重启或者动态编排,更符合软件及服务的概念。
开源化
SONiC上一个很重要的协议就是FRR,他是从Zebra->Qugga又分出来的一个开源路由协议组件,除了成熟的OSPF, BGP等路由协议外,对于MPLS和SRv6也增加了很多支持,FRR还增加了FPM(Forwading Plane Manager),即转发平面管理,除了支持传统的netlink接口协议,还支持了protobuf协议,更容易集成新的组件。在底层通过redis数据库的订阅发布机制,将事件生产者和消费者联系了起来,可以看看这篇文章的分析。
基于SONiC内核的网络操作系统—AsterNOS
作为国内第一批SONiC社区成员,星融元围绕开放网络技术进行了长期、持续的投入,并结合各种典型应用场景做了足够的测试验证和缺陷修复,所提供的SONiC企业级发行版AsterNOS目前已可稳定兼容几乎所有主流商业交换芯片,构建的一系列有特色的硬件平台,能够实现从数据中心到云化园区的跨场景使用。
截至2022年底,AsterNOS已针对社区原生版本的缺陷和不足完成了大量开发工作,并切实提升了软件的可靠性和易用性,这其中就包含了VXLAN、ARP Host Routing、BGP EVPN、VLAG、Monitor-link、STP/MSTP等网络功能补充和增强,以及对思科风格的CLI的支持。
为了更加充分地发挥开源开放的力量,AsterNOS还在SONiC云原生的架构之上提供了强大的SDK能力——用户可通过丰富的API(RESTful API和系统级API)在网络设备上简单快速地开发第三方APP,以及与各种开源运维工具/平台无缝集成。
SONiC商用场景扩展
数据中心(AsterNOS-DataCenter)
主要提供 L2/L3/VXLAN/Routing/EVPN 等云数据中心所需的各种功能,以及对智算等场景的RoCE、智能路由等特性的增强支持(未来也将主要基于此版本平滑支持下一代以太网协议,例如超以太网)。
企业园区(AsterNOS-Campus)
将SONiC的核心原则——开放性、易用性和灵活性引入园区。提供VXLAN 和 BGP-EVPN 虚拟化,实现灵活的逻辑网络编排;选定型号上采用 MPLS,可实现运营商级场景的无缝 WAN 集成;部分型号采用 PTP(精确时间协议),为关键应用提供高精度时间同步的网络。
从数据中心场景到园区网络,这不仅仅是“更换操作系统”,而是一次深度集成和系统级重构。我们针对资源受限的硬件平台(甚至是 1G 端口的接入交换机)移植并优化了SONiC,并围绕其他开放网络技术(例如OpenWiFi/OLS)提供端到端的新一代云化园区网整体解决方案。
边缘路由(AsterNOS-VPP*)
从硬件角度来看,业界已有很多强大的基础平台如各类 DPU 网卡、高性能服务器或虚拟化主机;在软件方面,VPP等数据平面解决方案也已经显著成熟,两者共同为构建开放路由平台奠定了坚实的基础。
然而,SONiC 仍难以在这些新平台上提供完整的路由功能——市场上明显缺乏一种能够真正取代昂贵的封闭式黑盒路由器的商用级、成熟且用户友好的开放式路由解决方案。
AsteNOS-VPP 则是目前我们围绕SONiC的最新实践。具体而言是将 SAI 接口集成到 VPP 上,使基于 SONiC 的 AsterNOS 能够从交换机 ASIC 平台扩展到具有完整路由功能的 DPU 和服务器平台。
参考文献
– mp.weixin.qq.com
– SONiC Boom: Leveraging Open Source and Merchant Silicon for Today’s Scalable Network Infrastructures