高可用多实例虚拟网络功能链弹性部署策略

黄 纬,张建德,温志萍,彭焕峰

(南京工程学院 计算机工程学院, 南京 211167)

随着互联网规模不断增大,网络结构逐步复杂化．当前,网络承载了大量的服务,而这些服务需要某些特定的网络功能来实现或支撑．传统的网络功能由硬件实现,这带来了升级维护不便和布线困难等弊端．为了提供更高的灵活性和扩展性,网络功能虚拟化(network function virtualization,NFV)技术应运而生.通过将硬件和软件解耦,使得虚拟网络功能(virtualized network function,VNF)以软件的形式运行在通用硬件平台上,避免了硬件实现的弊端．在虚拟化环境中,网络服务通常以虚拟网络功能链(virtualized network function chain,VNFC)的形式提供,数据包按照一定的顺序依次通过部署在服务器上的若干VNF,并进行相应处理[1]．

另一方面,由于互联网的开放性和动态性,使得网络服务不再绝对可靠和安全,服务中断可能会带来大量的经济损失和极差的用户体验．文献[2]中指出,2010年北美洲仅因为网络服务中断就承受了265亿美元的损失．据调查,当企业关键系统出现结点失效时,营收能力将平均下降29%．文献[3]中总结了可能引起服务中断故障的几种因素,其中包括硬件故障(服务器故障、电力中断等)、软件故障(通常是操作系统、虚拟机或软件自身问题)以及操作故障(错误操作或配置等)．为了应对网络故障并降低服务中断影响,服务提供商与用户间通常会定义一种双方认可的服务水平协议，规定所提供服务的可用性要求,通常来说这个指标是驱动服务质量提升的主要因素．

为了提供高可用的网络服务,目前有大量相关工作对VNFC部署策略进行了研究．文献[4]中通过将VNFC部署问题抽象并分解为两个NP难问题(设施选址问题和广义分配问题),设计了一种近似算法,通过两阶段进行问题求解,实现了VNF部署．文献[5]中则提出了一个考虑截止时间保证的VNF调度分配方案,目标是能够最大化满足服务等级协议保证的服务链请求的数量,同时保证租户之间的隔离性．文献[6]中考虑用预先指定的VNF实例部署策略来取代自由无约束的VNF部署,在总通信流量恒定的情况下,通过使服务器的内部带宽最大化，以使外部通信开销最小化．另外文献[7-9]中从不同角度对VNFC部署进行了不同程度的探讨和研究．

但是,实际网络不会总是可靠的,需要对VNFC设计相应的容错机制,以应对可能出现的各种网络故障．因此在上述工作的基础上,有些学者开始考虑NFV冗余容错机制.文献[10]中针对网络设备故障设计了一种冗余备份策略,通过整合不同VNF的冗余备份资源,减少了容错的资源消耗．文献[11]中总结了3种典型的VNFC冗余备份模型(端到端冗余、节点冗余、链路冗余),并将其形式化,提出了一种基于线性规划的求解策略．文献[12]中围绕VNF可靠性和路由优化问题进行了研究,假设各个网络设备可靠性相互独立，将问题描述为整数线性规划,并提出了用一种启发式方法对其进行高效求解．而文献[13]中设计了一种VNF的故障回滚机制,保证在故障恢复过程中内部状态的一致性．

