ONAP 技术详解与应用实践 (43):ONAP 架构设计 3.2.1

阅读数:2 2020 年 1 月 5 日 18:02

ONAP技术详解与应用实践(43):ONAP架构设计 3.2.1

(模型驱动)

内容简介
这是一本系统剖析 ONAP 的书籍,也是理论性与实战性兼具的网络自动化实践指导书!
本书详细全面地介绍了网络自动化的挑战和发展趋势,以及 ONAP 的概况、架构设计理念、设计原则、各模块实现细节、关键特性、应用场景和案例实践等。通过本书读者可以深入理解 ONAP,提升对网络自动化及相关领域的认知。
作者及其团队成员均是是华为网络开源领域的专家,长期参与社区的治理、贡献和回馈,致力于通过产业协作,打造统一的平台,降低集成成本,加快新技术导入,助力新一代网络运维系统升级。从另一个侧面说,本书是华为在网络开源领域的深刻洞察和见解,书中分享了华为参与网络开源的实践经验,是电信网络转型的重要参考。
本书共分为四大部分:
准备篇(第 1~2 章) 帮助读者梳理网络自动化的挑战和历史,分享了业界先进理念和经验,详细介绍了 ONAP 平台的版本能力以及与标准和开源组织的协同;详细描述了在三种环境(物理服务器、私有云环境、公有云环境)下安装部署 ONAP 的方法。
架构设计篇(第 3 章)系统介绍了 ONAP 在设计之初的目标与设计理念,从全局角度帮助读者了解 ONAP 当前架构是如何形成的,各个模块是如何划分的,最终又是如何保证系统质量的,在这个过程中开发人员分别有哪些考虑。具体包括模型驱动、DevOps、微服务化与云原生等,同时对 ONAP 数量众多的组件,从架构角度进行了归类和介绍。
关键项目篇(第 4~7 章),关键项目篇从架构角度将 ONAP 分为 ONAP 设计态组件、运行态组件、闭环组件和公共组件四部分,每个部分又包含若干项目。本书详细介绍了每个项目的功能描述、API 接口关系、关键特性、未来规划特性及开发指南等。这部分可帮助读者深入理解 ONAP 核心。
应用场景和案例实践篇(第 8~10 章),首先介绍了 ONAP 社区到 R3 版本为止的五个场景蓝图,以及基于 ONAP 来解决网络自动化和业务闭环的问题方法;然后以 CCVPN Usecase 为例,介绍 ONAP 支持一个新业务场景的设计思路、建模方法、工作流设计、闭环设计等;最后系统介绍了社区的测试认证项目 OVP、包括其发展路标、认证服务模式及未来构想。

介绍模型驱动前需要介绍一下什么是模型。模型是对“事物”的一种抽象化表达,从特定角度对系统进行描述,省略部分不重要的细节,聚焦感兴趣的特性。

模型驱动在软件开发领域有多种表达方式,如 MBD(Model Based Development,基于模型的开发)、MDD(Model Driven Development,模型驱动开发)和 MDA(Model Driven Architecture,模型驱动架构)。其主要核心都是从模型生成代码和其他开发过程中的组件,在解决领域问题的同时,提高生产效率,比如:发生变更时,软件设计不变或变更较少(模型不变)。与之对应的传统开发方式则是硬编码(即使用编程语言 C、C++、Java、Python 等编写代码)。但从本质上来说,只要是进行变更,肯定需要某人 / 某个 APP 在某个地方进行某些修改,这样才能让变更真正生效。

模型驱动的修改与硬编码方式的修改真正的差异在于:谁负责修改,改什么(包括在哪修改),影响多大。对于传统硬编码方式而言,所有变更都需要由原软件提供者(即 Vendor 软件供应商)来修改,且需要在实际产品代码上修改,包括重新编译、发布、打包等开发环节,再经过商业交付流程提供给使用者。而使用者则在此过程中则只能等待,等待供应商提供修改后的版本,然后再经过入网测试、升级部署等流程后才能在实际网络中使用。这样的方式不仅代价大、周期长(一般以月为单位),而且多数情况下,产品升级时还需要将系统关机重启,影响较大。如果整个过程中发生任何问题,包括理解上的差异,很可能需要从头再来。

