云系统中的资源管理的制作方法

文档序号:11455493阅读:209来源:国知局
云系统中的资源管理的制造方法与工艺

本技术涉及用于向来自多个物理资源和/或软件资源的物理资源和/或软件资源分配至少一个虚拟资源的方法和装置。特别地,本技术涉及用于电信云系统中的资源管理的租户亲和度(affinity)。



背景技术:

网络功能虚拟化(networkfunctionsvirtualization,nfv)是提供通信服务的方法。nfv应用来自it的虚拟化和自动化技术将运营商的网络中的当前网络功能(例如防火墙、dpi、服务网关……)从专用硬件移动到通用it基础设施。这些变换的网络功能被知晓为虚拟网络功能(virtualnetworkfunctions,vnf)。vnf可以由一个或多个虚拟机(vm)和虚拟网络组成,这些虚拟机和虚拟网络一起实现网络功能。在本发明中,这些vm和虚拟网络通常被称为虚拟化资源。

本发明解决的问题之一是由于资源的物理群集(clustering)而导致的数据中心中的资源的浪费。在此上下文中,“物理群集”意味着预定义的计算资源和存储资源的集合被排他地指派给来自特定供应商(在本文档中也称为“租户”)的应用软件。因此,即使这些资源是空闲的,来自其它供应商的应用软件也不能使用这些资源。这种“物理群集”有两个主要原因:

a.安全性:例如,由于可能利用管理程序或vm漏洞来窃听来自竞争供应商的vm的流量,所以供应商(租户)出于安全原因可能不希望其vm与来自其它供应商(租户)的其它vm并置(collocated)在共享的物理资源或管理程序软件资源上。

b.性能:供应商(租户)想要保证其vnf(从而,底层vm)的性能是可预测的,并且因此来自第二供应商的vm的功能失常(mal-functioning)会影响来自第一供应商的vm。对于供应商而言,一旦他们自己的vm遇到故障,也容易跟踪和分析故障原因。

“物理群集”会导致两个主要问题:

1.数据中心资源的浪费:资源集群(cluster)的预先供给(pre-provisioning)会导致资源的浪费,尤其是如果预先供给以不适当的方式完成使得它后来与租户的实际要求不匹配的话。具体而言,在这种资源集群中的资源的实际使用会由于诸如流量负载、故障等的各种因素而动态变化。

2.对供应商/租户要求的更强依赖性:数据中心中的资源的物理群集仍然将vnf软件的采购与基础设施硬件耦合。这种行为与引入虚拟化的初始动机之一强烈地相矛盾,其中该虚拟化的初始动机之一的目的在于从运行在物理/硬件资源上的应用软件抽象这些物理/硬件资源。

在整个本公开中,术语“软件”是指以下各项之一:首先,可以由不同租户共享并且是系统基础设施的一部分的软件,例如,管理程序软件形式的软件;第二,由租户提供以执行应用或服务功能(具体而言,网络功能)的软件。如果有必要并且如果根据上下文不以其它方式显而易见的话,就明确提及“管理程序软件”与“应用软件”或“vnf软件”以区分该术语的两种不同使用。

图2示出了上面概述的物理群集问题的示例。创建四个不同的集群,并且将这些集群指派给它们各自的供应商(租户),即t-a、t-b、t-c和t-d。该图还示出了vm如何被分配给某些物理主机(服务器),以及物理群集取决于流量负载等会如何导致每个集群内的资源浪费。实质上,本可以被共享的数据中心中的资源池现在被分片成阻碍向集群的所有者/用户以外的供应商/租户分配资源的不同集群。

