ONAP架构概述（文末附完整版PDF下载）

1.概述

随着电信运营商、有线运营商、云业务运营商以及他们的方案提供商对通用平台需求的增加，ONAP项目应时而生，并致力于在充分利用现有投资的前提下，提供按需定制、有竞争力的、差异化的网络服务。

在ONAP诞生之前，大型网络运营商为了提供新的业务，在从安装新的数据中心设备到（某些情况下）升级客户现场设备等一系列工作中，需要执行大量的人工调整工作。这种人工模式的规模和成本均对运营商提出了重大的挑战。许多运营商都在寻求利用SDN和NFV技术，提高业务创新速度，简化设备的互操作性和集成难度，降低整体的资产投入和运营成本。另外，目前高度分散的管理场景也使得端到端级别的业务质量难以得到监控和保障。

ONAP通过为物理和虚拟网络设备提供全局的和大规模（多站点和多VIM）的编排功能来解决这些问题。它通过提供一套通用的、开放的、可互操作的北向REST接口，以及支持YANG和TOSCA数据模型来提高业务敏捷性。ONAP的模块化和分层特性有助于提高互操作性并简化集成过程，它可以能够与多个VIM、VNFM、SDN控制器甚至传统网络设备的集成来支持多个VNF的环境。ONAP对VNF的整体要求发布将助力符合ONAP标准的VNF的商业部署。这样既可以帮助网络和云业务运营商优化他们的物理和虚拟基础设施，以降低成本、提高性能；同时，ONAP采用标准模型，降低了异构设备的集成和部署成本，同时最大限度地减少了管理的碎片化。

在ONAP平台上，终端用户组织和他们的网络/云业务提供商可以在一个动态、闭环过程中进行协作，实例化网络设备和业务，并对操作类事件进行实时响应。为了设计、实施、规划、计费和保障这些动态业务，主要有三方面的要求：

• 一个健壮的设计框架，可以在各个方面对业务进行规范，包括：对组成业务的各类资源和关系进行建模，制定指导业务行为的策略规则，制定业务弹性管理所需的应用、分析和闭环事件。
• 一个流程/策略驱动的编排和控制框架（业务编排器和控制器），在必要时提供自动的业务实例化，并能够弹性管理业务需求。
• 一个分析框架，可以根据指定的设计、分析和策略，密切监控整个业务生命周期中的行为，实现控制框架所要求的响应，从而可以对从设备自愈到根据需求变化对资源进行扩缩容调整等各种情况进行处理。

为此，ONAP将特定业务和技术细节从通信信息模型、核心编排平台和通用管理引擎（用于发现、配置和保障等）中分离出来。此外，它将DevOps/NetOps方法的效率和模式与运营商引入新业务和技术所需求的正式模型和过程相结合。它利用包括Kubernetes在内的云原生技术来管理和快速部署ONAP平台及相关组件。传统的OSS/管理软件平台架构会对业务和技术进行硬编码，在整合变化时需要很长的软件开发和集成周期，ONAP与之形成鲜明的对比。

ONAP平台根据以下基本原则，支持产品/业务的独立的设计、创建和生命周期管理：

• 在不需要平台软件新版本发布和影响现有业务操作的情况下，可以为新业务动态进行全生命周期编排（包括设计、配置和运营）和业务API部署；
• 电信级的可扩展性，包括横向扩展（线性扩容）和分发，以支持大量的业务和大规模网络；
• 元数据驱动和策略驱动的架构，以确保使用和发布功能的灵活性和自动化；
• 架构应该支持采用最好的组件；
• 常用功能只需要一次开发，多次复用；
• 核心功能应支持多种不同的业务和基础设施；
• 随着需求增长或收缩，架构应支持弹性扩展。

2.ONAP架构

ONAP平台提供了构建特定行为所需的通用功能（例如：数据采集、闭环控制、元数据流程创建、策略/流程分发等）。

当创建一项业务或运营能力时，需要利用ONAP设计框架的Portal模块来开发业务/运营特定的业务定义、数据采集、分析方法和策略（包括纠正/补救措施的流程）。

图2展示的是ONAP架构和基于微服务的平台组件的高层次视图。

在下面图3中，我们提供了ONAP架构的功能视图，突出新的关键组件的作用：

• 1.利用外部API组件，北京版本对ONAP平台的北向接口进行了标准化并改进其互操作性。
• 2.OOM提供了Kubernetes托管云环境下管理云原生安装和部署的能力
• 3.现在ONAP的通用服务可以管理更加复杂和优化的拓扑。MUSIC允许ONAP扩展到多站点环境，以支持全局规模的基础架构需求。OOF提供一种声明性的、策略驱动的方法用于创建和运行优化应用，如归属/位置、变更管理调度优化等。
• 4.信息模型和框架实用程序已经可以协同众多标准化组织的拓扑、工作流和策略模型，包括ETSI NFV MANO、TM Forum SID、ONF Core、OASIS TOSCA、IETF和MEF等。

