ONAP架构概述
相关阅读
- ONAP平台架构与5G蓝图：https://rtoax.blog.csdn.net/article/details/104392826
- ONAP主页：https://www.onap.org/
该文档摘自《ONAP_CaseSolution_Architecture_Chinese_062519.pdf》，侵删。
Table of Contents
概述
架构
安装与部署
微服务支持
OOM
Portal门户网站
SDK
设计态框架
运行态框架
编排
策略驱动的工作负载优化
控制器
清单
多云自适应
闭环自动化
共享服务
建模
行业进展
蓝图
蓝图
概述
随着电信运营商、有线运营商、云服务提供商以及他们的方案提供商对通用自动化平台需求的增加，ONAP项目应时而生，并致力于在充分利用现有投资的前提下，提供差异化的、按需定制的、有竞争力的网络服务。
ONAP所面临的挑战是要帮助通信运营商提供新的业务，在从安装新的数据中心设备到（某些情况下）升级客户现场设备等一系列工作中，需要执行大量的人工调整工作。这种人工模式的规模和成本均对运营商提出了重大的挑战。许多运营商都在寻求利用SDN和NFV技术，提高业务创新速度，简化设备的互操作性和集成难度，降低整体的资产投入和运营成本。另外，目前碎片化的管理场景也使得端到端级别的业务质量难以得到监控和保障。截止当前ONAP已准备发布第四个版本，这些挑战在现网依然存在。
ONAP通过为物理和虚拟网络设备提供全局的和大规模（多站点和多VIM）的自动化功能来解决这些挑战。它通过支持可以快速定义资源的TOSCA数据模型，提供一套通用的、开放的、可互操作的北向REST接口，以及支持YANG和TOSCA数据模型来提高业务敏捷性。ONAP的模块化和分层特性有助于提高互操作性并简化集成过程，它能够与多个VIM、VNFM、SDN控制器以及传统网络设备（PNF）的集成来支持多VNF的环境。ONAP对xNF的整体要求发布推动了符合ONAP标准的xNF的商业部署。这样既可以帮助网络和云业务运营商优化他们的物理和虚拟基础设施，以降低成本、提高性能；同时，ONAP采用标准模型，降低了异构设备的集成和部署成本。实现这些的同时，还最大限度地减少了管理的碎片化。
ONAP平台允许最终用户组织及其网络/云提供商以快速和动态的方式协同实例化网元和业务，并支持一个能够实时响应可执行事件的闭环流程。为了设计、实施、规划、计费和保障这些动态业务，主要有三方面的要求：
- • 一个健壮的设计框架，可以在各方面对业务进行规范，包括：对组成业务的各类资源和关系进行建模，制定指导业务行为的策略规则，制定业务弹性管理所需的应用、分析和闭环事件。
- • 一个流程/策略驱动的编排和控制框架（业务编排器和控制器），在必要时提供自动的业务实例化，并能够弹性管理业务需求。
- • 一个分析框架，可以根据指定的设计、分析和策略，密切监控整个业务生命周期中的行为，实现控制框架所要求的响应，从而可以对从设备自愈到根据需求变化对资源进行扩缩容调整等各种情况进行处理。
为此，ONAP将特定业务和支持技术细节从通用信息模型、核心编排平台和通用管理引擎（用于发现、配置和保障等）中分离出来。此外，它将DevOps/NetOps方法的效率和模式与运营商引入新业务和技术所需求的正式模型和过程相结合。它利用包括Kubernetes在内的云原生技术来管理和快速部署ONAP平台及相关组件。传统的OSS/管理软件平台架构会对业务和技术进行硬编码，在整合变化时需要很长的软件开发和集成周期，ONAP与之形成鲜明的对比。
ONAP平台根据以下基本原则，支持业务/资源的独立的设计、创建和生命周期管理：
- • 在不需要平台软件新版本和影响现有业务的情况下，可以发布新业务，并对新技术动态进行全生命周期编排（包括设计、配置和运营）和业务API部署；
- • 电信级的可扩展性，包括横向扩展（线性扩容）和分发，以支持大量的业务和大规模网络；
- • 元数据驱动和策略驱动的架构，以确保使用和发布功能的灵活性和自动化；
- • 架构足够灵活，可采用最好的组件；
- • 通用功能只需要一次开发，多次复用；
- • 核心功能支持多种不同的业务和基础设施；
此外，ONAP还提供了一个具有组件定义和接口的功能架构，它提供了除了开源代码之外的与行业对齐的能力。
架构
ONAP平台提供了构建特定行为所需的通用功能（例如：数据采集、闭环控制、元数据流程创建、策略/流程分发等）。
当创建一项业务或运营能力时，ONAP支持在设计态框架界面上设计业务/运营特定的业务定义、数据采集、分析方法和策略（包括纠正/补救措施的流程）。
图1展示的是基于微服务平台组件的ONAP架构概要设计视图。
图 1: ONAP平台架构 (Dublin版本)
下文的图2提供了ONAP架构的简化功能视图，突出部分关键组件的作用：
- 1. 设计态环境用于往ONAP上线业务和资源，并基于它们设计新业务。
- 2. 对外API组件为ONAP平台的北向接口提供了互操作性，同时Multi-VIM/CLOUD模块支持ONAP系统负荷在云间的互操作。
- 3. OOM提供了Kubernetes托管云环境下云原生安装和部署的能力
- 4. ONAP Shared Services为ONAP模块提供共享能力。MUSIC允许ONAP扩展到多站点环境，以支持全局规模的基础架构需求。OOF提供一种声明性的、策略驱动的方法用于创建和优化应用，如归属/位置、变更管理调度优化等。Logging提供集中的日志管理能力，Audit(pomba)提供了解析编排动作的能力。
- 5. ONAP shared utilities为ONAP组件支持提供了实用工具。
- 6. 信息模型和框架实用程序持续演进，以协同众多标准化组织的拓扑、工作流和策略模型，包括ETSI NFV MANO、TM Forum SID、ONF Core、OASIS TOSCA、IETF和MEF等。
图 2: ONAP架构的功能视图
Dublin版本在设计态和运行态领域、ONAP安装和S3P等领域提供了许多重要的新功能和特性。
- 设计态：Dublin版本已经引入控制器设计工作室（controller design studio）作为控制器框架的一部分，它使得ONAP控制器通过模型驱动的方法来控制网络资源。
- 运行态：业务编排和生命周期管理项目具有支持物理网络功能（PNF）、横向扩展、重启、流量迁移、扩展的硬件平台感知（HPA），归属优化服务，地理冗余和边缘云部署等新功能。 这将扩展生命周期管理工具包的操作集，提高性能和可用性，并解锁边缘自动化和5G用例。通过支持ETSI NFV-SOL003，可以让ONAP兼容集成VNFM。
为了便于VNF厂商集成，ONAP引入了一些映射组件，这些组件将特定事件（SNMP traps、telemetry、3GPP PM）转换为ONAP VES的标准化事件。
Policy项目支持多协议引擎，而且可通过SDC中的策略设计功能分发策略，从而简化设计过程。另外，Holmes告警关联引擎继续支持GUI功能，并通过脚本简化告警关联规则的开发。
ONAP北向API继续更好的支持TMF API（如Service Catalog, Service Inventory, Service Order and Hub API）和MEF API（围绕Legato and Interlude API），以简化与OSS/BSS的集成。VID and UUI operations GUI项目可通过简单的点击界面支持更多的生命周期管理操作，使操作员可以轻松执行更多任务。此外，CLAMP项目支持了一个新的仪表板，可用于在设计态和运行态期间观测DMaaP和其它事件，以简化控制环自动化的调试。ONAP已经在特定组件中引入了ISTIO，以促进服务网格Service Mesh的引入。
安装与部署
ONAP安装：ONAP Operations Manager（OOM）通过利用Kubernetes（Docker和Helm Chart技术）进一步简化ONAP的安装。在卡萨布兰卡版本中，OOM支持包括GlusterFS在内的可插拔的持久化存储，为用户提供更多的存储选项。在多节点部署中，在可用资源和节点的选择上，OOM可以对业务部署进行更多的控制。最后，OOM现在支持整套k8s部署的备份/恢复，从而引入数据保护。
可部署性：Dublin版本延续了之前北京版本的7维指标体系（稳定性、安全性、可扩展性、性能，以及弹性、可管理性和可用性）。新的日志项目——Post Orchestration Model Based Audit（POMBA）可以检查设计模型和运行实例数据的偏差，从而提高网络业务的可靠性。包括Logging、SO、VFC、A&AI、Portal、Policy、CLAMP和MSB在内的许多其他项目，在性能、可用性、日志记录、迁移到云原生架构、身份验证、稳定性、安全性和代码质量等方面都有所改进。最后，集成在ONAP中的OpenDaylight和Kafka版本都更新到Oxygen和v0.11版本，分别提供P4和数据路由等新功能。
微服务支持
作为由大量业务组成的云原生应用，ONAP的初始部署和运营管理十分复杂
ONAP的部署方法应足够灵活，以适应各种运营环境的不同场景和目标。用户可能希望只选择部分ONAP组件集成到他们自己的系统中。同时，ONAP平台应该是高可靠、可扩展、安全且易于管理的。为了实现这些目标，ONAP被设计为基于微服务的架构体系，其所有组件都通过Docker（Docker 是一个开源的应用容器引擎）容器发布，容器遵循最佳构建规则，以优化其镜像大小。为了减少ONAP的占用空间，首先实现了共享数据库，和一个Cassandra和mariadb-galera集群。
OOM负责协调端到端的生命周期管理和ONAP组件的监控。 OOM通过Kubernetes来提高CPU利用率并提供平台部署方法。另外，通过增强其管理组件的可扩展性和弹性，OOM有助于提升ONAP平台的成熟度。
OOM
OOM是ONAP平台的生命周期管理器，它利用Kubernetes容器管理系统和Consul提供以下功能：
- 部署 - 内置组件的依赖管理（包括多集群，跨站点的联合部署和反亲和性规则）
- 配置 - 所有ONAP组件的统一配置
- 监控 - 实时的健康监控，将监控的数据提供给Consul GUI和Kubernetes
- 重启 - 启动失败的ONAP组件将自动重启
- 集群和扩展 - 集群化的ONAP业务可实现无缝扩展
- 升级 - 在轻微或不影响业务的情况下更换容器或配置
- 删除 - 清除单个容器或整套部署
OOM支持大量云基础架构，以满足您的个性化需求。
微服务总线（MSB）提供基础的微服务支持，包括服务注册/发现、外部API网关、内部API网关、客户端软件开发工具包（SDK）和Swagger SDK。MSB同时支持OpenStack（Heat）和裸机部署。当与OOM集成时，MSB有一个Kube2MSB注册器，它可以从k8s元文件中获取服务信息，并自动注册ONAP组件的服务。
本着借用微服务能力的原则，在Dublin版本中进一步采取了模块化，业务编排器(SO) 和控制器已经提升了模块化水平。
Portal门户网站
基于用户角色，ONAP可以在设计态和运行态两种环境下提供统一一致的用户体验。在单个ONAP实例中可以对角色进行修改定制。
ONAP的Portal对用户体验进行管理，它通过共享的、基于角色的菜单或仪表盘，提了设计、分析和运营控制/管理功能的操作入口。Portal架构提供了基于Web的各种能力，包括应用的上线和管理、通过认证和认证框架（AAF）的集中访问控制、仪表盘和托管应用程序小部件等。
SDK
Portal提供了SDK，可以使多个开发团队利用内置模块（服务/API/UI控件）、工具和技术满足其一致的UI开发需求。ONAP也为部分操作人员提供所需（例如：当他们需要与他们的脚本环境集成时）的命令行界面（CLI）。ONAP SDKs可以使运营/安全、第三方（例如：供应商和顾问）和其它领域的专家不断地定义/优化新的采集、分析方法和策略（包括纠正和补救行为的策略），他们通过使用ONAP设计框架的Portal就可以完成这些工作。
设计态框架
设计态框架是一个全面的开发环境，它包括了各种工具、技术以及定义/描述资源、服务和产品的资源库。
设计态框架有助于模型复用，随着可用模型规模的增大，可以更进一步地提高效率。资源、业务和产品，以及它们的管理和控制功能都可以使用一套控制行为和流程执行的规范和策略（例如规则集）进行建模。流程规范可以自动完成资源、业务、产品和ONAP平台组件的实例化、发布和生命周期管理。某些特定的流程规范和策略可以根据地理位置进行分发部署，从而提升混和云环境下的性能优化和自动化程度。
SDC提供定义/模拟/验证系统资产及其相关过程和策略所需的工具、技术和存储库。在Dublin版本中SDC还支持TOSCA1.3列表类型定义，它提供了设计复杂业务描述符的能力。
SDC环境通过通用服务和实用程序支持不同用户。操作人员、工程师、客户体验经理和安全专家创建工作流、策略和方法，来实现闭环自动化/控制和管理弹性扩展能力。
为了支持和鼓励一个健康的VNF（网路功能虚拟化技术）生态，ONAP在VNF供应商API、VNF SDK和VVP组件中提供一套VNF打包和验证工具。厂商可以在他们的CI（持续集成）/CD（持续交付）环境中集成这些工具，从而打包VNF，并将其上传到验证引擎。一旦经过测试，这些VNF就可以通过SDC上线。另外，VNFSDK的测试功能正在LFN合规性认证计划中使用，以确保采用高度一致的VNF验证方法。
Policy Creation组件用于处理策略；这些是必需提供、维护和/或强制执行的规则、条件、要求、约束、属性或需求。在较低层面上，策略包括机器可读的规则，使得机器可以基于触发器或请求采取行动。
策略通常考虑实际应用中的特定条件（无论是在符合条件时触发特定的策略，还是采取特定的策略以接近特定的条件）。策略允许通过更新规则进行快速修改，从而在不需要重写软件代码的情况下，更新使用这些策略的组件的技术行为。策略允许通过抽象简化对复杂机制的管理/控制。
运行态框架
运行态执行框架执行SDC分发的规则和策略。
运行态框架允许在不同的ONAP模块（例如SO，控制器，DCAE，A&AI）中分发策略实施、模板，以及一个安全的框架。这些组件都使用了支持日志、控制访问和数据管理的通用服务。新组件MUSIC允许平台注册和管理多个站点的部署状态。外部API为第三方框架（例如MEF、TM Forum等）提供访问接口，从而支持运营商BSS与ONAP相关组件间的交互。日志服务还包括基于事件的一致性校验功能，从而支持编排后的一致性分析。
编排
SO组件通过自动顺序执行按需创建、修改或移除网络、应用或基础架构业务和资源所需的活动、任务、规则和策略，从而执行指定的流程。SO在一个非常高的层次上进行编排，并提供基础设施、网络和应用的端到端视图。
ONAP外部API接口(External API)，北向接口模块，当前通过实现TMF API向OSS/BSS开放ONAP的能力。在上一个版本Casablanca中，外部API已经提供了一套业务订单、业务存量、业务目录和事件发布/订阅服务订单通知管理。在Dublin版本中，外部API首次正式参与到两个批准的ONAP蓝图中，一个是宽带业务 (BBS)，第二个是跨域跨层VPN (CCVPN)。
VID应用可以使用户从SDC实例化基础架构服务及其相关的组件，并执行变更管理操作，例如对现有VNF实例进行扩展和更新软件。
策略驱动的工作负载优化
OOF提供一个策略驱动和模型驱动的框架，用于为各种用例创建优化应用。 OOF HAS是一个策略驱动的工作负载优化服务，可基于各种策略约束（包括容量，位置，平台能力和其它特定的业务约束）实现跨多站点和多云的业务优化部署。
ONAP MC和其它一些ONAP组件（如Policy、SO、A&AI等）在通过OOF-HAS实现跨云站点的“策略驱动的性能/安全感知的自适应工作负载部署/调度”中发挥了重要的作用。 OOF-HAS利用HPA和ONAPMC提供的实时容量检查，来确定最优的VIM /云实例，这些实例可以为工作负载（VNF等）的部署和调度（归属）提供所需的性能SLA。现在运营商在保障性能和安全SLA的同时，可以通过云资源的细粒度优化实现虚拟化的真正价值。
控制器
控制器是一些应用程序，这些应用程序将云和网络业务耦合，并执行配置和实时策略，以及控制分布式组件和业务的状态。运营商可以选择使用多种不同的控制器类型，来管理执行环境中与其分配的控制域中相应的资源，例如云计算资源（网络配置SDN-C和应用App-C），而不是仅使用单一的整体控制层。此外，VF-C提供符合ETST NFV标签的NFVO功能，并负责虚拟业务和相关物理的（CTOS）通用服务器基础设施的生命周期管理。VF-C提供通过的VNFM功能，同时也可以与外部的VNFMS和VIM集成，作为NFO MANO堆栈的一部分。
清单
A&AI提供系统资源、业务、产品及其相互关系的实时视图，它还保留了历史视图。A&AI提供的视图将多个ONAP实例管理的数据、业务支持系统（BSS）、运营支持系统（OSS）和网络应用进行关联，从而形成一个从终端用户购买的产品到形成产品原材的资源的自上而下的视图。A&AI不仅形成产品、业务和资源的注册表，还保持这些清单项目的相互关系的最新视图。
为了保证SDN/NFV的承诺的动态特性，当控制器在网络环境进行更改时，会对A&AI进行实时更新。A&AI是元数据驱动的，允许通过SDC产品目录定义快速地动态添加新的清单类型，从而避免冗长的开发周期。
多云自适应
Multi-VIM/Cloud为VIM /云提供基础设施适配层，除了标准功能外，还可以提供高级硬件平台的感知和意图功能，可用于OOF，以及为云无关工作负载部署增强云选择和SO/VF-C的其他组件。
闭环自动化
闭环控制是由许多设计态和运行态元素间的协作完成的。运行态环始于数据采集器DCAE。ONAP包括以下采集器：事件采集器VES、大容量事件采集器HV-VES、用于SNMP Trap的SNMP、接收文件的文件采集器File Collector、采集通知的Restconf采集器。数据采集/验证之后，数据经过微服务循环（如用于事件检测的Homes、用于决定动作的Policy），最后由控制器和协同器实现动作。CLAMP用于监视这些闭环自身。CLAMP、Policy和DCAE都可以在设计态中创建闭环。
我们将这种自动化模式称为“闭环自动化”，是因为它提供了必要的自动化功能，可以在没有人工干预的情况下对网络和业务条件进行响应。图3是“闭环自动化”的高级示意图，显示了使用自动化功能后业务生命周期内的不同阶段。
闭环控制是通过DCAE和一个或多个其它ONAP运行态组件提供的。它们共同提供FCAPS功能。DCAE收集性能、使用情况和配置数据，提供分析计算，帮助排除故障和发布事件、数据和分析方法（例如向策略、编排器和数据湖发布）。另一个组件Holmes与DCAE连接，为ONAP高容量VES和批量性能管理支持的新数据采集功能提供告警关联功能。
通过与Policy Framework和CLAMP协作，这些组件可以检测网络中存在的问题，并确定适当的补救措施。在某些情况下，这个工作是自动的，并且它们会通知SO或其中一个控制器采取行动。在其它情况下，根据操作人员的配置，它们会发出一个警报，在人工干预后再执行操作。通过引入自适应的策略执行，policy framework得到扩展，可以支持其他策略决策能力。
图 3 ONAP闭环自动化
共享服务
ONAP为所有ONAP组件提供一套运行服务，包括活动记录、报告、通用数据层、访问控制、弹性和软件生命周期管理。
这些服务提供访问管理和安全执行、数据备件恢复和修复。它们支持标准化的VNF接口和指南。
在虚拟化的环境中运行会引入新的安全挑战和机遇。ONAP通过在每个ONAP平台组件中嵌入访问控制来提供更高的安全性，同时专门设计用于检测和调整违规操作的分析和策略组件来进一步增强安全性。
建模
ONAP提供的模型有助于业务设计，ONAP服务组件的开发以及标准互操作性的改进。
模型是设计态和运行态框架开发的重要组成部分。ONAP建模项目利用成员公司、标准化组织和其他开源项目的经验，生成简单、可扩展和可重用的模型。目的是满足不同用例的需求，指导开发，保证ONAP组件间的一致性，并探索一个通用模型来提高ONAP的互操作性。
在Dublin（达布林）0版本中，ONAP支持下列模型：
- • 基于ETSI NFV IFA011 v.2.5.1的VNFD信息模型，根据ONAP的需求进行了适当的修改
- • 基于ETSI NFV IFA014 v2.5.1的PNFD信息模型。
- • 基于TOSCA实现的VNFD，基于IM和ETSI NFV的SOL001 v 2.5.1的数据模型已由SDC实现，vCPE用例支持。
- • 基于ETSI NFV SOL004规范的VNF包格式，在VNF SDK项目中被支持。
- • 基于ETSI NFV IFA规范和A&AI实现的VNF实例模型
- • 通过VFC（使用建模项目提供的解析功能）实现了网络业务描述符（NSD）。
- • 这些模型使ONAP可以与其它基于标准的实现进行交互，并促进产业合作。
在Dublin版本中，除了解析器库之外，建模项目还引入了通用解析器，作为一个独立的服务，它将为其他项目提供Tosca解析器的restful API。
行业进展
在架构上，ONAP很明显支持和其他标准和开源社区的协作。如：
使用了MEF和TMF的接口
• 除了上面提到的ETSI-NFV定义的VNFD和NSD模型外，ONAP还支持NFVO的接口（如SO和VFC之间的SOL005接口，SO或者VFC到外部VNFM之间的SOL003接口）。
想要获取更多信息，请阅读此白皮书：ONAP的进展：开源和标准协同。
白皮书：https://download.csdn.net/download/Rong_Toa/12171369
蓝图
理论上，ONAP可以支持无限量的用例。但是，为了提供如何使用ONAP解决实际问题的具体示例，开发社区已经创建了一套蓝图。除了通过端到端的解决方案帮助用户快速采用ONAP平台之外，这些蓝图还有助于社区优先处理他们的工作。随着ONAP Dublin版本的发布，我们在家庭连接领域推出了一个新的蓝图：宽带业务（Broadband Service）。之前的蓝图是vCPE、VoLTE、vFW/vDNS、5G、CCVPN。其中5G和CCVPN在Dublin版本中进行了特性增强。
蓝图
5G蓝图是经过多个版本的努力，围绕PNF集成、网络优化和网络切片三个方面。eMBB（承诺20 Mbps的峰值速率）、uRLLC（保证亚毫秒响应时间）和MMTC（可支持每平方英尺0.92个设备）的组合为它带来一些独特的需求。首先，ONAP需要对网络基于实时和批量分析进行优化，将VNF放置在合理的边缘云上，进行业务的扩缩容和自愈，并提供边缘自动化。其次，ONAP需要处理端到端的网络切片。这些需求已经导致以上列出的三方面内容。在Casablanca和Dublin版本期间，5G蓝图完成了PNF集成、边缘自动化、实时批量分析、homing（VNF放置）、扩缩容和建模工作，这些将在未来版本中支持端到端网络切片。
图 4 解耦的混合RAN网络
了解更多信息请阅读5G Blueprint：ONAP平台架构与5G蓝图：https://mp.csdn.net/console/editor/html/104392826。