基于R.M.B的下一代网管

"鹅厂网事"由深圳市腾讯计算机系统有限公司技术工程事业群网络平台部运营,我们希望与业界各位志同道合的伙伴交流切磋最新的网络、服务器行业动态信息,同时分享腾讯在网络与服务器领域,规划、运营、研发、服务等层面的实战干货,期待与您的共同成长。

网络平台部以构建敏捷、弹性、低成本的业界领先海量互联网云计算服务平台,为支撑腾讯公司业务持续发展,为业务建立竞争优势、构建行业健康生态而持续贡献价值!

背景

网管系统存在的价值,在于其自动化、智能化管理大型网络的能力。随着网络规模的增长,我们经历过标准网络架构的批量自动化建设、海量状态采集和监控、海量告警收敛的时代;再后来,业务需求的多样性导致网络复杂度增加以及精细化运营需求井喷,催生了NetDevOps发展,使得网工可以快速灵活定制自己的应用;AI技术的兴起,更让NetAIOps成为新的热点。

然而,随着这些新技术、新方法的应用,我们可以说网络管理的自动化水平更高了,但是网络管理面临的挑战似乎并没有收敛,不断有更新更深层面的问题浮出水面。

比如在规划建设阶段,一个新网络架构设计出来,想要实现自动化建设,仍然需要很多人工定制化适配,例如:新架构的互联方式需要由交叉改为口字,架构师需要将所有具体连接穷举到系统上;又例如,新架构要求对所有端口开启BFD特性,架构师需要穷举出该架构的所有端口,然后对每个端口写一遍开启BFD的命令;诸如此类的人工强依赖必然限制了建设质量效率的水平。

又比如在网络运营阶段,越来越多的指标被采集,流量/包量/错包/队列/缓存等,甚至可以使用AI算法搞定某些单指标的自动监控,但是这些单指标的异常,并不能直观看到问题根因,例如:我们用AI搞定了流量变化的自动监控,却不清楚A到B直通流量的绕行,仅仅是因为千里之外的“无关”设备被敲错一条命令行。我们有了很多监控、有了大量运营工具,但在复杂故障出现时,仍然时常发现力有未逮。

问题分析

为什么会这样?是因为网络结构太复杂、常变化?还是因为系统还不够”聪明”?前者是客观条件,后者并不能为我们指明方向。究其根因,还是因为网管系统对网络不理解,系统只是起了连接网工与设备的通道作用,又或者针对某些固定场景,提供执行某些具体动作的能力,控制权还在人手中。在规划和建设网络时,因为系统不理解语义,需要人工将网络架构设计(HLD)转换为网络能够理解的LLD(具体的连接关系、命令行等),然后交由系统执行,因为HLD变化而导致LLD改变的工作量,呈几何级数增长(一如前述交叉改口字、开启BFD的例子);在运营网络时,由于系统缺乏对网络全局的理解,无法从各种表象中找到问题根因,而经常变化的网络架构无疑对问题的定位和分析雪上加霜。

解决思路

如何解决这个问题?不妨设想一下两个场景:

 规划建设阶段,架构师只需要关注抽象的网络设计(HLD),系统能够识别这些抽象设计,并根据实际需求具象化为可落地的建设方案(LLD),以此来应对需求的多样性;

◆  网络运营阶段,系统基于网络的全量数据,能够智能分析各种状态和行为之间的联系,找出隐患或问题,并自动解决、规避,纵使架构发生变化,系统能够理解这些变化并自适应之。

我们继续往下看,如何才能具备这样的能力:

◆  首先需要有一套方法,能够结构化的描述整个网络的组成元素及相互关系,从网络到网元、机框、槽位、端口,乃至配置、状态等,都能够结构化描述,使得系统能理解网络语义;

◆  其次需要有一颗智脑,一方面可以理解架构师的意图,并将意图转换为可落地的方案,另一方面则能够从各种网络表象的变化中,分析出真正的隐患或问题

◆  最后还要有一系列的自动化工具,供系统根据分析的结论,实现具体的处理逻辑,并且最终应用到网络中。

这些自动化”触手”,我们称之为Robot;这套使得系统能理解网络语义的方法,我们称之为建模,建模最终生成的是系统可以理解的结构化模型(Model);能够识别用户意图,具备分析问题能力的智脑,我们称之为Brain;合在一起,就是今天要探讨的R.M.B。

图1 网管整体框架图

1.【Model篇】

Model是一套可以结构化描述网络的模型,网络通常分为物理部分和逻辑部分,物理指组成网络的各种硬件(机框、单板、光模块、线缆等),逻辑指各种软件特性的配置(路由协议、管理特性、QoS等),所以Model可以分为硬件模型配置模型,以及运行过程中的状态模型