在数据中心资源群集领域中存在几种试图解决以上问题的现有技术。一种方法是在“vsphereesxivcenterserverresourcemanagementguide”(可于http://pubs.vmware.com/vsphere-55/topic/com.vmware.icbase/pdf/vsphere-esxi-vcenter-server-551-resource-management-guide.pdf在线获得)中描述的vmware的vsphere5.5。vsphere允许定义多个类型的亲和度:

·cpu亲和度(cpu-affinity):cpu亲和度用于对向多处理器系统中的可用处理器的子集指派vm进行限制,即,它指定vm到处理器(vm-to-processor)的放置约束。

·vm亲和度(vm-affinity):vm到vm(vm-to-vm)亲和度规则用于指定各个vm之间的亲和度(或逆亲和度(anti-affinity)),即,它指定所选择的各个vm是应该在同一主机上运行还是被保持在分立的物理主机(服务器)上。

·vm-主机亲和度(vm-hostaffinity):vm-主机亲和度规则指定所选择的vm分布式资源调度器(drs)组的成员是否可以在指定的主机drs组的成员上运行。vm-主机亲和度规则包括以下组件:a)一个vmdrs组,b)一个主机drs组,以及c)关于规则是要求(必须)还是优选项(应该)以及它表达的是亲和度(在上面运行)还是逆亲和度(不在上面运行)的指配。

最后一种类型的亲和度(即,vm-主机亲和度)是用于在数据中心中对资源进行划分并创建资源集群(如图2中所示的资源集群)的类型。特定物理主机的这些集群(主机drs组)然后可以被指派给租户(vmdrs组)。然而,这种创建是离线(预先计划的)且提前进行的以接收vm分配请求,即,分配已经被事先指配。因此,它没有解决资源浪费的问题。图2和其它图中的数据中心模式指定了每物理服务器四个虚拟机(vm)。选择该配置是用于说明,并且该配置可以在实际实施例中变化,即,每物理服务器可以有一个或多个虚拟机。除了以上概述的资源集群的预先计划和分配的缺点之外,亲和度规则的规范和维护可能是非常复杂且劳动密集型的,尤其是在具有众多租户的数据中心配置中,这些租户具有带不同要求的各种工作负载。

在美国专利us8577892b2中,peirault等人描述了基于声明亲和度组并基于这种亲和度组分配数据项和计算资源的类似方法。此方法的基本思想是计算资源可以与亲和度组相关联,并且这种亲和度组可以与地理区域或多个数据中心相关联。数据项和计算资源与亲和度组相关联,并且然后可以基于这种相关联的亲和度组来进行分配。此方案与vmware通过其drs集群所支持的方案非常类似。

另一种方法是ferris等人在美国专利us8402139b2中提出的,在该方法中,匹配系统(其可以是云管理系统)收集关于可用云设备(其可以是数据中心中的物理主机或服务器)的信息,并且将这些设备与用户请求的服务匹配。这些被请求的服务是部署在多个vm上的应用。匹配系统也可以跟踪和管理资源,因此用户可以拥有特定的权限,并且所指派的资源被置为对这些用户可用。然而,us8402139b2没有解决基于与其它租户请求相比被表达和要求的亲和度来分配资源的问题。

另一种方法由g.shanamuganathan等人在关于计算机系统的测量和建模的acm国际会议(acminternationalconferenceonmeasurementandmodelingofcomputersystems,sigmetrics2013)的“defragmentingthecloudusingdemand-basedresourceallocation(使用基于需求的资源分配来对云进行解分片)”中描述。作者提出了两种算法,这两种算法基于客户的vm的各自需求以及其它的租户指定的制约(诸如预留、限制和优先级)在客户的这些vm之间动态分配客户所购买的大容量资源。所提出的分布式二分搜索(dbs)算法与集中式vmware的drs资源管理器的算法匹配,但是分布式二分搜索算法工作在分布式环境中。而另一个提出的算法即基础+比例过量(base+proportionalexcess,bpx)是完全异步的。该方案的主要区别在于它允许对云/数据中心资源进行解分片(defragmenting),这与本文所公开的技术相关,但是在这种情况下,分配基于由客户在请求中表达的vm的负载优先级以及vm负载。因此,它没有考虑明确的租户间亲和度信息。

当基于亲和度组分配资源时,所有上述方法都要求事先以预先计划的方式分配资源组。



技术实现要素:

根据一个实施例,提供了由虚拟化资源管理引擎向来自多个物理资源和/或软件资源的物理资源和/或软件资源分配至少一个虚拟资源的方法,该方法包括以下步骤:

获得用来识别请求所述至少一个虚拟资源的第一租户的信息,