但是,现有的相关工作仍存在一些不足．目前有一些工作已经开始对VNFC的高可用部署和状态管理进行初步探究[13-15],但是在VNFC的构建和部署方面依然存在一些难题．首先,由于目前的VNF状态一致性问题尚未有成熟的解决方案,因此现有工作中的VNFC部署问题多考虑的是具有较广适用性的单实例场景,在这些工作中,多数仍假设NFV系统工作在可靠网络的环境中,并没有考虑系统故障和容错方面的问题．另一方面,由于服务的动态伸缩已经成为当前网络中愈加明显的特征,为了应对传统部署方案中单点故障和性能瓶颈这两个问题,多实例的部署问题也将成为NFV技术中不可忽视的一项挑战．为了保证多实例VNFC正常工作和迁移操作的状态一致性,目前有工作开始从系统方面对NFV状态管理机制进行研究,但是在VNFC部署策略方面则尚未出现较为成熟的解决方案,现有的相关算法因为抽象度高或缺少深度优化等原因,并不适用于实际场景．基于上述研究现状,文中针对多实例VNFC部署问题,基于共享状态的NFV机制，提出一种弹性VNFC部署策略,通过基于节点评分的多实例扩展算法减少部署带来的通信开销和实例开销,并使用多实例冗余备份策略提高VNFC的可用性．实验证明文中提出的部署策略相比于现有策略,能够有效减少虚拟网络功能链部署的资源开销．

1 网络功能状态与弹性部署

1.1 网络功能状态

在NFV的实现中,各类VNF通常需要保存某些网络状态信息，如数据流信息、地址映射等,以支持数据包过滤、内容分析等各种复杂操作．根据文献[16]中总结的典型VNF的数据包处理流程,当VNF接收到数据包时,根据包头的五元组信息在VNF存储的状态中进行查询,并决定对包进行修改、丢弃、转发等操作．状态可分为内部状态和外部状态，内部状态只与当前VNF实例相关,而外部状态与网络中的其他同类VNF相关,需要维持其一致性．另外,外部状态中还分为相关状态和非相关状态，前者与数据流无关,只涉及此类VNF本身的信息,而后者则可能随着数据流的到达和处理而被修改．

以负载均衡(load balancer, LB)为例,负载均衡是数据中心基础设施的一个基本功能,对数据中心中的各种在线服务非常关键．为了应对大量服务请求,一个服务的背后通常有大量服务器在进行请求分流,以保证整体服务的性能．如图1,用户访问服务的地址称为虚拟IP(virtual IP address,VIP),这是由服务公开的一个或多个用于接受外界访问的地址．由多台提供此服务的服务器构成服务集群,每台服务器都有自身的直接IP(direct IP address,DIP)．LB接收所有发往VIP的请求流量,并根据特定的策略(随机、哈希等)为请求分配一个服务器并指定DIP,通过IP-in-IP封装将数据流分配到对应的服务器进行处理．为了将同一条流的数据包正确地转发到一个服务器,需要在LB中记录每条数据流与分配的服务器之间的映射关系,这通常为一个IP五元组到IP地址的映射表．每次接收到数据包,LB根据包头的五元组在表中查询是否存在IP映射,如果存在则直接转发,如果不存在,说明这是一条新的数据流,则根据特定策略为其分配一个服务器,并将这条新的五元组到DIP的条目加入映射表．这样的映射表就属于网络功能LB的内部状态,而每次到来的数据包都有可能对这个内部状态进行修改更新．

图1 负载均衡功能的工作流程Fig.1 Workflow of load balance function

1.2 服务弹性部署与共享状态机制

随着移动计算的发展和用户需求的快速变化,网络中的各类VNF对资源的需求也随着时间推移而不断变化．文献[17]中对数据中心网络中不同时段的VNF利用率进行了调研,并指出VNF的利用率在时间维度上剧烈变化,而这对于NFV的性能是一个巨大的考验,当对VNF的需求增长或减少时,需要对各类VNF进行性能伸缩，以最大限度地利用网络资源并减少性能开销．一般来说，对网络功能进行性能伸缩可以通过横向调整和纵向调整实现.以性能扩展为例,纵向扩展指为单台机器添加更多或更强的CPU、 存储和网卡设备,网络功能能够从硬件资源中获得更强的处理能力,从而满足用户的需求;横向扩展指添加更多的网络功能设备,设备之间互相协调合作,利用更多的机器资源来提升整体处理能力,从而达到满足用户需求的性能水平．而对于VNF来说,由于虚拟化技术和灵活弹性部署的需求,对通用设备友好的横向调整策略通常是更优的性能伸缩方案．

