NFV故障关联及故障自愈方案研究

毛斌宏，阳志明

（中国电信股份有限公司广州研究院，广东 广州 510630）

NFV故障关联及故障自愈方案研究

毛斌宏，阳志明

（中国电信股份有限公司广州研究院，广东 广州 510630）

利用NFV实现电信网络设备软硬件解耦，摆脱了对专用硬件设备的依赖，并能利用NFV资源共享、自动部署、弹性伸缩等特性，但同时也带来了故障点多、故障定位分析困难等问题，导致NFV网络的运营维护难度增加。分析了NFV故障处理的流程及故障关联方案，为NFV场景下的故障定位处理提供指引。同时给出了VNF故障自愈实现方案，利用VNF特性，实现网元及业务自愈，提升自动化运维能力。

NFV；MANO；故障关联；故障自愈

1 引言

SDN（software defined networking，软件定义网络）/NFV（network function virtualization，网络功能虚拟化）是当前电信网络技术研究的热点之一，NFV通过使用x86等通用性硬件以及虚拟化技术，承载通信网络处理功能，使网络设备功能不再依赖于专用硬件、资源可以灵活共享，实现新业务的快速开发和部署，并基于实际业务需求进行自动部署、弹性伸缩等。参照ETSI NFV系统架构，如图1所示，虚拟化实现了底层物理设备和上层操作系统、应用软件的解耦，而MANO（management and orchestration，管理和编排）则提供一个可管、可控、可运营的服务提供环境，使得底层基础设施可以便捷地提供给应用。MANO实现NS（network service，网络服务）及VNF（virtual network function，虚拟网元功能）生命周期管理相关的业务部署、资源调度和运维管理功能。

MANO包含 3个功能模块：NFVO（NFV orchestrator，NFV 编排器）、VNFM（virtual network function management，虚拟网元功能管理）和VIM（virtualized infrastructure management，虚拟化基础设施管理）。

· NFVO：主要负责跨VIM的NFVI资源编

排及NS的生命周期管理。

· VNFM：主要负责VNF的生命周期管理，包括VNF实例化、VNF弹性扩缩容、VNF终止等。VNFM一般分为通用VNFM和专用VNFM，其中专用VNFM可以部署多个，一个专用VNFM可以管理同一厂商的多个VNF。

· VIM：主要负责管理一个或多个NFVI-POP中的NFV基础设施资源。NFVI-POP是指部署了计算、存储、网络资源，符合运营商NFV硬件和虚拟化技术要求，由NFVI管理系统统一管理，提供VNF业务承载能力的局站。

NFVO、VNFM和VIM这3个功能模块在逻辑上独立，可通过标准接口互通，在实际部署时可根据需要分设或合设。此外，MANO还定义了实体模块之间的接口，包括：NFVO与VNFM的接口（Or-Vnfm）、NFVO与VIM的接口（Or-Vi）、VNFM与VIM的接口（Vi-Vnfm）、NFVO与OSS的接口（Os-Ma-nfvo）、VNFM 与 EMS的接口（Ve-Vnfm-em）、VNFM 与 VNF的接口（Ve-Vnfm-vnf）、VIM 与NFVI的接口（Nf-Vi）。

NFV的引入一方面带来了资源共享、网络快速部署的优势，但同时也带来了新的问题。随着软硬件解耦，相对于传统软硬件一体化设备而言，网元及业务的故障定位、分析、处理的难度会增加。当NFV出现故障后，故障信息可以是几个不同的故障源：物理资源故障（即 NFVI的物理计算、存储和网络相关的故障）、虚拟资源故障（如虚拟化层或VM相关故障）和应用故障（即VNF应用软件及功能相关故障）等。NFV虚拟网元相对于传统软硬件一体化网元设备，在故障管理方面主要有两大差异：一是故障点多，传统网元设备软硬件故障、业务故障都通过同一厂商的设备网管 EMS采集和上报，故障定位比较明确；而NFV虚拟网元硬件资源层、虚拟化层、应用软件层、业务逻辑层都可能产生故障。二是故障管理功能分散，传统设备通过网元—EMS—NMS（OSS）的层次进行处理；而 NFV网络，在原有处理功能基础上，增加了 MANO的故障处理功能，分别负责 NFVI层的硬件资源、虚拟资源故障以及VNF故障和NS故障。因此，本文将重点研究NFV场景下故障处理流程及故障关联方案，同时，由于NFV具备动态部署、弹性调整的特性，还要研究NFV故障情况下如何实现VNF故障自愈、网元及业务的自动恢复，提升自动化运维能力和业务可用性。

