王峰,赵慧玲
(中国电信股份有限公司北京研究院,北京 102209)
NFV开源技术
王峰,赵慧玲
(中国电信股份有限公司北京研究院,北京 102209)
NFV是运营商网络重构的核心组成部分,开源则是加速NFV发展的重要动力。如何利用开源技术推动NFV在电信网络的应用,是运营商在当前面临的重大课题。以国际标准化组织ETSI提出的NFV参考框架为参考,全面梳理了NFV开源技术体系,重点对NFVI、VNF、MANO等领域的主流开源项目的工作背景、技术路线、发展方向进行了深入剖析,并结合运营商实际情况指出了相关开源技术在现网引入时面临的技术瓶颈、解耦障碍和运营难题,提出了相应的工作建议。
网络功能虚拟化;开源;解耦架构;网络重构
NFV(network function virtualization,网络功能虚拟化)是当前网络领域的热点,其目标是利用虚拟化技术和标准化的通用IT设备实现网络功能。开源能够进一步推动网络的开放性,促进电信网络中私有、专用和封闭的网元的替换。因此,开源NFV是运营商网络重构的利器[1]。
NFV 的理念源自 ETSI(European Telecommunications Standards Institute,欧洲电信标准化协会)于2012年11月发起的NFV ISG(Industry Specification Group,行业规范组),其主要目标是定义NFV架构,并与业界主流标准化组织和开源社区互动促进标准生成,推动设备厂商验证并提供应用参考[2]。当前,ETSI NFV ISG已经制订了NFV参考框架,如图1所示,完成了NFV的需求、架构和应用场景分析,正在引导可支持互操作的NFV生态建设,明确NFV与SDN(software defined networking,软件定义网络)等领域的相关标准、开源项目的协作关系[3]。
为了加速 NFV 技术标准从概念验证向商用化部署,主流运营商、设备商与 Linux基金会在2014年9月联合发起OPNFV(open platform for NFV,NFV开放平台)项目,旨在利用开源社区力量开发和集成符合NFV需求和架构的开源参考平台。OPNFV以整合已有和新增的开源组件为基础,开展相关组件的性能、一致性和互操作性的验证,达到构建完善的NFV事实标准的目标。遵循这一愿景,OPNFV开源平台中,已经包含有KVM、Ceph、OpenDaylight、OpenStack、Open vSwitch(OVS)等众多开源项目[3]。
实践证明,在NFV的研发应用过程中,开源能够有效地推进硬件设备、虚拟化环境、网元应用乃至运营系统的全面解耦,这也是运营商引入NFV的重要工作目标。ETSI NFV参考框架示意如图1所示,综合考虑标准化组织和开源社区中NFV系统互操作方面的工作进展,NFV解耦首先将从虚拟化基础设施与硬件厂商设备的解耦以及NFVO(NFV orchestrator,NFV编排器)、各网元EMS(element management system,网元管理系统)与运营商的上层网管/支撑系统对接集成开始,然后实现直接模式下全局 NFVO和 VNFM(virtual network function manager,虚拟网络功能管理器)、VIM(virtualized infrastructure manager,虚拟化基础设施管理器)的解耦,最后是最具难度的VNF(virtualized network function,虚拟网元功能)和NFVI(NFV infrastructure,网络功能虚拟化基础设施)的解耦。在上述3个阶段中,开源软件都能够在标准编制、接口定义、原型验证乃至现网系统实现等方面提供全方位支持。
图1 ETSI NFV参考框架示意
综上所述,开源是NFV发展的重要动力。本文将对 NFV开源技术进行全面的研究和分析,阐述NFVI、VNF以及MANO(management and orchestration,管理与编排)的开源技术体系,并对主流开源项目的工作背景、技术路线开展深入的对比,并提出NFV开源技术在当前面临的主要问题。
NFVI是虚拟网元部署和运行的基础,其核心在于利用标准化的虚拟化手段支持多租户,从而能够为不同类型虚拟网元的同时运行按需提供资源支持。针对不同网元在功能、性能等方面的要求,用于承载VNF的NFVI可以有多种实现类型,如图2所示。
图2 典型的NFVI实现方式示意
图2中所示的基于NFVI的网元部署方案各有特点,其优点和不足的对比分析见表1[4]。
表1 典型NFVI实现方式的优缺点
NFVI开源技术需要灵活满足虚拟网元功能对计算、存储、网络等资源的需求。其中,在计算方面,需要考虑如何选择合适的x86架构虚拟化技术(如KVM、Xen、Docker等)用于网元承载;在存储方面,因为电信网络大部分网元功能具有无需向磁盘写数据等特性,所以可直接利用云计算领域的成熟开源项目(如Ceph);在网络方面,则需要关注虚拟网元功能(如OVS)及其I/O性能提升技术(如DPDK、VPP等)。
2.1 NFVI开源技术
基于虚拟化环境的软件网元部署是NFV的核心理念之一。当前,在虚拟化层面,KVM和Xen是主流的x86架构硬件虚拟化技术,它们普遍利用了底层硬件处理器对虚拟化技术的支持(如Intel VT、AMD-V),以有效提升虚拟化资源的处理性能。两者的架构如图3所示。
图3 KVM和Xen虚拟化架构示意
图3(a)中KVM作为Linux的内核模块,通过QEMU(面向完整x86系统的开源仿真器,具有高性能、跨平台等特性)为每台虚拟机提供模拟的磁盘、网络等设备,提供高性能的 I/O支持;图3(b)中Xen则只有域0具有访问硬件I/O设备的特权,它负责接收来自各个域 U(即虚拟机)中的设备前端驱动程序发来的 I/O请求,进而通过其具备的设备后端驱动程序驱动设备完成请求。
在此前的IT云中,Xen在性能、稳定性和成熟度等方面更具优势,从而具有广泛的应用(如AWS、阿里云都采用基于Xen的虚拟化技术)。但是,在新兴的NFV场景中,网元应用具有的高网络I/O压力使得Xen架构中的域0容易成为瓶颈,这使得KVM成为开源NFVI的首选[5,6]。
容器作为轻量级虚拟化方案,正在IT基础设施平台领域获得推广。其中,Docker是当前最为知名的容器引擎,同时Rocket、runC等开源项目也正在快速成长中。多个容器可直接在共享的宿主Linux上分别加载和运行应用程序,并利用cgroup、namespace等Linux内部机制实现不同容器间的隔离、权限管理和资源额度分配。作为操作系统层的虚拟化,容器不像虚拟机一样需要虚拟出完整的硬件平台并运行独立的操作系统,具有部署快捷、扩展性强、整合密度高等特点。
利用容器承载VNF是当前NFV领域的研究热点。与基于硬件的虚拟化技术侧重在资源层面实现物理向虚拟的转换不同,容器更强调的是软件组件的细粒度和松耦合。利用微服务(micro service)理念改造软件网元,进而通过容器承载微服务是容器在NFV领域引入的关键,这也为网元的研发、部署、管理提出了新的挑战。另外,在高带宽、低时延的网络流量压力下,基于容器部署的微服务间通信在同步性、时效性等方面的能力有待进一步验证。同时,容器技术自身也还存在不足(如Docker的向后兼容问题),更加剧了在当前利用容器平台承载虚拟网元功能的风险。
2.2 VNF开源技术
NFV实现了网元设备的软硬件解耦及网元功能的抽象,降低了传统网络设备制造领域的门槛。开源的VNF已经由来已久,但此前主要在数据中心网络被广泛部署应用,如:以 LVS、Nginx为代表的虚拟负载均衡,以iptables为代表的虚拟防火墙,以OVS为代表的虚拟交换机。当前,开源领域也出现了面向电信网络的开源VNF技术,例如OpenEPC、OpenIMS等,它们以纯软件的方式实现电信网络的网元功能,使之更适合于在虚拟化基础设施上运行。
在VNF的设计与实现中,x86架构及其虚拟化技术能否为虚拟网元功能提供足够的性能支持是亟待解决的问题,开源的 DPDK(data planedevelopment kit,数据平面开发套件)是针对这一问题的主流解决方案。DPDK是x86架构平台上用于报文快速处理的库和驱动的集合,其核心思想是支持运行在 Linux用户态空间的应用程序能够直接驱动物理网络设备而无需陷入操作系统的核心态,从而有效提升性能。当前,很多软件都在借助DPDK改善网络数据处理效能,如FD.io开源项目。FD.io的目标是提供模块化、可扩展的用户空间的 I/O服务框架,能支持高吞吐量、低时延、高资源利用率的I/O服务。它贡献的VPP(vector packet processing)是利用了DPDK技术的可供商用的vSwitch/vRouter方案,与同类开源技术相比拥有数量级上的性能优势。
与DPDK专注于提升运行在Linux用户态的虚拟网元功能的I/O性能不同,I/O Visor开源项目的思路是在Linux内核中拓展I/O虚拟化能力,从而提供可扩展的网络系统基础。使用I/O Visor,Linux内核中可以运行多个VNF乃至完整的服务链(service chain),系统在处理网络流量时也无需进行内核模块的加载,能够确保基础设施更新升级时不会中断网络操作。同时,I/O Visor支持在操作系统内核态直接处理网络I/O,也避免了传统的需要经由系统调用进入用户态的做法,有效地提升了VNF性能。
NFV MANO涵盖了支持基础设施虚拟化的软硬件资源的编排和生命周期管理以及VNF的生命周期管理。如图1所示,MANO主要包括3个模块:NFVO负责网络服务生命周期管理和总体资源管理等功能;VNFM负责监控VNF实例的整个生命周期(包括配置、扩展和终结等);VIM负责管理和控制 NFVI中的计算、存储和网络资源。其中,VNFM和具体的VNF有密切的关系,在当前还缺少完善的开源解决方案,而VIM则相对成熟。
3.1 MANO开源技术概述
对于运营商而言,网络资源的运维和调度是其核心竞争力,特别是NFV能够更便捷地支持网络服务的规模伸缩和质量优化,因此MANO吸引了众多运营商的目光,有很多运营商主导的开源MANO项目被提出,例如:Telefonica发起的OpenMANO、中国移动发起的Open-O、AT&T发起的 ECOMP(enhanced control, orchestration, management & policy,增强控制、编排、管理和策略)等。同时,标准化组织和开源社区也在MANO领域做出很多工作,例如:ETSI OSM(open source MANO)、OpenStack Tacker等。另外,还有一些企业在MANO功能模块方面做出了贡献,例如Gigaspace推出的编排器Cloudify、Canonical推出的VNF管理器Juju等[7]。
在经历了开源项目爆发期之后,MANO在当前正走向项目整合的方向。将多个相关领域的小型开源项目汇集整合到大型项目中,有利于产业的聚焦,避免重复研发,扩大社区影响力。例如,ETSI OSM 在其发布的首个版本中,就利用了OpenMANO实现资源编排,利用Juju实现VNF配置和管理,同时它还引入了ETSI NFV范围之外的开源服务编排组件RIFT.ware。2017年2月,同属于 Linux基金会的两大开源组织 Open-O和ECOMP合并成为ONAP(open network automation platform,开放网络自动化平台)项目。同为运营商主导的MANO项目,Open-O和ECOMP在架构设计、功能实现等方面存在共性,并且都具有良好的发展势头,其中,Open-O拥有众多运营商支持并成为OPNFV上游项目,ECOMP则已经在AT&T实现现网的规模部署。两个项目合并成立ONAP意味着 NFV已经度过初始的技术验证阶段,即将走向规模部署、规模商用的阶段。
NFV MANO开源项目当前不够成熟,但在ETSI发布的标准架构的指引下,该领域的开源项目都具有较为清晰的定位。不同背景的开源项目会有不同的发展路径,其中:标准化组织主导开源工作的原则之一是项目要服务于标准的制定,通过开源代码验证标准的合理性和可行性,并为文档工作的完善提供依据[8];运营商主导的项目则以满足电信网络重构的现实需求为目标,会在标准化架构的基础上结合自身需求进行能力的增减,并通过社区凝聚产业生态,加速落地;设备厂商发起的项目,更主要的是发挥自身在相关领域的特长,为前两类开源社区的能力完善和资源整合提供支持。为了确保自身利益,运营商主导的开源项目会设定一些规则,例如ONAP在号召运营商加入的同时对设备厂商董事成员名额进行了限制,这也是其与另两类开源项目不同的地方。
3.2 VIM开源技术
VIM是NFV MANO中相对成熟的模块,利用云计算和SDN的理念是当前实现VIM的主流思路。开源领域的 OpenStack云管理平台和以OpenDaylight、ONOS为代表的SDN控制器的融合构建成为了VIM领域广为使用的方案。
VIM 作为底层虚拟化基础设施的管理平台,需要负责计算、存储、网络资源池的统一管理和协同调度。OpenStack作为当前最具影响力的开源云管理平台项目,可实现在单一管理平台上对多个数据中心的管理,并具备通用的安全、身份识别服务、API 及用户界面。OpenStack的Nova、Cinder、Neutron等组件在云计算资源池的计算、存储、网络等领域的资源管理方面吸引了众多合作伙伴,实现了对云基础设施资源的全面管理。因此,OpenStack被众多 NFV项目用作虚拟化基础设施的管理组件,例如OPNFV。同时,OpenStack在VIM模块上的成功推动了其向 NFV MANO的全栈拓展。Tacker是 OpenStack社区中遵循 ETSI MANO架构实现NFVO和VNFM的组件服务,在端到端VNF平台模板交付、VNF服务目录、NFV生命周期管理等方面做出突出工作。
VNF部署的动态性、扩展性对网络连接提出了更高的要求,SDN则能够很好地支持NFV在电信网络的引入。控制器作为SDN的核心也是开源领域的重点,其中最具影响力的是 OpenDaylight和 ONOS。经过多年的发展,两个开源项目相互借鉴相互影响,在整体架构和技术路线上正日益趋同,例如采用 Karaf架构提升扩展性、北向采用模型驱动、南向支持多种协议等。类似此前MANO开源项目分析,OpenDaylight和ONOS分别是设备厂商和运营商主导。因此,OpenDaylight更符合厂商利益,并更适于和现网的平滑过渡;ONOS则更多体现了运营商的意志,贴合电信网络重构需求。
NFVI的发展趋势之一是容器的应用,因此容器集群的管理也是当前VIM领域的热点,主流开源项目包括Kubernetes、Mesos、Swarm、Rancher等。其中,源自Google的Kubernetes在当前最受关注,其在服务发现与容错调度等方面有较大优势;Mesos的调度机制分为资源委派和调度框架两个层次,更适用于复杂分布式应用的部署;Swarm是主流容器技术Docker的原生功能,在使用维护上较为简洁;Rancher作为后起之秀,则具备了对上述3家容器集群管理引擎的支持。如上文所述,容器的关键并非只是虚拟化资源交付方式的简单改变,更重要的是它能够更好地支持以微服务的粒度对VNF进行灵活的编排。相应的,容器的集群管理和资源调度解决的将不仅是VIM层面的问题,而且可以扩展到NFVO、VNFM等多个层面。随着基于容器的NFV技术的发展,以Kubernetes为代表的容器集群管理项目也将成为NFV MANO的重要选择。
对于运营商而言,开源是一把双刃剑:一方面,它能够充分借助社区的力量,帮助运营商脱离设备厂商的锁定,使得整个网络系统更加灵活;另一方面,在开源社区中,运营商、设备厂商有着不同的诉求,对运营商的掌控力提出新的挑战。另外,开源项目依托相对松散的社区提供代码维护和支持,在软件质量、版本兼容、代码冗余等方面存在不确定性,为其在现网的引入增加了障碍。结合开源项目的发展现状,运营商在运用开源NFV时需特别关注以下方面。
(1)技术瓶颈
开源NFV在性能、可靠性等方面存在瓶颈,这主要是因为作为其基础的x86架构及其虚拟化技术此前重点面向的是计算密集型应用而并非类似网元功能的 I/O密集型应用,虽然其网络处理能力在DPDK、SR-IOV等软硬件技术辅助下已有较大幅度提升,但是仍难以满足高性能转发的需求。同时,电信网络网元所需的高可靠性保障在此前需要依赖于专用硬件的特别设计,而在NFV场景下凭借通用IT设备和软件高可用设计来实现相关目标还需要更多的工作。
(2)解耦障碍
解耦是运营商部署NFV的重要目标,但在当前存在巨大障碍。主要原因来自两个方面:一个方面是设备商为了解决上述 NFV开源技术的瓶颈,必然会在NFV架构的软硬件堆栈开展优化,以建立技术壁垒;另一个方面是NFV除了在纵向上具有基础设施、虚拟网络和运营支撑等层次外,横向上还有横向的管理编排域,众多接口和协议标准分散在不同的标准化组织中,从而影响了兼容性和互操作性的实现。运营商的需求引领将是解决这一问题的关键,通过开源项目打造确保互联互通的事实标准是实现NFV架构在各个层次上充分解耦的重要手段。
(3)运营难题
虽然运营商已经在NFV开源项目中发挥了一定的主导作用,但是总体而言,运营商在软件设计开发、开源社区运营等方面尚不具有足够的实力,其中最典型的难题之一就是如何针对自身需求开展开源组件选型进而整合为业务系统。为此,SDN和NFV领域的重要标准化组织ONF(Open Networking Foundation,开放网络基金会)提出了开放式创新渠道(open innovation pipeline),目标是在开放平台上提供大量可应用框架,为运营商提供多种多样的解决方案,降低运营商进入软件开发领域的成本和障碍。另外,开源的引入绝不意味着运营商不再需要设备商的支持,围绕开源技术的集成服务和技术支撑将促使运营商和设备商此前建立的简单买卖关系转型为更深入的研发运营合作关系。
开源驱动的以软件为中心的架构正在加速网络的变革,以使得运营商能够应对市场竞争的持续加剧、用户需求的不断变化以及自身业务增收的巨大压力,NFV则是这一变革的重要组成部分。开源项目的涌现促进了NFV领域完备软件化体系的形成,有力地推动了NFV的标准制定、系统研发及落地实践。
NFV以及SDN、云计算构成了当前运营商网络重构的核心要素,它们的核心理念都是 CT产业与IT产业的能力融合。而开源作为IT产业迅猛发展的重要推手,也势必会在 CT产业发挥重大作用。运营商应牢牢把握这一趋势,借助开源的力量,掌控核心技术,建立事实标准,加快业务创新,降低运营成本,进而打造开源生态,引领产业发展。
[1] 中国电信集团公司. CTNet 2025网络架构白皮书 [R/OL]. (2016−07−11)[2017−01−15]. http://www.chinatelecom.com. cn/news/06/bps/. China Telecom. CTNet 2025 network architecture white paper [R/OL]. (2016−07−11)[2017−01−15]. http://www.chinatelecom. com.cn/news/06/bps/.
[2] European Telecommunications Standards Institute. Network functions virtualisation: network operator perspectives on in-dustry progress [R/OL]. (2014−10−17)[2017−01−15]. https:// portal.etsi.org/Portals/0/TBpages/NFV/Docs/NFV_White_Paper3.pdf.
[3] 马军锋. SDN/NFV关键技术问题分析和标准化进展[J]. 中兴通讯技术, 2016, 22(6): 12-16. MA J F. Key technical problems and standardization progress of SDN/NFV [J]. ZTE Technology Journal, 2016, 22(6): 12-16.
[4] 赵慧玲. SDN/NFV的发展与挑战[C/OL]//2016全球SDNFV技术大会, 2016年6月1日, 北京. [2016−06−01]. http://net. zhiding.cn/ network_security_zone/2016/0601/3078383.shtml. ZHAO H L. Developments and challenges of SDN/NFV [C/OL]//Global SDNFV Technology Conference 2016, June 1, 2016, Beijing, China. [2016−06−01]. http://net.zhiding.cn/network_ security_zone/2016/ 0601/3078383.shtml.
[5] Wind River. Open solutions for NFV [R/OL]. (2015−11−01) [2017−01−16]. http://www.windriver.com.cn/products/titaniumserver/2415-Open-Checklist.pdf.
[6] Red Hat. Network functions virtualization with Red Hat [R/OL]. (2015−09−03)[2017−01−16].https://www.redhat.com/en/files/ resources/en-rhel- nfv-value-inc0285929_v1_0815_kvm.pdf.
[7] IEEE. IEEE softwarization eNewsletter – July 2016 [R/OL]. (2016−07−13)[2017−01−16]. http://resourcecenter.fd.ieee.org/ fd/product/enewsletters/FDSDNNL0005.
[8] Open Source MANO. A conversation with the OSM Leadership Group [EB/OL]. (2016−10−01)[2017−01−16]. https://osm.etsi. org/news-events/news/a-conversation-with-the-osm-leadership-group.
王峰(1979−),男,中国电信股份有限公司北京研究院教授级高级工程师,主要研究方向为云计算、软件定义网络。
赵慧玲,女,长期从事电信网络领域技术和标准工作。现任中国通信学会常务理事;中国通信学会信息通信网络技术专业委员会主任委员;中国通信学会北京通信学会副理事长;中国通信标准协会网络与业务能力技术工作委员会主席;工业和信息化部科学技术委员会委员;中国电信科学技术委员会常务委员兼核心网组负责人;国际标准组织MEF顾问董事;SDN、NFV产业联盟技术委员会副主任。发表技术文章百余篇、技术专著12部,曾获得多个国家及省部级科学技术进步奖项。
Open source technology of NFV
WANG Feng, ZHAO Huiling
Beijing Research Institute of China Telecom Co., Ltd., Beijing 102209, China
NFV is a core component of the operator network reconstitution, and open source is an important driving force to accelerate the development of NFV. How to use open source technology to promote the application of NFV in telecom network is a major issue faced by operators. NFV open source technology system was surveyed comprehensively according to the NFV reference framework proposed by ETSI, and the background, core technology and development trend of mainstream open source projects of NFVI, VNF and MANO was analyzed. Finally, some critical problems (such as technical bottlenecks, decoupling obstacles and operational difficulties) and corresponding solutions were presented to help operators to make better use of open source technology of NFV.
network function virtualization, open source, decoupling architecture, network reconstitution
TP393
A
10.11959/j.issn.1000−0801.2017105
2017−02−20;
2017−04−04
国家高技术研究发展计划(“863”计划)基金资助项目(No.2015AA016106)
Foundation Item:The National High Technology Research and Development Program of China (863 Program)(No.2015AA016106)