获得作为资源分配请求的参数的亲和度信息,该亲和度信息指定所述被请求的虚拟资源是否可以与不同于所述第一租户的另一个租户的一个或多个虚拟资源并置在同一物理资源和/或软件资源上;

基于亲和度信息来分配至少一个虚拟资源。

此方法具有以下效果和优点,即,数据中心中的资源可以在不必向租户(供应商)预先计划和/或预先分配物理资源和管理程序软件资源的情况下进行分配。在没有这种预先分配的情况下,在数据中心中需要更少的资源,因为资源池在租户之间统计上共享而同时在确定分配时考虑了亲和度信息,其中亲和度信息表达对不同租户的虚拟机的放置的约束。因此,如图4所示,有可能节省基础设施资源和资本支出,这同时也减少了运营成本,因为所需资源量减少。

基于所述亲和度信息分配至少一个虚拟资源具有避免按照租户对资源进行分片的效果和优点。这赋予基于其它参数或资源能力(例如,资源的类型(如果在某些主机上某种特定硬件加速可用的话)、资源的质量、弹性等级(resiliencylevel)等)来执行这种分片的更大的灵活性。

在一个实施例中,该方法包括获得与虚拟资源对于多个物理资源和软件资源的当前分配相关的信息的中间步骤。

这具有以下效果和优点,即,数据中心中的资源可以在考虑亲和度信息的情况下以更动态的方式并且在运行时进行分配。

在一个实施例中,虚拟化资源管理引擎是负责数据中心或云基础设施中的虚拟资源、物理资源和软件资源的虚拟化基础设施管理的实体的一部分。

这具有以下效果和优点,即,它允许虚拟化基础设施的管理员(例如网络运营商)将数据中心中的计算资源、存储资源和网络资源与要部署的供应商的软件实现方案解耦合。具体而言,当在特定的云环境中部署应用软件的实现方案时,应用软件的实现方案不必考虑如何建立和实施亲和度约束。负责管理虚拟化基础设施的实体可以例如是nfv体系架构框架中的vim。

在一个实施例中,用来识别第一租户的信息和亲和度信息的发信号实体是负责管理虚拟网络功能的实体。

这具有以下效果和优点,即,它允许控制负责管理虚拟网络功能的实体的租户(供应商)根据每vnf部署/操作情况来决定这样的vnf和对应的虚拟化资源应该如何针对是否与其它租户虚拟化资源并置来进行部署。负责管理虚拟网络功能的实体可以例如是nfv体系架构框架中的vnfm。

在一个实施例中,通过负责调配资源和虚拟网络功能的实体转发信号通知(signaling)。

这具有以下效果和优点,即,它允许供应商和网络运营商在不同情况下具有部分地由负责调配资源和虚拟网络功能的实体确定的不同vnf供给策略,比如数据中心中的流量负载、他们的vnf的优先级和/或附加的网络服务和资源政策约束。负责调配资源和虚拟网络功能的实体可以是例如nfv体系架构框架中的nfvo。

在一个实施例中,该方法包括基于接收到的识别第一租户的信息来发现亲和度信息的中间步骤。

这具有的效果和优点在于,亲和度信息不需要被明确地指定和传送,而是基于第一租户的身份来确定。这使得信号通知协议更加高效,并且它允许除租户(供应商)以外的实体来确定特定的租户亲和度信息。

在一个实施例中,该方法包括基于接收到的识别第一租户的信息来发现亲和度信息的中间步骤,其中用来识别第一租户的信息的发信号实体是负责管理虚拟网络功能的实体,并且其中基于用来识别第一租户的信息发现与亲和度相关的信息由负责调配资源和虚拟网络功能的实体执行,以及其中用来识别第一租户的信息以及与亲和度有关的信息的发信号通知由负责调配资源和虚拟网络功能的实体执行。

此实施例实现了多个效果和优点:允许控制负责管理虚拟网络功能的实体的租户(供应商)根据每vnf部署/操作情况来决定这样的vnf和对应的虚拟化资源应该如何针对是否与其它租户的虚拟化资源并置来进行部署,此外,供应商和网络运营商可以在不同情况下具有不同的vnf供给策略,比如数据中心中的流量负载、他们的vnf的优先级和/或附加的网络服务和资源政策约束;最后,信号通知协议可以更加高效,并且它允许除租户(供应商)以外的实体来确定特定的租户亲和度信息。

