腾讯自研交换机系统优化之路

一、Tencent NOS概述

SONiC is an open source network operating system based on Linux that runs on switches from multiple vendors and ASICs. SONiC offers a full-suite of network functionality, like BGP and RDMA, that has been production-hardened in the data centers of some of the largest cloud-service providers. It offers teams the flexibility to create the network solutions they need while leveraging the collective strength of a large ecosystem and community.

摘自：

https://www.opencompute.org/projects/sonic

腾讯自研交换机采用白盒硬件 + 自研NOS模式， 基于SONiC( Software for Open Networking in the Cloud)深度自研的Tencent NOS，致力于打造高性能、高可靠、智能化的自主可控网络业务系统，在监控、管理、控制、转发层面对系统做了很多重要的优化。

图1. 自主可控DCN

Tencent NOS继承了SONiC的主要优点，包括：

1. Linux内核：相比传统交换机使用的嵌入式系统专用内核，Linux成熟的工具、良好的生态给交换机的开发和维护带来很好的体验；

2. 中央数据库：使用redis数据库作为系统的数据总线，组件之间通过对数据库的发布/订阅进行消息通信，应用只需发布/订阅他们关注的数据而不用关注功能无关的实现细节，有效避免了组件之间的耦合；

3. 容器化部署：用户进程按业务内聚原则被部署在docker中，功能可以独立发布和测试，并且能够在不停机的情况下完成应用的部署或升级，实现快速迭代；

图2. Tencent NOS Architecture

受益于系统良好的架构，APP化的网络应用可以在Tencent NOS上快速验证和部署，为了更好的支撑业务，腾讯自研交换机与网管、运维、架构等团队一起做了大量的工作。

二、监控平面创新

随着业务的蓬勃发展，大数据、AI和RDMA（Remote Direct Memory Access）等技术已经获得广泛应用。数据中心流量持续快速增长的同时，对网络运营能力也提出了越来越大的挑战。如何准确评估网络质量？如何网络故障快速定位？如何在业务感知前消除网络故障？对于这些问题，我们将通过网络监控平面的创新来寻找答案。

2.1  Netsense

图3. Network failures are the norm rather than exception

在大型数据中心网络中，故障几乎无法避免。随着业务不断发展，对网络故障的定位效率要求越来越高。传统数据中心通常使用pingmesh等方式进行故障定位，但存在限制：

1. pingmesh只能检测两个网元之间是否可达，无法准确定位故障设备和链路；

2. pingmesh的算法效率对全网拓扑的覆盖性能难以满足需求；

3. 探测报文无法模拟业务报文在网络中的真实转发路径、队列等；

为了解决这些问题，我们开发了Netsense功能，通过控制器上部署的算法构造合理的探测矩阵，路径覆盖效率大大提升。整体探测过程如下:

1. 控制器通过算法确认探测目标节点List，通告Agent报文信息并发起探测；

2. 部署在接入交换机上的Agent根据控制器通告的信息构造探测报文并向目标节点发出探测流，探测报文将通过源节点的芯片流水线进行转发，并覆盖业务流量可能经过所有端口/队列；

3. 探测报文在网络中逐条进行转发，最终回到探测源节点。源节点将丢包率高或延迟大的探测流信息上报控制器；

4. 控制器根据异常探测流经过的设备交叉匹配定位出故障设备/链路；

图4. Netsense方案说明

在完成netsense一期部署后，网络的故障定位效率已经得到明显改善：

1. 快速精准：1秒内发现故障，并精确定位故障节点或故障链路；

2. 方式灵活：可自由调整监控覆盖范围，支持高精度背景流实时探测和指定节点间的探测；

3. 全面覆盖：可检出包括路由黑洞、表项翻转、ACL过滤、端口单通、转发延迟高等多种异常；

2.2  MOD

传统交换机对于运维人员来说一直是黑盒，一旦发生丢包，只能由专业技术人员通过复杂的调试定位原因。为避免影响业务，运维人员通常选择对故障设备进行隔离，这样一来，就容易破坏现场，无法重现的故障不能得到及时解决，成为网络中的隐患。

