运营商NFV落地之困 择商用软件还是自主研发?

栏目: 后端 · 发布时间: 7年前

内容简介:运营商NFV落地之困 择商用软件还是自主研发?

目前,NFV的主要目标是实现传统网络、网元设备的软硬件分离、网元功能的软件化、可以进行云化、按需动态伸缩、自动化部署和编排以及将来实现智能化网络运营。

采用商用软件和自主研发各有利弊

NFV的总体趋势是底层硬件实现相对通用化,采用虚拟化技术、容器技术、分布式架构技术,实现对底层通用设备的共享、调度、弹性和可扩展,向上为VNF(虚拟网络功能,即网络功能的软件实现形式)按需提供自动化配置的资源,这意味着NFV具备三个方面的关键特征。

运营商NFV落地之困 择商用软件还是自主研发?

第一,网络功能软件化。未来的网络功能升级、增强都是通过软件完成的,不需要(或者很少需要)底层硬件的升级或扩容,因此VNF软件才是未来网络发展的焦点,VNF的微服务化、分布式架构改造、开源化、自主研发、Devops是未来的发展趋势,但当前VNF技术基本还是掌控在电信设备商手中,运营商几乎没有能力染指。

第二,构建统一的NFVI资源池体系。服务于全网的云化(虽然不同的网元对NFVI有差异化的需求,但并不影响NFVI的跨专业统一规划、建设与运维,只是从资源的具体部署方面必然存在不同专业网络一定的资源“隔离性”,例如部署在不同层次的DC)。NFVI是当前运营商认为的可以实现成本降低的主要希望,但实际上除了集约化带来的电力成本降低以及机房空间节省外,从基础设施角度看是否降低成本难以评估(传统网络设备难以严格区分硬件和软件的成本),需要综合考虑服务器/存储/网络新建成本,以及NFV软件、HA、灾备、机房改造等总体成本,软件将占据很重要的成本,对于运营商来说软件如果不是自主研发,就只有依靠通用化、规模化甚至标准化才有可能降低成本。

第三,引入新型的管理体系。实现对VNF、VR(虚拟资源)以及PR(物理资源)的监控、配置、管理以及更高层次的网络服务编排等,这部分目前是由NFV架构中的MANO来完成,在ETSI定义的MANO架构中,MANO由NFVO(NFV Orchestration)、VNFM(VNF Manager)以及VIM(Virtual Infrastructure Management)组成,分别完成网络服务编排与管理,VNF管理以及NFVI资源管理等功能。

在以上所述三个方面中,NFVI、VNF、MANO是NFV架构中的关键组成,以软件实现为主,从利于快速部署、规模化、成本最低化、业务连续性和迭代创新能力等方面考虑,运营商是采用商业产品还是选择自主研发目前存在一定的矛盾。

自主研发的好处是可以基于自身的需求进行快速定制化开发和实现迭代式优化与演进发展,而不是受制于厂商,不需要进行复杂的解耦、兼容性测试和集成,而且长远看能够实现成本的持续降低,有利于自身的可持续创新和发展,借助NFV/SDN发展机遇实现真正的转型。但传统运营商并没有软件研发的基因,从机制、文化、流程、组织架构等方面难以较短时间内培育打造一支有竞争力的软件研发和运营团队,以支持运营商网络软件化的发展需要,难以实现全面的网络软件自主研发;而采用商业化软件带来的好处是可以实现快速规模化部署,成熟度和可靠性高,但成本也会较高,而且依赖厂商带来的周期性更新,难以实现快速定制与迭代式发展,目前看厂商的网络软件仍然是高度封闭的,与传统网络设备发展模式几乎没有差异,运营商仍然受制于设备商和第三方软件商,长期发展能力和空间有限。

运营商自主研发实力尚薄

目前,对国内的运营商而言,还不具备条件全面采用自主研发的软件,需要基于需求、定位、资源以及自身能力,有的放矢地选择部分核心和关键组件,采用自主研发模式或者深度合作研发模式推进NFV的发展。笔者认为应该从以下三大系统软件入手。

第一,NFVI。打造一个统一的面向NFV的规模化云资源池体系,是运营商网络云化的基础和关键,因此,NFVI是较长时间内运营商工作与投资的重点,其中NFVI软件又是重中之重,目前主要以虚拟化软件(Hypervisor)为主,未来还包括容器技术、分布式软件技术等软件定义技术。

Hypervisor自主研发的好处是未来可以全网统一Hypervisor,有利于全网资源的统一共享与调度,更利于减少兼容问题和降低集成复杂度,对于像运营商来说,NFVI必然是规模庞大的,简单评估一下就会知道自主研发长远看是否降低成本。目前大部分厂商都是基于开源KVM进行商业化定制和优化,特别是针对NFV转发性能要求高的特点,各个厂商都做了针对性的优化,这部分工作仍然难度相当大,尤其是规模化应用难度大,需要投入的资源和时间较多。

