[阳志明 毛斌宏]
NFV MANO的关键问题研究与实践
[阳志明 毛斌宏]
主要分析电信运营商在未来NFV技术研发、网络部署所涉及的NFV管理和编排(NFV MANO)的关键技术问题,包括:资源管理Direct和Indirect模式,MANO与传统OSS/网管的协同,通用VNFM和专业VNFM要求等。对各关键技术问题,提出可能的解决方案并加以分析比较,给出相应解决方案的建议。希望能把握未来NFV MANO的发展趋势与重点方向,以期对国内相关技术发展提供必要的指导与支撑。
NFV MANO VNF 直接模式 间接模式
阳志明
中国电信股份有限公司广东研究院。
毛斌宏
中国电信股份有限公司广东研究院。
随着“互联网+”和“宽带中国”等国家战略的推进,信息通信业面临新的机遇和挑战,开放、创新、融合成为重要趋势。传统网络架构和运营体系越来越难以适应互联网业务发展的要求,网络转型升级和架构重构成为全球主流运营商的共同追求。与国际电信网络发展趋势同步,过去一段时间,国内三大运营商中国电信、中国移动、中国联通分别发布网络重构战略。通过网络重构,实现从网络被动适应互联网应用向网络主动、快速、灵活适应互联网应用的根本转变。
向目标网络架构演进有3个关键:SDN/NFV的引入、网络和IT的深度融合、开发运营一体化。其中,NFV作为网络架构演进的重要技术路径,通过在网络设备中引入虚拟化和云化技术,以虚拟化实现软硬件解耦,以云化实现硬件资源的共享及系统随业务大小的弹性伸缩。NFV的目标是通过基于行业标准的x86 服务器、存储和交换设备,取代通信网络中长期使用的私有专用的网元设备,从而帮助运营商降低部署、管理和维护网络的成本,同时提供更好的弹性和敏捷性,以适应业务需求变化的要求,从而支撑业务的快速创新和缩短业务的上线周期。作为一个新兴事物,NFV的引入,也给网络建设与运营带来新的挑战,在其逐步研究和试验部署的过程中,存在一些值得关注的问题,亟待逐步研究解决。
重点总结在研究和实践NFV关键要素:NFV MANO中所面临的关键技术问题,并提出相应的解决方案。
引入NFV后的系统组网架构如图1所示,虚拟化实现了底层物理设备、虚拟化操作系统和上层软件功能(虚拟化网络功能单元)的解耦。NFV引入了MANO(NFV Management and Orchestration,NFV管理和编排),通过MANO提供的可管、可控、可运营的服务提供环境,使得基础资源可以灵活便捷地提供给上层应用,其本质是实现虚拟化网络功能单元VNF、网络服务NS的自动化部署、弹性调度及高效运维管理。
图1 NFV系统组网架构
MANO包含3个方面的主要组成要素:功能、接口参考点及核心管理信息实体。
功能方面,MANO包含3个核心功能模块:NFVO(NFV Orchestrator)、VNFM(VNF manager)、VIM(Virtual Infrustration Management)。NFVO主要负责跨VIM的NFVI资源编排及网络服务的生命周期管理。VNFM主要负责VNF的生命周期管理。VIM主要负责对整个基础设施层资源的管理和监控。NFVO、VNFM、VIM三个功能模块在逻辑上独立,可通过标准接口互通,在实际部署时可根据需要分设或合设。
接口方面,MANO包含内部NFVO、VNFM、VIM三个功能模块之间的接口参考点:Or-Vnfm、Or-Vi、Vi-Vnfm;MANO与虚拟化网络功能单元VNF、NFV基础设施NFVI及EMS之间的接口参考点:Ve-Vnfm-em、Ve-Vnfm-vnf、Nf-Vi;以及MANO与OSS之间的接口参考点:Os-Ma-nfvo。
管理信息实体方面,MANO主要管理的信息实体包括:网络服务目录、VNF目录、NFV实例、NFVI资源等。
NFV MANO主要用于提供虚拟化资源、虚拟化网络功能(VNF)和网络服务(NS)的统一管理,以支持NFV硬件资源与软件功能解耦目标的实现。
VNF生命周期管理是NFV MANO需要支撑的核心要求,同时也是NFV架构下实现自动化运维的关键环节,包括VNF的实例化、终结、扩缩容、查询、自愈等,涉及VNF生命周期管理相关的资源编排、自动化部署、弹性扩缩容决策。在具体VNF部署时需根据业务的规格需求和基础设施的硬件属性完成自动化资源编排,根据亲和性/反亲和性策略、基础设施资源的负荷/可用状况等关键要素完成自动化部署,基于网元的CPU占用率、用户容量门限、带宽使用率等关键KPI指标进行扩缩容决策等。VNF生命周期管理一般由MANO的VNFM功能模块实现,由VNFM、NFVO、VIM和EMS协同完成。网络中VNF一般由多供应商提供,这就要求VNFM可以部署多个,如:每个厂商VNF部署一个VNFM,或者一个VNFM服务多个厂商VNFs。
网络服务(NS)生命周期管理是NFV MANO支撑的另一核心要求,类似包括NS实例化、终止、扩缩容、查询等,同时也需支持通过各种复杂性的网络服务配置更改来更新网络服务。网络服务生命周期管理一般由MANO的NFVO功能模块实现,NFVO通过使用VNFM提供的VNF生命周期管理接口,以及VIM提供的资源管理接口,协调实现NS生命周期管理功能。
从NFV的角度来看,以云化实现硬件资源的共享是NFV网络的价值所在,这就要求跨越一个或多个NFVI资源池实现NFV基础设施资源的统一管理。虚拟化基础设施的管理一般由MANO的VIM功能模块实现,它对上提供接口或API,用于控制和管理VNF相关的计算、存储和网络资源,以及他们的虚拟化。NFVO通过跨域协同VIM,实现对底层虚拟化资源的统一管控。
NFV促进了电信网络的软件化,为适应NFV网络的跨域、多厂商、多专业特性,NFV MANO要求支持跨域、跨厂商VNF软件版本的统一管理。
在网络服务、VNF生命周期期间,NFV MANO需要通过监视虚拟化网络的KPI,以支持自动化高效运维的实现。
NFV对传统电信网络除了结构性的改变以外,还面临着交付、运维模式的变革,需要引入大量的NFV业务编排和管理的创新技术。以下笔者就在从事NFV MANO研发和试验部署的过程中发现的3个关键问题进行深入分析和探讨,并给出相应的解决方案。
3.1 资源配置的Direct/Indirect模式问题
(1)Direct/Indirect虚拟资源分配模式的基本概念
Direct/Indirect模式是ETSI关于NFV特有的两种资源管理模式。NFV MANO允许NFVO和VNFM两者都能管理VNF生命周期管理所需的虚拟化资源,Direct/ Indirect是相对VNFM而言的。VNFM直接通过VIM分配VNF生命周期管理所需的虚拟化资源,则为Direct资源分配模式;否则,则为Indirect模式。2种资源分配模式的简要示意如图2所示。
图2 Direct/Indirect资源分配模式
(2)Direct/Indirect模式的对比分析
总体而言,两者都由VNFM提供VNF生命周期管理(LCM):
① 在执行VNF生命周期管理操作之前,无论该操作需要新增资源,还是修改或者释放已分配的资源,VNFM都需要向NFVO请求资源授权(request granting);
② 资源容量和状态等信息由NVFO统一维护管理。两种模式的不同主要体现在;
③ Direct模式下,VNFM和NFVO都需要与VIM交互;Indirect模式下,VFNM不需要和VIM进行交互;
④ Indirect模式下,NFVO需要提供VIM Proxy能力,将VIM的虚拟资源管理接口暴露给VNFM使用。
总体分析2种模式在架构、业务成效、性能、集成复杂度以及安全性方面的优劣:
表1 Direct/Indirect模式综合对比分析
(3)对两种资源管理模式的使用建议
综合以上分析,从功能、落地部署、安全性、未来演进角度考虑,Indirect模型较好;性能方面,Direct模式占优;系统集成复杂度两者相当。
考虑网络未来发展,笔者建议,运营商应要求厂商支持Indirect模式,以利推进分层解耦、实现对虚拟资源的统一管控。在NFV推进初期,运营商可以综合考虑部署时的具体情况,衡量取舍采取的具体模式。
3.2 通用VNFM与专用VNFM问题
(1)通用VNFM与专用VNFM架构的基本概念
通用VNFM和专用VNFM是ETSI定义的与VNFM相关的2种架构选项,ETSI关于通用和专业VNFM架构的研究主要体现在《gs_NFV-IFA009v010101p:“Network Functions Virtualisation(NFV); Architectural Options Report”》文档中。
通用VNFM的架构选项如图3所示:
图3 一个通用VNFM的架构选项
如图3所示,通用VNFM可以服务于不同类型和/或不同的供应商提供的VNF,通用VNFM对他所管理的多种类型、多厂商VNF的操作没有依赖性,但它应能够适应在VNF包中定义的不同VNF的特定脚本。视乎管理要求,可能有多个通用VNFM,每个VNFM管理一定VNF的子集。NFVO在这种情况下,需要同时处理多个通用VNFM。
NFV架构框架同时也允许一个或多个专用VNFM连接到单个NFVO,专用VNFM在其需处理复杂生命周期管理过程,并且这些处理过程可能是针对特定VNF的情况下是必需的。
专业VNFM架构选项如图4所示:
(2)两种架构的比较
两种架构选项对VNFM的功能要求大体相同,包括:解析VNFD,获得部署VNF所需资源要求及所需部署的业务软件;VNF生命周期管理,包括实例化、查询、扩缩容、终止等。
图4 专业VNFM的架构选项
两种VNFM架构选项带来的不同要求主要如表2。
表2 通用VNFM和专用VNFM部署方案的不同要求
根据以上架构比较,进一步分析2种架构在技术实现难度、运维复杂度方面的优劣:
表3 通用VNFM和专用VNFM部署方案的对比分析
(3)架构选择建议
综合考虑,建议采用专用+通用VNFM结合的方案。
① 对EPC、IMS等场景,VNF功能复杂,对VNFM要求较高,推荐采用专用VNFM;
② 对Gi-Lan等场景,VNF功能相对简单,但设备种类和数量较多,可以考虑采用通用VNFM,减少VNFM数量;
③ 在具体部署过程中,通用VNFM与VNF、EMS接口,是采用标准接口,还是采用VNFM与VNF、EMS接口适配模式,运营商可根据自身情况综合考虑确定。
3.3 MANO与传统OSS/网管的协同关系
NFV/SDN/云作为未来网络重构的三大核心技术,在网络演进中,三者将协同发展。探讨NFV MANO与OSS协同,离不开未来网络SDN/NFV协同发展的大环境。基于此,本节OSS与MANO协同方案,将重点探讨SDN/ NFV协同编排与OSS的协同方案。
总结而言,OSS与MANO协同,存在以下4种典型方案:
(1)方案1:现有OSS升级,形成对混合网络的管理能力。
如图5所示,本方案基于现有OSS系统升级,融入NFV/SDN网络的协同编排功能,形成对新旧混合网络的协同管理能力。
图5 OSS与MANO协同方案1
(2)方案2:新建NFV/SDN协同编排,升级现有OSS系统,负责顶层新旧网络协同
如图6所示,本方案新建SDN/NFV网络的协同编排功能,并基于现有OSS系统升级,形成对新旧混合网络的协同管理能力。
(3)方案3:新建顶层协同编排和NFV/SDN协同编排
如图7所示,本方案新建SDN/NFV网络的协同编排功能。同时新建顶层业务编排/网络协同系统,负责新旧混合网络的协同管理。
图6 OSS与MANO协同方案2
图7 OSS与MANO协同方案3
(4)方案4:新建SDN/NFV协同编排,逐步替换OSS
如图8所示,本方案新建SDN/NFV网络协同编排,实现新NFV/SDN网络的管理。后续逐渐增强SDN/NFV网络协同编排器功能,支持对现存旧网络的管理,支撑老网络逐步向未来网络架构的演进。
图8 OSS与MANO协同方案4
(5)方案选择建议
以下从方案实现难度、运营难度、投资成本及业务成效等角度分析对比以上4种方案优劣:
表4 MANO与传统OSS/网管协同方案的对比分析
建议运营商根据自身业务战略、现有OSS基础等,综合考虑各种因素,选择合适的OSS与MANO的协同方案。
在推进NFV关键技术研究的同时,为加强网络架构自主掌控能力,中国电信也实际推动了SDN/NFV协同编排器的自主研发。中国电信SDN/NFV协同编排器,面向SDN/NFV网络,提供统一的业务编排和网络资源弹性调度,提升业务部署和交付效率。目前,模型驱动的基础共享编排器平台研发已完成,具备灵活可扩展的多业务编排和自动化部署能力。初期支持的NFV业务包括:vDPI、vePDG业务管理和编排,SDN业务包括:面向SDVPN的大客户专线的协同编排能力,未来可灵活扩展支撑企业其他SDN/NFV业务。
整个研发过程,也实际验证了本文所述几项关键技术问题,包括:完成了间接资源分配模式面向vePDG业务编排功能的研发,采用通用VNFM实现对vDPI的业务编排和自动化部署。
在实际研发过程中,也暴露出大量影响NFV应用的技术问题:
(1)NFV MANO接口产业标准滞后。最为成熟的ETSI MANO接口规范,尚不能直接指导NFV MANO接口开发;
(2)类似直接、间接资源分配模式设计产业链利益的平衡,技术方案协调难度大;
(3)信息模型标准不统一,如厂商存在各自不同的VNF包标准,加大了运营商的应用推进难度。
基于来通信网络发展趋势的SDN/NFV技术,各大运营商都已基本确立自身的未来网络演进战略。但是传统网络体系太过庞大复杂,SDN/NFV化特别是NFV化,不仅是电信网络技术的变革,更涉及整个产业生态的重塑,为运营商未来业务发展提供机遇的同时,也对运营商传统运营模式和组织架构带来巨大挑战。聚焦NFV MANO领域,除涉及笔者文中探讨的3个关键问题外,开源、云网融合数据模型、云化网络的自动化运维等问题,同样需产业链各方共同努力、协同攻关。笔者相信,通过运营商与各设备厂商、IT 厂商的紧密合作,探索各方共赢方案,并对关键问题进行深入研究及实际检验,必将通过实践推动NFV MANO技术的不断成熟,从而加速NFV技术的落地应用。
1 ETSI gs_NFV-MAN001v010101p:”Network Functions Virtualisation (NFV); Management and Orchestration”
2 ETSI gs_NFV-IFA010v020201p:”Network Functions Virtualisation (NFV); Management and Orchestration; Functional requirements specifcation”
3 ETSI gs_nfv001v010101p:”Network Functions Virtualisation (NFV); Network Functions Virtualisation(NFV); Use Cases”
4 ETSI gs_nfv002v010201p:”Network Functions Virtualisation (NFV);Architectural Framework”
5 ETSI gs_nfv003v010201p:”Network Functions Virtualisation (NFV); Terminology for Main Concepts in NFV”
6 ETSI gs_NFV-REL004v010101p:”Network Functions Virtualisation (NFV); Assurance;Report on Active Monitoringand Failure Detection”
7 ETSI gs_NFV-SWA001v010101p:”Network Functions Virtualisation (NFV); Virtual Network Functions Architecture”
8 ETSI gs_NFV-IFA009v010101p:”Network Functions Virtualisation (NFV); Management and Orchestration;Report on Architectural Options”
9 ETSI gs_NFV-IFA011v020101p:”Network Functions Virtualisation (NFV); Management and Orchestration; VNF Packaging Specifcation”
2016-12-06)
10.3969/j.issn.1006-6403.2016.12.006