陈佳媛专家:中国移动NFV技术应用实践分享

2019-08-12 16:06 评论 0 条

  【IT168 资讯】11月 29日消息,以 " 新技术 · 新架构 · 新网络 " 为主题的 "GNTC 全球网络技术大会 " 第二天,NFV网络功能虚拟化专场,中国移动研究院网络所NFV技术专家陈佳媛发表了主题演讲。

陈佳媛专家:中国移动NFV技术应用实践分享

  ▲中国移动研究院网络所NFV技术专家陈佳媛

  演讲实录如下:

  回到2012年的时候,ETSI和全球的十三家运营商组建了NFV的工作组,当时他们发布了全球第一个NFV的白皮书,这个白皮书里宣称很多NFV可以给运营商带来的好处,我相信在各大运营商在引入NFV的时候,也会有自己的考量。中国移动最关心的方面,首先是技术对于上层业务的支持,底层业务到底好不好,要看它能够给上层业务带来什么,引入NFV之后,软硬件的分离使得我们在建设完资源池之后,网源的业务上线部署直接变成了软件的部署,所以整个业务上线的时间可以以月为记,提升了以小时、分钟为记的时间单位上。所以,NFV使得业务快速上线,频繁地迭代,灵活响应市场的变化,是我们引入NFV的一个核心驱动力。

  第二点从网络演进的角度,NFV是5G网络架构的一个底层关键技术,它的网络功能的软件化,以及底层资源的池化的特点,可以使得5G微服务以及5G切片部署变为可能。第三个是从成本,有人说X86的服务器不见得比ATC的服务器便宜,为什么说NFV可以降低成本呢?对这个问题我们内部有很多的分析,从短期来看,我们认为NFV因为要采购IT的设备,包括公司全员学习NFV的技术,包括一些培训的成本,它不见得可以省钱。但是从中长期来看,因为底层采用IT的通用技术,借助于一定的自动化的部署工具,整个网络的建设周期,以及业务部署的周期可以降低,从而降低整个网络建设的成本。其次,跟NFV同时引入的自动化的网管系统,这些工具可以增强网络自动化的管理能力,从长远看NFV可以降低整个网络运维的成本。

  这一页是中国移动定义的一个NFV逻辑架构,它和ETSI定义的标准不太一样,NFV的标准架构是分了三层一域,三层是硬件层、虚拟层和虚拟网源层,一域是管理编排域(MANO)。在标准的架构上,中国移动结合自己的运维管理需求定义了一些增强,首先从底层的虚拟层,我们在虚拟层定义了一个PM软件模块,用PM实现对于硬件资源,包括交换机、防火墙、存储和服务器等等所有这些服务器的统一管理。然后我们再在虚拟层VIM接口上,我们基于开源基础,定义了统一的虚拟资源和硬件管理,硬件资源在性能管理以及告警管理方面的增强。再往上是NFVU,考虑引入NFVU之后,整个线网的OSS如果要它增加虚拟化网源的管理,生命周期管理这个动静特别大,难度也特别大,我们在标准的NFV的基础上加了虚拟化网源的FKS的管理,使得它可以管理整个一套虚拟化的系统。

  然后再在NFV+和线网的OSS之间,我们定义了一套数据同步的接口,我们使得这两堆网源的管理数据,可以在任何一个界面上得到一个统一的呈现,这个是中国移动在NFV标准的逻辑架构上做出了我们的增强。基于刚才标准的逻辑架构,我们在推进NFV技术成熟的过程当中,我们部署了两大工作线条,首先是面向商用的NFV线网的试点,第二个是面向未来网络目标架构的NONET实验网,我们一方面通过这个NFV线网试点,按序推动NFV商用的落地,另外一方面我们利用NONFV实验网,去做一个新技术的实验和验证,我们在实验网上验证未来网络的目标架构,我们验证三层解耦的技术要求,包括ONAP的自主开发等等。这两条工作线是相辅相成,交替前进的,一旦我们新技术在NONFV实验网已经验证成熟之后,就会推到这个线网落地。

  到目前为止NFV线网试点工作,我们从最初的2015年10月第一期外场试点开始,到现在已经进入到第三阶段,而且它的业务也从一开始的虚拟化的MS,或者虚拟化的Volet,扩到了目前的虚拟化的NBLT和虚拟化的转线中心。在线网线条,它的业务方法更广,除了MS,除了NBLT,我们还会尝试固网宽带、CDN、数据中心的SDN、STTN等等这些业务场景,这是整个的情况。

  接下来我们主要介绍一下每个工作线条的具体工作进展。首先是NFV线网试点的总体情况,面向商用的NFV的研究工作,我们最初是从2014年启动的,当初的切入点是MS,在商用推进的过程当中,我们有三条线,首先是关键基础研究,然后是实验室的测试,然后是外场的测试,这三条工作线是并行开展的,其中技术研究主要是定位分析解决一些关键的技术问题,为NFV引入策略提供一定的指引。实验室的测试主要是侧重于异厂家之间互操作兼容性的测试,外场则是侧重于端到端口商用能力的验证,以及摸索运维管理的经验,同时我们在省公司培养一些技术力量。

  在NFV的线网试点的线条里,我们又有三个关键的里程碑,首先是在2016年5月的时候,我们联通当时业界是4家合作伙伴,我们成立是NFV五大专题工作组,分别是硬件、虚拟层、VF、MANO以及组网规划,我们在依托五大专题工作组,我们对NFV商用的100多个关键基础问题,和大家一起公关,为后续的实验室测试和外场测试奠定了很好的基础。

  第二个里程碑在2016年8月的时候,当时的中国移动就NFV有两条关键策略问题有了比较明确的定位,第一个策略问题是NFV的分层解耦度问题,当时我们明确了我们要先确保两层解耦架构成熟,然后再引入三层解耦。第二个问题是NFV的电信云与私有云的关系的问题,我们的策略是我们在初期先建以电信云和私有云独立建设、独立运维,后续具备一定条件之后,再考虑融合和统一,这两个问题不仅仅涉及到了我们定义一些相关的基础标准的要求,包括一些工作量等等,我们更直接的影响到中国移动引入NFV商用的时间点。

  第三个关键的里程碑在今年10月底,我们完成外场试点第三阶段虚拟化在NFV的测试,当时两层解耦的虚拟化NBLT已经具备了商用部署的条件。

  然后是我把外场试点的情况跟大家再展开介绍一下,从2015年10月份,中国移动组织了六省市、九个厂家开展NFV的三阶段的外场试点的工作,试点分三阶段进行,首先是第一阶段试点在陕西、安徽、山东、河北四个省市开展,主要是以NFV关键能力为主,一方面熟悉厂家的NFV系统,另一方面是验证NFV在承载Volet基础业务方面的能力,同时通过观察梳理NFV特有的生命周期管理的功能,我们去摸索一个相关的管理配套流程。在此基础上,我们第二阶段的外场测试从2016年8月开始,新增了广东和浙江两个大省,当时公司策略明确是两层解耦了,所以在第二阶段我们的主要验证内容,就是全面聚焦软硬解耦的技术架构,细化了虚拟层的一些功能、性能、可靠性要求,细化了MANO的流程接口的要求。

  第三阶段,根据商用落地的需求,我们在业务层进行了扩展,我们在新型的业务、线网的扩容,以及老旧设备替换三大典型的建设模式的里面选取了NBLT、Volet以及短信中心,作为典型的业务场景进行测试,我们基于NFV端到端业务能力验证,目前BNLT已经测完了,Volet和短信中心也即将结束。

  面向未来目标网络架构的NOMNET实验网,相比于商用试点的线条,试验网更像是一个新技术的实验平台,既然是新技术实验,我们会有一定的试错空间,我们是希望在这样的平台上,去验证各项技术的成熟性、合理性,然后再推到线网的落地,我们是在北京、上海、浙江和广东四个结点,我们建设了一个中国移动未来网络的一个微型版,我们在这个试验网上验证统一的资源池,去支持多业务环境的能力,支持三层解耦的技术能力。具体来说我们目标有以下三条,首先是验证目标网架构的合理性,中国移动未来的目标网络架构两层数据中心的结构,首先在核心层面,我们主要是用于部署控制面的网源,我们实现一个控制面的大集中。然后第二层是在边缘的数据中心,我们主要用于部署一些媒体层和接入层的网源,我们来实现流量的卸载。第二个目标是去验证协同编排器统一编排能力,我们通过在域类或者跨域两个层次搭建协同编排器,来实现统一的协同编排。第三个目标是验证统一资源池,支持多业务环境的能力,实现多业务之间的资源共享。

  目前,NOMNET实验网络已经完成了整个一阶段的工作,并且进入了二阶段的准备环境,跟线网试点不一样的是,我们在实验网完成了几乎所有的主流IT厂家的虚拟层的摸底测试,并且实现了这些IT展开的虚拟层与CT厂家网源的一个对接,这样我们也实现了功能的对接,性能上还没有做一个比较详尽的测试,对接过程非常漫长,难度也非常大,我们可以处处见到IT的思维和CT思维的碰撞,我们觉得实验网在培养整个NFV的良性生态圈方面,我们做了很多的努力和尝试,我们也希望在NFV的时代,IT和CT产业可以相互竞争合作,并且可以共同繁荣。同时我们通过实验网,我们也在培养我们自主的集成能力,我们编写了很多面向虚拟层的集成手册,也编写了自动化集成的测试工具。

  在我们推进NFV技术成熟的过程中,我们遇到的一些典型的问题。首先是关于NFV的硬件,我们提到之前我们商用线条是以两层解耦为主,把硬件独立出来,为了做到这一点,我们定义了面向控制面网源的服务器的配置模型,有MS、CSF、VoletES,有EPC等等这些网源,这些配置定完以后,基本上我们明确了NFV硬件的最低配置要求。第二个我们还定义了服务器与虚拟层的兼容性的要求,然后交换机防火墙还在兼容的定义过程中。第三个是硬件管理,我们在定义硬件管理的过程中,我们遇到了很多问题,我们知道目前OPENSDK在做硬件资源管理方面,它的定义相对还是比较粗的,而且一直以来各个服务器的厂家,在售卖服务器的时候,还会搭配自己管理的软件。但是对于运营商来说,我们面临的实际问题是我们以后的数据中心里,不可能只有一个厂家,或者一个型号的服务器,所以必然会面临着跨厂家硬件管理的需求。当时我们想用VIM实现跨厂家硬件统一管理的时候,问题就出现了。

  目前看,绝大部分的服务器管理都是基于IPMI和SMP来定义的,跟自己本身的管理软件进行定义,如果我们要改,对于硬件的改动需求基本上是无法实现的。问题是说,IPMI和SMP协议本身并不是一个标准化程度非常高的协议,我们当时发现有一个特别明显的例子,比如我们要服务器来上报他们自己厂家的名字,大家可能报的不一样,对于VIM来讲的,需要针对不同厂家的服务器,进行一个适配,每对接一个我得适配一遍,这样效率非常低。

  第三个问题是目前大多数大公司,可能会采用定制化的IPMI和SMP协议路线走,来满足自身特有的管理要求,但是对服务器厂家来讲,要去维护不同版本定制化的软件和协议,一旦某个定制版本出现了问题,一些客户就会面临支撑上面的一些风险。

  基于这些问题,我们后续对于硬件管理,我们会向retshi这个协议进行转变,retshi是一个服务器管理的开放标准,它具备了对于统一的服务器的配置,性能的监控,以及事件日志记录的基本管理功能,它基本上具备了跨厂家的管理基础,而且我们了解到目前越来越多的服务器的厂家,也在模仿这个协议。所以,retshi这个协议是我们后续的协议目标。我们从前期的有限研究当中发现,retshi在故障管理方面的能力还可能稍显不足,我们希望有服务器厂家专家,可以去评估一下,从运营商那边获取到的,在运维的管理过程当中,对于故障管理的需求,把它推到协议当中,去落实、实现,来完善整个retshi的协议。

  第二个问题是跟虚拟层相关的,其实中国移动对三层解耦问题的认识都差不多,虽然三层解耦是NFV的目标架构,它可以在软硬解耦的基础上进一步实现更大范围的,或者更高小的资源共享,但是我们在推进三层解耦的过程中遇到了很多问题,首先是测试的工作量,按照中国移动现有商用的测试标准去执行,我们只是在前期做NFV线网的试点,和实验网的五个业务上做全配对组合的话,我们需要做360组配对,远远大于当年我们Volet上线的时候,各个厂家MS接口的LT配置的测试量。所以,通过一个全配对测试方法,推动三层解耦的成熟,并不是一个高效的方式。我们再看一下从技术本身,我们去分析一下,三层解耦到底难在什么地方,我们在内部经常会被问一个这样的问题,三层解耦解的到底是什么?是否存在一个统一的或者标准的一个三层解耦规范,网源和虚拟层拿过来也可以对接成功,这样的东西是不是存在。从我们前期的研究来看,我们目前对这个持一个比较怀疑的态度,但是我们尽量在制订这个规范。

  首先,三层解耦主要是软软解耦,网源和虚拟层之间的解耦,它有两个接口,第一个是NFV和VIM之间的接口,第二个是VNF和WAID之间的解耦,NFV和VIM这个接口比较成熟,因为它有ITSI的标准定义作为一个基础,运营商可以在这上面做一些和运营管理相关的一些要求,所以这个接口的成熟度我们还是可以把控的。不成熟的主要是在另一层,我们暂且不叫它为接口,因为它跟普通认定的传统的3DPP定义的网源之间的接口不一样,它是没有一个统一的标准。它的不成熟主要来自于两个层面,首先虚拟层的本身机械要求是来自于开源社区的提供参考实现,这个参考实现随着自己版本升级是在不断变化的,它是一个动态的东西。其次各个厂家,又会根据自己的理解,在参考上提出自己的增强,比如说面向电信级的增强,对于这些增强又没有一个机构对它进行约束,这部分增强的差异直接导致了上层网源和虚拟层对接的困难。这两个因素加在一起,使得所谓的标准化的三层解耦的技术规范,需要一个长期的积累和迭代才有可能实现的。

  目前全球运营商宣称的三层解耦已经商用化,都是有一定前提的,他们可能是基于一个虚拟层或者两个虚拟层做的三层解耦,这种难度相对来讲比较低,但是对于中国的运营商来讲,因为我们没有所谓的短名单,我们必须面对全量虚拟层的厂家做对反,难度非常大,这是我们的认识。

  第三个问题是关于NFV可靠性,这个问题其实也是三层解耦导致的,NFV引入之后可靠性成了一个很大的课题,原来的厂家提供一个软硬解耦的一体化设备,它自己就可以保证一个网源五个9选择可靠性,现在引入NFV之后,一个网源被拆成好几块,这五个9该怎么去实现呢?我们在研究的过程当中发现,NFV各层在处理故障的流程和机制上的差异,会直接影响到整个系统端到端可靠性的能力。我们用一个比较典型的故障场景来解释这个问题,这个场景是有一个服务器坏了,这个服务器上跑的虚拟机会发生故障,这个虚拟机承载的业务模块也会发生故障,因为这些模块各层都是来自于不同厂家,我们暂且认为它们相互之间没有定义完善的一个通知机制,一旦故障的事情发生,有可能是业务层面,比如EMS、VFM会管制一个业务的故障,这个时候会尝试业务模块的倒换,或者一个业务进程等等措施。在差不多的时间,VIM也会感知到所管辖的虚拟机也出现了故障,这个时候他可能会尝试在本地重起虚拟机,或者迁移,或者在异地重生等等这些操作。由于两层之间没有通知,各干各的,很有可能在虚拟机还在尝试本地重起的过程中,VFM就发现我已经无比倒换了,它可能会要求VIM你重新在服务器让重建一个虚拟机。或者有可能VIM发现,我已经恢复好了,虚拟机不要再重启了,这些都是有可能冲突的场景。

  由于这个故障处理的机制,以及一些时间的要求,都是厂家内部实现,在两层解耦的时候并没有暴露出来,一旦三层解开之后,很有可能对可靠性造成比较大的影响,所以三层解耦以后,跨层之间的联动变得非常重要,针对这个场景,我们目前定义了两套处理办法,要么是以VFM为主导去处理这个故障,要么是以VIM为主导处理故障,这两种方法我们倾向于又VIM主导,其实就是各干各的,如果自己干不了,再去通知更上层做跨层联动。目前是这样一个相法,但是我们这两个方案的优劣势并没有通过实验去进行验证,性能还无法给出一个比较好的建议。

  三层解耦之后故障的恢复,以及处理的流程,以及各层之间的接口等等设置,有的更为详尽的要求,这个会要求厂家暴露他们的内部的实现,没有厂家的支持在做三层解耦下,可靠性联动是非常困难的,我们在这边也呼吁一下,希望厂家和我们一起推动三层解耦下的一个NFV可靠性问题。

  对于我们自动化集成的测试工具,NFV分层架构对运营商来讲,除了在传统网络、规划、建设、采购、运维环境带来的变化,我们还会引入一个新的角色叫做集成商,这个集成商需要把来自不同厂家的硬件、虚拟层、网源、MANO等等进行适配,让各个模块有机地可以运行在一起,集成商的角色对于整个系统的安装部署、业务上线、网络稳定都会起到至关重要的作用。但是我们在推进这个三层解耦的过程当中,由于厂家众多,导致异厂家配对的测试工程量是非常大的,即便我们只是做了有限的配对,我们在对接的过程中也发现了很多问题,比如我们会遇到三层网源和虚拟层,会因为对于CPU时间级的理解不一致,导致网源无法部署,我们也遇到过网源和虚拟层对于IP的分发和规划的方式、冲突,差异导致后续IP地址运维会发生冲突。所以,对我们来说,我们在商用的测试过程当中,我们一整套虚拟化NBLT的测试,我们有近两千个,一旦这个问题出现之后,我们需要花钱一到两天的时间才能解决,在推进整个三层解耦的过程当中,效率非常低。

  基于这个问题,我们设计了一套自动化的安装部署,包括测试的一个框架,我们让整个系统自动安装、自动部署、自动测试、自动的把测试结果导出,目前我们可以做到原有六周工作量缩短到两小时做完成,我们做了什么工作?首先是我们定义了编写了一套脚本,我们实现了系统的安装、部署、测试、运行、结果输出等等任务的自动化执行,目前任务也可以通过并行方式进行调度。第二个是我们鼓励厂家公开了他们商业版的虚拟层的API,来对接开源的部署工具,这个是领先于目前开源社区的一个工作,目前开源社区只能做开源社区版本的对接,我们是做到了商业版的虚拟层的对接,我们实现了商业版虚拟层的自动安装和部署,目前我们已经完成了部分厂家的虚拟层的产品的对接。后续我们还会统一接口要求,会选出一个比较合适的对接工具,来实现对于不同厂家虚拟层的统一安全和部署。

  第三个我们做了一个测试用力的脚本化的工作,我们有一个同事花了好几周的时间,把170多个虚拟层的测试用力都编成一个脚本,这个脚本做完之后,我们所有虚拟层的产品都可以套用这个脚本进行测试,而且我们可以保证所有的虚拟层的测试标准都是一样的,这个测试可以在一个小时之内完成,而且我们可以远程去考察它的检查点和测试的结果。

  这是我们自动化集成目前的成果,将来我们会把自动化集成工具再推广到ONAP社区,我们希望大家套用这个测试工具,希望让它变得更加完善,我们还想把业务的测试也加入到自动化的测试集团里,包括对EPC、MS有一个自动化的业务测试,这块就需要业务厂家有更多的支持,才可以把整个自动化测试工具变得更加完善。

  中国移动对NFV后续的一些工作重点,除了刚才提到的三层解耦自动化的集成了测试工具,还有ONAP,我们还会在NFV的基础上引入SDN,我们会考虑NFV和SDN怎么融合,我们会考虑SDN进入以后,数据中心内部和数据中心的主网应该怎么去做,然后我们还会考虑硬件情况,会考虑分布式存储的技术,还有加速技术的要求。虚拟层,我们也会研究容器,目前容器非常地火,但是从目前我们有限的研究来看,我们觉得容器的应用场景还有待考察,因为虚拟机目前基本上已经可以满足NFV的需求,容器来了以后有多大的提升,我们还需要测试,其实容器到来以后,会对MANO产生多大的影响,也需要进一步研究。

版权声明:本文著作权归原作者所有,欢迎分享本文,谢谢支持!
转载请注明:陈佳媛专家:中国移动NFV技术应用实践分享 | 天际彩友心水论坛-世外桃园论坛

发表评论


表情