9月19日，2020 SONiC产业生态研讨会顺利召开，会上星融元数据技术有限公司副总裁李明玉给大家分享了《企业级SONiC创新实践》。
李明玉的演讲主要分为三个部分：开源NOS的选择、企业级的SONiC和一些思考。
开源NOS的选择
微软在2015年和2016年分别发布了SAI和SONiC，目前SONiC产业和生态发展日趋繁荣，成员数量已经超过了60家。
作为面向开放网络的操作系统，SONiC以解耦和敏捷为理念，包括以下几个方面的目标：
- 软硬件组件自由选择
- 开放&模块化的软件架构
- 敏捷化的技术革新
- DevOps方面
李明玉表示，系统架构+抽象接口+协议栈，是网络操作系统目标达成的关键。
不过SONiC的设计过程也是一波三折。
2015年，惠普开源了OpenSwitch（OPS）网络操作系统，可以说这是第一个面向开放网络架构的开源网络操作系统（支持SAI）。OpenSwitch的架构中间是数据库，左边是控制平面和管理平面，右边是switchd，最下面是标准的Linux。从架构方面可以看到，SONiC的架构跟OpenSwitch实际上是非常类似的。
但是好的理念和架构，未必带来成功的NOS。OPS采用的是典型的开源项目模式，由惠普发起，提供一个初始版本的代码，希望通过吸引设计成员投入开发并壮大，但参与社区的成员很少，项目各种问题没人解决。到了2016年，OPS项目基本就关闭了。
随后，OPS项目被戴尔重新接管并更名为OPX，采用厂商带着若干硬件和芯片供应商做开源项目的模式，验证了OPS最初的框架，但是现在也基本上不发展了。
接着，云厂商主导模式出现了，微软既是开发者，又是NOS用户，自身有技术能力，也有动力。加上戴尔作为SONiC的初始合作方，把自己的基础代码贡献给了SONiC，可以说有理念、有架构、有落地，才有了今天SONiC的壮大。
近年来，主流开源平台的架构迅速迭代，此外其他核心组件变化也很大，包括抽象接口从早期的厂商绑定到SAI，协议栈从Quagga到GoBGP到FRR。传统的商用操作系统迭代周期一般是58年，而开源的NOS主要组件平均12年就有一个大的迭代，这对生态成员的技术能力和产品的稳定也是一种不小的挑战。
2014年，星融发布了AsterNOS 1.0，那时候业界还没有开放网络的概念，AsterNOS 1.0是基于OpenWRT开发的。2016年，星融启动了基于OPS的新产品开发AsterNOS 2.0。随着OPS终止发展，在2017年的时候，星融基于SONiC开发了AsterNOS 3.0。
李明玉表示，围绕开源做商业产品去满足企业用户的不同需求并不容易，从系统选择到持续快速迭代，对技术要求都很高，需要在专业领域有多方面的积累。
企业级SONiC的创新实践
李明玉指出，云厂商只是把SONiC作为在自己生产环境的操作系统，而AsterNOS 3.0作为企业级产品，是基于SONiC的商业发行版， 目标是服务于各行业的客户，两者技术体系一脉相承，但所以产品理念方面会有所区别，主要包括4个方面的要素：
第一，以客户需求为导向：面向不同行业使用场景，理解不同客户的需求差异性，合理规划，快速响应；
第二，品质稳定：友好的使用体验，完善的质量保证机制，在全生命周期交付中质量一致；
第三，兼容性：版本迭代上特性要向前兼容，面对不同芯片平台，要合理兼顾芯片差异化和特性兼容性；
第四，持续服务：组织有持续的交付能力和服务能力
在切换到SONiC平台后，星融首先面对的一个大的行业特性就是网络虚拟化的需求，也就是网络Overlay，主要包括VXLAN & EVPN的一些技术
下图展示了VXLAN 和 EVPN的趋势，以及商业的网络虚拟化解决方案（思科和开源解决方案）的关注趋势。
可以看到，行业对网络Overlay的关注是持续增加的，但是开源解决方案的关注度一直不高，主要原因还是开源解决方案迟迟没有跟上，满足不了用户的实际需求。
从技术发展来说，芯片和标准是网络虚拟化的技术基础。VXLAN 在2011年的时候被提出，到了2014年，硬件和RFC就已经基本完备了，思科在2014年的时候就已经发布了全系列的软硬件网络Overlay解决方案。2015-2017年，国内的很多厂商，例如新华三、华为也相继发布了类似的解决方案。
在开源方面，从数据平面到控制平面的发展都非常缓慢，FRR也是因为这个原因，在2017年从Quagga forked出来独立发展。SONiC社区对于网络Overlay当时是有这方面的规划的，但是直到2018年才刚开始支持VXLAN数据平面转发，2019年才把FRR纳入协议栈。
李明玉指出，网络Overlay在社区进展缓慢，直到现在，L2VXLAN、隧道管理、EVPN等特性仍不完善。
2018年，SONiC社区自身尚有许多不完善的地方： VRF/VXLAN转发支持的非常弱；SONiC本身不支持EVPN；SONiC不支持FRR；FRR对EVPN支持不完善；涉及主要协议模块VXLAN、BGP（MP-BGP）、VRF、ARP&ND。在这个背景下，星融要基于社区SONiC开发网络overlay要面临很大的挑战，包括数据平面：需要完善支持VXLAN，并实现芯片转发；控制平面：基于FRR，支持BGP-EVPN，以及芯片的VXLAN隧道管理；多平台：支持主流交换芯片的硬件平台；支持REST接口；便于未来和社区版本同步。
下图展示了AsterNOS的VXLAN/EVPN方案架构，从右到左可以简单地看成4个部分：
第一部分是swss，是SONiC的基本设计模式，包括
- 三件套：
evpnmgrd：主要负责静态数据的管理
evpnsyncd：主要负责动态数据的管理
evpnorch：主要负责ASIC_DB数据的管理
第二部分是BGP模块，除了要响应CONFIG_DB针对EVPN的配置，还需要与EVPN三件套配合完成三类路由宣告和学习，主要包括：
- EVPN宣告
隧道信息
主机信息
- EVPN学习
L2/L3 隧道
FDB
路由
第三部分是ARP代答，parpd/pndpd实现overlay ARP请求/邻居请求的代答。
第四部分是不同交换芯片厂家SDK的适配。
李明玉表示，目前AsterNOS和社区版SONiC相比更为完善，通过这个项目也意识到了涉及到芯片强相关的特性不能够完全依赖厂商的SAI实现。要想做到特性的完善，还需要对底层进行很多修改。另一方面，由于项目的开发周期非常长，需要在开发的同时关注社区的变化，有必要的话及时同步。
2018年，AsterNOS先于社区支持REST API，整个方案是一个独立的容器，最终实现了系统里面所有模块的所有REST API接口。李明玉指出，在很多需要先于社区开发特性设计的情况下，要预先考虑好后续怎么跟社区进行融合。
2019年底，社区发布了一套支持REST和命令行的mgmt框架。AsterNOS与mgmt的融合使得两套框架共存，统一由Ngnix根据URL分发给mgmt框架。并且在后续新的开发中也会尽量基于社区的mgmt框架，逐渐把AsterNOS已经开发的REST接口往新的框架上移植，这样的好处是可以更好地兼容后续的社区版本，同时也避免了社区分叉越来越远。
李明玉总结了一些实践方面得到的经验，
- 结合SONiC社区路标，合理规划，自研还是同步社区
- 自研特性要在方案上考虑未来如何与社区方案融合
- 不要忽视芯片SDK适配的风险和工作量，特别是芯片强相关特性
- 长周期项目，注意关注社区相关动态，及时同步，避免分叉
- 合理制定企业版和社区版的发行和同步策略
最重要的是要和社区持续共同促进，共同发展。
一些思考
开源NOS给行业的创新提供了技术基础，各家云计算公司也搭建了自己的云计算中心网络，形成了开放解耦的网络解决方案，从而在新特性落地方面以及新方案的快速验证方面都大大提高了效率，更好的满足了业务的需求。但是，新的模式也会遇到一些新的问题。
李明玉表示，新的模式指的就是网络产品和解决方案的交付模式，这跟传统模式相比发生了变化。在传统网络解决方案的交付中，技术创新和价值创造简单看就是一个链式创新的过程。新技术从芯片供应商传递到设备供应商，然后设备供应商结合对业务的理解，把这些技术形成差异的、有竞争力的产品和解决方案交付给最终用户。在这个过程中的话，设备商起到了一个桥梁的作用。而在开放网络架构下，由于软硬件的解耦，各个环节的角色都要直接参与到整个网络解决方案的交付过程中，整个交付模式就变成了一个网状的模式。
通过和合作伙伴和用户的交流，李明玉提出了几点思考。
思考一：开源是否让交付网络方案变得更容易？
李明玉表示，想用好开源NOS不容易，但这正是企业级SONiC需要解决的问题，友好的使用体验很重要。针对SONiC的使用来说，大部分用户都是直接使用，很少进行修改。真正有能力修改的、能够把修改贡献的到社区的其实是少数。大部分用户所能使用到的功能集其实是受限的，遇到质量/性能/支持/文档等问题，只能等开源软件自身慢慢完善。
思考二：行业用户的需求如何保障？
实际上，SONiC在路标规划、项目管理和质量保证方面较一般的开源项目有很大的改进，但是作为面向企业客户的产品，也面临几个问题。例如，企业个性化的需求很难被接纳，社区在设计阶段讨论方案和评审的周期非常长，以及Pull request时间不可控等等。
思考三：硬件/芯片供应商面临更多的新任务
以往芯片供应商的定位是做好有竞争力的芯片，而从芯片SDK适配到厂家NOS的工作是由设备制造商自己完成的。开放网络之后，即便是基于SAI，芯片供应商还是要做更多的工作。以前芯片供应商只需要专注做芯片，现在还要结合实际业务去做软件开发。同时，各厂家对SAI的理解也不一致，接口的完成度差别也很大，导致不同特性在不同芯片平台上存在很多差异。
基于这些思考，李明玉提出，新型模式需要一种新型的技术供应商：服务全生态-专业、全面、可靠的合作伙伴，交付企业级产品和服务。
主要体现在三个方面：
- 开源开放的合作理念，和社区、合作伙伴相互促进，共同发展，共同成长；
- 专业、全面、可靠的团队，网络设备开发是相对小众的技术领域，需要专业的软硬件的技能、开发经验和管理能力；
- 全面的支持能力，对行业需求的理解，驾驭硬件/芯片的设计开发，对开源社区/生态贡献。
最后，李明玉展示了AsterNOS的软件架构以及全系列硬件平台和解决方案，并表示，通过多年的积累，在SONiC生态实践的探索道路上，星融始终是一支重要的可以依赖的力量。星融希望能够把完善的软件架构、完备的硬件系列和完整的解决方案能力开放给社区生态，通过持续的技术创新，服务好社区和合作伙伴，共同构建开放的云网络架构，做好底层的基础设施建设。
