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》