1.1【硬件模型】

硬件模型包含两部分,首先是描述如何组网,然后是组网的网元具体由哪些硬件实现。

1.1.1【如何组网】

可以用一种抽象的方式来描述如何组网:

◆  有哪些架构角色,例如:一个IDC内网,是接入/核心两层,还是需要接入/汇聚/核心三层,每种架构角色的最大数量;

◆  各架构角色之间应该如何互联,例如:和哪些架构角色互联,互联单端口带宽,最大链路数,连接方式用口字还是交叉,链路数需要满足2的n次方还是等分带宽,对底层传输的容灾依赖等;

1.1.2【硬件实现】

通过设计组网的步骤,得到了对每台设备的端口数量和带宽需求,根据这些需求,需要找到对应的硬件实现,主要包括:

◆  有哪些硬件物料(机框、板卡、光模块等);

◆  各物料之间的配套关系;

◆  端口功能区的规划,即:哪些端口用于连接哪些架构角色,例如:接入设备的45~48号端口组成“To 内网核心”功能区。图3展示了功能区的设计,每种颜色对应一种功能区。

图2 硬件物料及配套关系定义

图3 端口功能区规划

至此,一款架构角色的硬件模型构建完成。

1.2【配置模型】

配置模型主要描述三个内容:

◆  一台设备要完成设计的网络功能,需要配置哪些特性

◆  这些特性需要在哪些对象上开启,对象可以是物理的(例如:某块板卡/某个端口),也可以是逻辑的(例如:某个BGP邻居/某个捆绑口);

◆  这些特性具体的值,例如:IP地址是多少,MTU配多少等;

网络发展到今天,各厂商的特性其实大同小异,使得一套统一的配置模型成为可能,一如OpenConfig组织提出的 OpenConfig YANG Model,这套Model描述了一个网络设备应该有哪些对象,有哪些特性,这些对象/特性应该叫什么名称,是怎样的数据类型,以及对象和对象,对象和特性之间的关系。

配置建模的构建,分为如下几步:

◆  架构师基于全量的Model(例如 OpenConfig YANG Model),结合实际需求,选择该架构需要使用哪些特性

◆  然后是架构师定义这些特性需要在哪些对象上开启,和定义硬件模型类似,使用枚举并不是一种好的方法,需要对这些对象进行抽象定义,物理对象的抽象定义可以复用硬件模型中的抽象,例如:类似 “To MAN的所有端口”这种定义,逻辑对象其实也可以用类似的方法定义,例如:“所有互联IP”,“所有BGP邻居”,需要有一个专门的模块来管理这些逻辑对象,例如:IP管理、BGP邻居管理等。

◆  第三步,架构师定义这些特性的值,可以支持直接赋值,但更多的场景是定义赋值的方法,因为很多值在具体的建设方案确定以后才能生成,例如:某台设备的管理IP、某个端口的描述(通常是对端设备名+端口名的组合)等。

图4 BGP配置模型

1.3【状态模型】

状态模型主要描述不同的网络对象,能提供哪些状态监控的能力,由于OpenConfig YANG Model中描述了网络对象之间的关系,所以基于这套模型,将状态监控项作为一种特性挂载其上,也是水到渠成的事情,实际上OpenConfig正是如此做的。

状态模型的构建和配置模型基本一样,不再赘述。

2.【Robot篇】

建模是网络自动化的基础,硬件/配置/状态模型结构化描述了网络中各种对象以及对象之间的关系,将网络转换为一套抽象的模型,使得系统可以全局的理解网络语义。一款Model Driven的Robot,其实质是理解这套模型,基于这套模型开发应用逻辑,通过对模型的增删改查,从而实现对网络的管理。

2.1【如何快速构建Robot应用】

这里有两个关键点:

◆  传统的开发模式,针对每个具体的场景,从业务逻辑到数据结构以及底层的交互,全部自己实现,这种垂直式的开发,不仅重复造轮子,而且对网络的整体变化缺乏把握,基于一套统一的模型来开发应用,使得系统更容易理解网络整体的状态,便于快速发现根因问题,另外基于一套数据模型进行开发,也使开发效率更快;

