吴丽华，沈蕾



NFV资源池规划与部署方案

吴丽华，沈蕾

（中国移动通信集团设计院有限公司，北京 100080）

网络功能虚拟化（NFV）是传统电信网络演进的方向，未来电信网络架构将以DC和资源池为核心。运营商经过广泛的NFV试点即将进入商用部署阶段，对于NFV资源池的网络架构、组网规划、资源划分等方面进行深入分析，探讨了NFV资源池规划方案，对资源池的建设提供了参考和建议。

NFV资源池；电信云；网络架构；资源池规划

1 引言

电信运营商的网络面临着硬件类别五花八门、资源分散、网络建设成本高、运维复杂的问题，而且网络上线和更新慢，无法满足业务快速上线、迭代的需求。为应对移动互联网时代业务的快速变化，运营商需要打破传统电信网络的封闭特性，并为推动电信设备的全面IT化，构建弹性网络。

与传统电信网络相比，网络功能虚拟化（network function virtualization，NFV）通过硬件设备通用化、网元功能软件化、平台资源虚拟化和网络管理分层化，实现了网络功能和资源的解耦，实现硬件资源共享，增强系统灵活性，提升管理和维护效率，是实现新业务快速上线、敏捷迭代、开放创新的有效手段。

NFV引入之后，网络将构建在以通用硬件为主的云基础设施之上，网络功能全部由软件定义，业务和功能的部署转化为软件的设计、编排和集成，因此NFV资源池的整体规划布局和各类资源部署至关重要，需要在满足上层业务部署需求的同时，确保电信级可靠性和安全性，提升资源利用效率。

2 NFV电信云网络架构

NFV是将传统电信设备功能通过软件实现，运行于通用硬件设备之上，并采用虚拟化技术，实现硬件资源共享，增强系统灵活性，提升管理和维护效率的目标。

ETSI标准组织提出的NFV架构，如图1所示。

NFV体系架构主要包括NFV基础设施（NFVI）、虚拟网络功能、NFV管理和编排（NFV management and orchestration）3个主要核心工作域。

（1）NFV基础设施将物理计算、存储、交换资源虚拟化成虚拟的计算、存储、交换资源池，为VNF（virtualized network function，虚拟网络功能）的部署、管理和执行提供资源池。

（2）虚拟化网络功能：包括VNF和EM （element management，网元管理）。VNF部署在NFVI上，实现软件化的电信网元功能。EM同传统网元管理功能，实现VNF的管理，如配置、告警和性能分析等功能。

图1 NFV参考架构（ETSI GS NFV 002 V1.2.1）

（3）NFV管理和编排系统，主要包括NFV编排器（NFVO）、VNF管理器（VNFM）和虚拟设施管理器（virtualised infrastructure manager，VIM）3部分。NFVO实现网络服务、VNF管理及全局资源调度，是云管理的决策者；VNFM实现虚拟网元生命周期管理，是VNF管理的执行者；VIM是虚拟化基础设施管理系统，是虚拟资源及硬件资源管理的执行者。

在NFV电信云资源池上承载基础通信相关各类网络功能，主要包括核心网、基础通信业务平台，传输网、承载网、接入网中适宜进行虚拟化的网元等，要求资源池满足电信级的可靠性和性能要求。NFV电信云资源池与现有IT云在硬件、虚拟层、管理架构、管理维护需求、可靠性等方面均不同，满足电信级要求的基础设施构建难度大，对于电信级云管平台的要求也更严格。因此NFV电信云资源池的规划方法与IT云也有较大的不同，具体见表1。

表1 NFV电信云与IT云比较

2.1 网络架构设计

现有传统通信网络的组网模式，以设备为核心，按地域分省组网分散管理。而NFV的引入将颠覆以网元设备为中心的组网方式，在基础设施层面形成以DC/资源池为中心的分层网络，所有的网络功能和业务应用都运行在云数据中心上，DC节点布局应充分考虑网络架构层级和用户接入要求分层部署。

根据网元特性和业务需求，DC需要规划2~3层。

（1）核心DC

位于大区或省中心，用于集中部署控制面网元。

（2）边缘DC

位于地市或区县，用于分布式部署用户面和转发面网元（如SGW/PGW、vBRAS-UP等），以实现流量快速卸载，优化用户体验。

图2 NFV网络架构

（3）接入AP

