微信邦 发表于 2018-6-20 11:51:12

基于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]
查看完整版本: 基于R.M.B的下一代网管