图1 NFV系统架构

2 NFV故障关联方案

2.1 NFV故障处理流程

NFV分层解耦后，每一层都会产生告警，仅靠单一层面很难进行故障定位，例如，一个网卡出现故障，会引起相关VIM层的告警和操作系统层面的告警，也会产生网络层面的告警以及业务层面的告警，这些告警由不同层面采集和监控，如何进行故障关联分析和处理，需要有完善的NFV故障采集、故障定位和故障处理流程。

NFV故障告警主要分为NFVI层物理资源告警、虚拟资源告警、虚拟网元告警和业务层告警。NFV故障管理流程示意如图2所示。

NFV故障管理流程的主要步骤如下。

· VNFM 接收与该特定 VNF实例相关的虚拟化基础设施故障（1a）。NFVO接收与该特定VNF无关的基础设施故障（1b）。

· VNFM可对某些所选事件执行其自身的故

障相关性分析。

· VNFM 可以将与该特定 VNF实例的相关故障信息转发到其他不同的故障关联点，主要是EMS（3a）和NFVO（3b）。

图2 NFV故障管理流程示意

· VNF实例可以将应用层故障发送到不同的关联点，主要是EMS（4a）和VNFM（4b）。VNFM 可以进一步将故障信息转发到NFVO（4c）。

· 故障相关性分析可能发生在任何故障关联点。EMS可以执行故障相关性分析以确定根原因和对VNF的影响（5a）。NFVO可以执行故障相关性分析以确定根原因和对网络服务的影响（5b）。

· 可以在不同的故障关联点处发起解决故障动作。

· 在OSS中可能发生额外的相关性分析和处理流程。

当相同故障原因的告警信息由多个告警源产生时，需要对这些信息进行关联分析。在NFV MANO架构中，这种相关性分析可能发生在多个地方：EMS、VNFM、NFVO或 OSS。一旦确定了故障关联点，其他功能单元必须能够将故障信息转发到故障关联点，如 VIM负责收集 NFVI物理资源和虚拟资源告警并进行转发；EMS负责收集 VNF产生的业务告警并进行转发。

2.2 NFV故障关联分析

NFV框架中不存在唯一的故障关联点或故障处理点。例如，某些故障相关性分析和故障处理在 VIM 中执行，而另外一些故障处理可能在NFVO、VNFM或EMS中执行，具体取决于故障本身的类型和层级。NFV架构中，每一个管理单元负责不同层级、不同类型的告警采集和故障关联，如图3所示。

NFV框架中需要根据故障类型确定故障关联点和故障处理点，每一个管理单元负责不同的告警采集和故障关联。

· VIM 负责收集虚拟资源告警与物理资源告警，并进行关联，以确定资源故障影响范围。

· VNFM 负责收集虚拟资源告警与相应的VNF网元告警，并与VNF生命周期告警关联，以确定网元实例影响范围。

· EMS负责收集VNF业务告警与VNFM上报的关联后的虚拟资源告警，并进行关联（即基础设施与应用关联），以确定业务影响范围。

· NFVO负责收集虚拟资源、物理资源告警以及VNF生命周期相关告警，并进行关联，以确定NS的影响范围。

图3 NFV故障关联示意

· OSS或新一代网络运营系统负责收集VNF业务告警、NS生命周期告警、VNF生命周期告警、NFVI重要告警，并进行关联，以确定网络影响范围、业务影响范围及客户影响范围。

基于以上分析，NFV故障管理中采用“逐层关联、分类管理”的原则，即物理资源、虚拟资源、虚拟网元、网络服务垂直逐层关联，资源故障、业务故障分类管理，这是NFV故障管理应采取的基本维护管理思路，需要通过分层协同的方式处理NFV运行监控和故障处理。例如，某个虚拟网元的业务单元出现异常，首先进行应用进程重启，而如果是整个虚拟网元出现异常，则可能会触发VNF实例生命周期管理流程（例如VNF扩缩容、VNF终止）或NS实例生命周期管理流程（例如网络服务终止）的操作以实现故障恢复。