为了满足服务扩展性,虚拟网络功能组成的网络功能链不再以单链拓扑的形式出现,每类VNF可能由多个运行于不同服务器的VNF实例共同组成,而每类VNF的多个实例之间又按照特定的顺序互相连接,形成了一种有序的网状结构,如图2． 然而,一旦使用多实例网络功能,实例之间的状态问题就不可避免地凸显出来,无论是多实例协同工作还是进行动态性能伸缩,如何保证网络功能状态的无缝同步和快速迁移就成为亟待解决的问题．针对该问题，文献[15]中调研了大量网络功能的内部状态,设计了一套通用的支持VNF状态迁移的API,并通过修改网络功能的内部实现,对虚拟网络功能的迁移和动态扩展提供了一定的支持．但是文献[14]中指出,对各个独立的网络功能实例内部状态进行操作来实现全局状态一致的策略是非常低效的,且本质上并没有解决状态一致性与错误恢复等问题．

图2 网状虚拟网络功能链Fig.2 Reticular virtual network function chain

另一方面,为了满足服务的可用性,必须保证当网络中某个设备故障时,服务的处理速率不出现明显降低．但是由于内部状态容易因机器故障而丢失,因此对于突发性故障,如何保证网络功能的快速故障转移与恢复是另一个亟待解决的难题．现有的对突发性故障的解决思路一般有两种,一种是设置周期性的检查点，定期将网络功能的内部状态作为快照存储下来,一旦出现突发故障,就能够根据最近的快照对原实例进行重建[18];第二种是对每个输入的数据包进行记录，发生故障后根据日志记录对内部状态进行推演,从而还原故障的虚拟网络功能[13]． 但是这些策略可能会显著增加每个数据包的转发延迟(通常数量级达到10 ms),而且状态重建也可能会耗费大量的时间,这对于大部分对稳定性要求较高的服务来说是无法接受的．

为了从根本上解决由于多实例VNFC部署带来的状态一致性问题,现在有一些研究者开始考虑对状态进行集中化管理,处理数据包，对状态数据解耦,把现有的网络功能分解成无状态的处理单元和通用的数据层,由处理单元负责具体的功能处理,并将处理后的网络状态与通用的数据层同步,可以使VNF更加易于扩展、升级．如文献[14]中提出了一种状态集中化的网络功能虚拟化架构StatelessNF,通过将系统中的VNF部分内部状态托管于低延迟、高可靠的数据存储系统,实现了网络功能实例之间的独立．VNF状态的共享集中管理对处理单元和状态数据进行了解耦,极大地增强了服务的灵活性和可靠性,是一种具有乐观前景的NFV解决方案．目前学术界对于这种无状态网络功能链的资源部署等研究较少,由于状态管理方式的不同,现有的网络功能链部署策略也都无法适用,因此文中对共享状态的多实例网络功能链进行研究,并提出一种有效的高可用VNFC部署策略．

2 高可用多实例虚拟网络功能链部署问题

为了解决虚拟网络功能链的部署问题,同时提供一定的可用性保障,需要对网络资源约束和服务水平约束进行形式化处理,从而构建一个有效的网络功能链模型,并定义相应的网络功能链部署问题．文中基于集中化的VNF状态管理机制,对 VNFC 的模型构建与弹性部署问题进行研究分析．

2.1 可用性模型

由于VNF实例的去状态化,对于同一类VNF来说,多个位于不同服务器的实例之间的状态可以认为是同步的,逻辑上可以将其视为同一个VNF实例,因此经过各个实例的数据流不再不可分流;另一方面,共享状态的VNF实例之间能够进行互相备份,将同类VNF的实例分别部署在不同的服务器上,一旦某个VNF实例发生突发性故障,系统整体的流量处理能力将出现不同程度下降,从而导致服务吞吐量下降等性能损失．

(1)

式中：Av和Aw为服务器节点的可用性．g(n)为当n中节点均发生故障时VNFCc总处理能力的剩余比例,计算为:

(2)

式中：C(i)为单个VNFi实例能够提供的最大处理能力；Ci,v,h为VNFi在节点v上实例h已使用的处理能力；ratec为VNFCc的流量速率．式(2)给出了当n中节点均故障时,整条VNFC在使用所有实例剩余处理能力后,能够提供的总处理性能相比VNFC请求速率的比例．综上所述,式(3)给出了一条VNFCc的可用性计算公式:

(3)

需要指出的是,文中的可用性计算更多考虑网络故障时VNFC的服务性能损失比例,因此使用g(·)刻画VNF实例处理能力的变化．

为了满足部署策略的可行性,需要保证每个VNF实例得到足够的CPU资源进行流量处理,因此任何一个服务器上所有VNF占用的CPU资源总和不能超过机器的物理资源上限:

(4)

同样的,每条物理链路上经过的流量总和不能超过其带宽上限:

(5)

为了保证用户请求的数据流都能够被处理,每个VNF实例处理的流量速率总和不能超过其处理能力上限:

(6)

另外,为了保证网络中的流量是可行流,必须保证每个非端点节点的入流和出流相等:

(7)

(8)

2.2 问题定义

不同于单实例VNFC部署问题，当状态集中共享之后,部署请求中的VNF可能在部署策略中由若干个同类VNF实例组成,具体的实例数量是未知的．

问题优化目标是使部署开销最小化，其中包含了部署VNF实例产生的开销(授权、维护等)以及实例之间流量转发产生的通信开销:

(9)

式中,Be表示物理链路e的带宽上限．每个VNF部署的实例数量对最终的部署策略和总体开销会产生一定的影响,如实例数量较多,用户可用性要求较容易满足,但是增加了实例部署开销,且容易较快用完网络中的计算资源;而若实例数量较少,每个实例的处理能力有限,会导致请求的流量无法及时处理,且可能导致路由的路径过于集中而产生流量热点,进而出现网络拥塞,影响网络整体性能．接下来,根据上文描述的问题模型,给出多实例VNFC部署问题的定义．

高可用多实例虚拟网络功能链部署问题定义：给定物理网络G(V,E)及一组部署请求,将每类VNF的若干实例部署在网络中形成VNFC,给出请求到VNFC的映射关系,满足部署的可行性约束式(4～7),且通过实例互相备份使得每条VNFC的可用性满足式(8),并使部署策略的总开销式(9)最小化．

3 多实例虚拟网络功能链部署策略

现有工作中对于单实例VNFC部署问题及虚拟网络嵌入(virtual network embedding,VNE)的研究较为成熟,但是对于文中讨论的多实例部署问题,由于部署的实例数量事先并不知道,需要根据物理网络、用户部署请求的信息进行动态决策,所以现有工作中的解决方案无法适用．一种可行的部署策略是,预先根据输入信息,估计每类VNF部署的数量,使得部署请求中的VNF链转换为一个有向无环图(directed acyclic graph,DAG),将其视为一个虚拟网络(virtual network,VN)并利用现有的VNE算法进行虚拟网络部署．这种方法将文中的多实例部署问题转化为一个已经有成熟解法的问题,但是由于在DAG转化过程中,并没有物理网络和部署信息的指导,形成了一个两阶段分离的部署策略,其中的第1步DAG 转换可能导致形成的VN不适合部署于当前的物理网络,导致最后的部署开销较大．文中实验部分将会实现一个基于VNE算法的多实例部署方案,通过实验证明其可能会导致较大的部署开销．

文中针对多实例虚拟网络功能链部署问题,提出了一种基于多实例扩展的部署算法,避免了多阶段部署带来的缺点,在使用尽可能少的节点数的前提下,使整体的带宽消耗最小化．

3.1 问题最优解形式与开销分析