在一个实施例中,与亲和度相关的信息是政策的一部分,并且亲和度信息作为政策的设置过程的一部分被发信号通知。

这具有以下效果和优点:负责管理虚拟网络功能的实体可以直接发出资源分配请求,该资源分配请求只需要指定用于这种资源分配的vnf的类型或类别以及资源要求。然后,vim将这些信息与政策中包含的信息进行映射,并相应地发出资源分配。因此,信号通知可以更加高效。

在一个实施例中,向来自多个物理资源和/或软件资源的物理资源和/或软件资源分配所述至少一个虚拟资源的过程是管理操作的一部分,其中管理操作优选地包括虚拟化部署的第一实例化,或者现有虚拟化部署的虚拟化资源的完全或部分向外扩展、迁移或者修复。

这具有以下效果和优点,即,分配方法在其它管理操作中也是有效的,使得当管理操作发生时,该分配方法的上述效果和益处得到维持。

在一个实施例中,至少一个虚拟资源是在操作系统上运行的管理程序或虚拟应用容器上运行的虚拟机(vm)或者是用于存储的虚拟盘驱动器。

这具有以下效果和优点,即,该方法适于数据中心中通常可用的基础设施以及计算机硬件和软件系统。

在一个实施例中,为虚拟化部署提供虚拟资源的分配,其中虚拟化部署是虚拟网络功能(vnf)。

这具有以下效果和优点,即,该方法适于为电信云中的虚拟网络功能分配资源。

在一个实施例中,亲和度信息可以采用多个值来涵盖不同的分配情况,优选地包括以下各项中的一个或多个:对特定租户的逆亲和度,对特定租户的亲和度,对计算密集型、存储密集型或网络密集型的虚拟资源的亲和度。

这具有以下效果和优点,即,亲和度信息可以表达对某一部分供应商或供应商的整个集合的亲和度或逆亲和度,或者,亲和度信息可以表达亲和度或逆亲和度以并置具有某些能力的虚拟化资源。

根据实施例,提供了用于由虚拟化资源管理引擎向来自多个物理资源和/或软件资源的物理资源和/或软件资源分配至少一个虚拟资源的装置,该装置包括:用于获得作为资源分配请求的参数的亲和度信息的模块,该亲和度信息指定所述被请求的虚拟资源是否可以与不同于所述第一租户的另一个租户的一个或多个虚拟资源并置在同一物理资源和/或软件资源上;设计为基于亲和度信息来分配至少一个虚拟资源的模块。

根据另一个实施例,该装置还包括用于获得与虚拟资源对于多个物理资源和软件资源的当前分配相关的信息的模块。

根据另一个实施例,该装置还包括用于基于所述亲和度信息分配所述至少一个虚拟资源的模块。

由该装置的实施例实现的效果和优点对应于以上已经详细描述的方法的实施例的效果和优点。

附图说明

图1示出了对用于网络功能虚拟化的体系架构框架(具体而言,etsinfve2e体系架构框架)的功能构建块的体系架构概览。

图2示出了数据中心的概念模式和物理群集问题的示例。

图3示出了租户亲和度使用以及当与vm亲和度规则一起使用租户亲和度时租户亲和度的效果的示例。

图4示出了根据基于drs集群的现有技术的数据中心的概念模式,以及具有根据基于租户间亲和度值的一个实施例的分配的数据中心的概念模式。

图5示出了基于租户亲和度信息分配虚拟化资源的方法的实施例,其中租户间亲和度值为“1”。

图6示出了基于租户亲和度信息分配虚拟化资源的方法的实施例,其中租户间亲和度值为“0”。

图7示出了当执行基于租户亲和度信息分配虚拟化资源的方法的第一示例性实施例时,nfv体系架构框架的功能块之间的信号通知和信息流。

图8示出了当执行基于租户亲和度信息分配虚拟化资源的方法的第二示例性实施例时,nfv体系架构框架的功能块之间的信号通知和信息流。