而对于模型驱动的平台架构,能做到对多数变更,但平台开发者(供应商)不需要参与代码修改,平台本身也不需要停机、重新编译、发布等开发过程。而是由使用者 / 用户通过修改外部(相对平台代码而言)的模型文件(TOSCA 或 YANG 等)或插件(可能包括 JavaScript、Python 等动态语言)即可动态生效,这一开发过程在 ONAP 中被称为设计。当然为了实现这一点,需要提前定义一些约定:模型的格式(模型文件应该如何描述)和模型生效的流程(模型如何加载、生效,如果中间出现错误如何处理等)。多数模型驱动的架构还会提前定义一些预定制的元模型或领域模型示例,以简化学习门槛,加速在指定领域中的应用。

在本节中,模型驱动表达的意思是,ONAP 支持在不需要修改 ONAP 自身框架代码的前提下,通过对模型做组合 / 变更(新增,删除或修改),实现电信业新业务的上线或更新。一般是通过修改某些脚本及动态加载部分插件或驱动来实现的。

注意 模型驱动并不意味着业务变更完全不需要修改代码,只是不需要修改 ONAP 框架代码,即分为两部分:一部分负责对平台的修改(尽可能少甚至不需要),平台的设计人员不参与;另一部分是(在多数场景下)负责新业务发放的业务设计员通过对模型的组合与修改完成的(也可能包括一些脚本的开发)。

ONAP 各组件是元数据驱动和策略驱动的,以确保功能和特性能灵活使用和交付,支持动态增加或变更,而且作为面向电信领域的开源社区,也有利于定义面向电信自动化领域的相关模型规范。具体体现在以下几方面:

  • 全局数据结构:ONAP 的全局数据结构都定义在 Schema 文件中,文件名类似 aai_schema_v15.xsd(早期 Amsterdam 版本中的数据模型版本是 V8 与 V9,最新的 Casablanca 版本已升级为 V15 了),正常情况下,在 SDC 中每次修改模型的定义(不是模型对应的实例,比如在网元中增加一个“名称”属性等),则 SDC 会自动触发模型文件的版本递增,ONAP 的 A&AI 支持多个版本的模型文件并存。ONAP 社区版本发布时都会指明具体对应的模型文件版本号,并将运行态分发到各需要访问模型的组件实例下。也就是说,ONAP 在代码层面并不固定描述用户、网元或设备的数据模型,即没有硬编码定义这些对象的结构,而是采用 Schema 脚本进行描述。因此,在需要变更(比如增加对象或某对象增加属性定义)时,只要在设计态修改对应 Schema 脚本,并分发到运行态涉及的组件中即可。在全局存量系统 A&AI 启动时会自动加载 Schema 文件,并在数据库中创建对应的表结构与关系。
  • 各资源构件:各资源构件(网络或业务的定义,如 BPMN 与 Policy 等)都保存于可重用资源库目录中,方便动态支持资源上线、服务的定义和创建,且支持通过由更简单的、可重用的资源构件组合成复杂业务。
  • ONAP 平台自身:ONAP 自身特异性也采取类似的元数据驱动的方式实现。比如从 ONAP 的 Casablanca 版本开始,在 CCSDK 项目中启动 CDS(Controller Design Studio),通过设计与定义不同的控制器蓝图(Controller Blueprints),即可帮助运营商根据需要灵活定义 Controller 模板(比如将有线与无线融合到一个 Controller,或者分成不同 Controller)。策略驱动在不同层次或领域闭环机制中都有应用,以实现对云、网络和业务的实时自动化控制。
  1. 常见模型

