基于开源技术的NFV平台架构研究

徐 雷 张云勇 熊 微

引言

在移动互联网时代，运营商面临内外夹击的困局。就自身而言，传统的流量增长—网络扩容—收入增长的商业模型正在逐渐失效，庞大、僵化的电信基础网络已不能很好地满足用户日益丰富和变化的需求；就竞争对手而言，互联网企业的业务快速迭代，能够很好地契合用户不断变化的需求，同时，OTT服务商不断推陈出新的各类移动互联网业务也强烈冲击着运营商传统业务市场，使得运营商相关服务收入停滞甚至下降，并且在网络中越来越趋向于管道工的角色[1]。目前，全球运营商普遍面临增收放缓、利润下降的困境。电信行业资讯公司OVUM在其发布的行业报告中指出，预计到2016年OTT社交通信应用将使电信运营商短信收入减少540亿美元；预计到2018年，OTT网络电话将使全球电信行业的收入减少630亿美元。面对如此困局，运营商正在积极探索解决之道，一方面希望能够打破专有硬件设备的垄断，构建基于标准硬件的通用平台；另一方面希望能够快速灵活地进行业务迭代，满足用户差异化需求，提升与互联网企业开展有效竞争的能力。

随着云计算概念的普及和X86服务器性能的提高，网络功能虚拟化技术(Network Function Virtualization，NFV)顺应电信IT化的趋势，作为一项新的网络技术进入了大众视野。将NFV技术应用到电信网络中，能够大幅提升网络的灵活性，有利于新业务的开发和部署，实现业务的灵活配置，提升网络的管理和维护效率[2]。对运营商而言，NFV是一次改变困局、实现跨越发展的难得机遇，在降低CAPEX和OPEX成本及整体TCO的同时，还能加速新产品推出和业务创新。

NFV和SDN作为下一代网络的革新技术已成为业界共识，从2012年NFV概念提出至今，NFV在标准化、部署应用和行业影响力上快速发展。标准组织积极地开展相关标准的制定，国内外运营商也纷纷试水NFV，推动并促进厂商进行NFV设备和SDN网络的广泛部署，使其市场规模不断扩大，全新的生态环境和产业链正逐渐形成。随着NFV进入快速发展期，运营商的管理研发体系及其与设备商的关系也将发生改变，CT和IT融合将更加深入。

1 NFV架构特点

在当前网络部署的各种设备中，各类网元被封装在独立的盒子内且网元间的硬件资源无法互用。为了适应新的业务需求，增加网络服务能力，通常采用增加硬件的方式为设备扩容，而缩容后硬件资源闲置，这种方式不仅耗时长、弹性差并且成本较高；在NFV技术体系下，通过硬件最小化来减少依赖硬件，其实质是将网络功能从专用硬件设备中剥离出来，实现软件和硬件解耦后的各自独立。各种网元被虚拟化成独立的功能应用，可以被灵活部署在基于标准的服务器、存储和交换机构建的平台上，使得软硬件解耦，各类网元功能应用可通过快速增加/减少虚拟资源实现快速扩容/缩容的目的，从而有效提升网络的弹性和灵活性。

NFV的技术基础主要是云计算和虚拟化[3]，虚拟化技术能将通用的计算、存储、网络等硬件设备分解为多种虚拟资源，实现应用与硬件解耦，根据需要实现网络功能及动态灵活部署；云计算技术可以实现应用的弹性伸缩及资源和业务负荷的匹配，不但提高了资源利用率，而且保证了系统响应速度。

NFV的提出在给产业界网络架构带来新变化的同时，也提出了新的设计需求[4]。主要包括以下三个方面。

1)基础硬件平台的可编程性。为实现与业务无关的资源池化能力，计算、存储及转发设备应当在保证性能的前提下，提供可编程的逻辑内核和易于调用的应用接口。可编程硬件将逐步替代传统专用硬件，实施过程则依赖于网元结点的功能属性、性能要求、成本等多种因素的综合影响。

2)基础硬件之上将加载虚拟化和云计算平台软件。云平台软件既对计算、存储和网络设备等资源进行调度和管理，又为上层业务显现提供一个开放的运行环境；因此，这就要求云平台软件必须具备高度的开放性，不仅能支持多种硬件共存的异构网络环境而且可提供健康的生态系统。OpenStack作为当前得到广泛应用的开源云平台，围绕可靠、安全、性能、应用体验等方面的需求提供相应的功能，确保NFV架构的开放、稳定和高效。

3)NFV架构将硬件、中间件与软件实现解耦，因此，各类上层业务和功能作为软件模块能够进行灵活的集成与部署。

2 NFV相关开源技术对照分析

在传统标准化工作开展的同时，开源组织也对NFV进行积极推动。2014年9月30日，由AT&T、中国移动、戴尔、惠普等运营商和设备商与Linux基金会合作联合发起成立了NFV开放平台项目(OPNFV)的开源组织，旨在通过开源组织的力量开发符合NFV需求和架构的虚拟资源层软件，构建一个完整的NFV实现标准，并于2015年6月发布了首个版本Arno。