图9示出了当执行基于租户亲和度信息分配虚拟化资源的方法的第三示例性实施例时,nfv体系架构框架的功能块之间的信号通知和信息流。

图10示出了当执行基于租户亲和度信息分配虚拟化资源的方法的第四示例性实施例时,nfv体系架构框架的功能块之间的信号通知和信息流。

具体实施方式

首先,将在以下缩写列表中定义描述中使用的一些术语。

cms云管理系统

drs分布式资源调度器

nfv网络功能虚拟化

nfvinfv基础设施

nfvonfv调配器

vim虚拟基础设施管理器

vnf虚拟网络功能

vnfmvnf管理器

用于nfv的规范正由欧洲电信标准协会(etsi)的行业规范组(isg)推动。etsinfv已经定义了nfv体系架构框架,该体系架构框架聚焦于由运营商的网络的虚拟化带来的新功能块和参考点。图1中示出了nfv体系架构框架的概览。

nfv体系架构框架描述了功能块和这些功能块之间的参考点。功能的分割和所声明的参考点支持多供应商生态系统中的vnf101的管理和调配。具体而言,该框架提供了所需的功能分割,以确保vnf软件可以与底层基础设施解耦合。在这种场景中,vnf供应商和实现者成为使用可能由另一个实体(比如例如移动网络运营商)管理的基础设施的实际租户。该基础设施由放置在一个或多个数据中心中的计算资源、存储资源和网络资源组成。该基础设施也旨在被共享:通过使用虚拟化技术,多个vm可以被分配和运行在单个物理服务器上。

在整个描述中,术语“供应商”和术语“租户”将被可互换地使用。

本文公开的技术主要涉及图1中所示的nfv体系架构框架的以下功能块:

-nfv调配器(nfvo)102,其负责nfv基础设施和软件资源的调配和管理,并且在nfvi上实现网络服务。网络服务由一个或多个vnf的集合来实现。

-vnf管理器(vnfm)103,其负责vnf生命周期管理(例如,vnf的实例化、更新、查询、缩放、终止)。

-虚拟化基础设施管理器(vim)104,其控制和管理nfvi计算资源、存储资源和网络资源。在基于云的nfvi的情况下,vim可以被实现为云管理系统(cms)。

-nfv基础设施(nfvi)105,其包括在其上分配虚拟化资源的计算资源、存储资源和网络资源的集合。

虽然nfvo提供全局资源分配,但是vnfm可以与vim(例如cms)直接交互,以请求虚拟化资源的管理,作为vnf的部署和管理的一部分。这种交互的示例是用于所部署的vnf的容量扩张:此扩张可以包括vnfm从cms请求附加的vm,这些附加的vm然后被添加到vnf。

本公开的教导在nfv体系架构框架的上下文中解决了以下问题:假定多供应商vnf场景,其中vnf来自不同的供应商,每个都具有其特定的资源要求,如何能够确保可以避免资源的物理群集,从而保证在不同供应商之间共享资源方面的更好的统计增益?

在下文中,将描述本发明的实施例。

本文公开的技术是基于根据租户/供应商信息来声明明确的亲和度规则。通过声明这种信息,虚拟化资源管理器引擎(云管理系统或vim的一部分)然后可以分配虚拟化资源(例如,虚拟机)作为虚拟化部署(例如,vnf)的一部分,而无需提前预先计划数据中心中的物理资源和软件资源的划分。

该解决方案聚焦于:

·关于涉及nfv体系架构框架的功能块的接口上的租户亲和度的参数。

·用于基于租户亲和度信息的资源分配的方法。