常见模型包括业务模型、概念模型、数据模型、对象实例(物理数据模型)和元模型等,分别表示从现实世界到信息世界的不同层次的抽象。

  • 信息模型、业务模型、概念模型:可简略记成 IM(Information Model,信息模型),其为对现实世界中真实事物的描述,不涉及具体软件实现,例如员工、合同、客户、网络、站点、设备等;也包括这些抽象概念之间的关系,比如站点中“包含”设备、而交换机“属于”某种设备等。
  • 数据模型:可简略记成 DM(Data Model),这是对业务模型 / 概念模型的进一步分解和细化,包括所有的实体(抽象代表一类对象,如员工代表所有具体的员工)和关系(实体间的关系)。需要确定每个实体的属性,定义每个实体的主键,指定实体的外键,并进行范式化处理。一般在软件设计中定义对应的数据 / 对象结构,比如员工包括工号(字符 Char(8))、姓名(最长 20 个字符的可变字符串 varchar(20))、年龄(数字 integer)和出生日期(日期 date)等。
  • 对象实例:英文一般为 Instance(实例),用于在数据模型基础上定义每个具体的独立对象,比如定义员工的数据模型,此时某个具体员工 A 的工号是 00123456,则员工 A 就是一个实例。
  • 元模型(Meta Data):即模型的模型,是模型驱动设计更高一层次的抽象。一般针对特定领域的模型定义抽象概念(元模型),并用其构建该领域中具体数据模型。比如,在网络领域 IPV4(形如“10.10.10.10”的 32 比特的对象)或 IPV6(形如“1:123::ABCD:0:1/96”的 128 比特的对象)可作为元模型,然后用它来表示新的模型对象,比如 VPN(每个接入点都可以是 IPV4/IPV6 的 IP 地址)。

目前很多领域都有自己特有的模型及模型语言,如前文所述,ONAP 致力于创建一个开放、可编程的软件生态,支持业界最佳组件,而非一切重新开始,重新发明轮子。因此,ONAP 自身也采用了多种模型,比如面向业务与 VNF 生命周期管理的 TOSCA 语言,面向网络层配置管理的 YANG 语言,内部数据库建模又采用 XML Schema 语言等。下面就一一介绍。

  1. 常见模型语言

1)XML

XML(Extensible Markup Language,可扩展的标记语言)是 1998 年 2 月由 W3C(World Wide Web Consortium,万维网联盟)正式批准定义的标准通用标记语言。“标记”指计算机所能理解的信息符号,通过标记,计算机之间可以处理包含各种信息的文章等。如何定义这些标记?既可以选择国际通用的标记语言,比如 HTML(HyperText Markup Language,超文本标记语言),也可以使用像 XML 这样由相关人士自由决定的标记语言,这就是语言的可扩展性。XML 是从 SGML(The Standard Generalized Markup Language,标准通用标记语言)中简化修改出来的。XML 是一套定义语义标记的规则,这些标记将文档分成很多部件并对这些部件加以标识。XML 也是元标记语言,即为定义其他与特定领域有关的、语义的、结构化的标记语言的句法语言。

直白解释就是,XML 是一种规则,其把一个文档划分为不同的层次或部分,并对这些层次或部分做好标记。这个文档是能支持不同领域的(比如文学、物理、化学、音乐等),不同领域的文档可定义其特有的领域语言(也用 XML 定义)。XML 文档的字符分为标记(Markup)与内容(content)两类。标记通常以“<”开头,以“>”结尾;或者以字符“&”开头,以“;”结尾;不是标记的字符就是内容。

XML 有如下几个特征:

  • 内容与形式分离,其设计宗旨是传输和存储数据,而不是显示数据。
  • 良好的可扩展性,标签没有被预定义,需要自行定义。
  • 被设计为具有自我描述性。
  • 遵循严格的语法要求。
  • 便于不同系统之间信息的传输,是 W3C 的推荐标准。

一个简单例子如下:

复制代码
<student>
<age>19</age>
<name>John</name>
<school> Wuhan University</school>
</student>

以图的方式表达更好理解一些,如图 3-4 所示。以上 XML 脚本描述的是一个学生,记录了学生如下信息:年龄、姓名和学校。其中的学生、年龄等即为自定义标签(tag)。

ONAP技术详解与应用实践(43):ONAP架构设计 3.2.1