用于解决用户“最后一公里”接入问题，将存在专用设备、x86设备和虚拟化设备等多种设备形态。

未来考虑采用SDN技术实现DC间互联，DC节点间通过SDN统一实现广域网连接和链路调度，从而实现网络、网元和业务的管理编排调度，实现高效、分布式的网络连接，如图2所示。

表2 控制面网元集中化分析

2.2 网元虚拟化后在DC中的位置

网元虚拟化后，控制面网元具备进一步集中的条件，而媒体转发面网元需要根据时延和实时类业务需求分散部署在地市、区县。

业务平台、控制面、数据面网元与其他网元连接全部采用IP承载，且时延较不敏感，较适用于集中部署。综合考虑用户分布，结合与无线接入网的关系、与外部设备的连接需求、用户数据和业务等因素综合考虑集中程度。控制面网元集中化分析见表2。

媒体转发面网元的部署位置主要考虑时延和业务体验。时延要求高的媒体转发业务，网元分散部署在地市；时延要求极高的实时类业务或转发业务量较集中的区域，媒体转发网元可下沉至区县以下。

3 NFV资源池规划

3.1 硬件规划

资源池硬件包括计算资源、存储资源和网络资源。

• 计算资源主要为服务器，应尽量采用同一规格的硬件服务器承载多种类型VNF，以实现VNF在资源池内各服务器之间的资源调配。可以根据网元特性进行分类，通过2~3种硬件规格配置（如计算型、高转发等）满足不同网元的硬件需求。

Ÿ•存储资源包括磁盘阵列等传统存储设备以及分布式存储等。相对于磁阵来说分布式存储可采用通用服务器实现存储，不再依赖传统磁阵；最大支持容量大，IOPS（input/output operations per second，每秒进行读写操作的次数）高，扩展性强；存储节点分布化，理论可靠性高；但分布式存储运维难度较大，存在由于操作不当导致整个存储系统崩溃的可能。目前分布式存储尚不成熟，初期NFV商用可采用传统存储设备，后续演进为分布式存储。

Ÿ•网络资源包括TOR交换机、EOR交换机以及防火墙等安全设备。根据服务器和存储设备配置以及组网方案进行网络设备配置。

对硬件资源的规划有如下两种方式。

（1）方式一：基于上层VNF规划估算硬件资源需求

该方式根据拟在资源池上部署的VNF的容量、数量规划，估算VNF所需的硬件资源，并考虑虚拟层性能消耗、冗余，得出对于资源池硬件的需求。资源池的建设周期与网元的建设周期类似，如每年扩容一次。

该方式适用于VNF的业务中可预测的场景，如对基础通信类业务，一般可以通过发展趋势预测未来的容量需求。但在VNF厂商未定的情况下，由于不同厂商的同一VNF对资源需求存在差异，可能存在预测不准确的情况。

（2）方式二：完全软硬解耦规划，按资源池实际运行利用率启动扩容

该方式主要依据对资源池实时监测的利用率等指标启动资源池的扩容建设，资源池的建设周期较为灵活，可长可短。

该方式适用于VNF的业务中难以预测的场景，如互联网新业务，业务上线之后可能爆发式增长，也可能增长很小。该方式不存在由于资源池建设先于VNF选型，而造成硬件资源预测不准的问题。

电信运营商在NFV资源池上部署的大部分网元为基础通信业务相关的核心网、业务平台等网元，业务较可预测，比较适合采用方式一进行硬件资源规划。

3.2 软件规划

NFV资源池中主要涉及的软件有VIM、Hypervisor、VNF（含guest OS）。Hypervisor和VIM接口较难打开，一般由同厂商提供，统称为虚拟层软件；电信厂商一般会基于通用版本guest OS进行裁剪、优化，因此VNF与guest OS一般也由同厂商提供。

由于虚拟层与VNF之间的接口为软件集成接口，因此较难定义接口规范，初期采用软硬解耦、软件厂商一体化的方式，能够实现快速部署。但为达到扩大资源共享范围的目的，运营商会以三层解耦（VNF、Hypervisor、底层硬件之间的三层解耦）为目标进行推进。

3.3 组网规划