在权利要求中被称为亲和度信息的租户亲和度参数给出了租户(供应商)所请求的虚拟化资源是可以还是不可以与来自其它租户(供应商)的其它虚拟化资源并置在同一物理资源和/或软件资源上的信息。租户亲和度是与现有技术中已知的其它亲和度参数(例如,背景技术部分中描述的由vmware的drs提供的那些参数)不同的参数。图3解释和示出根据实施例的租户亲和度参数以及租户亲和度信息的使用如何与现有技术中使用的vm亲和度信息(即如上定义的vm到vm亲和度)互补。该vm亲和度信息仅指所选择的vm(而不是服务器)之间的亲和度。这里,vm亲和度=0意味着新选择的vm不能被分配在同一服务器上,而vm亲和度=1将意味着所选择的vm必须分配在同一服务器上。在这个示例中,租户“c”的虚拟资源(vm)c3和c4是具有vm亲和度=0的被选择的vm,并且当利用“vm亲和度=0”信息时,c3和c4被分配在服务器1和服务器2上(情况301)。因此,它们被分配在不同的服务器(服务器1和服务器2)上。然而,当附加地考虑“租户亲和度=1”信息时,这意味着租户的新vm中的每一个都必须被分配给在其中只分配有该租户的vm或者其中还没有分配vm的服务器。因此,如图3的右手侧所示,在服务器2和服务器3上执行分配(情况302),其中服务器2和服务器3仅被同一租户c使用(指服务器2)或者根本没有被使用并且因此是完全可用的(指服务器3)。

本领域技术人员将理解,虽然图3示出了仅具有两个被选择的vm的示例,但是相同的原理也可以应用于要分配的多于两个的被选择的vm。

图4比较了(基于drs集群的)现有技术和根据本公开的技术。图的左手侧示出了上述“物理群集”方法。右手侧示出了使用租户亲和度参数的示例。在这种情况下,亲和度值“1”意味着资源不能在租户之间共享,因此具有该值的虚拟化资源只能与来自同一租户的其它虚拟化资源共享服务器。此外,还存在具有亲和度值“0”的虚拟化资源,这意味着它们可以与来自其它租户的虚拟化资源共享服务器。

使用这种基本思想的多个实施例是可能的,并且它们中的一些实施例在以下详细描述。

本文描述并在权利要求中指定的技术具有以下优点:

·它允许数据中心中的资源以更动态的方式和在运行时进行分配,而不必向租户(供应商)预先计划和预先分配物理资源和软件资源。在数据中心中需要更少的资源,因为资源池在租户之间统计上共享。因此,如图4中所示,有可能节省资源和资本支出,这意味着同时还可以减少运营成本,因为所需资源量减少。

·避免按照租户对资源进行分片。这赋予了基于其它参数或资源能力(例如,资源的类型(如果在某些主机上某种特定硬件加速可用的话)、资源的质量、弹性等级等)来执行这种分片的更大的灵活性。

·它允许虚拟化基础设施的管理员(在我们的情况下,是网络运营商)将数据中心的计算资源、存储资源和网络资源与供应商的vnf软件的实现方案解耦合。

·它允许租户(供应商)根据每vnf部署/操作情况来决定这样的vnf和对应的虚拟化资源应该如何针对是否与其它租户虚拟化资源并置来进行部署。这允许供应商在不同情况下具有不同的vnf供给策略,比如数据中心中的流量负载、他们的vnf的优先级和/或附加的网络服务和资源政策约束。

在下文中,描述了基于租户亲和度信息来分配虚拟化资源的方法。

图5示出其中租户间亲和度值为“1”的示例。这意味着vm不能与来自其它租户的vm并置。

图6示出其中租户间亲和度值为“0”的示例。在这种示例中,请求是vm可以被分配以及与来自其它租户的vm并置。

图5和图6中示出的方法包括以下四个主要步骤:

1.步骤1(s501):执行分配一个或多于一个虚拟化资源(为了简单起见,假设这些资源是虚拟机,即vm)的请求。这种请求包括识别发出这种请求的租户的信息(参数)以及每虚拟化资源的租户亲和度值。

2.步骤2(s502):虚拟化资源管理引擎511从步骤1的请求中收集输入信息。此外,它可以收集关于数据中心中的共享的物理资源和软件资源的池上的虚拟化资源的当前放置的附加信息(或者是存储的,或者是从另一个实体取回的)。对于每个识别出的物理主机(由“服务器id(server-id)”参数521识别出),此附加信息至少包含在与图5和图6中的示例一起示出的表中的以下信息元素:

a.所使用的亲和度(used-affinity)522(当前主机/服务器如何被使用);这对应于在步骤1中发信号通知的租户亲和度参数,但是在这里它识别当前物理主机是可以与其它租户共享的(所使用的亲和度为“0”)还是租户独占的(所使用的亲和度为“1”)