首先对多实例虚拟网络功能链部署问题的最优解进行分析,并试图找到其开销的理论下界．根据式(9),部署开销分为实例开销和通信开销．一方面,为了尽可能减小部署带来的实例开销,应该在满足用户请求可用性要求的前提下,尽可能减少VNF实例的个数．为得到VNF实例数量的理论下界,假设物理网络的每个节点的可用性都取所有节点可用性中的最大值,即:

(10)

(11)

对上式进行变换得到:

(12)

(13)

另一方面,为了尽可能减少实例间的通信开销,在部署请求的流量速率不变的情况下,应尽量减小每条流量路径的长度．为了得到通信开销的理论下界,假设对于网络功能链c,部署在网络中的每条路径长度都是最小值,即从c的源点s到终点d之间的最短路径的长度|shortestPath(G,s,d)|．当VNF的状态集中共享之后,用户请求的流量是可分流的，因此对于功能链c,通信开销的理论下界为:

(14)

综上所述,多实例网络功能链部署问题的理论下界可以表示为:

(15)

文中分析了问题最优解可能的形式,但是由于这是一个NP难问题,直接寻找其最优解是困难的,其对应的整数线性规划问题求解的复杂度也是不可接受的．因此文中根据上述的问题分析,同时考虑实例开销和通信开销,提出一种基于多节点扩展的优化部署算法,在不断迭代过程中,将需要的VNF实例依次引入,并保证带宽消耗最小,直到满足处理能力要求和可用性要求．

3.2 部署算法

文中提出一种基于多实例扩展的多实例部署策略EXTEND．首先,根据到来的用户请求的流量速率和可用性要求,计算每个请求的权重:

(16)

按照权重从大到小的顺序对请求进行排序,依次部署．之后,对于一个待部署的请求,将其需要的VNF各部署一个实例,使得网络功能链具有初步的完整形状．根据式(9),为了保证带宽消耗最小,部署每个VNF的第1个实例时,选择部署节点的依据是使该节点u∈V到源点和终点的距离之和distance(s,u)+distance(u,d)尽可能小,在距离之和相同的情况下,选择可用性最大的节点．

每类VNF的首个实例部署完成后,需要判断当前的网络功能链是否满足要求,需要满足两个标准：① 计算当前网络功能链的可用性,判断是否达到用户请求的可用性要求;② 判断每类VNF的实例处理能力之和是否大于请求的流量速率．若两个条件都达到,则此请求部署完成,继续部署下一个请求;否则,需要为这一轮部署中的瓶颈VNFb∈c.NF增加实例．这里的瓶颈指当前功能链中可用性最小的VNF或者实例处理能力不足的VNF．

为VNFb增加实例时,需要选择实例的放置节点,为了形成互相冗余备份,候选节点应该排除已经部署了b的实例的节点．定义候选集合Vc,其中包含了所有已部署同类VNF实例的节点和CPU计算资源足够增加新实例的节点．为了使部署的通信开销最小化,同时充分利用VNF实例,按照式(17，18)计算每个候选节点t的评分:

(17)

(18)

式中：Vpre(b)和Vpost(b)分别表示请求c的VNF列表中VNFb的前驱和后继VNF的所有已部署实例所在的节点集合；Cb,v,h指节点v上对应VNFb的实例h的已使用处理能力比例,若不存在则为0． 根据式(17，18),每个节点的评分依据标准化的节点带宽开销与已有VNF实例占用处理能力比例来衡量,其中带宽开销指距离前驱和后继VNF所有实例的距离之和．将实例部署在评分最小的节点上,能够减少部署时的带宽消耗,同时充分利用已部署实例资源,提高整体的资源利用率．以此进行迭代,重新判断当前的网络功能链是否满足要求,并按相同的策略进行处理,直到满足要求为止．

(19)

需要注意的是,在本问题中,计算的网络流是多源多汇的,因此每次计算最大流时,为源点集和终点集添加一对虚拟源点s′和虚拟汇点d′,与其他节点连接的带宽根据上述分配原则分别设置为各个源点和各个汇点对应的流量,s′到d′的最大流即为要求的VNF多实例间的网络流．每类VNF 实例间的路由策略计算完成后,当前的请求部署完成,之后按照上述过程部署下一个请求,直到所有请求都成功部署到物理网络中．