3.微服务支持

作为由大量业务组成的云原生应用，ONAP的初始部署和运营管理十分复杂

ONAP的部署方法应足够灵活，以适应各种运营环境的不同场景和目标。用户可能希望只选择部分ONAP组件集成到他们自己的系统中。同时，ONAP平台应该是高可靠、可扩展、安全且易于管理的。为了实现这些目标，ONAP被设计为基于微服务的系统，其所有组件都通过Docker容器发布。

OOM负责协调端到端的生命周期管理和ONAP组件的监控。 OOM通过Kubernetes来提高CPU利用率并提供平台部署方法。另外，通过增强其管理组件的可扩展性和弹性，OOM有助于提升ONAP平台的成熟度。

OOM是ONAP平台的生命周期管理器，它利用Kubernetes容器管理系统和Consul提供以下功能：

• 1.部署 - 内置组件的依赖管理（包括多集群，跨站点的联合部署和反亲和性规则）
• 2.配置 - 所有ONAP组件的统一配置
• 3.监控 - 实时的健康监控，将监控的数据提供给Consul GUI和Kubernetes
• 4.重启 - 启动失败的ONAP组件将自动重启
• 5.集群和扩展 - 集群化的ONAP业务可实现无缝扩展
• 6.升级 - 在轻微或不影响业务的情况下更换容器或配置
• 7.删除 - 清除单个容器或整套部署

OOM与MSB组件项目集成。MSB提供基本的微服务支持，例如服务注册/发现、外部API网关、内部API网关、客户端SDK和Swagger SDK。MSB还支持OpenStack（Heat）和裸机部署。

4.Portal

基于用户角色，ONAP可以在设计态和运行态两种环境下提供统一一致的用户体验。在单个ONAP实例中可以对角色进行修改定制。

ONAP的Portal对用户体验进行管理，它通过共享的、基于角色的菜单或仪表盘，提了设计、分析和运营控制/管理功能的操作入口。Portal架构提供了基于Web的各种能力，包括应用的上线和管理、集中访问控制、仪表盘和托管应用程序小部件等。

Portal提供了SDK，可以使多个开发团队利用内置模块（服务/API/UI控件）、工具和技术满足其一致的UI开发需求。ONAP也为部分操作人员提供所需（例如：当他们需要与他们的脚本环境集成时）的命令行界面（CLI）。ONAP SDKs可以使运营/安全、第三方（例如：供应商和顾问）和其它领域的专家不断地定义/优化新的采集、分析方法和策略（包括纠正和补救行为的策略），他们通过使用ONAP设计框架的Portal就可以完成这些工作。

5.设计态框架

设计态框架是一个全面的开发环境，它包括了各种工具、技术以及定义/描述资源、服务和产品的资源库。

设计态框架有助于模型的复用，随着可用模型的增大，可以更进一步地提高效率。资源、业务和产品，以及它们的管理和控制功能都可以使用一套用于控制行为和流程执行的规范和策略（例如规则集）进行建模。流程规范可以自动顺序完成资源、业务、产品和ONAP平台组件的实例化、发布和生命周期管理。某些特定的流程规范和策略可以根据地理位置进行分发部署，从而提升联合云环境下的性能优化和自动化程度。

SDC提供定义/模拟/验证系统资产及其相关过程和策略所需的工具、技术和存储库。每一项资产都可以归到资源、业务、产品、要约等四类的一种。

SDC环境通过通用服务和实用程序支持不同的用户。通过使用设计工作室，产品和业务的设计人员可以上线/扩展/下线资源、业务和产品。操作人员、工程师、客户体验经理和安全专家创建工作流、策略和方法，来实现闭环自动化/控制和管理弹性扩展能力。

为了支持和鼓励一个健康的VNF生态，ONAP在VNF供应商API、VNF SDK和VVP组件中提供一套VNF打包和验证工具。厂商可以在他们的CI（持续集成）/CD（持续交付）环境中集成这些工具，从而打包VNF，并将其上传到验证引擎。一旦经过测试，这些VNF就可以通过SDC上线。

Policy Creation组件用于处理策略；这些是必需提供、维护和/或强制执行的规则、条件、要求、约束、属性或需求。在较低的层面上，策略包括机器可读的规则，使得机器可以基于触发器或请求采取行动。策略通常考虑实际应用中的特定条件（无论是在符合条件时触发特定的策略，还是采取特定的策略以接近特定的条件）。

策略允许通过更新规则进行快速修改，从而在不需要重写软件代码的情况下，更新使用这些策略的组件的技术行为。策略允许通过抽象简化对复杂机制的管理/控制。

CLAMP为闭环控制的设计和管理提供了一个平台。CLAMP用于设计一个闭环，针对某一项网络业务配置其特定的参数，然后部署和停止使用。一旦部署，用户可以在运行期间内更新控制环的参数，也可以暂停和重新启动它。

完整版PDF下载链接：https://pan.baidu.com/s/151e1-WShuIY_xQZNUlQugQ