b.使用这种资源的一个或多个租户(所使用的租户id(used-tenant-id)523),以及

c.虚拟化资源(例如,vm)的标识符(虚拟机id(vm-id)524):在该物理主机上实例化的虚拟机的列表

3.步骤3(s503):虚拟化资源管理引擎使用资源和租户亲和度要求查找物理主机(服务器)。

4.步骤4(s504):虚拟化资源管理引擎向管理程序或虚拟机管理器发出针对所选择的服务器/主机的分配请求,以在数据中心(云基础设施)512中分配虚拟化资源(例如,vm)。

基于谁发出和处理具有租户亲和度信息的请求以及这种信息如何被处理,多个实施例是可能的,例如,

·基于接口上的实际资源请求,或者

·通过将资源请求映射到资源的实际预留(注意:在这种情况下,预留是逻辑上的,例如虚拟存储器、vcpu的数量等;即,更多地在配额方面而不是物理主机预留方面),或者

·通过设置和使用政策。

图7至图10示出当执行基于租户亲和度信息分配虚拟化资源的方法的示例性实施例时,nfv体系架构框架的功能块之间的示例性信息流流动,这些示例性实施例在以下作为实施例1至实施例4分别进行描述。

被称为实施例a至实施例d的其它可能的实施例包括在资源管理操作(诸如向外扩展虚拟化部署(例如,vnf))期间、或者在虚拟化资源的部分或完全迁移期间、或者在虚拟化部署的部分或完全修复期间利用本发明。此外,租户亲和度参数可以被扩展为不仅保持到目前为止被用作示例的二进制值“0”和“1”之一,而且还保持来自具有多于两个值的集合中的值。在以下部分中总结和解释了所有这些实施例。

第一组实施例1至4涵盖在资源分配请求过程期间使用本发明:

实施例1是在整个上文中被用作示例的主要和基本实施例。这里,除了现有参数(比如特定资源要求和可能的预留信息)之外,资源分配请求还包括如本公开中给出的租户的标识(租户id)和所请求的每虚拟化资源的租户亲和度。在这种情况下,资源请求由vnfm做出,并且如步骤s701中对vim发出。在资源选择期间的租户亲和度的映射和这种要求的处理由vim实现。图7中示出了根据实施例1的功能块之间的信号通知以及步骤序列。

实施例2是也针对作为分配请求的一部分发信号通知租户亲和度和租户id的另一个实施例,但是,在这种情况下,它是通过nfvo间接地进行(如步骤s801和s802中所示)而不是如实施例1所概括的那样在vnfm和vim之间直接进行。租户亲和度信息仍然由vnfm发信号通知。在此过程中,nfvo还可以将vnfm的资源请求映射到特定的预留。图8中示出了根据实施例2的功能块之间的信号通知以及步骤序列。

实施例3与实施例2的不同之处在于,不是所有信息都需要从vnfm发信号通知。而是信息的一部分由映射来自vnfm的资源请求中的租户id的nfvo推导得出。这里nfvo保持允许它推导出租户亲和度信息的内部信息。nfvo还可以将vnfm的资源请求映射到特定的预留。然后,类似于实施例2,nfvo可以继续向vim发信号通知资源分配请求(如在步骤s902中那样)。图9示出了根据实施例3的功能块之间的信号通知以及步骤序列。

实施例4:在这种情况下,发信号通知租户亲和度信息是政策创建过程的一部分。在图10中示出的此示例性情况下,nfvo是“创建政策”的发出者,并且vim是保持这种政策的实体。这种政策创建请求(步骤s1001)包含关于租户标识符(租户id)、租户亲和度参数以及来自应该遵循这种亲和度放置要求的租户的vnf的类别或类别列表([vnf-class])的信息。参数表示使用方括号“[”“]”来指示可以指定一个值或者值的列表。vim存储以后可以用于做出分配决定的这些信息。一旦创建了政策,另一个第三元件(例如,vnfm)就可以直接发出资源分配请求(步骤s1003),该请求只需要指定资源要求以及用于这种资源分配的vnf的类型或类别(vnf-class)。然后,vim将这些信息与政策中包含的信息进行映射,并相应地确定资源分配。