腾讯自研交换机基于主流芯片开发支持MOD功能，可实时捕获芯片常见的丢包事件（如路由未命中、MTU错误等），并将发生丢包的设备信息和丢包原因上送监控服务器，系统可据此快速做出应对措施。针对芯片无法上报MOD事件的丢包原因，还可通过Telemetry实现高精度的采集并通告网络监控平台，实现对芯片转发面丢包的全面覆盖。

图5. Mirror on Drop

2.3  立体监控方案

除了上面提到的netsense和MOD，我们还支持INT，telemetry和高精度BFD。通过这些功能的有机组合，基于腾讯自研交换机和网络监控系统打造了一套立体监控方案，全面覆盖网络故障关键要素：

1. 谁丢包了：MOD上报丢包业务，INT上报延时增大

2. 丢在哪里：Netsense探测故障节点/链路，BFD上报会话状态

3. 为什么丢：MOD上报丢包原因，Telemetry高精度采集设备信息

图6. 立体监控方案

依托于立体监控方案提供的平台能力，我们可以实时有效地监控网络状态，准确评估网络质量，发生故障的节点/链路以及造成故障的原因能够被快速且精准的定位。很快，我们将会拥有一个具备故障快速自愈+精确调度能力的智能化网络业务系统。

三、管理平面突破

2019年，腾讯基础设施服务能力进入“双百时代”（服务器数量超过100W，与此同时，腾讯云峰值带宽突破100T），服务和流量迈入全球第一梯队。量变引发质变，海量设备规模对网络管理平面提出了新的要求：

1. 网络设备的管理需要标准化/自动化；

2. 网络系统需要能够频繁交付，持续部署；

3. 交换机/服务器应该共享运营生态；

3.1  统一化管理平台

通过CLI下配置+SNMP采集信息的手段，经过长期的实践已经证明，无论在性能、效率、自动化能力上都无法很好的满足需求。

1. 性能差：SNMP信息采集频率1-5分钟级，无法满足RDMA场景秒级/毫秒级需求；

2. 效率低：执行一条CLI命令普遍需要100-200ms，且无法执行批量配置下发；

3. 不通用：不同厂商的CLI实现差异和私有MIB带来额外的适配工作；

网络运维系统对交换机的管理需求可以抽象成Get（主动获取状态和配置信息，如BGP配置/接口流量/Buffer队列长度/丢包等等）、Set（配置下发，如缓存水限/端口shutdown等日常的业务变更动作）、Push（设备端主动上报的信息，包括周期性推送的日常监控信息和触发式推送的关键事件等）。

图7. 高性能框架

为满足大规模部署及自动化运维的需求，秉承“对人友好，对机器更友好”的宗旨，我们基于高性能框架打造的统一化管理平台：

1. 使用统一YANG模型，无需适配CLI或MIB；

2. 使用业界成熟的gRPC框架，性能和安全性都有保证;

3. 使用更适合机器识别的json替代CLI字符串，支持批量配置下发；

3.2  全方位无损升级

DevOps是运营的一个趋势，在传统交换机上，版本发布是一项涉及多个团队、压力很大、风险很高的活动。这种模式显然难以令人满意——我们希望网络具备持续交付和部署的能力，以便我们可以满足运营人员要求更好的可靠性和安全性的同时，更快更好的发布特性以满足快速发展的业务带来的复杂多变的需求。

能够做到这一点，关键的技术基础便是无损升级。为了提升系统可用性，从针对函数级别缺陷修复的hotfix技术，到进程热补丁，再到docker级别的warm-restart和系统级warm-reboot。腾讯自研交换机在无损升级方面，做了大量的工作，以便我们可以放心地在生产环境中对系统的任何一个角落进行升级。

现在，我们甚至可以在控制面和转发面完全不中断的情况下，对SDK/SAI进行修复/升级。网络业务系统的升级，变得像手机上的APP升级一样容易。我们可以通过更频繁的发布来减少变更范围，由于每次部署不会对生产系统造成巨大影响，各项网络应用程序可以快速迭代，以平滑的速率逐渐生长。