2.3 业务与资源故障关联实现方案

参照ETSI NFV架构及相关实体职责分工，MANO（包括 VIM、VNFM、NFVO）主要负责资源域的告警监控与处理，VNF-EMS-OSS主要负责业务域的告警采集与处理。而当资源域与业务域告警信息需要关联时，目前业界一般有以下两种实现方案。

方案一：OSS负责业务与资源故障关联

方案一如图4所示，EMS负责网元层级的业务告警（从VNF收集）与资源告警（从VNFM收集）的关联。OSS负责业务层级的业务告警（从EMS收集）与资源告警（从NFVO收集）的关联。这种方案与现有的电信网络运营维护体制相适应，能够将新的 NFV网络融入传统OSS进行管理，最终实现新旧网络一体化运营维护。

方案二：NFVO负责业务与资源故障关联

方案二如图5所示，EMS负责网元层级的业务告警（从 VNF收集）与资源告警（从 VNFM收集）的关联。NFVO负责业务层级的业务告警（从EMS收集）与资源告警的关联。这种方案需要对ETSI定义的NFVO功能框架进行功能扩展，统一管理NFV网络的业务编排、资源调度及运营维护，不需要与传统OSS发生关联，即“新网新思路”的办法。这种方案简化了故障处理流程，有利于实现故障处理流程的快速启动和基于策略的故障恢复及故障自愈。

图4 OSS负责业务与资源故障关联

从NFVO功能要求、故障处理效率、运营模式、EMS要求等方面对上述两种方案进行对比分析，见表1。

上述两种方案各有优劣，如果需要兼顾传统网络与NFV新网络一体化运营，则建议采用方案一；如果需要提升NFV网络告警处理效率，则建议采用方案二。

2.4 分层故障处理方案

故障采集上报、关联分析需要逐层分解、逐层关联，同样，故障处理也需要采用逐层处理的方案，如图6所示。

NFV架构中各功能实体分别负责相关故障的处理。

· EMS负责VNF业务故障处理。

· EMS根据策略向VNF发起配置变更操作。

· OSS负责业务、网络故障处理。

· OSS通知EMS对相应VNF网元进行调整。

· OSS通知NFVO对相应NS、VNF生命周期及其资源进行调整。

· NFVO负责 NS故障处理以及与网络相关的物理资源、虚拟资源故障处理。

· NFVO基于策略调整虚拟资源或物理资源。

· VNFM负责VNF生命周期相关故障处理。

图5 NFVO负责业务与资源故障关联

表1 业务与资源告警故障关联方案对比分析

· VNFM基于策略需要对虚拟资源进行调整时，通知NFVO（间接模式）。

· VNFM基于策略需要对虚拟资源进行调整时，通过VIM实现（直接模式）。

因此，NFV在故障处理时，首先需要分析故障类型（资源故障或业务故障）和故障影响范围（单网元故障或业务级故障），再确定合适的故障处理流程，快速定位故障，并基于策略实现故障修复或故障自愈。

3 故障自愈方案

传统电信网络设备的告警采集监控是自动化处理过程，而故障修复一般需要转人工线下处理，因此故障监控和故障处理是两个相对独立的处理流程。而NFV的引入使得虚拟化网元设备的故障监控与故障处理流程实现了闭环融合，利用虚拟云化资源特性为NFV故障自愈创造了条件。

NFV将软件功能和专用硬件分离，且采用通用的硬件，当硬件出现故障时，应用软件可以自动转移到备份的硬件上重新部署。具体而言，硬件故障时，该硬件上承载的VM转移到备用硬件上，也就是将应用软件重新部署在新的通用硬件上，维持业务的连续性。当VM出现故障时，重建VM即可。

当VNF出现异常时，可以通过VNF自愈流程实现自愈，保障VNF网元和业务的连续性。

如图7所示，基于策略的VNF故障自愈有3种常见模式。

· VNF故障自愈：当VNF出现异常无法恢复时，则通过VNFM发起VNF自愈恢复流程，重新实例化部署该VNF，恢复历史数据，进行VNF恢复。

· VNFC故障自愈：当某个VNFC出现异常无法恢复时，则通过 VNFM 删除原有的VNFC，新建VNFC进行恢复。

· VM故障自愈：当VNFC对应的VM出现异常时，则通过 VNFM发起新建 VM，并安装部署相应的VNFC，实现VNFC功能恢复。

