NFV再谈（应用现状篇）

NFV全称是Network Function Virtualization，是指对网元做虚拟化。NFV一般来说，是指用x86虚拟机（有时也会用物理机）实现专用网络设备的功能，以及与之衍生的管理系统。半年前在专栏说过一次NFV（NFV闲聊），其中有一些基本概念，这次再从一些应用的角度来看看NFV。

有关NFV的误解

NFV只与电信运营商有关?

之所以有这个观点，这与欧洲电信标准中心（ETSI，European Telecommunications Standards Institute）在NFV的发展过程中的重要作用不无关系。有关ETSI提出的NFV架构标准在上一篇中有过介绍，感兴趣的同学可以回去看上一篇：NFV闲聊（基础技术）。

并且，早期与ETSI一起制定NFV标准的都是一些电信公司，例如AT&T，荷兰电信，NTT等。这些公司的参与给NFV或多或少打上了“电信”的标签。基于成本和稳定性等因素的考虑，ETSI和这些电信公司指定了一些可以被虚拟化的网元。如下表所示：

可以看出，这是一个很具有电信运营商特色的表格，其中一些网元只存在于电信运营商的应用场景，例如Broadband network gateway，GPRS support node等。

另一方面，现在主要的NFV项目，例如Open Source MANO，ONAP等都是由电信运营商在背后支持。

所有的这些似乎都表明NFV只是电信运营商的技术。那实际上呢？

实际上在数据中心内部，虚拟化的网元已经存在了很多年。例如虚拟的路由器，虚拟的防火墙，虚拟的WAN优化器等。数据中心内部的虚拟化网元，倾向于提供网络的4-7层服务。其实从ETSI和电信公司们指出的可虚拟化的网元中（上表）可以看出，表中很多虚拟化的网元可以直接应用在数据中心内部。实际上，大部分集中式的网络服务，都适合以NFV形式在数据中心内部实现。对比电信运营商的NFV和数据中心内部的NFV，共同点多于不同点。并且，普遍认为，数据中心的NFV架构更加简单。

根据Webtorials《The 2016 Guide to SDN & NFV - Complete Guide》,有超过50%的IT专业人士认为NFV与企业数据中心有关联。

因此，现在当我们在讨论NFV的时候，这不是一项专属于电信运营商的技术，NFV技术同时应用于电信运营商和数据中心。

NFV的优势是降低成本?

这是一个普遍的误解。从VNF本身来说，成本是低于传统的物理网元（PNF）。但是部署VNF本身需要一个x86资源池，数据中心内部或许本身就有这样一个资源池，边际成本较低。但是对于电信运营商来说，切换到NFV意味着需要新建一个x86资源池，早期边际成本较高。

由于VNF运行在一个共享的x86资源池中，影响性能的因素较多，例如分配的资源，带宽等。举个例子，一个实现了router的VNF，究竟能承载多少路由、网关，与分配给VNF的资源有很大关系。 要使得NFV能够终满足商用目的，对于x86资源的调优和高可用需要额外投入成本。而这些在PNF中是不存在的。PNF由于是专用设备，制造商在出厂时，已经完成了相关的调优和高可用方案。

现在流行的两个NFV项目，Open Source MANO和ONAP，都是开源项目。表面上看，开源能够降低NFV成本，但是开源本身只是节省了软件的采购费用，并没有节省集成和运维费用。实际上这两个项目都太过复杂，落地和运维需要投入大量人力，并且离实际应用还有很远。现阶段开源NFV并不能给NFV带来成本效益。

总之，NFV在短期内的投资回报比（ROI），是不如传统物理网元的。

在讨论NFV的优势时，应当更多关注其快速、灵活的部署和运维能力。例如，为了应对高峰业务，用户可能需要采购1000台设备，但是高峰业务，一般是短暂，且有规律的。这意味着1000台设备中的大多数，在可预期的时间里要闲置。如果应用NFV，使用虚拟化设备完成相应的功能，再根据业务的需要创建或者删除这些设备，在平时只维护100个设备，在业务高峰再创建剩下的900个设备，这可以从一定程度上减少使用成本。

