【大咖・来了 第7期】10月24日晚8点观看《智能导购对话机器人实践》

IHS 近期发布的报告显示，包括硬件、软件和服务在内的全球NFV市场规模，将在2020年达到155亿美元。近年来，移动运营商在软件领域的投入要远远大于在服务器、存储以及交换机硬件方面的投入，足以见得电信行业想通过NFV技术将重心从硬件转移到软件的决心。

不过运营商在发展NFV的过程中，由于对新兴技术理解不足、现网商用经验匮乏等原因，会产生诸多误区。比如，很多运营商认为NFV需要用虚拟机承载，并且只能用某家设备厂商提供的软件虚拟出来的虚拟机。这就造成很多设备厂商打着“底层优化”的幌子，对运营商进行产品的“捆绑销售”。本文将针对“NFV与虚拟机的误区”进行详细解析。

虚拟机应按需求部署

在网络架构中，虚拟机的出现是因为物理服务器处理能力太强，某个应用独立占用过于浪费，所以将物理机的处理能力“一分为N”，在物理服务器上部署一个虚拟化软件，将物理服务器的CPU、内存和I/O设备进行“虚拟化”后再次共享，模拟出多台虚拟的服务器。

但是虚拟化的过程本身是需要消耗不小的性能。为了模拟出一个“虚拟机”，也需要额外的附件，这些附件包括虚拟化软件、东西防火墙、防病毒软件等。这些附件都是需要额外购买的产品，并且运行这些软件还需要占用物理服务器的计算资源，并且消耗资源。

虚拟化的目的是提高资源利用率，但不一定节约成本，只有合理的虚拟化才能达到节约成本的目的。虚拟机的一些特性，如HA((High Availability，高可用性)、迁移等，确实会带来应用管理上的便捷，但这是虚拟化带来的“副产品”，如果为了“副产品”而选择采用虚拟机，比如，一个服务器上只开设一台虚拟机或少量虚拟机，那就是资源浪费。

云计算的理念是按需分配，并不是一味追求全部使用虚拟机。因此我建议，对计算资源需求不大的小应用适合采用虚拟化技术，而对计算能力要求大于服务器能提供能力的四分之一以上的应用，建议采用物理服务器。另外，由于不少传统运营商的基础核心网元承担着基础通信任务，通俗地说就是“很忙”，对计算、网络带宽都有很高的要求，在这种情况下，就要根据不同网元的实际情况，选择物理机或虚拟机。甚至可以在同一个网元上采用物理机+虚拟机的混合部署模式，比如日常基础量用物理机承载，突发量采用虚拟机承载。

采用同厂家虚拟化软件恐再陷垄断

大多数设备厂商提出，运营商实现NFV所需要的虚拟化软件必须是本厂提供。这点类似于运营商传统核心网网元要采用同一个厂家提供的服务器要求，是典型的“捆绑销售”，是“软件垄断”的前奏。

因为应用并不是直接部署在服务器上，而是部署在操作系统上。从架构上来看，物理机和虚拟机的架构完全一样，虚拟化层只是对原来的硬件做了点“手脚”。除了CPU、网络等资源是按照“时分”外，其他的如内存、存储等都是按照“空分”来实现。虚拟化层的“魔术”会让操作系统完全区分不出用的是物理机还是虚拟机，更何况是加载在操作系统之上的应用。

而虚拟化软件的差别只在于其本身运行的稳定性、安全性和兼容性。对于一个成熟的虚拟化软件来说，只要是在x86服务器上能正常运行的操作系统，同样就可以在虚拟机上运行。目前，很多设备厂商的虚拟化软件其实就是基于开源的XEN或者KVM(Linux虚拟化技术用户目前可选择的两种免费开源管理程序)上改造而来，但这种类型的虚拟化软件应用场景少，也没有经过大范围的验证，反而风险更大。另外，如果不同的NFV网元采用不同虚拟化软件、建设不同的资源池，不但资源共享无从谈起，可能再次形成了各种资源池的“竖井”，与传统的服务器“竖井”架构毫无区别，***结果就是，好不容易打破的硬件“竖井”又改头换面出现了。

虚拟机迁移功能并非代表高可靠保障

另外，大多数人也会对虚拟机的“迁移”(vMotion)功能产生误区。迁移是虚拟机带来的最重要特性。迁移是一项资源管理技术，不能替代原来的高可靠性技术(如HA等)。迁移可以分为“热迁移”和“冷迁移”。虚拟机的“冷迁移”本质上就是虚拟机的HA，即每台虚拟机和管理平台都有“心跳”，当管理平台发现某台虚拟机失去“心跳”，就会在合适的物理机上重建这台虚拟机。这个过程实际上需要中断业务，而业务恢复的时间也是分钟级的。

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

也就是说，不管是冷迁移还是热迁移，都无助于应用访问进行故障切换和快速恢复。迁移的目的是尽可能方便地为维护人员提供资源调度、转移手段，当物理服务器维护时需要关机重启，当物理服务器出现繁忙，当数据中心需要扩容重新安排资源，这种时候迁移就有用武之地了，但虚拟机的迁移并不给应用带来任何的高可靠或自愈特性。

虚拟机无法向应用提供弹性伸缩能力

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

如果真想实现应用的“横向”弹性伸缩，可以借助负载均衡模式。负载均衡是网络设备本身提供的，他们识别的是IP地址和端口号，对于物理机和虚拟机来说效果都是一样的。只是虚拟机可以更省些资源，因为虚拟机在关机的时候就变成共享存储里的一个文件，并不需要占用实际的物理资源。

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

换了“马甲”的NFV改造意义不大

目前，在运营商NFV改造过程中，出现了很多“为了改造而改造”的现象。比如原来是设备上一张板卡，就对应一台虚拟机的的改造，把虚拟机直接封装在容器里进行容器部署的改造。特别是核心网元的改造，因为提供的是普遍服务，日常的业务量巨大，硬件改造成为软件后，本身的处理能力实际上是下降的，这种情况就需要一个能够符合软件定义特点的架构和实现方式。

特别强调的是，“容器”的微服务架构可以帮助解决核心网元长期以来的“升级影响大”、“新业务开发慢”等难题。但是真正采用容器的微服务架构，需要将原来的应用体系完全推倒重来，而且短时间内也达不到现有系统的功能和稳定性。上述成本是运营商不愿意承担的，所以现在运营商还是喜欢用“新瓶子装老酒”，但这样换了“马甲”的NFV改造意义不大。