谈谈开源交换机操作系统SONiC

更新说明： 本文已同步发表到个人博客上，具体看这里，更多关于SONiC技术的内容请访问：https://thinkdancer.net

一. 背景介绍

传统交换机上运行的都是厂商私有的系统，比如Cisco的IOS,华为的VRP等。这些系统首先是出厂固化的，用户（一般是运营商或者企业）只能基于已有的配置平面（命令行，网管SNMP，或者web）使用,不能够自己基于已有的系统开发新的功能；然后是封闭的，即你无法看到系统内部的运行机制，也就无从提高系统的安全性，只能依赖于设备商提供的版本更新，而这一般是以月来计的，或者是年；最后，不同厂商的配置平面不同（或者是专利限制，或者是实现限制），私有协议不能兼容，导致需要同时维护多套管理系统，甚至设备间互通不兼容。

对于运营商来说，可以通过集采规范来约束设备商之间实现兼容，通过第三方网管实现不同设备的统一配置；但是对于企业用户来说，没有资源和时间去搞集采，也没有资源实现兼容第三方网管。对于后一种用户来说，设备上的系统最好是开放的，可编程的，灵活定制的，而这就是开源交换机操作系统SONiC的诞生背景。SONiC之所以在众多开源网络操作系统中脱颖而出（AT&T的dNOS,Facebook的FBOSS），我想主要有如下几个原因：

  1. SONiC背后有微软的强大支持。微软的Azure云数据中心中就直接使用了SONiC做为网络操作系统，微软云计算做出的成绩有目共睹，大有和亚马逊AWS一拼高下的实力，因此SONiC也就有了业界最佳实践。这里摘录一段关于SONiC发展小插曲，和微软拥抱Linux的大背景有关系，具体可以参考：https://www.sdnlab.com/23377.html

就在大家满心欢喜的时候，命运却开了一个不大不小的玩笑。ACS最初是基于微软公司的Windows平台开发的，就在ACS Windows原型系统即将大功告成之际，微软开始积极拥抱Linux和开源系统，而Windows并非是开源网络系统中的主流操作系统，因此Azure网络产品部门的负责人Albert Greenberg立刻叫停ACS Windows���发，转向Linux，也就是今天的SONiC项目。“那个时候，大家在ACS Windows上已经投入了巨大的心血，突然知道项目被叫停，都十分无奈和沮丧。”熊勇强回忆到。“但是不得不说，投身Linux确实是一个十分明智的决定。Linux的开源生态对于SONiC来说是至关重要的。”

  1. 众多第三方开源工具的使用。容器化可以类比于浏览器模式的插件化，这样很多第三方工具可以很方面的集成到SONiC中，而不需要对系统做很大的更改。即插即用模式非常符合目前的软件潮流，他意味着开放的精神。下图中Applications标注的就是用户工具，比如LAG,LLDP, BGP等。


(图片来自SONiC库中images/sonic-architecture_new.png)

二. SONiC系统亮点

SAI接口和容器化是SONiC的两个突出的亮点。SAI使得SONiC可以兼容不同芯片的设备，且芯片驱动只需要提供接口，不需要开源，保证了芯片驱动的封闭性，因为SAI是微软提出并贡献给OCP组织的，并且成为了事实上的标准，因此得到了很多主流芯片厂商的支持，包括Cisco都加入进来了；容器化使得SONiC可以充分利用现有的开源软件，比如redis, Quagga/FRR, GoBGP等，通过内核/redis-db来实现各个容器之间的通信，同时保证各个第三方组件的相对独立，便于对容器进行控制，也可以很快的兼容新的特性。当然，SONiC本身是完全开源的，最开始是Microsoft开源出来，但是放在Azure下维护，最近SONiC被移交给了Linux基金会管理，开源生态越来越成熟，独立性也越来越强，不再依赖于某一个厂商。


(图片来自SAI\doc\figures\sai_switch_system_architecture.png)

  1. SAI接口

除了SONiC使用了SAI外，其他一些开源的白盒交换机项目也使用了SAI接口作为驱动层，用以兼容不同厂家的白盒交换机，比如FBOSS，实现SAI接口的芯片厂商很多就代码开源到了Github上，这里是地址列表：
https://github.com/Broadcom-Switch/SAI
https://github.com/Marvell-switching/SAI-plugin
https://github.com/CentecNetworks/sai-advance
https://github.com/Dell-Networking/sonic-sai-vm
https://github.com/p4lang/switch
https://github.com/Mellanox/SAI-Implementation
https://github.com/Cisco-8000-sonic
https://github.com/jayantwu/Cisco_SAI
其实SAI有哪些厂商支持可以参考这里：https://github.com/Azure/sonic-sairedis/blob/master/syncd/scripts/syncd_init_common.sh