另一方面，NFV可以缩短业务部署时间，传统的物理网元，布线，布电，机架空间的准备等，需要数周甚至数月的时间才能使业务上线。而NFV部署网元的时间可以大大缩短，几个小时或者几分钟，就可以将一个VNF部署出来。时间成本的降低，一定程度上来说也是成本的降低。

NFV能防止厂商锁定（vendor lock-in）?

数据中心内的VNF更多的是用户开发，现在的软件，例如haproxy，lvs，iptables，dnsmasq等够较为方便的在linux机器上，实现相应的VNF。

对于电信运营商，VNF更多是采购自相应的网络设备商。而NFV大吸引力之一在于打破了单一供应商的锁定，使用户在未来的网络搭建中掌握更多的主动权。用户可以根据技术和商业发展来改变自身的策略，混合各家的产品，采购合适的解决方案，并且连接到同一个管理平台。这使得买方的议价能力大大提升。

但是以上都是买方的美好愿望。现实中，厂商出于各种目的会尽量避免自家的VNF与第三方VNF集成的方案出现。厂商可能会说，与第三方的集成需要额外收费，或者说兼容性不好，集成起来非常麻烦，甚至说与第三方的连接性能不如全采用自己一家。厂商的目的大部分时候是简单的做单，尽量做大单，而不是真正意义的开放，与第三方集成违背他们自己的本性。

NFV和SDN

普遍认为，SDN和NFV各自独立发展，同时也相互补充。

从NFV的角度来说，或者从电信运营商的角度来看，SDN之于NFV是这样的：

• SDN控制器对应了ETSI的NFV架构中的网络控制器。
• SDN由于其灵活的网络控制能力，在管理NFVI（NFV Infrastructure）资源时，能灵活提供网络连接，带宽分配，监控，安全，策略控制等功能。
• SDN能为NFV方便的提供多租户。
• SDN中的SFC功能可以实现NFV的Forwarding Graphs

ETSI和ONF（Open Networking Foundation）积极推进SDN和NFV的集成。在OpenFlow-enabled SDN and Network Functions Virtualization中，还给出了NFV和SDN集成参考架构，在SDN的三层架构中，NFV位于应用层。

从SDN的角度来说，或者说从数据中心的角度来看，NFV更像是4-7层网络服务的理想实现方式。以OpenFlow为例，并不是所有的服务都适合通过OpenFlow实现。因为一方面OpenFlow的目前的语句大多停留在2-4层，且比较简单，另一方面，通过上送控制器实现网络功能效率和可靠性得不到保证。现实中通常在SDN控制器节点上运行单独的进程完成相应的网络功能，例如eBGP router。而采用NFV的概念，可以将这些进程解耦成VNF，在单独的节点上实现，并且通过VNF的接口api来控制相应的网络功能。

根据Webtorials《The 2016 Guide to SDN & NFV - Complete Guide》，绝大多数IT组织认为SDN和NFV是互补的技术。

NFV的发展

NFV的概念是从2012年开始提出，但是根据Webtorials的报道，直到2016年为止，只有14%的用户在产品中使用了NFV。大部分还处于实验，分析和计划阶段。

一方面可以说NFV仍然有很大的发展空间，另一方面，也可以看出，NFV的前几年的发展势头并不很好。阻止NFV发展的因素，归结起来可以有以下几点：

• 缺乏强有力的案例。不可否认，NFV已经发展多年，现在仍然没有一个大的成功案例
• 安全性的考虑，专有设备的安全性通常被认为会更高
• 目前产品仍然不够成熟
• 技术栈的更新。传统的方案相关的运维人员，在面对NFV时，通常需要重新学习。