第二组实施例涉及不同类型的资源操作,比如缩放vnf的容量,或者将vnf的虚拟机从一个物理主机部分或完全地迁移到可以对其使用这种租户亲和度的另一个物理主机,或者部分或完全地修复vnf。这些实施例因此与第一组实施例正交:第一组实施例描述了实现发信号通知过程以支持与租户亲和度相关的信息通过nfv体系架构框架内的不同功能块的不同方式;第二组实施例描述了可以被支持的对虚拟化资源的不同操作。因此,可以组合来自两组实施例的实施例的特征。

实施例a在vnf(虚拟化部署)的新实例化过程期间使用租户亲和度信息作为实际的虚拟化资源分配请求的一部分。这是到目前为止在本描述中所使用的示例。

在实施例b中,假设vnf应该被向外扩展,例如通过向此vnf添加更多的虚拟机。因此,这种向外扩展过程也需要分配新的资源,并且租户亲和度信息被用来确保这些资源的恰当实例化。在这种情况下,新的虚拟化资源可以被请求作为这种vnf的一部分,或者作为现有的虚拟化资源上的扩充,例如,向现有的虚拟化资源(vm)分配更多的vcpu或虚拟存储器。注意的是,在其中减少vnf的容量的向内收缩过程也可能需要租户亲和度信息。示例是vim想要决定首先移除哪个vm的情况,或者是针对在向内收缩之后的资源整合后的vm应该被迁移(如以下实施例c所述)的情况。

实施例c假设迁移场景,即,完整的vnf或者其部分要被迁移到数据中心内或数据中心之间的不同服务器。利用数据中心中通常使用的标准虚拟机迁移技术,这是可行的。这里,租户亲和度信息用于确定vnf的vm可以或不可以被迁移到哪些服务器。

实施例d涵盖针对整个vnf或者针对其部分的vnf的虚拟化资源修复(故障恢复)。这里的示例是vnf的某些vm的故障,这些vm然后需要重新部署在新的服务器上。在这种情况下,租户亲和度信息也用于确定用于这种重新部署的合适的候选服务器。

最后,在第三组实施例i至iii中,租户亲和度参数的可能值是变化的。或者它们是到目前为止描述的二进制,或者它们采用来自预定义的值集合中的不同值。

在实施例i中,租户亲和度参数是二进制值,该二进制值确定虚拟化资源是否可以与来自其它租户的虚拟化资源并置:如果该参数等于“0”,那么虚拟化资源可以与来自其它租户的其它虚拟化资源并置在数据中心中的共享的物理资源和软件资源上;而如果该参数等于“1”,那么虚拟化资源不能与来自其它租户的那些虚拟化资源并置。这是在上文中已经描述的实施例。

在实施例ii中,租户亲和度参数可以采用来自值集合中的值,其中不同的值表示对某一部分租户(供应商)或租户(供应商)的整个集合的亲和度或逆亲和度的信息。例如,

·租户亲和度=a:对组a的任何租户(供应商)的亲和度。

·租户亲和度=b:对不同于租户id=x的任何租户(供应商)的亲和度。

·租户亲和度=c:对租户id=z但不是对租户id=y的亲和度。

·等等。

在实施例iii中,租户亲和度参数可以采用来自具有多于两个值的值集合中的值,其中不同的值表示对具有某些能力的并置的虚拟化资源的亲和度或逆亲和度的信息。例如,

·租户亲和度=m:对来自其它租户的计算密集型vm的逆亲和度。

·租户亲和度=n:对来自其它租户的密集型输入/输出数据vm的逆亲和度。

·等等。

对本领域技术人员将显而易见的是,结合本发明的实施例描述的方法、元件、单元和装置可以用硬件、用软件或作为两者的组合来实现。具体而言,将认识到的是,本发明的实施例和与其结合描述的模块的元件可以由在计算机上运行或由微处理器执行的一个或多个计算机程序来实现。具体而言,实现本发明的任何装置可以采用充当网络实体的计算设备的形式。

当前第1页1 2 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1