近日，在第三届未来网络发展大会SDN/NFV技术与应用创新分论坛上，新华三解决方案部架构师孟丹女士发表了主题为《NFV资源池实现中的技术探讨》的主题演讲。
孟丹指出，新华三的NFV核心理念主要分为三个部分：标准、开放、整体交付。标准指的是新华三的方案符合ETSI架构、有编排层、生命周期管理层、云平台层，有NFVI，有VNF网元，有EMS；开放是指层之间是解耦的，网元可以跑在友商的服务器、云平台上，目前多家运营商已经做过解耦测试。整体交付是和单设备交付相对应的，现在交付的是端到端方案。
上图中的可管理是指对NFV网元进行配置管理、生命周期管理、扩缩容管理等控制动作，可呈现是可以端到端展示多层级的资源使用状况，同时还可以对方案中的实体网元一并管理及呈现。
基于上述理念，可构建灵活定义、快速部署、随需调整和高可靠的NFV解决方案。
NFV理念：从运营商到行业的渗透
孟丹表示，早期也有基于X86平台的路由器，但是它不是跑在虚拟化平台之上，也没有NFV关联的网元。后来NFV概念不断明确，形成了一个标准的体系架构。NFV并不局限于网元本身，还包括一套体系，从编排器到VNFM到VIM，从网元到NFVI，在行业领域也开始有了一些延伸，如数据中心方案中的vRouter/vFW/vLB，如uCPE（将X86/ARM CPU中剩余的计算资源管理起来，运行第三方IT APP或CT网元），甚至在园区出口都有可能在一定条件下用NFV网元实现灵活认证。除此之外，编排的概念也在跨场景中得到应用，如园数融合、DC和DCI融合，提供一个统一入口、端到端视图。
下面讨论NFV网元（CT）和VM（IT）的差异，这里的VM是指基于虚拟化平台运行的IT网元，比如你在数据中心云平台之上申请虚机，在其中运行你自己的应用软件。NFV网元和VM两者有相同点，也有不同点。两者最大的共同点都是基于虚拟化环境，受云平台管理，有生命周期管理。
再看不同点，一个是性能需求，一般的VM网元数据需求比较低，普通网卡就可以搞定。NFV网元包括控制类和转发类，控制类的性能要求比较低。而转发类的网元性能要求比较高，一般在5G的网元转发面会选择SRIOV，这就不属于X86的性能了。
第二个差异是网元形态，分为主机型和路由型，VM属于主机型，它基本上就是对外提供服务，一个IP就够了；NFV网元是路由型，它不仅要管自己对外的路由，同时还要管下面网元的发布，因为他本身就是一个CT网元的替代，这样就可以实现把流量牵引过来。
第三个就是NFV网元是支持CT网元特有的VLAN和QINQ的子接口，而IT网元不带VLAN。最后一个是架构，比如在数据中心用IT网元，最顶层就是云平台，云平台是一个总入口。NFV网元总入口不再是云平台，而是总的编排器NFVO，它会调VNMF，然后再调下面的数据，这个地方两者有不少差异。
借鉴IT：NFV资源池化提供统一服务
孟丹指出，NFV网元本身不能跨服务器，虚拟化层就不可能提供这种技术，甚至NFV网元还不能跨NUMA，跨NUMA的内存访问会损耗30%左右的性能。也就是说，单个NFV网元的性能是非常有限的，那怎么解决这个问题呢？这个时候就要借鉴IT资源池的概念，将若干NFV网元集中管理，形成NFV资源池，对外提供统一的服务。另外，运营商在网络重构时会建立多级DC，在部署时按照NFV流量特征和业务特征选择合适的DC承载，比如低延时，大流量的部署位置相对低点的DC，不太在乎延时的、小流量的部署在位置更高一点的DC。
借鉴IT：将数据库引入NFV资源池
NFV池化以后，作为CT网元的一种，必然要考虑可靠性，要考虑当一个NFV网元故障时如何如何保证业务不中断，保证用户体验不到资源池内的故障。这是非常必要的。IT的可靠性和CT不是一个水平的，服务器故障比较常见，一般容易接受，而作为网络的重要组成部分，CT可靠性要求非常高，看下运营商集采就有体会，稳定性测试是非常严格的。原先的CT实体设备是一个独立的、分散的网元，物理位置并不是集中的。而NFV池化物理上会部署在同一DC内NFV池是集中管控的，这时可以将IT资源池中的数据库技术引入进来。
有了数据库多个功能相同的NFV网元可以将数据保存在数据库中，当某一个NFV网元故障时，就能够从数据库中恢复出它的运行数据，保证会话不中断，用户不感知。那为什么不用虚机的热迁移技术呢？原因有两个，一是强依赖于共享存储，成本高，另一个是NFV在使用SRIOV时无法迁移（举例来说，PF直通模式，NFV网元迁移后，虚拟化层没有机制调用NFV网元中的PF驱动，迁移前后网卡的配置信息是不同的，如果不能重新初始化那网卡无法正常运行）。
除了故障热切换，当不同NFV间流量不均衡时，也可以依靠数据库技术在NFV间进行流量调配，比如我们发现某个网元CPU使用率或者用户数已经达到阈值了，而另一个NFV网元比较空闲，这时可以依靠数据库技术把部分用户数据在NFV之间迁移，并且这种调配也是用户无感知的。也就是说，数据库技术在NFV池化中是非常有用的。
借鉴IT：NFV资源池弹性扩缩容
不管是虚机还是容器，弹性扩缩容是一个非常典型的特性，这是虚拟化一个非常明显的优势。流量潮汐是因为设备所处的地理环境是不同而带来的，有的地区是办公楼集中的，白天流量大，夜晚流量减少，有的是生活区，反过来，白天流量小，晚上开始流量增大。用NFV资源池来按需应对就非常有效。先定好弹性策略，流量下降到一定程度就先将剩余用户集中到少量NFV网元上（当然这个过程也是借助数据库的），再缩减NFV网元数目。
这样的好处在于能够降低供电需求，降低散热压力。不过在实际现网中是否使用还是一个值得讨论的问题，网络弹性实际上也意味着不可控，而原来的运营商网络是一个非常明确的系统，但不管怎样，弹性扩缩容提供了一种技术上的可能。
IT资源池中的概念是否要引入到CT？
这部分主要分为三块内容
思考1：NFV资源池部署LB必要性探讨
上图增加了LB负载均衡组件，它的作用是对外屏蔽资源池内部结构。所有外部网络设备只看到LB，并不知道LB后面有多少NFV网元在进行实际的业务处理。
但这里有个问题需要思考一下。CT网元和IT网元是不同的，那么对LB的需求也是不同的。前文提到，NFV转发类网元的性能要求很高，而作为对外统一入出口的LB，其承载的性能压力将是所有NFV南北向流量之和，这远远不是IT资源池中LB所能匹配的。另外，LB作为关键路径，可靠性要求非常高，而为了提供对外统一接口，LB通常采用主备方式部署，如果出现故障，整个NFV资源池都无法再对外提供服务了。
那有没有变通的方式呢？NFV标准架构里最上层是编排器，负责业务的编排，如果能够扩大编排器的范围，将外部网络设备也纳入管控范围，实现端到端管理，那么编排器就有一个全局的视角，在一定程度上可以实现一定粒度的LB。比如编排器直接在配置时对外部网络设备按接口+业务类型直接分配不同的NFV网元，这也实现了负载均衡，只不过是一种静态的、预先规划的负载均衡。这种静态的，再结合NFV间流量调优，也能满足一定场景的需求。
思考2：NFV网元容器化部署必要性探讨
现在云平台不仅提供虚机服务，还可以提供容器服务，给用户更多的选择。那么容器是否适用于NFV网元呢？容器特点之一是轻载，因为它没有操作系统，所以在容器数目负载多的时候，这一部分就可以减少很多服务器的压力。但CT网元和IT网元不一样，同样服务器配置下，NFV网元数目非常少，比IT低一个数量级，尤其转发类NFV网元可能一种CPU只跑一个网元，所以轻载就可能没有那么强的必要性。
容器特点之二是部署速度快，因为它的启动就是直接秒级作用的，非常快。但NFV网元一般启动后就不会关闭，是持续运行的状态，故障倒换时也是预先拉起网元，所以启动时间起到的作用也并不关键。容器最明显的特点就是安全性低，毕竟多容器都是共享同一个HostOS，其中一个容器崩溃如果影响到内核，那么其它容器也必然受到影响，而NFV网元对安全性、隔离性要求是非常高的。
所以是否进行容器化部署还需要探讨，或者采用折衷的方案用虚机+容器来承载NFV网元。
思考3：NFV资源池对云平台的需求
上图中的数据中心方案里，顶层为云平台，用户在云平台上操作，创建网络、子网、端口、Router/VPN/FW/LB，总入口在云平台，VM的生命周期（创建删除）都是由云平台发起的，所以openstack是一个非常完整全面的复杂系统。而在NFV架构里，总入口是编排器，它了解业务，决定NFV生命周期的时机，云平台只是提供北向接口被动响应请求。
孟丹表示，云平台在NFV架构里的地位已经被弱化了，是否相应云平台的功能也不用要求太多？这个问题的提出也是对实际部署问题思考后的结果，每次落地时管理服务器数目的缩减都非常让人头疼，毕竟前期NFV资源池规模小，管理服务器有时候显得太重了，甚至曾经想过能不能VNFM直接对虚拟化层，把云平台这层省略掉，但这样解耦会有问题，所以目前也没有一个可行的方法。
最后，孟丹指出在做NFV资源池的这个方案中，对待IT技术的态度应该是选择性借鉴的，基于低可靠的IT硬件来构建高可靠的CT网络，让方案更合理、更可靠、更有意义。