NFV，凛冬将至？
我目前从事传统通讯领域产品研发工作。产品以及产品线在NFV领域已经投入了多年，自己也亲历了几年前业界“忽如一夜春风来”的风风火火，踌躇于今天NFV领域运营商和设备商的同时迷茫。业界对此的思考越来越多，最近在搜狐号上读到了一篇文章，《NFV的五大矛盾》，作者是“顾炯的云世界”。顾炯挺客观的对NFV甲乙双方进行了分析，罗列出业界的种种郁闷。我总觉得，NFV的意义是非凡的，但绝不是今天的技术或思路能够匹配，这需要时间，需要对曾经的脑子发热进行复盘，也需要付出一定的代价，才能更加理智客观。
原文很长，也很深入，摘录《NFV的五大矛盾》中的部分关键的文字，感谢顾炯的思考与分享。
《NFV的五大矛盾》 -- 顾炯的云世界
（原文地址：http://www.sohu.com/a/132083438_610325）
矛盾1：自主与商业的矛盾
NFV的主要目标是实现网络设备的软硬件分离，可以进行云化、按需动态伸缩和自动化部署，未来结合网络大数据可以实现智能化运营。
NFV的总体趋势是底层硬件实现相对通用化，采用虚拟化技术/容器技术或分布式架构技术实现对底层通用设备的共享和弹性，向上为VNF（虚拟网络功能）按需提供各种配置的资源，这意味着NFV三个方面的特点或关键点：
- VNF才是未来网络发展的“焦点”。VNF的微服务化、分布式架构改造、开源化、自主研发、Devops是未来的发展趋势，但当前VNF基本还是掌控在已有电信设备商手中，运营商几乎没有能力染指。
- 构建统一的NFVI资源池体系，服务于全网的云化，这是运营商认为的可以实现成本降低的主要希望，但实际上除了集约化带来的电力成本降低以及机房空间节省外，从基础实施角度看是否降低成本难以评估，需要考虑服务器/存储/网络新建成本、NFV软件、HA、灾备、机房改造等总体成本。
- 需要引入新型的OSS和EMS/NMS，实现对VNF、VR（虚拟资源）以及PR（物理资源）的监控、配置、管理以及更高层次的网络服务编排等，这部分目前是由NFV架构中的MANO来完成
在以上所述的三个方面中，NFVI、各类VNF、MANO是NFV架构中的关键，以软件实现为主，从利于NFV规模化发展和实现最低化成本考虑，运营商是应该选择部分组件进行自主研发，但现实情况是：
- NFVI：目前大部分厂商都是基于开源KVM进行商业化定制和优化，特别是针对NFV转发性能要求高的特点，各个厂商都做了针对性的技术优化，这部分工作仍然难度相当大，运营商没有任何技术基础和人才积累。各个厂商的Hypervisor与各自的VIM是存在捆绑性的，形成各自的“小王国”，无法实现不同厂商Hypervisor的互通。
- VNFs：各类网元原来都是软硬件一体化的，运营商对网元的内部实现机制并不熟悉，也没有人真正去探究网元设备的大型软件系统该如何实现，这部分软件目前对于运营商来说也没有可能采取自主研发来实现，需要运营商逐步去积累和投入，重点是实现VNF的分布式部署，微服务化，为将来实现真正的基于容器的部署打下基础。
- MANO：MANO是由NFVO、VNFM和VIM组成的，VNFM与VNF是强关系的（存在部分通用VNFM）、VIM与Hypervisor也是强关系的，这两部分运营商目前还无力进行自主研发，所以VNFM和VIM基本也是放弃的
对于运营商而言，NFV的可靠性可能更重要，NFV的弹性并非想象的那么重要，VNF自身在架构上应能实现横向扩展（例如借助弹性负载均衡），不能完全依赖于NFVI的弹性（这种弹性也只是VM/容器本身资源能力的伸缩，也就是垂直扩展）。因此运营商应着重在NFV系统的多层次、多模块之间的联动故障检测和统一自愈策略上进行研发，同时推动VNF本身架构上的革新，以更有效地利用NFVI的优势。
矛盾2：解耦与一体化的矛盾
NFV架构相比传统的云资源池要复杂一些，由于VNF相比传统的IT和业务平台，对基础设施（NFVI）要求高很多，同时为了实现可运营和自动化，引入相比云资源池的云管平台更复杂的MANO系统（内部又可以独立为三个模块），这就带来了非常复杂的体系架构，如果要按照模块或层次解耦来部署，不同层次或模块之间有大量的需要规范的接口，对于运营商来说，选择一体化的紧耦合的NFV的厂商整体解决方案还是力推解耦，模块化组合和集成的多厂商方案，是目前最为棘手和相对难度较大的问题。
选择一体化的单厂商整体方案的好处就是可以实现快速部署，整体系统的性能、稳定性与可靠性是比较理想的，不需要进行异构厂商的互通测试与集成；不利的地方是与传统网络设备一样，存在软硬件一体化和封闭性，难以实现灵活的架构部署，不利于实现共享，与厂商存在捆绑关系，不利于竞争，会再次形成烟囱式部署，总体成本较高，也不利于自主创新以及灵活的迭代式部署升级。
选择解耦的多厂商集成方案好处是可以实现通用化、标准化、模块化、分布式部署，架构灵活，而且部分核心模块可选择进行定制与自主研发，也有利于形成竞争，降低成本，实现规模化部署；不利的地方是需要规范和标准化，周期很长，也需要大量的多厂商互通测试，需要很强的集成开发能力，部署就绪时间长，效率较低，后续的运营复杂度高，故障定位和排除较为困难，对运营商的运营能力要求较高。
矛盾3：集中化与分布式的矛盾
云计算存的几大本质特征：
- 按需分配，动态伸缩，这是云最为重要的特征。这种按需和动态是自动化的，不需要或很少需要人去干涉，由监控系统监控资源负载甚至用户应用负载情况，然后自动去调度资源、扩展和回收资源
- 云之所以有成本上的巨大优势，并非简单地引入虚拟化技术就能实现的，涉及到全局资源调度能力、产品模型优化、规模化经济效应、服务器高度定制化、 软件定义技术、自动化部署与运维技术、DC机房选址以及制冷电力节能技术的引入等
- 云服务也是一种互联网化的IT服务，既要保证有规模，还要离用户更近一些，同时更要保证HA
从云计算的几个特征看，云计算的基础设施需要尽量集约化和规模化，以保障最大化的共享、按需提供资源以及实现低成本，但过于集约化和规模化可能无法保障用户的体验，所以需要在集约和分布两者间实现平衡
NFV的基础是NFVI，本质上是云基础设施，而NFVI的部署同样面临着集约化与分布式部署的矛盾。集约化好处是建设部署门槛较低，运营成本更低，能够集中实现冗余和灾备，网络架构较为简单，管理更为方便，但是仅适合于计算型的VNF，例如vIMS，但不适合于实现接入型、宽带流量型和高转发型的VNF，例如BRAS、交换机、路由器等，这是与网络本身的特性和层次化架构相关的，涉及到用户体验以及网络架构调整的问题，成本太高（例如要增加大量的光缆，况且现有的路由器/交换机交换能力和端口带宽限制也无法满足集约带来的流量过渡汇聚）。因此，对于运营商的网络NFV，无法做到像IT资源池那样集约化，需要根据网元位置进行分层的下沉部署，例如在本地化的DC上进行部署，这将导致NFVI的资源池节点体系非常分散，带来的挑战非常巨大：
- 本地网目前并没有合适的可部署NFVI的机房，需要充分利用本地网CO机房进行DC化改造，这带来CO选址、改造的挑战（有些CO机房改造成本过高，而新建机房又没有政策条件）
- 本地网的NFV容量较小，这就带来了大量的分布式的资源池建设问题，资源池的分裂以及网络条件的限制无法实现共享和调度，建设成本也较高（例如每个资源池都要独立部署VIM、VNFM模块），每个本地网的DC都需要有容灾的部署，增加了部署成本，另外在资源的维护上压力也较大，人工成本较高
- 各省的本地网需求和CO差异较大，这可能带来的问题是未来NFVI资源池五花八门，很难统一（例如厂商类型过多，架构封闭性，实现资源统一规划、部署和管理难度极大）
总而言之，未来的NFV资源池部署既要考虑网络层次化架构带来的分布式部署必然性，又要充分利用云资源池集约化部署优点，充分做好业务和DC规划，通过包括传控分离技术、业务流量分离技术等技术实现一定的集约，同时也需要从资源池的部署架构（包括冗余）和管理架构上进行统一，避免因为分布式部署带来的架构分裂和管理分散，为将来条件成熟时统一部署NFVI DCI网络以及实现统一调度创造基础条件。
矛盾4：现网NFV与否的矛盾
NFV概念之所以会被提出来，一个是云发展到较为成熟的阶段，一个是软件定义网络（SDN）概念的兴起，让全球运营商几乎一致地（AT&T更早开始践行）选择NFV作为网络演进的方向。NFV实际上首先就是要让网络功能能够从封闭的专有硬件中分离出来，以软件的形态（例如VNF）存在，其次就是为了能够承载各类VNF，对现有的云基础设施和管理架构进行增强和扩展（例如引入MANO，增强了网元生命周期管理以及网络服务（Network Service)的编排能力，实现自动化的网络服务管理与部署）。运营商部署NFV不外乎两个目标：
- 节省成本，这个是一个伪命题，如果认为专业化设备成本太高，NFV化因为虚拟化共享就一定能够带来成本的降低，那一定是一个误解或者被忽悠。NFV除了大量的服务器（虚拟化比例比IT更低）、昂贵的FC SAN存储、新的接入/核心交换机外，还要大量的Hypervisor License、MANO组件License、VNF License，为承载NFV而进行CO改造的成本，还有为备份、HA、容灾需要付出的软硬件成本以及网络成本等，网络NFVI的最终规模要远远大于业务平台或IT云资源池，这意味着如果要把现有网络所有网元都进行云化，要付出巨大的云化成本（新增投资，几乎没有可利旧的）。对于运营商来说，由于不掌握NFV核心技术（即使投入自主研发，由于研发效率和机制问题，不一定就比购买商业软件便宜），如果为了NFV而NFV，已有未退网的网元为了实现云化比例进行迁移，很难说在成本上会有节省。有人说，针对扩容或者新建可以先行部署NFVI，成本上有优势，但至少我目前还没有看到厂商有可信服的成本节省公式，如果将来能够实现标准化和解耦，也许通过通用化和规模化集采，可以节省一部分成本
- 快速部署，弹性伸缩，能够让运营商变得跟互联网公司一样，可以迭代式开发业务，快速升级业务，可以快速和动态满足客户需求，这是一个看起来很美的好处，但实际上运营商有没有这样的业务值得怀疑。有人说比如VoLTE业务按原来模式需要按照1亿用户部署，现在只需要先部署100万，然后随着业务发展，自动扩展资源，快速部署VNF，就可以满足了，可以节省大量资源的闲置，但是这种情况是假设运营商的规划、建设和采购模式也跟着“NFV”化才行。
NFV看似很美好，运营商可以转型为“玩”软件的高大上公司，但实际上所有都是要“买”的，最后能节省的可能是由于技术的引入而带来运维人员成本的降低，但运营商最不缺的就是人啊。之前有人说设备商对NFV是咬牙切齿的，NFV是会埋葬设备商的，至少目前看来，短期内NFV是设备商的新增市场，长期看，设备商依然占据着VNF License。
当然NFV也并非一无是处，至少对于运营商来说，提供了一个“潜力”，确实在部署和升级业务上可以比之前更快（理论上可以只升级VNF软件）。在理想状态下，NFVI可以借助软件实现全网的自动化部署和智能化管理，最终实现硬件通用化甚至白盒化后，可以实现成本的下降，另外也提供了自主研发的可能。而从VNF看，未来物联网和大视频时代，网元的弹性需求可能比现在要求要高得多，NFV肯定要比现在固化的网络更能满足发展需要，另外VNF外后，也提供了一定的创新空间，同时创造了网络开放的更好条件，不过这一切都需要运营商具备足够的掌控力才能真正发挥出来，否则可能是海市蜃景。
因此，对现有网络而言，并没有NFV化的急切需求和必要性，现有网络可以随着扩容或退网而逐步引入或替换为NFV技术。当然，现有网络不推进NFV，仅是新业务部署NFV的话，很难在既定时间内实现网络云化的目标，将来也面临着两套网络系统的部署和运维问题。不过，当前NFV更重要是在于全网架构以及技术应用和发展策略的明确，而不是云化的目标，或者所谓降低成本和为了弹性（绝大部分没有真正的分钟级甚至秒级的弹性需求）
矛盾5：统一承载和分离承载的矛盾
随着NFV的推进，自然而然地运营商一方面希望未来VNF与IT也可以实现统一承载，另一方面希望可以利用现有云资源池承载VNF，从而实现“利旧”。但是由于以下原因，这种希望当前还不太现实：
- 目前NFV不要说三层解耦，就是物理资源和之上“软件”的解耦还没有解决。由于承载的是传统网络网元，目前主流的NFV方案基本由设备厂商把持，传统的IT方案厂商被边缘化。而根本的原因是VNF是由设备商来主导，设备商或忽悠或强势要求只能采用自家的虚拟化软件甚至服务器，才能保证性能和可靠性，而要推进三层解耦，需要充分的多厂商的测试和集成工作
- 虽然说现有云资源池从技术上基本具备承载计算型的VNF，但现有的云管平台还需要增强NFV支持（例如巨页内存、DPDK、SR-IOV、NUMA绑定等），需要测试对各种虚拟化软件NFV特性的配置和支持能力，同时由于NFV引入所谓的MANO架构，云管平台还需要测试与NFVO以及各种厂商VNFM的对接能力
- 针对转发性能要求高的VNF（例如vBRAS、vEPC）, 网卡数量上有更高的要求，服务器模型必须更新
- 只有部分网元适合放在集约资源池，其他大部分网元需要放到端局层面的DC上，而这个层面没有IT承载需求，属于新建的NFV资源池节点
- NFVI基本上采用的都是基于KVM的商业定制版（与基于OpenStack的商业定制版VIM配合），虽然VMWare本质上承载VNF也没问题，但VMWare是IT厂商，VNF没它事，而且VMWare已经被标签为昂贵的商业软件，这带来的问题就是现有以VMWare为主的IT资源池未来与NFVI资源池没有共享性
综上，现有云资源池虽然可用于承载部分VNF，但未来需要新建大量专属于NFV资源池节点（或在现有云资源池中独立部署集群），新的服务器模型（可能会出新的定制化服务器），新的虚拟化软件模型，新的管理架构（可共享部分现有云管理平台功能作为VIM），VNF和IT无法统一调度承载，更多的只能在规划、建设和运维层面去统一
以上五个矛盾，正是运营商这几年的痛苦经历。云化是一种方法，但不是目的。业务与管理双重演进的方向需要及早明确，这永远都应该放在第一位。
最后，再次感谢顾炯，他的很多文章都值得去看一看，友情链接如下：
顾炯的云世界：http://mp.sohu.com/profile?xpt=Z3VqaW9uZ2Nsb3VkQHNvaHUuY29t