点击查看代码 

    if [ "$SONIC_ASIC_TYPE" == "cisco-8000" ]; then
        config_syncd_cisco_8000
    elif [ "$SONIC_ASIC_TYPE" == "broadcom" ]; then
        config_syncd_bcm
    elif [ "$SONIC_ASIC_TYPE" == "mellanox" ]; then
        config_syncd_mlnx
    elif [ "$SONIC_ASIC_TYPE" == "cavium" ]; then
        config_syncd_cavium
    elif [ "$SONIC_ASIC_TYPE" == "centec" ]; then
        config_syncd_centec
    elif [ "$SONIC_ASIC_TYPE" == "marvell" ]; then
        config_syncd_marvell
     elif [ "$SONIC_ASIC_TYPE" == "barefoot" ]; then
         config_syncd_barefoot
    elif [ "$SONIC_ASIC_TYPE" == "nephos" ]; then
        config_syncd_nephos
    elif [ "$SONIC_ASIC_TYPE" == "vs" ]; then
        config_syncd_vs
    elif [ "$SONIC_ASIC_TYPE" == "innovium" ]; then
        config_syncd_innovium
    elif [ "$SONIC_ASIC_TYPE" == "soda" ]; then
        config_syncd_soda
    else
        echo "Unknown ASIC type $SONIC_ASIC_TYPE"
        exit 1
    fi

  1. 容器化
    传统的设备操作系统是单一系统，各个协议通过多线程或者多进程交互，因此需要定义交互的协议类型，报文格式，比较常见是私有协议，或者基于Linux各种Socket的标准底层协议。这种实现要求各个协议之间数据格式是相一致的，因此也只有设备上自己开发的软件能够实现。而容器化是将各个协议使用容器的方式聚合（典型的是docker），容器之间通过操作系统的接口实现交互，因此各个容器之间是弱连接，这样便于容器之间的软重启或者动态编排，更符合软件及服务的概念。

  2. 开源化 https://linuxfoundation.org/press-release/software-for-open-networking-in-the-cloud-sonic-moves-to-the-linux-foundation/
    SONiC上一个很重要的协议就是FRR,他是从Zebra->Qugga又分出来的一个开源路由协议组件，除了成熟的OSPF, BGP等路由协议外，对于MPLS和SRv6也增加了很多支持，FRR还增加了FPM（Forwading Plane Manager），即转发平面管理，除了支持传统的netlink接口协议，还支持了protobuf协议，更容易集成新的组件。在底层通过redis数据库的订阅发布机制，将事件生产者和消费者联系了起来，可以看看这篇文章的分析。

三. SONiC系统应用

下面是个大互联网公司使用SONiC的情况，基于目前可查找的公开资料汇集。

Microsoft
https://azure.microsoft.com/zh-cn/blog/microsoft-showcases-software-for-open-networking-in-the-cloud-sonic/
https://azure.microsoft.com/zh-cn/blog/sonic-the-networking-switch-software-that-powers-the-microsoft-global-cloud/

LinkedIn
https://www.sdnlab.com/20355.html

Alibaba https://www.sdnlab.com/25694.html

Tencent https://www.sdnlab.com/25761.html

中国电信 https://www.sdnlab.com/25765.html

中国联通 http://www.iitime.com.cn/html/10207/753337.htm

其他厂商
京东 https://www.cnblogs.com/jdclouddeveloper/p/10907298.html

凤凰项目 http://www.opendatacenter.cn/work-group/p-958516783572459522.html
官网介绍：凤凰项目于2017年8月正式发起，目前项目成员包括阿里巴巴、腾讯、百度、移动、联通、京东、电信、中国信息通信研究院。其中阿里巴巴负责社区软件评估及发行版制作，腾讯负责发行版软硬件兼容性，百度负责运维管理体系，中国信通院负责凤凰发行版实验室测试。PS:不知道这个项目目前是否还在运行。

四. SONiC系统基本原理
已经有很多文章分析了SONiC的实现原理，我就不重复别人的工作了，具体可以参考如下几篇文章。

  1. http://www.nfvschool.cn/?cat=8
    这个系列文章分析了syncd组件，LLDP状态交互过程，路由状态交互过程，端口交互，teamd聚合组，内部通信机制和系统架构。

  2. https://rancho333.github.io/2021/04/08/SONiC路由协议简述/
    SONiC路由协议简述，主要针对路由协议流程的分析。

  3. https://www.sdnlab.com/24362.html
    浅谈数据中心SONiC，比较高的视角和架构分析。

  4. https://www.sdnlab.com/23377.html
    从ServerSwitch到SONiC Chassis：数据中心交换机技术的十年探索历程。微软出品的文章，分析了SONiC的历史成长之路。

  5. https://www.sdnlab.com/20309.html （2017）
    Microsoft Azure中的SONiC架构简析,作者毛健炜的个人博客在这里，不过很久不更新，但还可以访问。网站貌似访问不了了，Github上作者个人主页。

  6. https://www.sdnlab.com/20618.html （2018）
    SONiC项目的发展及其相关介绍，算是比较早介绍SONiC的文章了。

SONiC目前主要针对的是盒式交换机设备，对于框式设备的支持还不足，微软（链接1，）和中国电信(链接2)对这方面分别做过相关研究。不同的是微软针对的是Chassis Switch，也就是采用机架结构的switch形态；而中国电信针对是STN机框式设备，一般具备双主控架构，因此需要支持HA(high availability)特性。相同之处在于具有ASIC转发芯片的每个单元/板卡都需要运行一份单独的SONiC系统,优势是：

这样我们用标准的（二层）Clos以太网（Ethernet Network）来连接这些芯片。Clos以太网是当今数据中心的标准架构。这样，网管们可以轻松地把数据中心网络的大 量成熟技术（比如控制平面协议、流控机制和故障诊断技术）和运维管理经验直接移植到Chassis内部网络上来。


（图片来自https://www.sdnlab.com/23377.html）

这里我谈谈自己对于SONiC实现的一些理解。

五. SONiC系统发展

  1. 技术文档

六. 一点想法

七. 参考资料

  1. SONiC架构分析
  2. SONiC架构分析
posted @ 2022-06-25 17:32  LionelGeng  阅读(12390)  评论(0)  编辑  收藏  举报