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

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

ONAP技术详解与应用实践(47):ONAP架构设计 3.3.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、包括其发展路标、认证服务模式及未来构想。

ONAP 大体上可划分为两大框架:

  • 设计态框架:用于对平台进行设计、定义和编程的设计期框架(统一上线)。
  • 运行态框架:执行设计态框架所编写的逻辑(统一进行交付和生命周期管理)。

ONAP 并不是简单集成这两个框架,而是非常紧密地结合,结合两者的就是模型,即设计态框架输出的模型,就是运行态框架的输入,模型文件通过 SDC 中的分发功能实现二者的无缝对接,如图 3-14 所示。

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

图 3-14 设计态与运行态关系图
  1. 设计态框架

ONAP 设计态框架是设计、定义和编程的框架,目标是方便开发可部署、可重用的软件资产,满足业务全生命周期的需要:增加新功能、修改已有能力、持续维护提升等。这是网络 DevOps 人员操作的重点,未来网络的自动化运行,多数工作都是在该平台上进行的。在 ONAP 上主要涉及三个项目:

  • VNF REQS(VNF Requirements,VNF 需求):描述与定义可被 ONAP 管理的对象的需求。
  • VVP(VNF Validation Program,VNF 验证程序):验证基于 VNF REQS 规范的 VNF HOT 模板和环境文件。
  • VNF SDK:搭建测试验证可被 ONAP 管理对象的一个工具链平台,对符合 ETSI NFV 标准的 VNF(TOSCA 脚本描述)进行测试验证。它也是 LFN 的 CVC(兼容认证项目)的重要组织部分,用于支持以代码化的方案验证可管理对象(VNF 或 PNF)是否满足 VVP 定义的需求。如果验证通过,则将其上线到设计态框架的目录中,供 SDC 设计使用。
  • SDC(Service Design and Creation):定义了多种角色以分别负责业务与资源设计、设计结果测试验证、资源确认等流程。完整设计工作至少需要定义设计者、测试者、验收者这三类角色。当然用户还可按需定义安全专家、客户专家、运维专家来创建相关模型、策略和工作流等。
  1. 运行态框架

运行态框架提供执行框架来执行逻辑,包括两大场景:业务实例化的自动化部署、自动发放场景(通过协同器与控制器两层机制来实现)及闭环控制场景(包括监控、分析、策略等闭环驱动框架能力)。

业务实例化的自动化部署和发放,即按用户在设计态框架中的设计结果及相应实例化的输入信息,实现新业务发放。业务发放过程中需要根据工作负载进行优化,选择对资源的最优部署方案,同时触发 DCAE 系统对设计态明确需要关注的事件进行实时监控。这一阶段完成后,即表明业务已开通,完成了与用户的业务交互。

闭环控制场景则是由事件触发的,即在特定事件或故障发生时,根据预置的动态策略实时闭环处理。它也是前面提到的闭环自动化中的主要使能部分,即设计→创建→收集→分析→检测→发布→响应中除设计之外的所有部分。

运行态框架从自行化层面可分为两层:编排层与控制层。二者的功能有部分重叠。其中编排由跨领域的业务编排器(Service Orchestrator)实现,而控制由各单领域的 Controller 控制器(包括 Multi-VIM,VF-C,SDN-C,APPC 等)实现。

运行态框架还包括一些核心组件与服务:

  • 公共服务(Common Services):提供访问控制、消息 & 文件转发、日志、数据管理等功能。
  • 控制器层公共服务(Common Controller SDKC,CSDK)。
  • 全局数据库(Active and Available Inventory,A&AI)。
  • 数据采集 & 分析(Data Collection, Analytics and Events,DCAE)。
  • 策略框架(Policy)。

运行态框架还包括一些周边服务和模块,它们一般是可选的:

  • 管理界面(Dashboard)。
  • 优化框架(OOF,ONAP Optimization Framework)。
  • 安全框架(Security Framework)。
  • 集成测试(Integration)。
  • 外部接口(External API)。
  • 运维部署服务(ONAP Operations Management,OOM)。
  1. 编排与控制

编排(Orchestration)本为管弦乐中的术语,主要是研究各种管弦乐器运用和配合的方法,通过各种乐器的不同音色来充分表现乐曲的内容和风格。但它在计算机领域被描述为对复杂系统、中间件(middleware)和业务的自动化安排、协调和管理。它与自动化的差别在于,自动化通常专注于一个任务,而编排通常是指与特定任务无关的自动化调度能力,常指对流程与工作流的自动化。通过某种描述语言定义相关工作流,同时由编排器(Orchestrator)负责根据加载的工作流执行对应的动作。

而控制原本是控制论中的术语,描述根据控制对象输出反馈来进行校正的控制方式,比如在实际测量值与计划值发生偏差时,按定额或标准来进行纠正。在 SDN 领域也引入了控制器(Controller)的概念,负责领域内的资源自动化。

在 ONAP 中,对编排器和控制器都给出了自己的定义,其中控制器与行业中的一般概念是有差别的。

首先,这里的控制器与行业中的控制器都有 Orchestration 编排的能力,即支持根据预先定义的工作流或流程,在运行态框架中解析并执行相应动作。这与硬编码的自动化过程的最大差别表现在图形化设计和修改工作流的能力,这跟模型驱动的设计理念是一脉相承的。借助便利的定义操作和无须开发投入的变更操作,编排器提供了灵活的适应性,缩短了新业务或变更业务的上市时间,是 ONAP 架构灵活性的主要使能技术,与 Policy 策略组合在一起,共同提供了可灵活定义流程的能力,让用户从业务和技术策略出发,灵活地完成自动化任务。