图8. 全方位无损升级

3.3  管控分离的硬件设计

传统交换机在设备异常无法登陆的情况下，只能通过管理人员进入机房执行下电操作进行隔离/恢复，这会导致长时间的业务中断。腾讯自研交换机在硬件设计引入BMC对设备进行管理，将管理通道与控制通道分离，交换机与服务器共享运营生态，真正做到Switch-as-a-Server。

图9. 管控分离的硬件设计

四、控制/转发平面优化

对于传统的控制平面和转发平面，我们只有2个目标：高性能+高可靠。

4.1  高精度BFD

图10. Linux kernel bypass

作为SONiC默认使用的路由协议组件包，FRR从6.0版本开始支持BFD特性。一直以来，软件实现的BFD性能，在园区互联等需要大量会话的场景都显得难以胜任，往往只能通过降低检测精度进行妥协。

硬件BFD方案是一个可选的方案，但其过于依赖芯片实现，一方面短期内难以成熟，另一方面给特性的跨平台/产品迁移能力也带来很大限制。Tencent NOS通过独立于Linux内核的旁路通道，配合性能强大的X86 CPU，实现软件BFD方案检测精度堪比硬件BFD。

拥有Linux内核旁路通道不仅在高精度BFD上给我们带来帮助，在未来的诸多场景中，强大的系统控制面帧收发能力也将让我们持续受益。

4.2  集中式路由算法

BGP目前已经是构建数据中心Underlay网络的首选路由协议，相比传统采用IGP协议构建的网络，在可靠性、性能以及横向扩展（Scale-out）能力等诸多方面都有明显优势。但由于协议天然的局限性，BGP在跨跳故障收敛性能方面一直表现不佳。

腾讯自研交换机团队与湖南大学合作推出的集中式路由算法，可以有效改善数据中心网络的故障收敛性能。基于已经明确的网络架构，我们可以有规律的组织链路和路径，建立链路——路径的映射关系，在链路表中记录其影响的路径范围。当链路状态发生变化时，通过链路与路径的映射关系，快速找到所有受影响的路径，并更新相关的路由信息。

通过部署集中式路由算法，我们在对现有网络架构不做任何修改的情况下，成功将跨跳BGP收敛性能从秒级提升到200ms以内。未来，基于集中式路由算法对拓扑的感知能力，我们还可以结合立体监控平台，基于流做更为精细化的调度。

图11. 集中式算法部署

4.3  网关硬件卸载

随着腾讯云快速发展，未来每个region需要承载千万级VPC接入，全网路由规格数以亿计。与此同时，公网出口带宽也已来到百T级别。超大规格路由表，超高转发性能，需要软硬件结合来同时满足业务的灵活性，网络的扩展性和成本之间的平衡。

腾讯自研交换机已经扩展转发面支持VXLAN功能，系统识别到大象流后，控制器将会下发流表到交换机对流量进行卸载，通过硬件加速来提升系统整体的转发性能和吞吐能力。

图12. 网关硬件卸载总体架构

五、展望未来

目前，腾讯自研交换机稳定运行近一年，大幅提升了网络系统的可靠性和运营效率，并在疫情期间承载腾讯云关键业务，经受住了考验。自研交换机的大规模部署，成功构建了一张自主可控的数据中心网络。

2020年7月，基于新一代可编程芯片开发的200G/400G交换机硬件完成点灯，通过芯片可编程能力的扩展，我们将具备在更为复杂的网关和DCI场景提供服务的能力。随着网络端到端自研计划的逐步推进，腾讯自研交换机将会出现在越来越多的场景，为云而生的腾讯自研网络会在未来带给我们更多惊喜。

参考资料：

• SONiC architecture -https://github.com/Azure/SONiC/wiki/Architecture

• Peng, Yanghua, et al. "deTector: a topology-aware monitoring system for data center networks." 2017 USENIX Annual Technical Conference (USENIX ATC 17). 2017.

• Primus: Fast and Robust Centralized Routing for Large-scale Data Center Networks.