NFV理解的误区

masichen

NFV理解的误区

原创 2017-03-28 顾炯 顾炯的云世界

    写过了“NVF的本质就是IT化”和“吃瓜群众的NVF”以后大家再聊“NFV的陷阱”。

NFV是CT人干的事情。这里的CT不仅仅包括运营商还包括了设备提供商。CT人有意无意的给自己挖了一个陷阱，认为NFV就需要用虚拟机承载。我接触过的所有CT厂家，都是这样的观点，并且都只能用本厂提供的虚拟App虚拟出来的虚拟机。打着“底层经过优化”的幌子，行“捆绑销售”的本质。但是我并不是认为那是CT人的故意，因为CT人实在没有搞清楚什么是云计算，所以提及“资源可以灵活共享，系统可以快速部署，实现新业务的快速开发和部署，并基于实际业务需求进行自动部署、弹性伸缩、故障隔离和自愈等。”的时候，把这些光荣而重要的任务就扔给了云计算，扔给了虚拟机。在很多人眼里“云”就是保险箱，就是万事通，这里有很多误区需要澄清。

NFV并不是一定要用虚拟机承载

虚拟机的出现是因为物理服务器处理能力太强，应用独立使用太浪费，所以将物理机的处理能力一分为N。在物理设备上部署一个虚拟化App，将物理服务器的CPU、内存和I/O设备进行“虚拟化”后再共享，模拟出多台虚拟的服务器。虚拟化的过程本身也是需要消耗不小的性能。在“虚拟机是个浪费的东西”的文章中阐述过：“对计算资源需求不大的小应用适合虚拟化，而计算能力要求大于服务器能提供能力的四分之一以上的应用建议采用物理服务器。”不少传统CT的基础核心网元，承担着基础通信任务，通俗的说就是“很忙”，对计算、网络带宽都有很高的要求，可以根据不同网元的实际情况不同，选择选用物理机或者虚拟机。甚至可以在同一个网元上采用物理机+虚拟机的混合部署，比如日常基础量用物理机承载，突发量采用虚拟机承载。

延伸阅读：“按需应用”（3）——虚拟机是个浪费的东西

虚拟化App和NFV没有关系

所有的CT厂家提出NFV需要的虚拟化App必须是本厂提供。类似于原来核心网很多网元一定要同一厂家提供的服务器一样，是典型的捆绑销售，是“App垄断”的前奏。

应用不是直接部署在服务器上的，而是部署在操作系统上。虚拟化App只是模拟出一台服务器而已，这种模拟是基于底层指令集的，对于操作系统本身也并不感知，更何况是操作系统上的应用呢？不同的虚拟化App的差别是虚拟化App本身运行的稳定性、安全性和兼容性。对于一个成熟的虚拟化App来说，只要X86服务器上能正常运行的操作系统就可以在虚拟机上运行。所谓CT厂家的虚拟化App其实就是基于开源的XEN或者KVM上改造而来，这些大部分CT厂家的虚拟化App应用场景少，也没有经过大范围的应用验证，反而风险更大。如果不同的NFV网元都采用不同虚拟化App，建设不同的资源池，资源共享就无从谈起，又成为各种资源池“竖井”，和传统的服务器竖井架构有什么区别？好不容易打破的硬件竖井又改头换面回来了。

延伸阅读：“按需应用"(2)——虚拟机就是X86

虚拟机的迁移不是高可靠的保障

虚拟机带来最好特性就是“迁移” 。但虚拟机的迁移并不给应用带来高可靠或自愈的特性。虚拟机的“冷迁移”本质上就是虚拟机的HA，即每台虚拟机和管理平台都有“心跳”，当管理平台发现某台虚拟机失去“心跳”会在合适的物理机上重建这台虚拟机。这个过程实际上中断业务的，业务恢复的时间是分钟级的。

虚拟机的“热迁移”其实也是虚拟机本身维护手段。一般分为主动热迁移和被动热迁移。主动热迁移是维护人员为了维护主机等原因将虚拟机迁移到其他服务器上。被动热迁移是指当虚拟机所在的物理机利用率达到设置的阀值后采取的减负措施。迁移走的是本物理机上最空闲的虚拟机。不管是主动或者被动热迁移并不是每次迁移都会成功，CPU和内存利用率高的虚拟机的迁移往往经过长时间的尝试后失败。

虚拟机的迁移是围绕“物理机”的一种维护手段，并不会感知应用。但可以利用虚拟机的特性来提高维护水平，比如原来采取物理机承载，当物理服务器故障恢复是一个比较漫长的事件，而利用虚拟机可以分分钟可以搞定。

延伸阅读：基础常识——虚拟机的迁移

虚拟机并不可以向应用提供弹性伸缩的能力

虚拟机的在线“纵向”扩容能力（在线增加CPU、内存等资源）并不是虚拟机的能力，而是操作系统的“功劳”。但是，并不是所有的操作系统都可以支撑在线扩容。所有的操作系统都不支撑在线的“纵向”缩容（在线减少CPU、内存等资源），要完成缩容操作需要虚拟机的重启才能完成，也就是需要中断业务。所以虚拟机并没有像大家以为的那样灵活。简单的想利用虚拟机的“弹性”做不到基于实际业务需求进行自动部署、弹性伸缩。

大家可以借助“四到七层”的网络设备——负载均衡来做到应用的“横向”弹性伸缩。本身这个特性是网络设备本身提供的，认的是IP地址和端口号，对于物理机和虚拟机来说是一样的。只是虚拟机可以更省些资源，因为虚拟机在关机的时候就是在共享存储里的一个文件，并不需要占用实际的物理资源。

不管是“纵向”还是“横向”伸缩能力都要结合应用本身的特点，而不是简单的监控CPU和内存。需要利用一些业务系统收集的日常数据，进行数据分析，建立合适的模型，防止误判，实现弹性伸缩。实际应用中，特别是“缩容” 可能会影响到内存里的数据和进程，随便重启或关机也会中断或影响业务。

延伸阅读：“按需应用”（4）——应用架构

改造并不是简单的迁移

不少NFV改造往往是为了改造而改造，比如原来是一张板卡，就对应一台虚拟机的的改造；把虚拟机直接封装在容量里做容器部署的改造等。。。特别是核心网元的改造，因为提供的是普遍服务，日常的业务量很大，硬件改造成为App后，本身的处理能力实际上是下降的。就需要一个能够符合App定义特点的架构和实现方式。“容器”的微服务架构可以帮助解决核心网元长期以来的“升级影响大”、“新业务开发慢”等存在的难题。但是真正采用容器的微服务架构，需要将原来的应用体系完全推倒重来，而且短时间内也达不到现有系统的功能和稳定性。这个成本是CT厂家不愿意承担的。所以现在CT还是喜欢用“新瓶子装老酒”，卖了二道钱。换了马甲的NVF改造意义不大。

延伸阅读：按需应用（五）——“多小灵”的细微变化