图 3-4 Student 学生模型示意

2)XML Schema

上面的 XML 例子中,虽然可以描述一个对象(通过自定义标签),但对于计算机处理来说可能还是不够的,只能说明它是语法正确—术语称为 well-formed XML,但不一定合法—术语称为 validating XML。

比如年龄这个标签,在计算机处理中还需更进一步严格定义:数据类型是一个数值,而不是字符串。显然,说年龄是 10(岁),这是合法的(一个数值);而把年龄说成一个字符串 OK 或“非常大”,则是非法的。

为了约束一个字段或者说为了约束 XML 的类型,就有了 XML Schema(XML Schema Definition,XSD),它是一套 W3C 标准,即为用于 XML 的模式定义语言,其作为关联的文档来定义 XML 标记规范。

以下是一个对 Age 进行约束的例子。Age 这个标签(XML 又称元素,即 element)有如下定义 / 约束:

  • value 必须是整型(xs:integer)。
  • 值范围必须是 7~50。
复制代码
<xs:element name="age">
<xs:simpleType>
<xs:restriction base="xs:integer">
<xs:minInclusive value="7"/>
<xs:maxInclusive value="30"/>
</xs:restriction>
</xs:simpleType>
</xs:element>

3)YAML

YAML(Yet Another Markup Language,另一种标记语言)是一种以数据为中心的标记语言,官方定义为一种人性化的数据格式定义语言。数据组织主要依靠的是空白、缩进、分行等结构。YAML 相比 XML 有如下优点:

  • 可读性好。
  • 和脚本语言的交互性好。
  • 使用实现语言的数据类型。
  • 有个一致的信息模型。
  • 易于实现。

比如上面那个学生的例子,用 YAML 语言表述如下。

复制代码
- student:
name: John
age: 19
school: Wuhan University
friends:    # YAML 用缩进后的横杠'-'表示列表项的多个取值
- 'mike'
- 'Tom'

由于 YAML 有较好的可扩展性与可读性,相比 XML 编码效率更高,在特定场景下具备明显优势。比如常用的动态语言(Python、Ruby 等)就支持用 YAML 定义的数据结构与数据类型。一些常见 IT 工具也使用它来定义模板,比如 OpenStack 的 Heat 和 AWS 的 CloudFormation、SaltStack、Puppet、Chef。

一个环境描述的 Heat 实例(包括对 Nova、Database、Chef 的定义)如:

复制代码
# Environment
environment: environment_1000_stag
name: Rackspace Cloud US - staging
providers:
nova:
id: nova
vendor: rackspace
provides:
- compute: linux
- compute: windows
constraints:
- region: ORD
database:
id: database
vendor: rackspace
provides:
- database: mysql
chef:
id: chef-server
vendor: opscode
provides:
- application: http
- database: mysql

4)YANG

YANG 是 IETF 在 RFC 6020 中定义的用于网络配置的数据模型描述语言,支持 NETCONF 接口协议,实现了网络配置的标准化,是一种 DSL(领域特有语言)。

注意 NETCONF 协议(NETwork CONFiguration Protocol)是一个网络配置管理协议,是由 IETF 标准组织定义的一套管理网络设备的机制。用户可使用这套机制增加、修改、删除网络设备的配置,获取网络设备的配置和状态信息。

YANG 与 XSD(XML Schema Definition)基本是等价的,也即 YANG 是一种 Schema 定义的语言,而不是像 XML/YAML 一样为了数据的传输和存储。

YANG 从设备维护的角度,将数据的层次结构模型化为一棵树,树中每个节点都有名称,且要么有一个值要么有一个子节点集,其还给节点提供了清晰简明的描述,同样提供了这些节点间的交互。相比 XML Schema,YANG 语言定义的数据模型没有晦涩的内容,可读性好、简单易懂、可扩展。当前 YANG 已在设备配置领域被普遍接受,IETF、ONF 等标准组织都要求提交的模型用 YANG 来写。其他组织,如 Openconfig,OpenDayLight 等也普遍支持 YANG。