算法的伪代码如下:

(1)sortedRequests=sortByWeight(Requests)

(2) forr∈sortedRequests:

(3) fori∈r.NF:

(4)candidate=FindNode(G,{r.src},{r.dst},i)

(5)place[r][i]=candidate

(6)update(G)

(7) endfor

(8) loop

(9)bn=Check()∥判断当前链是否满足要求

(10) ifbn==-1

(11) break

(12) endif

(13)candidate=FindNode(G,pre(bn),post(bn),bn)∥按照式(17，18)选择候选节点

(14)place[r][i]=candidate

(15)update(G)

(16) endloop

(17)route[r]=Flow(G,place)∥计算网络流

(18) endfor

(19) return {place,route}

其中选择部署候选节点位置的过程FindNode(G,{r.src},{r.dst},i)的伪代码如下:

(1) forv∈V:

(2) ifv上已有VNFi的实例h或v.CPU≥U(i)

(3)Vc.add(v)

(4) endif

(5) ifVc==∅:

(6) returnnull

(7) endif

(8) endfor

(9) forv∈Vc:

(10) 按照式(17，18)计算每个节点v的rankv

(11) endfor

∥升序对Vc进行排序

(12)sortedV=sortByRank(Vc)

(14) returnsortedV[0]

4 实验结果与分析

4.1 实验配置

模拟实验平台配置为Intel Core i5-4590 3.30GHz CPU,8GB内存．实验中使用的物理网络拓扑来自SNDlib[19]的nobel-germany网络,其中包含50个物理节点,由88 条物理链路互相连接．对于每个物理节点,设定其CPU 计算资源为800单位(为简化问题,文中只考虑CPU计算资源,但易于扩展到内存、网卡等多资源情况),其可用性在90%～99%之间按均匀分布随机取值,而每条物理链路的双向带宽均为2 000 Mbps;用户的部署请求随机生成,每个请求的流量速率要求在[20, 40]之间按均匀分布随机取值,且可用性要求在[0.8,0.9]之间按均匀分布随机取值．实验中设置8种VNF,其CPU资源消耗分别为45、35、30、25、35、40、20、30，数据包实时处理能力分别为15、20、20、15、15、20、25、30，生成的随机VNF序列长度分别在[2,4]和[4,6]间随机取值．

现有工作中还没有考虑进行多实例相互备份的高可用VNFC部署算法,为此,文中将贪心算法Greedy作为对比算法,同EXTEND算法的性能进行比较．Greedy在部署实例时,选择计算资源最大的节点作为候选节点,直到满足网络功能链可用性．

考虑到本问题的形式与VNE问题也存在一定的相似性,因此文中选择了文献[20]中提出的VNE 部署算法OVNM作为对比算法,并进行了相应修改．VNE问题给定一组虚拟网络请求和一个物理网络,将所有虚拟网络部署到物理网络中．OVNM的思路是在部署虚拟网络时,尽可能选择相邻链路带宽总和最大的节点作为首个部属节点,以提升后续节点和链路成功部署的概率,当发生无法部署的情况时进行回溯．相比于VNE问题,多实例VNFC部署问题也需要将一个虚拟网络部署到物理网络中,但是这个虚拟网络并不是给定的,事实上部署请求中只规定了VNF顺序、流量速率等,因此本质上这是两类不同的问题．文中对OVNM进行了一定的修改,首先计算出每个部署请求的每类VNF 实例数量的最小值,使其满足请求的可用性要求,形成明确的虚拟网络,之后使用OVNM原算法对生成的虚拟网络进行部署．

4.2 结果与分析

