ONAP架构分析以及TOSCA模型简介

作者简介:肖凯西,SDN以及网络重构研究,博客地址:https://blog.csdn.net/crystonesc

ONAP(开发网络自动化平台)是由原Linux基金会下两大MANO工作组Open-O与ECOMP合并而来,Open-O主要是由中国移动发起的项目,而ECOMP则是当年AT&T提出Domain 2.0转型时的落地项目。两个组织合并后,ONAP也陆续推出了阿姆斯特丹,北京以及卡萨布兰卡三个版本。ONAP相对于其它的开源MANO系统,提供了更多丰富的功能,收到较高的关注度。

1.ONAP架构及主要模块介绍

上图是ONAP Beijing的整体架构,可以看到,其相对ETSI给出的参考标准更加复杂,接下来对ONAP整体架构进行简单的介绍。ONAP由一系列子模块组成,主要由两大部分构成,SDC和RUN-TIME,下图是ONAP的总体功能流程示意图:

1、运营人员在SDC完成VNF的载入等管理,并完成NS的编排设计、测试等工作,最后通过上线流程将NS推送到RUN-TIME的SO模块,整个设计过程是基于TOSCA/YANG模型完成的。
2、SO模块主要负责NS的管理,并解析来自SDC的模型文件,对于网络部分,则交给SDN-C进行编排,对于VNF和应用,则交给VF-C和APPC管理。VF-C主要负责VNF的全生命周期的管理。
3、SO还会将设计模型注入到A&AI之中,并且根据之后资源使用的动态情况,实时调整A&AI的资源使用情况。
4、最后,DCAE主要负责采集底层资源、应用、VNF、网络等状态数据,并提供大数据分析和闭环操作的能力。

1.1Design-Time(SDC)

Design-Time 是供开发,设计,测试人员对VSP(虚拟服务产品)进行设计的功能模块,对于开发人员,可以通过SDC对VNF进行开发和测试,对于设计人员,可以通过SDC将成熟的第三方VNF产品或者ONAP market place的VNF产品进行导入并验证,最后通过将不同的VNF组合起来,完成VSP的设计。对于测试人员,在设计人员完成VSP设计后,可以通过与SDC集成的测试环境来对VSP的功能,结构等进行验证,验证通过后,设计人员可以将VSP发布到Run-Time环境。上述的过程可以通过SDC GUI界面完成,同时也可以通过调用Rest API进行。

1.2Run-Time

在SDC中完成VSP设计后,设计人员可以将VSP发布到Run-Time环境中,可以理解,Run-Time实际生产环境,Run-Time中包含许多功能组件,以下进行详细说明:

1.A&AI(Active & Available Inventory)
A&AI的作用是维护资源(Resource)和服务(Service)的实时关系,其中资源(Resource)是指如CPU,存储,网络连接,VNF之类的构成服务的元素,而服务(Service)是由多个资源组合起来的。如下图所示,在设计人员完成VSP设计后,在向Run-Time发布VSP后,SDC会将VSP的模型载入AAI,AAI解析模型配置文件,将其中各类资源和服务的关系通过图的方式存储起来,举个例子,subscriber(服务订阅者,一般指客户) → NS(网络服务) → VNFs → VMs → compute/storage/networking nodes。之后在网络服务运行过程中,如果发生了动态的调整,其它组件也会通过接口将实时变化的信息反馈到AAI当中,综上所述,可以将A&AI看成一个动态的资源管理库。

2.SDN-C
SDN-C是ONAP中网络控制的核心,它可以通过Network Adapters与各类虚拟环境中本地的控制器或者网络组件交互,同时MSO可以通过API将网络开通,配置交给SDNC来处理。在SDN-C中最具体色的是提供DG-Builder,用户在通过DG-Builder来编写脚本,这些脚本包含一些一步一步执行的指令实践,例如:配置路由,发送BGP消息,发送Openflow消息等等,这些配置脚本可以通过SDN-C中的SLI来执行。DG-Builder能够使用户在不编写代码的情况下,为SDN-C增加新的功能。

3.APPC(Application Controller)
APPC对应到ETSI规范中,可以与VNFM对应,用于对VNF进行全生命周期的管理。

4.Multi-VIM/Cloud
在运营商的网络当中,虚拟化环境是由多厂家提供,例如:openstack,VMware等等,Multi-VIM/Cloud就是聚焦在这部分,如下图黄色的部分,Multi-VIM/Cloud在各类虚拟化环境和Run-time各模块之间提供了中间层,屏蔽了不同虚拟化环境的差异,提供统一标准的API,其中Provider Registry提供将基础虚拟化环境注册到A&AI的服务,包括虚拟化环境的地域,容量等等信息。Infra Resource提供给MSO,DCAE等组件管理资源的能力,例如创建VNF需要的虚拟机,SDN Overlay提供配置和管理虚拟化环境Overlay网络的功能,这些功能往往是通过虚拟化环境中本地的SDN controller来具体执行。VNF Resource LCM用于提供给APP-C和VF-C对VNF全生命周期的管理。由此可见,在ONAP中,已经考虑到了多VIM的集成,这非常符合运营商的实际情况。

5.MSO(Master Service Orchestrator)
MSO是ONAP的核心功能,当设计人员在SDC完成VSP的设计后,将VSP发布到Run-Time环境,此后如果由客户在OSS/BSS生成产品订单后,OSS/BSS通过调用MSO的接口,MSO就会将VSP进行实例化,MSO将VSP模型进行分解,关于网络这部分的开通需求交给SDN Controller(L1-L3),关于VNF APP这部分(L4-L7)的内容交给App Controllers处理,同时对于一些虚拟化的资源,则交给对应的云平台供应商,在这些底层组件完成开通后,会将结果反馈到MSO当中,同时MSO会将这些动态信息写入到AAI当中。