资源池的物理组网采用出口层、核心层、接入层的层次化组网架构。网络出口层负责网络内部路由信息和外部路由信息的转发和维护。对外完成与外网设备的高速互联，对内负责与数据中心的核心层交换设备互联。网络核心层部署核心交换机，负责接入层交换设备的汇聚，核心交换机上联网络出口层路由设备，完成与外网设备高速互联。接入层包括接入交换机和接入终端设备，接入终端设备包括机架式服务器、刀片式服务器以及存储设备。

通常部署相同应用的服务器要求在二层广播域内，因此为方便业务的部署、扩缩容和迁移，要求资源池内的服务器二层可达，资源池需要构建大二层网络。大二层网络主要有以下两种技术。

（1）增强二层技术

二层网络的核心是环路问题，而环路问题是随着冗余设备和链路产生的，增强二层技术的本质为跨机箱链路捆绑，将相互冗余的成对设备/链路合并成一台设备/链路，从而消除环路。

（2）隧道技术

如VxLAN，能在三层网络的基础上建立二层网络隧道，即将二层报文用三层协议进行封装。同时VxLAN技术还可以与SDN相结合，在资源池内应用，可实现网络自动部署，简化运营运维流程，便于新业务快速上线。

SDN技术也可应用于跨资源池互联应用，互联网络分为underlay网络和overlay网络。其中underlay网络用于实现各站点SDN网关间IP地址可达，可根据业务场景选择承载网；overlay用于实现站点间业务网络互通，采用VxLAN封装为业务提供逻辑隔离的互联网络。

4 NFV资源池内的资源划分方案

4.1 OpenStack资源池模型

OpenStack资源池模型将计算资源按region（分区）—availability zone（AZ，可用区）—host aggregate（HA，主机组）的层次结构进行划分，如图3所示。

（1）region为逻辑上隔离的资源池，一套OpenStack所管理的资源对应一个region，每个region有自己独立的OpenStack服务访问点（endpoint），region之间完全隔离。

（2）AZ为region内物理独立的可用区域，通常指使用相同电力供应设备的一个区域，这个电力供应设备故障将导致这个可用区的所有硬件出现故障。根据粒度不同，一个独立机房内的机架、由同一列头柜供电的机架、一个独立的机架等都可以被划分成AZ。

（3）HA为具备一个或多个相同属性的主机组，属性一般指技术规格（如硬件规格、虚拟层参数）或人为定义的属性（如用途）。

图3 region、AZ、HA层次结构

（4）一个节点只能属于一个region、一个AZ，但可能属于多个HA。

4.2 资源分区方案

（1）region规划原则

由于OpenStack消息队列机制存在瓶颈，管理能力有限，当硬件资源池规模较大或需要跨机房/DC统一进行资源管理时，可采用多region部署方式，多个region之间可共享同一个Keystone和horizon组件，进行统一的认证并呈现统一的访问界面，其他组件各自独立。

当一个硬件资源池上有多个region时，各region管理的物理主机独立，各region可共用TOR、EOR和磁盘阵列，要求磁阵能划分为多个虚拟存储池。为减少VNF设计的复杂度，提高VNF内部通信的性能，建议单个VNF的所有VNFC全部部署在一个region内，不跨region。多region部署示意如图4所示。

图4 多region部署

（2）AZ规划原则

一个资源池可规划一个或多个AZ。为保障资源池的可用性，资源池规划两个具有独立供电系统的可用区（AZ），根据VNF、管理类网元部署原则将虚拟网元部署在不同的AZ内，保证单套供电系统出现故障时业务的可用性。AZ的规划原则如下。

• 每个AZ内有独立的服务器、服务器所接入的TOR、磁盘阵列。

• 两个AZ共用成对设置的EOR、CE、防火墙等出口层设备。

• VIM对于AZ内的所有资源能实现完全的资源共享、调度、虚拟机迁移。

• 每个AZ内按安全域的要求分为管理域、业务域、DMZ；管理域部署VIM及其他管理类网元，业务域部署不能被公网访问的网元，DMZ部署可以直接被公网访问的网元。

• 对于+配置的VNFC，VIM应根据VNFM提供的反亲和性部署要求，部署在相应数量的物理主机上。

（3）HA规划原则

为实现硬件最大利用率，需要根据业务、对硬件需求等维度，对HA进行划分，以满足不同的业务部署需求。不同维度定义的HA是可并存的，即一个主机可归属于多个HA，如一台主机可同时归属于业务域HA、控制面网元HA。可能有的划分维度见表3，可以根据具体的业务需求和运维策略进行定义。