下面为用 YANG 定义的一个 RPC(远程进程调用)的示例,表示一个 activate-software-image 的远程调用方法,输入是一个 string 参数 image-name,输出是 string 类型的 status:

复制代码
rpc activate-software-image {
input {
leaf image-name {
type string;
}
}
output {
leaf status {
type string;
}
}
}

5)TOSCA

TOSCA 全称是 Topology and Orchestration Specification for Cloud Applications,是一种数据建模描述语言,是由 OASIS 组织( https://www.oasis-open.org/ )制定的面向云计算环境中的应用拓扑和编排描述语言,目前支持 YAML 和 XML 实现。

TOSCA 的基本概念有两个—节点(node)和关系(relationship),且都可通过程序来扩展,同时 TOSCA 规范中也支持 Plan(即 Workflow 工作流文件)。

(1)节点预定义了很多基础类型,包括云基础设施中常用的计算节点、网络节点、数据库节点等。

(2)关系定义了 node 之间的关系,具体如下:

  • DependsOn(依赖于):表示节点间的顺序依赖关系,一般影响实例化过程中的创建顺序,比如 A 节点依赖于 B 节点,则在创建 A 对象前须提前创建 B。
  • HostedOn(运行于):比如“MySQL 数据库”与“计算机”的关系就是 HostedOn 的关系,即数据库运行在计算机上。
  • ConnectsTo(连接):表示连接关系。

TOSCA 面向云计算环境中的应用拓扑和编排场景来预定义一些属性,因此一般认为较适合用于解决以下场景中的需求:

(1)自动化的软件部署和管理。

(2)应用生命周期(安装、扩容、卸载等)管理方案的可移植性(注意:不是应用本身的可移植性)。

(3)组件之间的互操作性和重用性。

注意:OpenStack 中的 Heat 子模块也是基于 TOSCA 标准的。

考虑到 YANG、TOSCA 都具备较强的扩展能力,个人认为语言本身没有本质区别,也不存在谁一定更适合某领域的说法,这更多是不同领域习惯的差异问题。IETF、OASIS 等组织也都在不断扩展两种语言。

比如,NFV 领域的 VNFD,就是以 TOSCA 描述文件(可以是 YAML 或 XML 格式)进行说明的,包括安装软件过程中都有哪些组件、组件之间有什么依赖关系等;当然,实际运行时还需要用 TOSCA 运行态环境来对 TOSCA 文件进行读取(分析文件的语法、语意)和解释执行(进行具体的软件安装、配置工作)。

一个 TOSCA 描述文件(称为 Service Template)示例:在遵循 TOSCA 1.0 和描述信息 description 之外,还需要遵从拓扑模板,包括一个名为 my_server 的节点,类型是 tosca.nodes.Compute。该类型预置了两个 capabilities 信息,一个是 host,定义了硬件信息;另一个是 os,定义了操作系统信息。

复制代码
tosca_definitions_version: tosca_simple_yaml_1_0
description: Template for deploying a single server with predefined properties.
topology_template:
node_templates:
my_server:
type: tosca.nodes.Compute
capabilities:
host:
properties:
num_cpus: 1
disk_size: 10 GB
mem_size: 4096 MB
os:
properties:
architecture: x86_64
type: linux
distribution: rhel
version: 6.5

TOSCA 脚本还可用于表达对输入、输出的建模。比如,以下就定义了一个新节点类型—tosca.nodes.DBMS.MySQL。该类型允许接收 root_password 和 port 的参数。在 requirements 里定义了 mysql 这个节点,该节点需要被安装到 db_server 节点上,这就是“关系”。

复制代码
topology_template:
inputs:
# 略
node_templates:
mysql:
type: tosca.nodes.DBMS.MySQL
properties:
root_password: { get_input: my_mysql_rootpw }
port: { get_input: my_mysql_port }
requirements:
- host: db_server
db_server:
type: tosca.nodes.Compute
capabilities:
# 略

ONAP SDC 项目使用 TOSCA 来描述 Serivce 业务、Resource 资源对象,而且定义了一些电信运维领域的资源 / 管理对象(CP 连接点 connection Point,VL 虚拟连接 Virtal Link 等),以简化设计。

由图 3-5 所示可看出,一个 vIPR ATM service 包括两个 Node:一个 VNF(vIPR ATM VF),一个外部网络 VL 连接(vIPR ATM OAM Net)。当然,真正的场景中业务可能会复杂得多,如多 VNF 及多 VL 连接等。VNF 自身也可能是更细粒度的对象,只不过是以模型方式组合而已。比如上例中,VNF(vIPR ATM VF)由更小的 VFC、VL 及 CP 组成。示例模板如图 3-6 所示。

ONAP技术详解与应用实践(43):ONAP架构设计 3.2.1

图 3-5 TOSCA 表示 VNF 与 NS 的示意图
  1. 模型设计示例

由于对象之间存在复杂关系,且不同对象可分别对应不同模型文件,因此在 OASIS 组织中就定义了一种把多个模板文件以特定方式组织并进行 Zip 打包后的存档包格式,即 CSAR 云服务存档(Cloud Service Archive)。它支持云应用程序生命周期执行和管理所需要的文件,包含不同类型的多个文件(英文叫 artifacts)。这些文件通常组织在几个子目录中,每个子目录包含的文件都是相关的(可能还有其他子目录)。

ONAP技术详解与应用实践(43):ONAP架构设计 3.2.1

图 3-6 ONAP 中一个 VF 的 TOSCA 模板示例**1**

1 引用自:SDC Data model https://wiki.onap.org/display/DW/SDC+Data+model

每个 CSAR 必须包含一个所谓的清单文件。此文件名为 manifest,文件扩展名为.mf。它表示 CSAR 中其他文件的元数据,这些元数据以“名称 / 值”对的格式提供。

一个 ONAP 的 CSAR 文件示例结构如图 3-7 所示,商用部署场景下还可能包括 License 文件、metadata 元数据目录等,CSAR 架构细节定义可参见 https://wiki.onap.org/display/DW/Csar+Structure

ONAP技术详解与应用实践(43):ONAP架构设计 3.2.1

图 3-7 ONAPCSAR 文件结构示例

CSAR 文件是 ONAP 中模型上线、校验、分发的原子单位,且每次对模型进行修改变更之后,都必须修改模型版本号。

ONAP 支持多种 DM 格式,如 Heat、TOSCA、YANG 等,但内在的 IM 信息模型是保持一致的,即从 VNF 厂商提供 CSAR 包开始,ONAP 可能会对 DM 做一些映射与转换,但因为有统一的 IM 模型,因此屏蔽了厂商差异,如图 3-8 所示。

ONAP技术详解与应用实践(43):ONAP架构设计 3.2.1

图 3-8 ONAP 对 VNF 的 IM 信息模型示意图

VNF 网元供应商需要按 VNF SDK 项目的要求准备好相应的 CSAR 文件,其中最重要的就是 VNFD 文件(VNF Description,VNF 描述文件),它不仅定义了 VNF 的基本情况信息(名称,版本号,供应商),还明确了 VNF 对计算、存储、网络等基础设施的细节要求,以及支持哪些操作、如何操作对应的工作流文件等。然后将准备好的文件按 VNF SDK 项目的要求,进行自动化测试验证,之后即可加入 ONAP 的设计态目录,并被 ONAP 系统使用(这称为 onboarding 上线)。ONAP 在编排过程中,可能会根据各项目的需要对相应 DM 数据模型做一些转换 / 处理,比如,SO 与 Controller 可能将类似信息保存到不同数据结构中,但整个 IM 信息模型在整个 ONAP 中是共享的。在 ONAP 的 A&AI 全局数据库中,尽量采用通用的 DM 定义,比如,业务实例定义可表示任何业务,即原则上并不会因为新增了一个领域的业务,或新增对某厂商 VNF 的支持而要求 A&AI 修改数据库结构定义。

具体流程如图 3-9 所示(参见 https://wiki.onap.org/display/DW/Onboarding+Services+into+SDC+and+Instantiating+through+VID )。

ONAP技术详解与应用实践(43):ONAP架构设计 3.2.1

图 3-9 ONAP 业务设计以及分发过程示意

步骤 1 在 VNF SDK 中验证 VNF/CNF。

VNF SDK 验证通过的 VNF/CNF(Containized Network Function 容器化的网络功能)会将相关 CSAR 文件自动加入 SDC 目录中,并作为资源等待处理。

步骤 2 通过 SDC 界面进行相关设计。

用户在 SDC 的 GUI 界面中设计生成对应的模板文件,包括在界面上 import 导入外部的资源模型文件(上一步中 VNF/CNF 的 TOSCA CSAR 包)。

在 SDC 设计界面中设计资源与业务,及其之间的映射关系,如 VF、Service 等,并将其加入 SDC 目录中(可用于后续基于此做更改或进一步设计封装)。

将所有设计结果导出为对应的 csar 包(包括生成对应的版本号),并提交测试验证。

此时由负责测试和校验的用户角色登录 SDC,测试人员与校验人员完成测试和校验后(线下方式等),进入 SDC 中审核并让流程进入下一环节。如果此环节发现问题,可返回。

步骤 3 设计结果通过 SDC 分发引擎分发到运行态各组件。

管理员进入 SDC 后,可点击 Distribute 将模型文件从设计态向运行态的各实例分发(运行态各实例之前就已在 DMaap 总线注册了要监听的模型文件类型),相关 SDC Message Broker 分发总线则会根据注册情况,发送通知给相应运行态实例。

各运行态组件实例(SO、A&AI、Controller 等)收到通知后,会主动从 SDC 目录中获取设计态中已完成的模板文件—CSAR 包及对应的 Artifacts 交付件,并将之导入自身目录中。此时运行态组件即支持了新的模型对象,等待上层 OSS 或 GUI 界面对业务进行实例化。

  1. 模型定义示例

举例而言,Device 设备的定义如下:包括 device-id 属性、esn 号、device name 设备名称、Description 设备描述、Vendor 供应商、Classic 分类等。在 A&AI 全局数据库中的定义如图 3-10 所示。

ONAP技术详解与应用实践(43):ONAP架构设计 3.2.1

图 3-10 ONAP A&AI 中的 Device 对象示意

打开 Schema 文件,仅须关注 Device 类。以属性 device-id 和 esn 号为例,对应描述如下:

复制代码
<xs:element name="device">
<xs:complexType>
<xs:annotation>
<xs:appinfo>
<annox:annotate target="class">@org.onap.aai.annotations.Metadata (description="Instance of a device",indexedProps="device-id, device-name,esn,vendor,class,type,version,system-ip,system-ipv4,system-ipv6,operational-status",nameProps="device-name",searchable="device-id",uniqueProps="device-id",container= "devices",namespace="network",requiredProps="device-id")</annox:annotate>
</xs:appinfo>
</xs:annotation>
<xs:sequence>
<xs:element name="device-id" type="xs:string" minOccurs="0">
<xs:annotation>
<xs:appinfo>
<annox:annotate target="field">@org.onap.aai.annotations.Metadata(isKey=true,description="Uniquely identifies this device by id")</annox:annotate>
</xs:appinfo>
</xs:annotation>
</xs:element>
<xs:element name="esn" type="xs:string" minOccurs="0">
<xs:annotation>
<xs:appinfo>
<annox:annotate target="field">@org.onap.aai.annotations.Metadata(description="Store the esn of this device.") </annox:annotate>
</xs:appinfo>
</xs:annotation>
</xs:element>
……………
<xs:element ref="tns:relationship-list" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
</xs:element>

Schema 文件基本上是自解释的,可看出 device-id 属性和 esn 号都为 String 字符串类型,目前没为其指定默认值,其 Description 字段中简要描述了属性的含义。

对应的 aai_schema_v15.xml 则根据 Schema 文件自动生成 Java 语言定义的 XML 文件,具体如下:

复制代码
<java-type name="Device">
<xml-root-element name="device"/>
<java-attributes>
<xml-element java-attribute="deviceId" name="device-id" required="true" type="java.lang.String" xml-key="true">
<xml-properties>
<xml-property name="description" value="Uniquely identifies this device by id"/>
</xml-properties>
</xml-element>
<xml-element java-attribute="esn" name="esn" type="java.lang.String">
<xml-properties>
<xml-property name="description" value="Store the esn of this device."/>
</xml-properties>
</xml-element>
......
<xml-element java-attribute="relationshipList" name="relationship-list" type="inventory.aai.onap.org.v15.RelationshipList"/>
</java-attributes>
<xml-properties>
<xml-property name="description" value="Instance of a device"/>
<xml-property name="indexedProps" value="device-id,device-name, esn,vendor,class,type,version,system-ip,system-ipv4,system-ipv6, operationalstatus"/>
<xml-property name="nameProps" value="device-name"/>
<xml-property name="searchable" value="device-id"/>
<xml-property name="uniqueProps" value="device-id"/>
<xml-property name="container" value="devices"/>
<xml-property name="namespace" value="network"/>
<xml-property name="requiredProps" value="device-id"/>
</xml-properties>
</java-type>

注意 最后的 ref="tns:relationship-list" 字段代表与 Device 对应的对外引用关系列表,这是 ONAP 模型定义的一个常见的基础属性类型,因为 ONAP 的 A&AI 系统是基于图数据库系统设计的,因此支持根据不同的 relationship 从一个对象查询相关联的对象。比如,查询在一个 AZ 内,属于某个特定租户的所有 VM 的所有网卡上的 IP 地址列表。如果是传统关系型数据库,则很可能需要一个非常复杂的 App 才能完成。有了图数据的关系,采用 Traverse 查询方式,通过一条命令即可返回结果。

图 3-11 所示可简要解释关系列表的组织,它可包括一系列的关系 relationship,而每个关系又有指向的对象、关系的 Label 描述、Link、关系对应的 Key/Value 对及属性等。

ONAP技术详解与应用实践(43):ONAP架构设计 3.2.1

图 3-11 ONAP A&AI 项目中 Relationship 关系示意图

对应 Schema 文件定义如下("relationship-list" 是 "relationship" 的 List 列表对象):

复制代码
<xs:element name="relationship">
<xs:complexType>
<xs:annotation>
<xs:appinfo>
<annox:annotate target="class">@org.onap.aai.annotations.Metadata (description="URL to the object in A&AI.")</annox:annotate>
</xs:appinfo>
</xs:annotation>
<xs:sequence>
<xs:element name="related-to" type="xs:string" minOccurs="0">
<xs:annotation>
<xs:appinfo>
<annox:annotate target="field">@org.onap.aai.annotations.Metadata(description="A keyword provided by A&AI to indicate type of node.")</annox:annotate>
</xs:appinfo>
</xs:annotation>
</xs:element>
<xs:element name="relationship-label" type="xs:string" minOccurs="0">
<xs:annotation>
<xs:appinfo>
<annox:annotate target="field">@org.onap.aai.annotations.Meta-data(description="The edge label for this relationship.") </annox:annotate>
</xs:appinfo>
</xs:annotation>
</xs:element>
<xs:element name="related-link" type="xs:string" minOccurs="0">
<xs:annotation>
<xs:appinfo>
<annox:annotate target="field">@org.onap.aai.annotations.Metadata(description="URL to the object in A&AI.") </annox:annotate>
</xs:appinfo>
</xs:annotation>
</xs:element>
<xs:element ref="tns:relationship-data" minOccurs="0" maxOccurs= "5000"/>
<xs:element ref="tns:related-to-property" minOccurs="0" maxOccurs= "5000"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="relationship-list">
<xs:complexType>
<xs:sequence>
<xs:element ref="tns:relationship" minOccurs="0" maxOccurs="5000"/>
</xs:sequence>
</xs:complexType>
</xs:element>

ONAP技术详解与应用实践(43):ONAP架构设计 3.2.1

购书地址 https://item.jd.com/12536723.html?dist=jd

评论

发布