◆  另外一个关键点是:基于模型开发的应用,输出的是对模型实例的增删改查操作,这些操作如何能转换为实际设备可识别的指令?当前网管与设备交互协议繁多,SNMP/CLI/Netconf/rest API等,即使协议一样,各厂商的具体指令也不尽相同,甚至某些时候,网管需要交互的对象是控制器而不是设备,适配的工作占用大量的开发时间,这就需要系统能够提供一个平台,根据设备的实际能力,自动将应用生成的模型实例转换为设备/控制器可以识别的指令,从而屏蔽底层差异,应用开发者只需关注业务逻辑,快速实现各种自动化应用。

2.2【Robot应用场景】

从场景看,Robot可以应用于网络规划建设和运营的全生命周期。

◆  规划建设阶段:提供自动化建设系统,基于架构师设计的抽象模型,结合实际建设需求,系统能够自动生成具体的建设方案

    ◆  基于硬件模型生成物料清单、安装方案、连接关系等,用于指导采购、安装、布线;

    ◆  基于配置和状态模型则生成相应的配置和状态实例,并最终转换为设备可以识别的信息;架构师只需聚焦于网络的抽象设计(HLD),具体的建设方案(LLD)由系统自动生成,以此来面对网络架构频繁变化的挑战。

图5 自动生成的连接方案

◆  网络运营阶段:规划和建设阶段,网络的复杂性主要体现在方案的差异上,设计、生成方案的方法是通用的,但是运营阶段则不尽然,不同架构、不同设备、不同故障场景,业务恢复和故障处理的方式都不尽相同,网络的差异性在运营阶段体现的淋漓尽致,这也是运营工具需求井喷的原因,这种工具相对独立,相互间耦合不多,一个工具解决一个问题,并且会随着网络情况的变化经常调整,在网管智能化能力未全面覆盖之前,大量的运营工具需求将长期存在。这也是我们推行NetDevOps的原因之一,基于Model的开发,无需自己定义数据结构,无需关注底层设备差异,使得应用可以快速上线;使用Devops模式,减少了运营人员/产品经理/开发之间的沟通,使得Robot应用开发更敏捷。

总之,Robot主要聚焦各种自动化应用的实现,考虑到运营场景的多样和变化,提供一套基于Model的NetDevOps平台,让运营人员快速DIY自己的Robot应用,是个不错的思路。    

3.【Brain篇】

Model提供了一套数据模型,Robot负责基于这套模型做事情,相当于手和眼,还缺一个大脑(Brain)来控制这些Robot,以前的大脑是人,人来控制工具的执行,要真正实现自动化闭环,还需要一颗智脑。

3.1【Big Data】

讨论智脑之前,先说说数据,不论是人工智能,还是大数据分析,都离不开海量有效数据。传统网络不论是数据实时性(SNMP/CLI只能支持分钟级的采集),还是数据完整性(当前主要是CPU/内存/流量/包量/丢错包/光功率等指标, 缺乏对设备底层例如芯片层面的监控),都很难满足大数据分析和AI对数据的需求。

所幸近年来通过业界的努力,秒级上报的telemetry技术已开始商用,可编程芯片+ P4语言的组合,使得更多芯片级的状态可以被监控起来,而状态建模则建立了这些状态项之间的联系,使得大数据分析和AI具备了数据基础。

3.2【Brain】

有了数据基础,再来谈谈智脑,这颗智脑应该具备两方面的能力:

◆  一是面向网络的,能够理解网络中的变化,并将各种错综复杂的变化,归纳收敛为具体的根因事件,这种能力常应用于故障定位、故障预防等场景中,通过智脑分析出网络的具体变化或变化趋势,然后驱动Robot进行处理。

举个例子:通过对状态模型的分析,可以得到当前设备状态是否异常,将状态异常的设备找出来,然后根据拓扑、IP连接、协议邻居等关系,通过一套计算聚合度的方法,可以找到这些异常设备的中心点,这个中心点即为根因设备,然后在根因设备内继续深挖,根据硬件模型、配置模型可以得到机框/板卡/端口/捆绑口/IP/路由协议这些对象之间的映射关系,将状态异常的对象标示出来,则很容易找到本次异常的根因。

◆  另一种能力是面向人的,智脑能够理解人想干预网络的意图,并将其转换为可以落地的方案并实施,这种能力常应用于网络变更场景中。

但这种对于人意图的理解,还不同于前面提到的基于Model的架构设计和自动化建设,前者要求架构师还是要将HLD设计出来,例如设备架构角色定义、互联规范选择、功能区定义等,这些事情还是需要很高的专业度才能做,然后系统将HLD转换为LLD;基于意图的网络则更加抽象,人更多关注的是需求,是要做什么,如何做由系统来考虑