首先,文中对EXTEND本身的性能进行一些测试．图3展示了分别在长链(功能链长度为[4,6],默认为[2,4])和高可用性(可用性要求为[0.9, 0.99],默认为[0.8, 0.9])，而其他参数默认的情况下,随着请求速率增长,EXTEND的通信带宽使用量变化情况；而图4展示了实例个数的使用情况．可以看出,可用性要求较高的情况下,部署的带宽消耗没有额外增加,而实例个数显著增加,这是因为网络中增加了额外的VNF实例以满足可用性要求,但是由于实例之间分摊流量,数据包路由的路径长度基本不变．而长链情况下,为了部署更多的VNF,带宽消耗略有增加,而实例个数显著增加．

图3 EXTEND在不同参数下的通信带宽开销Fig.3 Communication bandwidth cost in differentparameters of EXTEND

图4 EXTEND在不同参数下的实例开销Fig.4 Deployment cost in differentparameters of EXTEND

然后,文中将提出的EXTEND与前述的OVNM算法和Greedy算法进行对比．图5展示了在部署请求的数量增加时,3种部署算法的通信开销变化情况,可以看出Greedy消耗了较多通信带宽,EXTEND带宽开销最小,而OVNM的通信开销略高于EXTEND,总的来说,EXTEND相比Greedy和OVNM,在相同环境下能够平均节省约39.9%和13.7%的通信带宽开销．这是因为EXTEND在部署时,从最短路径开始进行扩充,且每一步尽可能减少路由路径的长度,使得总路径长度较其他算法更短,因此节省了更多的带宽资源．

图5 不同请求数量下的通信带宽使用量Fig.5 Communication bandwidth usage ofdifferent request number

图6展示了不同请求数量下,3种部署算法的实例使用数量的变化情况．

图6 不同请求数量下的VNF实例使用数量Fig.6 VNF number of different request number

可以从图中看出,EXTEND和Greedy的实例个数差别不大,而OVNM则比EXTEND平均高大约49.4%,这是因为OVNM是多阶段方法,为了使用这个针对VNE的部署算法,在形成虚拟网络时没有物理网络和请求的信息作为指导,因此可能导致部署多余的实例,使得实例部署数量较大．

为了衡量部署策略的总体性能,文中综合考虑部署的通信带宽使用量和VNF实例数量,根据式(9)定义部署开销指数,其中β=1,γ=15．此指标衡量了VNFC部署结果的总体资源消耗,并反映了部署策略的资源利用率．从图7中可以看出3种部署算法的总体部署开销指数,文中提出的EXTEND算法比其他两种算法具有更低的部署开销,比OVMN 和Greedy 分别降低了23.1% 和26.6%．Greedy在部署过程中优先选择剩余计算资源较多的节点,因而节点之间路径长度较大,导致通信开销较大;OVNM为了满足可用性要求，生成的虚拟网络冗余节点数量可能过多,因此实例开销较大．反之,EXTEND算法从最短路径开始扩展,且按照节点位置计算评分,使得整体通信开销较小,另外在部署过程中不断迭代,每次在合适的位置添加实例,因此保证能够在满足可用性要求的前提下使实例开销最小化．

图7 不同请求数量下的部署开销指数Fig.7 Deployment cost index of different request number

最后,图8展示了3种算法的平均执行时间,可以看出EXTEND 的执行时间比Greedy略微增加了一些,而OVMN 由于需要进行回溯，执行时间增加了约1倍．

图8 不同请求数量下的执行时间Fig.8 Processing time of different request number

5 结论

(1) 文中针对多实例VNFC弹性部署问题,对虚拟网络功能内部的状态和一致性问题进行了阐述,并介绍了几种现有的解决方案和机制．

(2) 为了达到最优化的部署效果,基于现有的共享状态的系统机制,文中构建了一种用于衡量可用性的模型,并针对高可用的多实例VNFC部署问题,提出一种基于多实例扩展的优化部署算法,通过多个实例间的冗余备份及迭代引入VNF,在满足可用性要求的前提下使带宽使用最小化．

(3) 模拟实验表明,相比于现有算法,文中提出的算法在降低部署实例数量和通信带宽方面能够达到更好的效果．