6.DCAE(Data Collection Analytics and Events)
DCAE是ONAP所宣称closed-loop的重要环节,如下图所示,DCAE纵向分为两个部分,DCAE Platform和DCAE Analytic Applications。DCAE Platform主要完成NFV环境的数据采集,并通过Data Movement模块对数据,实践,消息进行分发。这些结构化或者非结构化的数据可以持久化到其所称的data lake(数据湖当中),同时DCAE Platform还提供一系列数据的分析框架。DCAE Analytic Applications则是基于DCAE Platform的数据分析框架和采集数据开发的分析应用,用户可以根据DCAE的SDK开发自己相应的应用。同时DCAE还提供闭环反馈能力,当分析应用得出结果后,可以调用相关Action触发MSO,Controller对现网的网络服务进行调整。在部署上面,DCAE可以支持边缘和中心的分布式部署。

2.编排的核心:模型驱动

ONAP要完成对网络服务的编排和部署,其核心源于ONAP是按照模型驱动而设计的,设计人员完成VSP的模型设计,并提交给MSO编排器,MSO按照模型文件从资源到应用来对整个产品进行编排。为了完成编排,ONAP需要遵从一系列标准,其中TOSCA模型就是用于NS、VNF以及应用编排的。

TOSCA(Topology and Orchestration Specification for Cloud Applications)

TOSCA是云应用的拓扑编排规范,通俗的讲就是制定一个规范,用于描述应用在云平台上面的拓扑结构,目前支持XML和YAML两种格式。TOSCA目前被广泛应用到NFV的编排领域,其规范组织OASIS还给出了《TOSCA Simple Profile for Network Functions Virtualization (NFV) Version 1.0》,掌握TOSCA模型对理解ONAP的模型驱动有很大的帮助。下面通过《TOSCA Simple Profile in YAML Version 1.0》中的例子来简单介绍下TOSCA。

以下这个例子是如何使用TOSCA描述一个MYSQL数据库服务在云平台的部署信息:

1.定义基础资源服务器

上述TOSCA描述了一个简单的计算节点:my_server,其节点类型为tosca.nodes.Compute,当然这个类型是需要预先定义好元数据的,同时对my_server进行了capabilities(容量)和os(操作系统的描述),通过下图可以看出其描述结构:

2.定义输入输出

进一步,我们还可以对该TOSCA定义一些inputs和outputs,如上所示,inputs的作用是告诉编排器这里需要使用外部输入,这个外部输入会被应用到node_template的num_cpus当中,通过inputs的方式,用户可以自定义一些变量和参数。outputs的作用是告诉编排器暴露一些关于这个应用编排的状态信息。

3.安装mysql服务

如上所示,出现了一个新的节点mysql,并且类型属于tosca.nodes.DBMS.MySQL,同样tosca.nodes.DBMS.MySQL的元数据是预先定义好的,同样这里看到,对于这个mysql,需要用户输入其root密码以及端口,同时其需要(requirements)db_server作为部署主机。文件底部有对db_server的配置声明。如下图所示,是目前对TOSCA的图形描述。

4.配置数据库

如上所示,TOSCA还允许通过interfaces来定义一系列自动化的操作,对于本例子中的mysql,我们定义了一个脚本:my_own_configure.sh来对mysql进行配置。

5.数据库内容的部署

上面的定义都只是部署了一个mysql的应用服务,但是目前还没有创建database,上面的描述文件就能够告诉编排器创建一个节点名称为my_db的database,并且允许用户输入database的名称,用户名,密码以及端口。同时还可以看到在db_content部分定义了外部的数据表内容文件,用于导入数据。完成这部分定义后,一个完整的从数据库服务到数据库内容的部署就做好了,其关系如下图所示:

通过上面一个对MYSQL部署的示例可以看出,TOSCA模型能够清晰的描述出应用与资源之间的关系,同时还支持自动化操作,从而完成应用的配置和启动。

3.小结

本节首先对ONAP 北京版的功能架构进行了介绍,之后分析了ONAP模型驱动的核心TOSCA,之所以对ONAP进行研究,原因在于ONAP是目前开源MANO项目当中成熟度较高的,较ETSI提出的NFV参考架构还提供了许多其它功能,例如上面提到的SDC、A&AI等,并且这些功能特性都是从运营的角度来考虑的,对运营商OSS域的演进提供了很高的参考价值,目前运营商OSS域中的系统,例如:资源系统、智能网管、网络大数据平台等都能够在ONAP中找到对应的功能模块,这里不展开详细讲解。同时许多其它开源项目也将ONAP作为编排器纳入其架构中,例如Akranio项目中针对边缘计算的蓝图就将ONAP作为编排器,故希望通过本文简单介绍,能够让读者能够对ONAP有一个大致的认识。

参考资料:
1.https://wiki.onap.org/
2.《TOSCA Simple Profile in YAML Version 1.0》


  • 本站原创文章仅代表作者观点,不代表SDNLAB立场。所有原创内容版权均属SDNLAB,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用,转载须注明来自 SDNLAB并附上本文链接。 本站中所有编译类文章仅用于学习和交流目的,编译工作遵照 CC 协议,如果有侵犯到您权益的地方,请及时联系我们。
  • 本文链接https://www.sdnlab.com/22904.html
分享到:
相关文章
条评论

登录后才可以评论

crystonesc 发表于19-01-22
0