虚拟化网络运营和测试实践探讨
2019-08-30柏楠唐静雷波
柏楠 唐静 雷波
摘要:NFV是运营商网络向未来演进的重要方向,需要建立适应NFV技术特点的网络运营管理系统。对NFV的基本架构进行简单介绍,分析了引入NFV技术后网络运营管理及网元测试管理方面的问题,探讨了尝试解决部分问题的NFVO应用实践,为虚拟化网络运营和测试提供应用参考。
关键词:网络管理;网络功能虚拟化;网元测试
1 引言
网络功能虚拟化(NFV, Network Function Virtualization)是指基于标准服务器、交换机等设备,采用虚拟化软件化的技术手段,实现传统网络设备实体的功能。从2012年ETSI成立网络功能虚拟化工作组(ETSI ISG NFV)以来,网络虚拟化持续发展,在网元设备上提倡分层解耦,采用通用设备来节省运营成本;在业务运营上提倡自动化,以自动扩缩容功能为代表的网络弹性与快速构建能力对运营商颇具吸引力。NFV技术的引入,使得运营商在通信技术的发展与变革上有了更多的挑战,本文主要针对NFV后网络的运营管理和网元测试管理方面进行了深入探讨和研究。
2 网络虚拟化带来的问题
经过近几年的发展,NFV技术面临的一些性能瓶颈已有相当的进展,但从运营商对网络运营管理的角度来看,在现有物理网络中大规模引入网络虚拟化,应用虚拟网元(VNF, Virtualize Network Function)来构建网络承载业务还面临诸多困难。
2.1 网络运营管理的难题
ETSI NFV的参考架构如图1所示,从管理角度来看,MANO是管理NFV框架的核心环节,它包括虚拟设施管理器(VIM, Virtualised Infrastructure Manage)、VNF管理器(VNFM, VNF Manager)和NFV编排器(NFVO, NFV Orchestrator)3个部分,从底层向上分别负责对虚拟资源、虚拟网元和网络服务的管理。其中VIM与虚拟化层的hypervisor具有接口;VNFM与网元管理系统(EMS, Element Management System)和VNF具有接口;NFVO与OSS具有接口。
运营商网络中传统网元设备占多数,其测试建设、运营管理和维护都已非常成熟,BSS/OSS體系建设
相对完善,虚拟网元的引入带来了“虚实共管”的问题,虽然有NFV MANO(Management and Orches-tration, 编排与管理)体系参考,但MANO与EMS及OSS的交互接口不够细致,实现上缺少支持。管理复杂度的增加延缓了网络管理自动化的进程,从而拖累了NFV技术的部分优势。以vBRAS为例,作为较早引入到城域网中的VNF,vBRAS在实施过程中就面临DC内资源分配和网络配置、网管纳管、业务初始配置等多个操作环节。沿用传统物理网元的管理方式和维护惯性,往往需人工干预。网络管理上的困难主要体现在:
(1)缺乏端到端的自动化配置能力。在虚拟网元(VNF)与传统物理网元(PNF, Physical Network Function)共存的网络中进行网络服务编排,需要具备对两者的基本管理和配置能力。PNF和VNF的业务配置都在EMS系统中,但VNF生命周期管理在VNFM和NFVO中,这两套系统之间需要建立必要的协同关系。
(2)各类网元间及虚拟资源层面的告警、性能未实现协同。告警分析是网络运营维护的重要一环,多个故障现象可能都是由同一原因导致,正确的告警关联性分析至关重要。在虚实网络或网元之间的、虚拟网元及虚拟化资源层面之间的性能事件、告警信息的协调仍然没有实现。
(3)在网络维护管理中,受维护人员使用习惯等原因的影响,在进行业务初始配置或状态操作时,仍存在少量不易管理的手工操作方式。尤其是在接入网中,对于部分虚拟化的接入网元,如vBRAS或vCPE,还有人工操作命令行的情况。这不仅增加了操作错误的风险,更重要的是它可能会干扰NFVO或VNFM对虚拟网元生命周期的状态管理。
(4)虚拟网元的承载层面基础设施分布广,面临复杂层级的资源管理。运营商业务种类繁杂,承载网络种类繁多,不同网络、不同网元的部署位置各不相同。运营商的NFV基础设施,按所处地理位置和业务部署的差异,也会有接入局点、边缘DC、核心DC、区域中心DC等不同类型。通常不同的VNF会部署在不同位置,如vBras部署在核心DC或边缘DC,而vCPE则部署在接入局点,而且对具体的业务网络来说,存在随需动态变化的可能,这对资源管理和VNF管理提出了很高的要求,相应地需要NFV-MANO的部署和管理范围具有弹性,可以动态调整。
2.2 网元测试管理的问题
在虚拟网元的测试方面,随着NFV解耦的进展,在基础设施硬件、Hypervisor、VNF等层面分别采用不同供应商的解耦方案已日趋成熟,由此,面临如何在有限资源投入情况下对虚拟网元进行客观、全面快速的测试等问题。
(1)VNF的更新频率从原有网络设备的的9~12个月缩短至3个月甚至更短,频繁的版本迭代产生更多的测试资源要求,若保持传统的测试方案会使测试周期十分漫长,无法满足市场的需求。
(2)在软硬件解耦的环境下,每一个环节的变化都会导致测试场景的变更,例如每次网元的升级,都会将所有的测试用例(包括功能及性能)进行遍历,测试内容更加复杂,要求测试方法更加完善。
(3)在VNF管理方面已不同于实体网络设备,在虚拟网元众多的情况下,需要保证现网使用的VNF的安全性与可靠性。
3 运营和测试管理的实践
从2016年提出CTNet2025网络重构以来,中国电信一直推动NFV技术及产业链的发展与成熟,在移动核心网、城域网等领域进行了大量的实践探索。在城域网重构方面,随着CO机房的DC化改造及vBRAS网元产品的发展完善,在构建场景化应用的过程中,中国电信研究院以TeleNOS系统为主体,对虚拟网元的运营管理、测试管理进行了持续探索。
3.1 TeleNOS的基本信息
TeleNOS(Network Orchestration System,网络编排系统)系统是参考ETSI NFV-MANO相关标准研发的增强NFVO。如图2所示,系统具备NFVO的各项功能,包括NSD和VNFD模板编排管理、NS/VNF生命周期管理等,支持多VIM和多VNFM的注册管理、故障告警管理和性能事件管理等。
在架构设计上,以分布式任务队列为核心,以NSD和VNFD模板为输入,采用插件适配器的方式封装不同形态特性的周边系统接口,实现NFVO的各项功能及更多增强功能,如图3所示。
3.2 VNF业务配置实践
在NFVO基本功能基础上,基于灵活扩展的系统架构,通过EMS适配插件,TeleNOS系统与EMS进行对接。在VNF实例化的过程中,操作人员可在单一系统内进行资源编排选择和业务初始化配置,避免了各部分的信息需要分别使用不同系统或者人工进行操作的情况,降低配置错误的可能性,提高操作人员的效率。选定的业务初始化配置信息由TeleNOS系统暂存,并在VNF实例化完成后,通过执行EMS适配插件,调用相应EMS的功能接口,将VNF实例纳管到EMS后,将配置信息下发到VNF,完成配置生效。
系统中进行实例化操作时即可配置其业务初始化参数,包括其管理IP地址、EMS中的地址池设置、vxlan设置等。当实例化操作完成后,vBras实例已经具有初始业务配置。
进一步地,借助EMS适配插件,还可以实现对部分PNF的配置管理,从而增强NFVO对PNF和VNF混合编排管理的能力。此外对于部分规模较小、功能单一的VNF,缺少对应VNFM和EMS的情况,可以考虑将VNFM与NFVO合并功能,通过CLI适配插件,完成对其的业务配置管理。如图5所示,虚线为增加的NFVO与EMS、与VNF的接口。
3.3 自动化部署级联实践
在NFV环境中,考虑到NS或VNF的实例化面临着多DC或多级DC的实施,需要NFV-MANO的部署和管理范围灵活可变,具有弹性,在TeleNOS中引入NFVO的自动化多级部署方案,将NFVO本身封裝为特殊的VNF包,实现这一要求。
在NFV-MANO需要扩展管理范围时,如接管新DC的虚拟化资源或网络部署实例要求向新增DC做延伸,NFVO(上层O)可在注册了新增DC节点的VIM后,使用级联部署插件,自动化地在新增的DC节点部署NFVO实例,将它作为与原NFVO(上层O)进行级联的下层O,并配合上层O实现NS或VNF在新增节点的实例化。这种自动部署能力实现向下扩展的方案适用于DC分级架构,如图6所示,以部署于核心DC的NFVO接管某边缘DC虚拟资源并向边缘DC中实例化一个下层O的实际场景为例,其流程如下:
(1)向核心DC的NFVO(上层O)中注册边缘DC的VIM信息,包括租户账号、管理地址、密钥等。
(2)在上层O的模板数据库中保存有NFVO自身级联部署所需的模板及安装包等。
(3)在上层O的插件数据库中上传级联部署的插件。
(4)在上层O中对级联部署的模板进行实例化,并输入参数。
(5)上层O通过运行插件,将在边缘DC中实例化一个下层O的实例。
(6)实例化过程和结果都会记录在上层O的日志中。
(7)下层O实例正常运行,与上层O协同工作。
针对DC基础设施分散,而管理要集中统一的情况,这种分层级联的自动化部署方式就非常合适。其中上层的NFVO是编排调度和资源管理的核心,在这一节点上系统可以采用双机或集群式的部署模式,增加可靠性;而在下层NFVO则采用虚机承载,轻便灵活,随需而设。功能上,上层的NFVO负责全局的编排和统一管理,可以执行跨域跨DC的NS编排和实例化,而下层NFVO则通过同步机制,协助上层完成对本节点的资源调度及操作。以上层NFVO发起在新增边缘DC实例化某VNF为例,其流程如下:
(1)上层O的模板数据库中保存有VNF的模板及包。
(2)上层O的插件数据库中已有该VNF对应的VNFM适配插件。
(3)在上层O中,选择将VNF通过下层O在边缘DC进行实例化。
(4)上层O调度下层O实例自动进行插件的同步。
(5)上层O调度下层O实例自动进行模板的同步。
(6)上层O调度下层O实例执行VNF的实例化。
(7)在下层O所在边缘DC中VNF实例生成,运行正常。
(8)下层O回传过程日志到上层O中。
3.4 VNF网元测试实践
在网元及其相关的测试方面,依托TeleNOS系统,针对虚拟网元的测试需求,使用TOS(Testing Orchestration System,测试编排系统)组件对VNF、测试用例(TestCase)、测试套(TestSuit)、系统接口(API)、测试结果都进行统一的管理,可提高VNF验证和测试的自动化水平,便于运营商采购时对VNF开展评估,加速新业务网元的规范引入。
面向繁琐的测试环境部署,将测试环境交由TeleNOS进行管理编排,按测试所需提出模板,实现被测VNF实例的自动化创建,减少测试环境的人工干预。TOS组件根据网元专业类型自动化匹配测试套,同时对结果数据进行自动化整理,大幅提高了测试效率,缩短了测试周期。通过与专业仪表厂商进行合作,可根据不同的测试类型匹配对应的仪表。同时,在测试过程中会对资源进行全程监控,测试结束后生成周期内的资源监控报告。在TOS组件中引入版本管理,通过对连续版本的虚拟网元进行测试而建立起的网元版本库,系统可支持网元版本升级评估及合格网元新版本推送等。
4 结束语
运营商网络的云化虚拟化是产业发展的必然趋势,在规模应用虚拟网元构建虚拟网络服务的过程中,要建立切合实际生产需要的、高效可靠的管理系统。中国电信在近年的运营商网络云化领域进行了部分探索与应用,可以实现NFV技术下虚拟网元的运营管理及测试管理,为NFV的网络管理建设提供参考。
参考文献:
[1] ETSI. Network functions virtualisation (NFV); management and orchestration; functional requirements specification: GS NFV-IFA 010[S]. 2019.
[2] ETSI. Network Functions Virtualisation (NFV) Release 2; Protocols and Data Models; RESTful protocols specification for the Ve-Vnfm Reference Point: GS NFV-SOL 002[S]. 2019.
[3] ETSI. Network Functions Virtualisation (NFV) Release 3; Management and Orchestration; Report on management of NFV-MANO and automated deployment of EM and other OSS functions: GR NFV-IFA 021[S]. 2019.
[4] 林文峰,陳锦潮. NFV网络运营体系构造[J]. 邮电设计技术, 2018(7): 60-65.
[5] 胡亚希,霍筱宁. 引入NFV 技术的网络管理方案[J]. 电信科学, 2018(S1): 72-77.
[6] 雷波,解云鹏,王波. vBRAS应用场景及评估方法探讨[J]. 中兴通讯技术, 2017(2): 23-26.
[7] 雷波,唐静. 中国电信打造NFV自动化集成与验证平台[J]. 通信世界, 2019(13): 46-47.
[8] 李晨. SDN/NFV赋能5G网络架构的云化演进[J]. 通信世界, 2019(12): 45-48.
[9] 赵鹏,段晓东. SDN/NFV发展中的关键:编排器的发展与挑战[J]. 电信科学, 2017,33(4): 18-25.
[10] 史凡,赵慧玲. 中国电信网络重构及关键技术分析[J]. 中兴通讯技术, 2017,23(2): 2-5.