图6 NFV分层告警处理方案

以 vIMS分层解耦部署为例，要求网元及VNFM 具备故障自动恢复功能，备用模块对应虚拟机恢复后，vIMS网元应能恢复对应模块的备用工作状态。在设定时间内，备用模块虚拟机由于物理故障等无法恢复的情况下，VNFM应能启动虚拟机重建将备用模块对应虚拟机迁移至其他物理机上，并启动部署及配置业务功能。在故障自愈过程中，也对各个环节的处理时限提出了要求。

· 从故障产生到被VIM检测出来并上报告警的间隔时间小于10 s。

· 故障硬件对应的模块业务倒换至备用模块，业务损失时间小于2 s。

· 在设定时间内虚拟机无法自动恢复，VNFM能启动虚拟机重建流程，虚拟机能够重建成功，重建时间小于10 min。

尽管虚拟化基础设施管理平台VIM一般具备VM迁移的能力（如OpenStack），但VIM主动发起的虚拟机迁移无法实现业务网元连接、业务数据恢复，无法保障业务的连续性，因此一般不建议采用VIM发起的主动迁移虚拟机，而是通过VNFM或EMS根据告警及性能策略触发，由业务层发起业务级的虚拟机迁移，并恢复相应的业务连接和业务配置，保证业务的连续性。

图7 基于策略的VNF故障自愈示意

4 结束语

NFV为通信网络变革带来了机遇，同时也为未来的网络运维提出了新的挑战。本文分析了NFV故障处理的流程及故障关联方案，提出了VNF故障自愈实现方案，为NFV场景下的故障定位处理、故障自愈提供了基本思路和方法。总体来说，NFV故障处理需要采用“逐层关联、分类管理”的原则，既分工负责，又统筹协同，充分发挥云化部署弹性可扩展的特性，实现虚拟网元故障自愈，提升自动化运维能力。在此基础上，下一步还需深入研究策略引擎、规则引擎等关键技术，制定分层协同故障处理模式下故障快速定位的方法和机制；研究制定故障自愈策略，提高虚拟网元的自愈恢复能力。

[1] ETSI. NFV management and orchestration[S]. 2014.

[2] ETSI. NFV MANO functional requirements specification[S].2017.

[3] ETSI. NFV MANO Or-Vi reference point - interface and information model specification[S]. 2016.

[4] ETSI. NFV MANO Vi-Vnfm reference point-interface and information model specification[S]. 2016.

[5] ETSI. NFV MANO Or-Vnfm reference point-interface and information model specification[S]. 2016.

[6] 赵慧玲, 史凡. SDN/NFV的发展与挑战[J]. 电信科学, 2014,30(8): 13-18.ZHAO H L, SHI F. Development and challenge of SDN/NFV[J].Telecommunications Science, 2014, 30(8): 13-18.

[7] 王海宁, 赵慧玲. NFVO标准和实践[J]. 电信科学, 2017,33(4): 1-7.WANG H N, ZHAO H L. NFVO standards and practice[J].Telecommunications Science, 2017, 33(4): 1-7.

Research on NFV fault association and fault self-healing

MAO Binhong, YANG Zhiming
Guangzhou Research Institute of China Telecom Co., Ltd., Guangzhou 510630, China

NFV implements the hardware and software decoupling of telecommunications network equipment, gets rid of the dependence on dedicated hardware equipment. NFV brings benefits such as resource sharing, automatic deployment, flexibility and other features, but it also brings some problems such as more fault points, difficult fault analysis and so on. It results in NFV network operation and maintenance more difficult. The NFV fault process and fault association were analyzed, and guidance for fault location processing in NFV was provided. At the same time,the VNF fault self-healing implementation scheme was given to realize the network element and service fault self-healing, and improve capability of automatic operation and maintenance.

NFV, MANO, fault association, fault self-healing

TP393

A

10.11959/j.issn.1000−0801.2017261

2017−06−11；

2017−08−30

毛斌宏（1975−），男，中国电信股份有限公司广州研究院高级工程师、高级企业信息管理师，主要研究方向为NFV MANO及电信运营支撑系统。

阳志明（1972−），男，中国电信股份有限公司广州研究院高级工程师，主要研究方向为信息与通信技术、运营支撑系统理论与实践。