NFV大规模化商用部署前的回顾与反思系列文章（下）

本篇文章3752字，读完约9分钟

赵华，大中华区nfv首席专家

【引言】:在最后一篇文章中，我向读者解释了全球运营商nfv的总体情况、典型海外运营商nfv的发展思路以及中国运营商nfv的发展情况。虽然国内运营商在使用有线电视方面取得了很大的成绩，但与国外运营商相比，国内运营商的有线电视整体商业化进程并不快。原因是从多厂商互操作性、vnf云能力和端到端自动化水平的角度来看，仍然存在一些明显的问题和不足。这些问题的具体表现是什么？企业应该如何应对？国内运营商未来的发展思路是什么？你会在文章中得到答案。

V.存在的问题和未来的发展思路与国外运营商相比，国内运营商的整体nfv商业化进程并不快。通过近两三年的poc、试验网络、现有网络试点和商业试验等一系列工作，国内三大运营商基本掌握了nfv虚拟化阶段的核心技术和能力，预计2018年会有更多大规模的商业部署。然而，从多厂商互操作性、虚拟网络云能力、端到端自动化水平等角度来看，仍然存在一些明显的问题和不足，不可能实现虚拟网络功能和服务的无缝组装，如乐高积木。

这些问题对于从虚拟化阶段到云阶段的nfv来说是不可避免的，未来有必要进一步推动从虚拟化到云能力的突破。下面讨论几个主要问题，并提出一些后续发展思路。
(1)多个供应商之间的互操作性
NFV开放生态系统发展面临的最大挑战是如何实现互操作性。为了应对这一挑战，etsi在定义关键接口规范方面取得了实质性进展，这对于确保不同实现之间的互操作性是必要的。

如图10所示，互操作性要求的关键在于接口和模型(vnfd、nsd、vnf包等)的标准化。)基于etsi定义的功能需求和模型驱动的设计思想。

图10:实现nfv供应商之间互操作性的关键

etsi nfv规范定义了三个成熟度阶段(参见图11)。从2015年到2017年上半年，etsi nfv发布的规范主要集中在第二阶段，不能直接指导多个供应商之间的互操作性。直到2017年8月，sol工作组发布了第三阶段的一些关键成果，这成为解决多供应商互操作性问题的一个重要里程碑！

图11:ETSI NFV规范的三个阶段

etsi sol工作组主要发布和即将发布的nfv互操作性规范文件见图12。

图12:支持ETSI NFV第三阶段互操作性的关键标准规范

由于近两年etsi nfv标准化进展缓慢，国内运营商基本上依靠第二阶段的etsi标准，独立完善和设计了相关接口的mano、restful协议等关键功能的数据模型，实现了多个厂商之间的互操作。这与大多数海外运营商的做法相似，是标准滞后于实践而导致的折衷解决方案。

将国内三大运营商的mano规范与最新的sol stage 3规范进行比较，可以看出存在很多问题，如:
模型驱动的核心是模型本身的开放性。受一些厂商的影响，目前国内运营商规范基本不支持nfvo对vnfd模型的直接分析，而是变相增加了一个查询vnfd的接口。这违背了模型驱动思维的本质，不利于未来基于乐高积木的虚拟网络框架的快速验证和部署；
从etsi设计的角度来看，授权接口实质上授权了vnf生命周期管理的操作(例如，删除vnf的操作需要nfvo确认vnf是否被实例化的ns使用，如果不使用，则可以授权删除)，而目前国内运营商规范只授权虚拟资源的应用。仅从资源的角度考虑授权与etsi设计的初衷相违背，会带来许多潜在的问题；
etsi规范定义了容量扩展机制的完美设计，包括部署风格、规模方面、实例化级别和其他信息元素，同时支持规模到级别和规模的操作。目前，国内运营商规范根本没有体现这种细粒度、准确的扩容设计思想，也不能支持vnf云本地能力；
在国内运营商的规范中，各种通知的订阅通知界面不符合互联网程序的设计管理，也不符合etsi规范的设计思路。

在nfv的实践中，运营商最重要和最基本的目标之一是实现在开放的生态系统中快速组装不同组件的互操作能力。在开放环境中，互操作性必须首先基于对etsi定义的功能规范、模型驱动的思想以及接口和模型规范的全面和完整的理解，而不是简化和曲解。

etsi的一些关键互操作性标准已于2017年8月发布，后续的tosca模型如vnfd将于2018年初发布，这为解决开放的生态环境奠定了重要基础。何时以及如何将现有运营商的mano规范过渡到标准etsi第3阶段规范，从而彻底解决互操作性的基本问题，是国内运营商在后续发展nfv时的重点考虑和规划。

(2) vnf的云就绪性
从国内运营商近两三年的nfv实践中可以发现，vnf的云就绪性没有得到系统的研究和测试，这是nfv从虚拟化阶段突破到云能力阶段的关键。