ETSI NFV参考架构中，MANO主要由VIM、VNFO和VNFM等组件组成。在标准研发的基础上，NFV的落地实现和一批相关开源组织紧密相联，如OPNFV、OpenStack、KVM、OpenvSwitch、ONOS、OpenDaylight等，这些都为NFV的落地提供了技术参考。以OPNFV为代表的NFV开放平台项目，旨在集中服务提供商、云计算基础设施厂商、开发者和用户，为行业定义一种运营商级的集成开源参考平台，把现有开源构件与新组件及测试整合在一起，确保多种开源组件间的一致性、性能和互通性，从而加快NFV的开发和部署。

目前，国内外越来越多的组织或企业通过开源的方式开放相关组件的功能，从而更加快速地推动NFV在功能及性能上的发展。

2.1 开源NFVI及VIM架构

开源OPNFV项目于2015年6月正式公布第一版NFV开源框架Arno，该版本聚焦ETSI NFV参考架构中的NFV基础设施(NFVI)和虚拟架构管理(VIM)，为NFV上层VNF和业务编排系统提供了一个运营商级的、集成的、开源的底层能力平台。Arno不只是第一个针对NFV推出的开放源码平台，还为开发者提供更方便开发和部署NFV的环境。

在可用性方面，Arno能够持续集成、自动化部署和测试上行项目的组件，如：Ceph、KVM、OpenDaylight、OpenStack和Open vSwitch。Arno允许开发者和用户自动安装，并在平台进行探索。在部署测试方面，Arno允许终端用户和开发者在其上部署自己的或者第三方的VNF，在多种场景和案例下进行VNF的功能和性能测试。在测试架构方面，Arno提供了一个基于社区测试的实验基础架构(Community Test Labs Infrastructure)，这个架构能够让开发人员可以在不同的NFV场景和硬件条件下测试实验平台，确保多种开源组件能同时满足供应商和终端用户的需求。

2.2 开源NFVO

西班牙电信公司Telefónica于2 0 1 5年初将自身研发的OpenMANO代码开源通过GitHub门户向开源社区正式发布。OpenMANO包含openvimd、opennanod和openmano-gui三部分及两个命令行客户端(openvim和openmano)。该平台虽然实现了符合ETSI NFV参考架构中的NFVO功能框架，但并没有实现同底层VIM的接口。

2.3 开源VNF

N F V网络功能的软硬件解耦及功能抽象的本质，降低了企业进入到通信领域的门槛。伴随着NFV相关技术的不断发展，目前，已经出现了开源的VNF，如OpenEPC(http://www.openepc.com)、OpenIMS(http://www.projectclearwater.org/)等。它们以纯软件的方式，对原有电信网元功能进行了实现，更适合云平台的承载。

图1 NFV标准架构与开源软件对照

3 基于开源技术的NFV平台框架

NFV涉及诸多领域，包括底层基础设施资源(包括计算、存储、网络)、虚拟网络功能(各类电信服务)、综合管理(资源管理、VNF管理)、业务编排和网管等，而且不同模块可有多种不同实现技术手段，各模块对开源技术的选择可能会直接影响到所搭建的NFV平台的性能，因此，搭建一套完整的NFV平台是一个较为复杂的系统工程。目前，对NFV不同模块开源实现的研究较多，但是缺少从整体视角出发利用这些分散的开源技术搭建整套NFV实验平台方面的研究。本文参考ETSI NFV整体架构，根据在NFV开源平台搭建及开源软件使用方面的实践经验，提出一个利用开源平台搭建NFV实验平台的通用架构及其技术选择方案，为今后开展相关NFV验证及测试提供支撑。

本文所提出的NFV平台通用架构是建立在ETSI NFV参考架构框架之上，它将开源软件/平台对应到NFV标准框架的各个模块中去，从而快速搭建NFV试验平台，实现网络服务的编排、部署、可靠性以及弹性扩展等端到端的业务验证及性能测试，具体如图1所示。

3.1 NFV基础设施硬件

NFV基础设施硬件部分主要为底层云平台提供计算服务器、存储服务器以及相关的网络设备。服务器的选型方面，建议采用支持硬件辅助虚拟化的同一类型的服务器，计算服务器对CPU及内存要求较高，存储服务器对磁盘IO要求较高，同时，为提高虚拟服务器的存储性能，无论是使用本地存储还是共享存储，建议增加SSD硬盘，从硬件上提供虚拟存储的性能；在网络设备选型方面，为使网络设备的转发能力不影响虚拟网络服务的正常运行，建议配置万兆交换机，同时可以选择SR-IOV网卡来提高虚拟机的网络转发性能。基于以上原则，在NFV基础设施硬件选择方面提供以下建议。

1)计算服务器。建议采用支持虚拟化功能的多核CPU，大内存，2个千兆网络、2个万兆网卡的X86服务器。

2)存储服务器。建议采用至少2个千兆网络、2个万兆网卡的X86服务器。

3)网络设备。建议采用万兆交换机。

3.2 NFV基础设施软件