运营商技术基础和人才积累不足,目前完全采用自主研发Hypervisor并不现实(至少要投入100人左右,而且需要经过长时间的大规模验证)。但是采用第三方Hypervisor也面临巨大的挑战,各个厂商的Hypervisor与各自的VIM甚至VNF存在耦合与捆绑,形成各自的“小王国”,不同厂商Hypervisor难以互通,需要大量的规范、测试和后期的部署集成工作,而且也很难针对运营商的个性需求进行定制开发。对于Hypervisor,自主研发的窗口期已经过去,运营商一方面当前应采取减少现网Hypervisor的型号和版本的策略(同一资源池节点建议只采用一种Hypervisor,全网建议不要超过2种Hypervisor),另一方面可在新技术(例如容器技术)方面进行储备,并且逐步引入自主研发软件。

第二,VNFs。各类网元原来都是软硬件一体化的,运营商对网元的内部实现机制并不熟悉,也没有真正去探究网元设备软件系统该如何实现,大部分网元功能软件目前对于运营商来说还没有可能采取自主研发来实现,但对于运营商而言,NFV也不能停留于仅仅实现基础设施的统一和共享,VNFs是运营商必然要去逐步攻克的,否则实现软件化只是表面的工夫。这部分需要运营商逐步去积累和投入,至少要具备能力去推动VNF软件的开放和架构重构,了解VNF软件的实现细节,推动VNF微服务化,为将来实现分布式和容器化部署打下基础,在能力具备后,应深度介入甚至自主研发部分VNF软件(例如NAT、FW、CDN、DPI等)。

第三,MANO。如前所述,MANO是由NFVO、VNFM和VIM组成的,当前VNFM与VNF是强关系的(VNF并不开放,VNF开放后可实现通用VNFM)、VIM与hypervisor也是强关系的(当前可基于厂商VIM或Hypervisor开放的接口实现通用VIM功能),目前大部分运营商选择与OSS关系紧密、与网络业务关系较大的NFVO进行自主研发。

NFVO的复杂度决定于VNFM是通过NFVO还是直接与VIM交互,同时也决定于NFVO的功能定位,仅仅是实现基于VNFM和VIM的聚合呈现与管理,还是端到端的业务编排,包括对VNFM、VIM以及SDN控制器的全面掌控,实现VNF/VNFC(VNF的组件)、资源(软件、模板、虚拟化资源以及硬件)和网络连接的统一管理和编排。长远来说,运营商应完全掌控MANO管理体系(涉及到VNFM和VIM的统一),近期以NFVO自主研发为主(适配不同厂商的VNFM和VIM)。当然即使是NFVO,对于运营商来说完全采用自主研发系统近期也还无法做到,自主研发的NFVO需要经过现网的考验,功能不断迭代完善,探索运营维护机制,初期很可能采用商业化NFVO和自主研发NFVO并存的方案。

对于运营商而言,NFV整体可靠性、故障检测与自愈,以及可扩展性等运营能力十分重要,这是运营商的核心掌控点,应是重点研究和自主研发的对象。运营商也可以探索与相关厂商与提供商进行深度联合研发,建立相应的研究、开发、运营的联动机制,同时探索相应的规划、建设、采购新模式。

作者:中国电信北京研究院网络规划中心主任 | 饶少阳


以上就是本文的全部内容,希望本文的内容对大家的学习或者工作能带来一定的帮助,也希望大家多多支持 码农网

查看所有标签

猜你喜欢:

本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们

JavaScript基础教程

JavaScript基础教程

Tom Negrino、Dori Smith / 陈剑瓯 / 人民邮电出版社 / 2007-9 / 45.00元

《JavaScript基础教程》(第6版)循序渐进地讲述了JavaScript 及相关的CSS、DOM与Ajax 等技术。书中从JavaScript 语言基础开始,分别讨论了图像、框架、浏览器窗口、表单、正则表达式、用户事件和cookie,还有两章讲述了Ajax 基础。《JavaScript基础教程》(第6版)不仅有对于基础知识和使用方法的介绍,也包含了对JavaScript 应用示例的深入探讨。一起来看看 《JavaScript基础教程》 这本书的介绍吧!

HTML 压缩/解压工具
HTML 压缩/解压工具

在线压缩/解压 HTML 代码

Base64 编码/解码
Base64 编码/解码

Base64 编码/解码

HEX CMYK 转换工具
HEX CMYK 转换工具

HEX CMYK 互转工具