面对高昂的专线成本和复杂的业务需求,每一个优秀的网络建设运维团队都在探索更先进的技术方案,在保证网络SLA的基础上,不断提高带宽利用率,以构建低成本、高可用的网络。当前主流的流量调度系统,一般是通过SDN平台实现流量自动调度,在保证服务质量的基础上,把高成本的洲际、省际专线的利用率不断提升,从而达到节省带宽成本的目的。爱奇艺网络团队长期跟踪研究RSVP、SR-TE等各种流量调度技术方案,并根据网络资源和业务需求情况,落地了一套基于业务优先级的全网流量自动调度系统,不断实践团队对高可用和低成本的极致追求,最终实现了分钟级自动调度,且链路可用率从99.524%提升到99.9999%。
爱奇艺全网流量自动调度系统分为B1(外网)调度和B2(内网)调度两部分,这里主要分享B2自动流量调度系统。爱奇艺B2网络采用省际骨干网和省内城域网两级组网架构。骨干网分为骨干核心层、骨干接入层;城域网则为树状结构接到骨干网。全网采用BGP协议,骨干核心节点、骨干接入节点、城域网均设置独立的AS,为流量调度提供良好的架构基础。
流量调度的底层逻辑并不复杂:流量突发是动态的、而带宽设置是相对静态的。流量调度要做的就是把超过阈值的流量,调度到利用率相对较低的链路上,避免局部流量突增影响业务可用性。
方案的关键点是,我们需要根据不同的网络架构,选择合适的流量调度实现方案。省际骨干网为网状组网,流量模型复杂,转发路径成环的风险高。省际骨干网多级AS的组网架构,提供了丰富的路由调度手段,所以在省际骨干网中,采用BGP路由策略实现流量调度;而城域网组架构、流量模型相对简单,但是希望在城域网实现对单一业务,甚至单一主机的流量控制,所以选择策略路由实现流量调度。
图2-1 全网调度示意图
骨干网调度方案
流量调度系统由监控告警、信息收集、信息整理、调度分析、调度下发共五个模块组成,架构图如下:
图2-2 调度逻辑架构
监控告警:
信息收集:
信息整理:
调度分析:
调度下发:
具体调度过程:
图3 调度流程
调度邮件通知:
调度:
回退:
城域网实现方案
城域网的实现方案与骨干网相似,主要区别在于拓扑计算通过Dijkstra算法;调度方式通过向设备下发策略路由。可实现城域网内基于五元组的流量调度,比骨干网更加精细化。
精确性
精确性是流量调度方案可行的前提:包括现网流量精确统计、对调度规模的精确评估。
现网流量精确统计:再如,sFlow采样反算的流量存在误差,所以我们通过SWC基于SNMP拿到的流量和sFlow反算的总流量计算出一个比例,在用此比例乘以NTA中的各目的地址段流量来计算目的地址段的实际流量;当然,这种算法仅限于流量未达到100%的情况,如果流量超过100%,SNMP采集的流量就不准确了,我们会通过sFlow的当前和历史情况分析是否有地址段严重突发,并进行相应的阻塞或降级处理。
调度规模精确评估:网络中除了单一路径的拥塞、延迟及丢包,当一个方向有多个平面负载,且一个平面又有多条链路负载的时候,出现某些链路流量跑高该如何计算?我们通过SDN平台实时感知具体的网络拓扑结构、协议组成。基于网络平面进行流量分析,支持交叉互联情况下的多平面、正反方向分析,同时监控可用带宽的动态变化、中断平面、中断接口数等,分析多链路、多平面负载情况。通过这些算法,综合判断、计算出准确合理的可用链路和调度流量。
实时性
除了准确性,实时性在流量调度中也是非常重要的。对于sFlow的采样和分析,为了提高准确性我们需要调高采样比,同时随着覆盖DC和网络设备越来越广,导致每天仅采集的数据便达到数十T。要满足调度的实时性,就必须能对海量的数据流进行实时分析。这对我们最早的分析架构提出了挑战,数据延时越来越大。
为了解决这个问题,我们调整了架构:前端负载到多台flow-agent,将数据流打标从Logstash调整到Vflow,在解包的同时就打好相关标签,分析后入一级Kafka,对接Flink流数据处理,对数据进行加工统计,汇入到ES集群和二级Kafka,最终实现延时在分钟内的业务数据查询。
图3-1 NTA逻辑架构
另外,通过对SWC流量监控组件升级,针对端口的OID增加更快频率的并发SNMP扫描,将SNMP流量统计周期提升到1分钟,同时在支持telemetry的设备上改用telemetry监控来实现秒级的端口流量统计。由于节点间是多端口多平面互联,而流数据可能先后到达分析平台,而我们需要统计各端口ingress和egress流量总和。这时候有两种解决办法,一种采用轮询算法,等待固定周期后,我们查看缓存数据是否到齐,是否触发调度阈值;另外一种基于epoll思想机制,给每条实时的数据流提供poll方法,驱动检测阈值。显然方法一的调度实时性,取决于轮询的周期,而方法二让我们能实时的驱动调度,所以我们选择方法二来实现实时计算。
安全性
自动调度虽然可以更快的解决问题,但如何保证自动调度不会引发新的问题,我们也对有可能产生的问题做了相应的规避方案,如路由策略方案中我们制定骨干网路由策略规范,所有设备统一的预置策略;策略路由方案中,规定发生过一次调度的设备不会再次下发策略;备份链路流量跑高优先进行调度回退等。
可用性
由于整个系统都是由大量数据来驱动,而数据的传输是非常依赖网络的健壮性的。这里便出现了矛盾,本来调度是来解决网络问题,却因为网络问题使调度系统失去了感知,导致系统形同虚设。事实上,在系统的迭代过程中,出现过某条专线1s内被打满,导致监控数据出现延迟到达,导致调度失效,甚至ssh无法登录对应的网络设备。
图3-2
针对以上问题我们需要把数据单元、计算单元下沉到区域内,调度下发模块异地分布式部署;增加独立的调度执行agent;支持rpc服务轮询, 确保有效ssh登录;调度分析模块异地部署;对接异地swc数据消费;同时提高网络设备管理监控相关协议的Qos等级。以此来规避网络问题导致的调度失效。
图5 SWC逻辑架构
爱奇艺流量自动调度系统实现了基于IP地址段并匹配业务优先级的自动流量。由自研SDN平台统一管理,进行实时业务保障,也可人工介入按需进行流量调整。流量调度系统当前已运行一年时间,自动规避流量突发、链路中断等影响业务可用性的故障时长超过2000分钟。实现了:
当前的流量调度实现方案是基于IP或路由进行调度,无法完全基于业务进行调度。我们正在研究通过可编程交换机和智能网卡等新硬件来实现业务和网络的联动,使网络设备能更好的识别业务,从而实现基于业务的调度。
由于当前网络为全交换机组网,功能和性能受限,所以实现调度所用方案和技术都并非最优,并且无法覆盖所有场景,我们也在研究通过增加服务器和路由器来实现SR方式的流量调度作为扩展,当前已小规模部署,敬请关注后续介绍。同时也期待各位读者有问题或更优方案与我们分享交流
注释:
①SWC:通过SNMP采集设备信息的系统。
②NTA:通过sFlow采集的网络流量进行分析、打标、归类等操作的系统。
……