ONAP 运行态框架在绝大部分场景中均无须人员介入,需要人员介入往往是在设计流程之前(在设计态框架中完成),但部分过程有可能需要人员干预或是选择动作,如进行例外或事后处理时。

编排支持同时处理大量请求,因此,编排器引擎被设计成一种可重用的服务,以便 ONAP 的任何组件中都可以执行预定义的过程方法。编排服务提供一套公共 API 来保证跨 ONAP 组件的交互的一致性。编排器引擎可解析工作流并遵照执行。这种服务化的设计模式可保证跨所有编排活动的一致性,并保证工作流执行环境一致。

其次,ONAP 中的编排器和控制器的差异仅在于:自动化适用领域的目标与范围 / 层次不同,对编排效率的要求不同,被编排对象是有状态的还是无状态的,如图 3-15 所示(注:MSO 项目在 ONAP 最新版本中已换名为 SO,ASDC 换名为 SDC)。

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

图 3-15 ONAP 中 Orchestrator 编排器与 Controller 控制器的对比**1**

1 引自: https://about.att.com/innovationblog/virtual_functions

SO 即业务编排器,负责从最顶层管理编排工作和实现对下层控制器间的编排,包括理顺控制器间的数据交互,帮助其根据指定的流程和所需信息去完成相应方法所指定的动作。通过自动顺序执行按需创建、修改或移除网络、应用或基础架构业务和资源所需的活动、任务、规则和策略,执行指定的流程。SO 在一个非常高的层次上进行编排,并提供基础设施、网络和应用的端到端视图。

SO 性能要求相比控制器更低(图 3-15 所示的分钟级只是示例,具体要求视业务场景而定),且一般要求被编排对象是无状态的。对新业务来说,这可能涉及业务、资源优化部署的决策,以及为满足业务请求参数,选择具备相应能力的控制器来处理。如果现有控制器(基础设施、网络或应用)不存在或不具备相关能力,SO 将创建并实例化一个新的控制器,以执行相应业务请求。

SO 通过访问 A&AI 取得已有网络和对应控制器的信息来支持业务请求。A&AI 提供可支持业务请求的候选控制器的地址;然后 SO 询问控制器是否仍具备相关能力;最后 SO 和控制器向 A&AI 报告完成业务请求的参考信息,以供随后的操作使用。SO 执行的编排工作包括:

  • 现有业务的交付或变化。
  • 业务伸缩、优化或迁移。
  • 控制器实例化。
  • 容量管理。

尽管重点在编排,所有方法仍需要使用配置信息、标识符和 IP 地址来更新 A&AI。

控制器是一些应用程序,这些应用程序将云和网络业务耦合,并执行配置和实时策略,以及控制分布式组件和业务的状态。运营商可以选择使用多种不同类型的控制器来管理执行环境中与其分配的控制域中相应的资源。控制器负责单业务或网络领域的自动化编排,效率要求一般是秒级或更高。其管理对象可能是有状态的,意为控制器需要保存相应领域资源的状态,并能对相应事件进行实时响应。目前社区主要有如下控制器:

  • 基础设施控制器(Multi-VIM):为 VIM/ 云提供基础设施适配层,除了提供标准 VIM 的管理功能适配外,还可提供对 HPA(硬件平台感知功能)的支持,以便 OOF 及 SO/VF-C 等组件基于硬件差异对资源进行最优化部署。比如,Multi-VIM 可在 SO 的请求下创建 / 启动一个或多个虚机,并加载合适的 VNF。当 Multi-VIM 完成请求之后,会把虚拟资源识别符和访问信息(IP)返回给 SO 并更新到 A&AI 等,以供其他制器使用。
  • 网络控制器(SDN-C):构建和操作方式跟基础设施控制器类似,支持在 SO 的请求之下,建立 LAN 或 WAN 连接并进行配置。
  • 应用控制器(APPC):在 SO 的请求下完成 VNF 的实例化、配置或规模伸缩等 LCM 操作。需要注意的是,APPC 不负责 VNF 的创建与删除,这是在 SO 层面完成了的(更新 A&AI 即完成),即 VIM 基础设施层的资源分配等由 SO 调用基础设施控制器完成。APPC 比较适用于简单的 VNF(单虚机或容器)或者多 VNF,但多 VNF 之间没有复杂的网络或依赖关系。
  • 虚拟功能控制器(VF-C):ONAP 的控制器领域提供了符合 ETSI NFV MANO 标准的解决方案,它提供的是符合 ETSI NFV 标准定义的 NS(网络业务,Network Service)粒度的接口。VF-C 适用于类似 vEPC、vIMS 等复杂电信级 VNF(需要多个虚机或容器资源,且互相之间有复杂的网络与依赖关系等),VF-C 一般通过自身拥有的通用 VNF 管理器 gVNFM 或对接符合 ETSI NFV 标准的厂商 VNF 管理器 sVNFM 来实现对 NS 的 LCM 管理。

注:控制器目前选择与编排器不同的编排引擎,在 SO 中使用的是 Camunda 工作流引擎,编排脚本是符合 BPMN 标准的 bpmn 脚本,而 SDN-C 与 APPC 使用的是 DG(有向图)工作流引擎,脚本采用 Node-Red(一个面向 IoT 场景的工作流开发工具 https://nodered.org/ )的 XML 文件。当前 DG 引擎在 CCSDK 项目中,未来不排除某些控制器采用其他编排引擎甚至重用 Camunda 引擎的可能。

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

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

评论

发布