目前，在nfv实验室测试和目前的网络试点过程中，国内主要运营商还没有采取有效的手段来了解制造商的vnf是按照云化还是云本土(更不用说这方面的规范和约束)来设计和实施的，例如:
VNFC的设计是否合理？每个vnfc是否可以提供单一功能并且相互独立(例如，取决于特定加速功能的功能组件是否设计为独立的vnfc)？
VNFC组件的部署是否存在单点故障？
关键组件的冗余备份模式是什么？如何在多个并行处理组件之间实现负载平衡？如何检测组件故障并完成自动恢复？如果自动恢复是不可能的，如何通知马诺干预？
微服务能力:vnf是基于微服务架构设计的吗？每个vnfc能否独立部署、配置、升级和监控？
部署和容量扩展机制:您能否支持多种部署规范来满足不同的业务场景？是否可以针对与特定流量容量相关的一组vnfc执行独立的容量扩展和收缩？不同的vnfc组能否根据不同的级别和粒度进行扩展和收缩？
状态管理:vnfc的设计和实现是否尽可能无状态？对于有状态的vnfc，逻辑和状态是否已经分离，状态如何保持？

上述vnf云就绪能力是否具备，将极大地影响vnf的可靠性、水平弹性扩展能力和自动管理能力，这对基于vnf部署的业务运营非常重要。

云模型与传统企业计算模型的一个非常重要的区别在于，假设基础设施不可靠，不能提供足够的可靠性，从应用层的角度采用云设计思想以确保应用程序具有高可用性是必要的。此类应用程序可以部署在任何不可靠的基础架构环境中，同时确保业务的高度可靠运行。领先的运营商已经考虑这项工作很长时间了。例如，如上所述，at t已经制定了一系列要求和指南，专门针对域2.0中的虚拟网络基础架构的云就绪性。此外，etsi还在其规范eve 011中定义了一系列针对云本地vnf的非功能性要求。

建议国内运营商在基本实现虚拟化阶段目标的基础上，尽快规范和测试vnf云就绪性。

(三)自动化能力水平
从商业部署和业务创新的角度来看，具有虚拟化能力的nfv不能完全满足业务运营和维护的自动化要求以及新业务快速推出的要求，因此有必要重点建设和提升云阶段的自动化能力水平。

自动化能力的提高涉及到很多方面，如:
为不同厂商的虚拟网络设备建立统一的虚拟网络设备认证测试平台(类似于at t的ice环境)(基于上述虚拟网络设备云就绪性要求和互操作性规范)，可以大大提高vnf认证测试的自动化水平，缩短认证时间，加快新业务网元的规范引入。今后，我们可以进一步考虑将该平台与运营商下一代oss的devops平台连接起来，实现vnf厂商与运营商之间跨域ci/cd管道，这将对多厂商nfv生态环境的建设起到重要的推动作用。
端到端业务管理自动化能力的提高。Etsi规范和nfvo+的国内实践不包括vnf的服务配置和服务管理控制能力，即使虚拟网络元件的fcaps管理能力有所提高。从自动业务操作和维护的角度来看，存在一些缺陷。图13展示了一个可行的想法，即通过业务编排、nfv编排和ems的同时对接，通过整合与网络业务相关的语义信息和虚拟化的nfv环境的语义信息，可以自动编排业务并端到端操作。

图13:通过业务流程编排实现端到端业务管理的自动化

目前，几乎所有与nfv相关的开源项目，如onap和osm，都扩展了基于nfv架构的业务协调层，相关的标准化组织，如tm论坛zoom和mef lso，也在这一领域进行研究。国内运营商可以在以后的实践中借鉴这一成果。

六.总结
nfv是下一代云可编程网络的关键支持技术，etsi制定的nfv核心框架和相关模型/接口是蓬勃发展的nfv行业的基石。随着互联网和云计算领域更多新技术的发展，nfv框架不断丰富和完善。根据poc和国内外运营商现有的网络部署，nfv技术还处于相对早期的阶段，还有很多问题需要解决。目前，全球nfv发展总体上处于虚拟化阶段，尚未进入云化阶段。
近两三年来，国内三大运营商通过poc、试网、现有网络试点、试商用等一系列工作，基本掌握了nfv虚拟化阶段的核心技术和能力，预计2018年将有更大规模的商业部署。但是，从互操作性、vnf云就绪性和自动化水平来看，仍然存在一些明显的问题和不足，需要进一步推动nfv从虚拟化到云能力的突破。

Nfv不仅是一项技术，也是通信行业新兴it创新技术和能力的持续应用过程。Nfv在开发过程中需要it厂商的开源理念、创新理念和开放思维。

在nfv从虚拟化走向云化的过程中，进一步增强运营商的领先能力，优化nfv生态建设，营造it和ct共同参与的良性nfv环境，具有重要的战略意义。

来源：央视线