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

腾讯技术工程 2020-09-17 18:00

一、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.

推荐阅读