官网首页 / 资讯 / 现场直播|百度网络架构师刘小军:SR技术在百度的探索与实践_IDC国内资讯_中国IDC圈

现场直播|百度网络架构师刘小军:SR技术在百度的探索与实践_IDC国内资讯_中国IDC圈

2019-01-28 10:32


10月17日,2018年开放数据峰会(Open Data Center Summit 2018,下文简称ODCC)数据中心网络分论坛在北京国际会议中心举办。ODCC关注数据中心产业的各个方面,从国家政策和法规,到地方制度和项目,从产业全局发展到具体技术落地,从尖端热点技术到传统行业推广,从国内到国际,从宏观到微观,全力推动中国数据中心产业发展。

刘小军

以下为百度网络架构师刘小军的演讲实录:

大家好,我是来自百度的刘小军,主要从事网络相关工作,今天分享一下SR技术在百度的探索、实践及应用。

我们2016年就接触了相关的SR技术,凭着一腔工程师对新技术的热情开始学习,2017年的时候我们静下心来开始思考,用SR技术能给我们带来什么,能帮助我们解决哪些问题。2017年下半年和一些设备厂商开始联合研发,2018年上半年我们做了测试,并在海外做了小批量的部署。

接下来我会给大家分享一下我们的应用场景,以及在实施部署的时候我们遇到的困难和挑战,在实践的过程中走过的一些坑。

首先是我们的需求,百度网络大概分成三个圈,最里面的一圈是数据中心,大量的服务器部署在这些数据中心里。中间绿色点和黄色点的一圈是外网骨干网,这张网将各个数据中心的外网出口连接起来,同时和运营商互联,这是百度服务器和互联网用户通信的出口。最外面一圈是访问百度的互联网用户。

数据中心的业务,我们分为两类。一类是对质量特别敏感的,比如搜索、自动驾驶类服务;另一类是对成本比较敏感的,比如网盘、视频类服务。

我们有这么多的出口,有成本昂贵的transit出口,有成本相对便宜的对等peer。怎么才能让质量敏感类服务走时延最低、丢包最少的出口,让成本敏感类服务,走成本最低的出口?要解决这个问题,我们可能要做一个比较复杂的系统。我们发现看起来要解决一个简单的问题,可能要付出很大的代价,至少在这个系统里需要做三个基础模块。一个是AAA,就是权限管理模块,需要做一些权限认证;另外要一个是DB数据库,用于存储网络拓扑、配置数据;最后一个是log日志分析组件。

左边向上的箭头是采集设备信息,向上传给上面的分析模块,根据分析结果我们做一些策略往下推。

Route feed模块采集设备路由变化信息;Flow Analysis分析流量大小,这里不紧紧是分析端口级流量,需要详细分析每个路由前缀的流量;Limits Computer主要采集物理网络的硬件参数,比如网络带宽空闲量、网络跳数、时延等。分析平台会把三种数据做综合分析,去除干扰数据,将有效数据传输给决策层。决策层根据现网的情况,和来自controller的输入,做出调度方案,同时将调度方案发送给路径计算模块。路径计算模块根据决策层传递的调度方案,计算出流量路径,并通过bgp injector注入到设备。

今天我重点要给大家讲的是网络设备上流量调度的实施方案,回到最原始的需求,选择出口的问题。在没有SR技术之前,控制器和所有网络设备建立一个IBGP会话,通过这个控制器下发BGP路由。将期望调度的目标前缀的下一跳修改成你想调度到的出口的网络设备,从而将流量调度到该出口。然而,这个方法并不能解决我们的问题,因为基于前缀的调度,将质量敏感类业务和成本敏感类业务都调度到了这个出口,但这个出口可能质量很好、成本很高,我们满足了质量敏感类业务的需求,却不能满足成本敏感类业务的需求;相反有些出口成本比较低、质量比较差,能满足成本敏感类业务需求,不能满足质量敏感类业务的需求。可见传统的基于BGP路由调度的方法,不能同时满足两类业务的需求。

这个时候正好出现了SR相关技术,2017年的时候我们对SR寄予了特别大的希望来解决这个问题。SR怎么解决呢?对成本类、质量类服务通过dscp标签的方式分别做一个标记,先进行分类;在出口选择的时候,我们为每一个出口设定了一个Community值,以此标记出口。当想调度某个前缀的流量到某个特定的出口时,将该前缀打上该出口的bgp community值即可。这样我们就可以同时match dscp和community,将流量注入到SR隧道中,通过SR隧道将特定业务类型的数据传输到适合该业务的出口。

这个方法看起来非常完美了,那么实际实施中有什么问题吗?首先,摆在我们面前的第一个问题是如何动态操作多厂商设备?我们遵循了google的open config标准,基于YANG模型对网络设备进行配置。然而,各个设备厂商对YANG模型支持力度参差不齐,大量时间花费在沟通上,开发进展缓慢。此外,各厂商对SR-TE引流方式技术也不完全相同,比如cisco采用SR-POLICY、华为采用QPPB,这导致网络配置逻辑上存在一定差异,从而给配置模块引入较大难度。

除此之外,还有一个非常致命的缺陷,就是策略变更时效性低。

传统的网络依靠BGP路由收敛,在故障发生的时候,收敛时间是秒级的,当采用SR标签转发后,故障发生时需要重新下发新的标签,否则数据就会丢弃掉。故障发生——控制器计算——下发新的标签,整个过程需要分钟级,在这一分钟内,意味着业务数据包会丢弃掉,这是业务所不能容忍的。

所以针对这个问题我们最终选择了比较折中的方案,首先我们采用VRF来做业务类型区分,其次,SR隧道我们依然保存,但是仅仅是做SR标签转换,不再重新生成隧道,我们静态配置点到点的隧道。通过控制器向VRF注入BGP的路由,还是采用改变下一跳的方式,将数据引入到相应的SR隧道中,从而实现基于业务类型的流量调度。

最终我们采用这种方式在海外网络做了部署,这种方式显著的优势就是对网络设备的要求降低了,不需要动态修改设备配置,对设备厂商的南向接口依赖降低。但是它依然还是存在着一个很严重的缺陷,就是传统MPLS-TE面临的问题,需要建立点到点的隧道,每个设备的每个VRF都要跟其它所有设备建立隧道,如果有n个设备,每个设备有2个VRF,就需要建立2(n-1)个隧道。大量的隧道维护额外增加了运维人员的工作。

在未来我们计划将路由器的VRF功能和引流的功能迁移到NFV网关上。在百度,所有的南北向流量都会经过自研的NFV网关,那么我们就可以在NFV网关设备上基于流进行SR头部封装,实现基于服务的出口调度。中间的网络设备只做SR标签转发,不再做复杂的引流工作。

这个方案我们目前正在研讨的过程中,预计在2019年会按这种方式去做。这样做了之后整网络设备环境会非常干净,网络运维会变得更简单。

这是我的分享,谢谢。



服务支持

我们珍惜您每一次在线询盘,有问必答,用专业的态度,贴心的服务。

让您真正感受到我们的与众不同!