一种HA规划的示例如图5所示。

表3 划分维度

图5 HA规划示例

4.3 VNF在资源池部署的要求

根据VNF各虚拟机在资源池AZ/HA中的分布，VNF的资源部署有如下两个方案，如图6所示。

(1) 方案一：VNF不跨AZ部署。单个VNF的所有VNFC全部部署在一个VIM的一个业务AZ内，有容灾备份关系的多个网元（如同一个pool内2个CSCF）分别部署在两个AZ内。单套电源引起的故障，可能会引起整个VNF出现故障，因此通过VNF层的容灾机制（如pool）实现业务接管。

图6 VNF在资源池部署方案

优点：对VNF和资源池没有特殊要求。

缺点：需要网元层面进行冗余配置以保证整体业务接管率。

（2）方案二：VNF跨AZ部署。VNF的主备模块要求分布到不同AZ中，负荷分担的模块也平均分布到不同AZ中。由于单套电源引起的故障，会影响VNF性能，但不影响VNF的功能。

优点：单电源系统出现故障时，VNF能保留一半的处理能力，整体业务提供能力降低较少。

缺点：要求VNF支持部分模块出现故障时，不影响业务功能；对于组pool的网元，由于无法实时修改pool中的业务分担系数，可能导致超过故障网元接管能力的部分被分流至故障网元，造成业务损失。

5 结束语

NFV资源池作为向上提供统一硬件资源、存储资源和网络资源的基础设施，其网络架构、组网规划、资源划分规划等会对上层VNF的功能和性能产生影响，同时也会影响资源的利用效率。本文深入分析了NFV资源池规划的关键问题，给出了方案和建议，为实际NFV商用建设提供了参考和指导。目前规范和厂商产品也在迭代优化中，运营商对于NFV的建设部署也在探索过程中，后续还要基于部署经验进一步研究NFV资源池规划、部署方案。

[1] ETSI. Network functions virtualisation (NFV); infrastructure overview: GS NFV-INF 001[S]. 2013.

[2] ETSI. Network functions virtualisation (NFV); architectural framework: GS NFV 002[S]. 2013.

[3] 赵远, 王计艳. NFV引入对核心网网元及规划方法的影响[J]. 电信科学, 2017, 33(4): 127-132.

ZHAO Y, WANG J Y. Influence of NFV introduction on core network element and planning method[J]. Telecommunications Science, 2017, 33(4): 127-132.

[4] 吴丽华, 沈蕾. 核心网NFV部署及组网方案[J]. 电信科学, 2016, 32(Z1): 83-92.

WU L H, SHEN L. NFV deployment and networking scheme of core network[J]. Telecommunications Science, 2016, 32(Z1): 83-92.

[5] 翟振辉, 邱巍, 吴丽华, 等. NFV基本架构及部署方式[J]. 电信科学, 2017, 33(6): 179-185.

ZHAI Z H, QIU W, WU L H, et al. Basic architecture and ways of deployment of NFV[J]. Telecommunications Science, 2017, 33(6): 179-185.

[6] 沈蕾, 邵永平, 吴海. 核心网NFV机房部署策略[J]. 电信科学, 2017, 33(4): 142-147.

SHEN L, SHAO Y P, WU H. Deployment strategy of NFV central office in core network[J]. Telecommunications Science, 2017, 33(4): 142-147.

NFV resource pool planning and deploying scheme

WU Lihua, SHEN Lei

China Mobile Group Design Institute Co., Ltd., Beijing 100080, China

Network function virtualization is the direction of traditional telecommunication network evolution. The telecom network architecture in the future will be based on DC and resource pool. After test and trail, the telecommunication operators will begin NFV commercial deployment soon. An in-depth analysis of the network architecture, network planning and resource division of the NFV resource pool was given and the NFV resource pool planning scheme was discussed, which provided reference and suggestions for the construction of resource pool.

NFV resource pool, telecommunication cloud, network architecture, resource pool planning

TN915.81

A

10.11959/j.issn.1000−0801.2018200

吴丽华（1982−），女，中国移动通信集团设计院有限公司高级工程师，主要从事NFV、IMS网络、RCS、物联网等方面的方案设计和咨询工作。

沈蕾（1980−），女，中国移动通信集团设计院有限公司高级工程师，主要从事核心网及互联网领域的方案设计和规划咨询工作。

2018−04−07；

2018−06−01