还是举个例子:业务需要在某个园区部署一批机器,人主要关注这个部署需求是否合理,系统能够根据业务的历史流量模型,分析出流量的带宽需求,然后结合对现有网络的智能学习或者人工内置的各种规则,自动生成扩容方案。

以上两个场景,都依赖智脑的规则,这种规则可以是人工指定,也可以是基于AI自动生成,不论哪种方法,都需要实时、完整的网络大数据支撑。

总结

Robot是各种自动化应用,相当于网络管理的眼睛和手;Model提供了一套结构化描述网络硬件、配置、状态的方法,使得系统能够理解网络语义,快速开发Robot成为可能,同时也为Brain提供实时、完整的数据;Brain是大脑,基于大数据,用各种人工指定或者机器学习生成的规则,驱动各种Robot工作。下一代基于Robot.Model.Brain(R.M.B)的网管,将网络结构化、抽象化、智能化,大大降低网络设计、建设、运营过程中人的参与,使得全自动网络管理成为可能。

欢迎关注公众帐号“鹅厂网事”,我们给你提供最新的行业动态信息、腾讯网络与服务器最接地气的干货分享,还有一大波互动交流板块和有奖活动正在筹备当中,需要您的热情参与哦,敬请期待!

注1:凡注明来自“鹅厂网事”的文字和图片等作品,版权均属于“深圳市腾讯计算机系统有限公司”所有,未经官方授权,不得使用,如有违反,一经查实,将保留追究权利;

注2:本文图片部分来至互联网,如涉及相关版权问题,请联系v_huanjian@tencent.com

原文发布于微信公众号 - 鹅厂网事(tencent_network)

原文发表时间:2018-06-20

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏数据和云

电信核心系统去小型机化-去“I”

去“IOE”是一个甚嚣尘上的话题,在经年的渲染之后,很多企业都在以各自的方式在进行演绎。 云和恩墨最近帮助用户实施了一个重要的“去I”项目,引用恩墨一线负责人...

2423
来自专栏数据科学与人工智能

【ETL工程】大数据技术核心之ETL

抛开大数据的概念与基本知识,进入核心。我们从:数据采集、数据存储、数据管理、数据分析与挖掘,四个方面讨论大数据在实际应用中涉及的技术与知识点。 核心技术 架构挑...

30810
来自专栏腾讯大数据的专栏

精准推荐平台现网引流测试初探

前言 大数据时代,海量流量和数据是变现的源泉。腾讯拥有最多样的用户数据,社交、聊天、游戏、听音乐、看电影、逛电商,等等,有巨大的挖掘空间,个性化精准推荐无疑是一...

2735
来自专栏蓝天

电信系统架构方案

撰文/青润(本文来自《程序员》杂志2003年3期) 国内软件业曾有人对行业性软件进行划分,在几个较大的行业中,排行前几位的分别是:通信、电力、金融…… 但从...

784
来自专栏WeTest质量开放平台团队的专栏

2018 Unite大会——《使用UPA工具优化项目》演讲实录

2018年5月11日至13日,腾讯WeTest与Unity联合打造的移动游戏性能分析工具(Unity Performance Analysis,以下称为UPA)...

3836
来自专栏跨界架构师

[译文]Domain Driven Design Reference(五)—— 为战略设计的上下文映射

  两个组之间的关系是“上游”小组的行为影响“下游”小组的项目成功。但下游的行为并不会显著影响上游项目。(例如,如果两个城市沿着同一条河流,上游城市的污染主要影...

542
来自专栏大数据和云计算技术

​大数据和云计算技术周报(第35期)

“大数据” 三个字其实是个marketing语言,从技术角度看,包含范围很广,计算、存储、网络都涉及,知识点广、学习难度高。

882
来自专栏PPV课数据科学社区

警察叔叔是怎么用大数据来思考与实践的

近年来,伴随着全国各地公安机关信息化的迅猛发展,数据共享和深化应用的需求空前高涨。但是,随着数据的汇聚和数据量的爆炸式增长,传统的数据库和数据仓库技术出现了诸多...

3219
来自专栏北京马哥教育

数据分析≠Hadoop+NoSQL,不妨先看完善现有技术的10条捷径

马哥linux运维 | 最专业的linux培训机构 ---- 让业务搭乘大数据技术确实是件非常有吸引力的事情,而Apache Hadoop让这个诱惑来的更加的...

3285
来自专栏吉浦迅科技

英伟达DesignWorks VR用虚拟现实做现实世界的设计

英伟达(NVIDIA)发布了DesignWorks VR,一套新的工具配合之前推出的GameWorks VR SDK一起使用,聚焦代替在虚拟现实里创建物理对象。...

2556

扫码关注云+社区