NFV基础设施软件部分主要是云平台在虚拟计算、虚拟网络和虚拟存储方面使用相关的软件来提升虚拟基础设施的性能，从而满足虚拟网络服务的业务需求。在虚拟计算加速方面，增强支持在NUMA类型宿主机上的分配、支持虚拟CPU到物理CPU的绑定以及支持在虚拟机中的大页面分配等；在虚拟存储加速方面，增强共享存储支持SSD和支持多vm共享内存访问等；在虚拟网络方面，增强基于DPDK的OVS和增强支持SR-IOV等。基于以上原则，在NFV基础设施软件选择方面提供以下建议。

1)虚拟计算。建议采用KVM；如果进行虚拟计算性能测试，可以通过DPDK技术实现虚拟计算能力的增强。

2)虚拟存储。建议采用CephGiant版本；如果进行虚拟存储性能测试，可以通过SSD硬件实现虚拟存储性能的增强。

3)虚拟网络。建议采用Openvswitch2.3.0以上；如果进行虚拟网络性能测试，可以通过DPDK或SR-IOV等技术实现虚拟网络性能的增强。

图2 基于Openstack和Opendaylight的VIM融合方案

3.3 VIM

VIM作为底层虚拟基础设施的管理平台，不仅要完成对虚拟网络、虚拟计算、虚拟存储的统一管理，同时对上层的网络功能编排及管理系统提供底层虚拟基础设施的能力抽象。采用云计算和SDN技术来实现VIM的搭建是目前较为公认的方法，而使用开源项目Openstack和OpenDaylight的融合构建方案已然成功业界首推的技术方案。Openstack完成底层虚拟资源的统一管理与调度，而OpenDaylight控制器以插件的方式集成到Openstack中完成对虚拟网络的灵活管理。基于以上原则，在VIM选择方面建议采用OpenStackJuno+OpenDaylightHelium版本。

图2描述的就是基于Openstack和Opendaylight的VIM融合方案的整体架构。

Openstack Neutron包含ML2机制驱动，该机制驱动(ODL)作为REST代理能够调用所有的Neutron API。ODL包含北向REST服务(Neutron API服务)，能够调用这些代理API缓存数据并可用于ODL的其他服务。

OpenDaylight与Neutron进行通信是采用Neutron网络节点上的ML2插件，并使用经由北向通信的REST API。例如OpenStack用户执行任何网络相关操作(创建/更新/删除/读取网络网络、子网和端口等资源)，典型流程将如下所示。

1)OpenStack仪表板(Horizon)上的用户操作将被转换成相应的网络API，并发送到Neutron服务器；

2)Neutron服务器收到请求后，将同一请求传递给已配置的插件(假设ML2已配置好了ODL机制驱动和VXLAN类型驱动)；

3)Neutron服务器/插件会对数据库做适应的变动；

4)插件会调用与SDN控制器对应的REST API；

5)当收到请求，ODL会使用任何南向插件/协议，比如OpenFlow、OVSDB或OF-Config，对网络元素做必要的变化。

需要注意的是，SDN控制器和OpenStack方面存在不同的集成选项。比如说，可以完全消除Neutron服务器与计算节点上的代理之间的RPC通信，SDN控制器作为管理网络的唯一实体；或者SDN控制器只由物理交换机管理，虚拟交换机可以从Neutron服务器直接管理。

图3 vEPC和vIMS部署示例

3.4 VNF(s)

建议每个VNF以Openstack平台镜像的形式提供，每创建一个VNF实例即在Openstack云平台中创建一个其镜像对应的虚拟机实例。每一个VNF提供商需要提供与VNF相对应的VNFM，VNFM的南向接口需要同Openstack集成，而北向接口需要符合VNFO的接口规范要求。

3.5 VNFO

不同的运营商可以根据自身的情况定制网络服务的编排流程，对应VNFO在网络服务模板以及虚拟网络功能模板的定义会存在一定的差异，因此，VNFO需根据实际情况定制化开发，但其调用VIM的接口需要符合Openstack接口。

一个网络服务(NS)的实现需要一个或一组虚拟化网络功能(VNFs)，以及一组相关联的NFV基础设施(NFVI)共同组成来实现。针对IMS的服务功能就需要多个VNF(包括ELLIS、HSS、PSCSF、ISSCSF以及XDMS)构成，以及虚拟资源支撑。以本文中涉及到的vEPC和vIMS为例，具体网络服务如图3所示。

4 结束语

本文提供了一个NFV平台通用架构，它主要建立在ETSI NFV参考架构框架之上，利用相关开源平台快速搭建NFV试验平台，从而实现网络服务的编排、部署、可靠性以及弹性扩展等端到端的业务验证及性能测试，为运营商开展NFV实践提供了参考。

参考文献

[1]许阳,高功应,王磊.移动互联网时代后向OTT合作业务及移动网络架构演进[J].邮电设计技术,2015,(8):32-35

[2] 薛淼,符刚,朱斌,等.基于SDN/NFV的核心网演进关键技术研究[J].邮电设计技术,2014,(3):16-22

[3]ETSI ISG NFV.Network Function Virtualisation White Paper[S].2013

[4]ETSI ISG NFV.Network Functions Virtualisation(NFV)：Architectural Framework[S].2013