【IT168 资讯】11月 29日消息，以 " 新技术 · 新架构 · 新网络 " 为主题的 "GNTC 全球网络技术大会 " 第二天，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产生多大的影响，也需要进一步研究。
