CN105052097A - 统一云资源控制器 - Google Patents

Abstract

提供了用于统一云资源控制的措施。此类措施示例性地包括接收指定多个资源类型的资源组合的资源要求的请求，并根据所述资源要求来控制来自基础设施资源池的基础设施资源的预留。

Description

统一云资源控制器

技术领域

本发明涉及云计算且尤其是作为云计算服务器模型的基础设施即服务（IaaS）。

例如在http://csrc.nist.gov/publications/nistpubs/800-145/SP800-145.pdf中定义了IaaS相关术语。

本发明特别地涉及统一云资源控制。更具体地，本发明示例性地涉及用于实现统一云资源控制的措施（包括方法、装置和计算机程序产品）。

背景技术

IaaS是一种云计算服务模型，其为消费者提供处理、存储、网络及其它基本计算资源，其中，消费者能够例如部署并运行任意的软件，其可以包括例如操作系统和应用程序。消费者并不管理或控制底层云基础设施，但是能控制已部署的操作系统和应用程序、存储以及所选联网部件（例如，主机防火墙）的可能有限的控制。

流行且众所周知的IaaS服务提供商是例如Amazon、RackSpace以及FlexiScale。在此非常动态的领域中还出现了许多较小的提供商。

此外，存在许多服务提供和软件应用程序，其在基本的IaaS模型之上还提供增强的IaaS模型，例如使得由IaaS云提供的资源的处理的各种方面变得容易的配置、自动化、管理和协调工具/服务。

此类提供的示例是RightScale或enStratus。

主要的IaaS应用编程接口（API）专有地在基本资源层级工作。JClouds具有节点组的概念，但是从一组单独虚拟机（VM）聚合的，并且该操作实际上被分解成基本调用。

此外，服务和应用程序部署一般地被视为必须建立于IaaSAPI（例如enStratus、RightScale）之上的任务。然而，这些解决方案将资源预留分解成单独步骤，并且不保证预留序列会成功，并且因此一个点处的失败意味着更早的预留必须被撤消（并且在需要时重新尝试）。

开放虚拟化格式（OVF）允许将一组合作VM的描述封装在一起作为“虚拟设备”，并且其定义此VM组所使用的相关资源。然而，OVF集中于在VM之上定义软件（SW）堆栈，并且其并不要求关于定义虚拟设备的部署序列的任何事。实际上，OVF大部分被用于在虚拟化基础设施上部署设备（与IaaS云相反），并且部署是以逐步方式执行的，即并不利用关于设备的完整资源要求的隐含知识。

此外，现有技术IaaS解决方案支持虚拟网络的定义和将VM与之相连。然而，可以分配给这些网络的资源只有逻辑（例如网际协议（IP）地址、虚拟局域网（VLAN）标识符（ID）），并且仅使得能够实现业务的分离。逻辑资源的分配并未对可以部署VM（和已分配物理资源）的位置施加任何限制。

OpenStack（http://wiki.openstack.org/StartingPage?action=show&redirect=OpenStack）具有用以处理不同类型的资源的不同模块（即，Nova模块用于计算资源，Quantum模块用于联网，Swift模块和Cinder模块用于存储），但是这些是独立的模块。即使Quantum模块宣称为虚拟网络提供端到端服务质量（QoS）的可能性，也不清楚其如何能用当前的覆盖模型来实现，并且即使其将是可实现的，也不清楚网络资源限制如何影响VM的替换。

另外，VM放置判定是基于IaaS意识到的硬件资源的可用性完成的。在大多数情况下，这局限于中央处理单元（CPU）、存储器以及本地磁盘容量。将主机互连的物理网络资源对于IaaS而言是未知的。

因此，出现了本领域中的现有措施几乎完全缺少处理物理联网资源的支持的问题（并且其中没有一个支持具有QoS保证的联网），并且将用于云中的应用程序部署的资源预留视为基本资源预留序列，其可导致失败（参见图5和图6）或资源利用率差。

图5呈现了其中由多个功能来控制资源且客户端必须单独地对其进行处理的现有技术架构。

图6呈现了现有技术措施，特别是其中客户端尝试逐个地预留资源的情形，其导致失败的尝试（和对其中客户端可尝试修改资源请求的二次尝试的需要）。特别地，图示出根据现有技术的分段资源预留（虽然资源可用，但向（一个或多个）客户端指示失败）。

特别地，即使数据中心网络作为基础云计算资源的一个是数据中心基础设施的一部分，并且在这方面应由IaaS来控制，但现有技术IaaS实现并不支持计算实例、即虚拟机（VM）之间的联网QoS要求（例如保证带宽、延迟）。

此外，IaaSAPI将基础设施资源（CPU、存储器、储存器、网络）呈现为只能逐个地预留的不同实体。然而，现实世界的应用程序要求基本资源（例如，VM、用于简单应用程序的IP地址和虚拟盘、用于更复杂的应用程序的多个VM、磁盘等的组合）的组合，因此逐个地预留这些组合资源的尝试在许多情况下可以导致失败以及几乎必然地导致可用资源利用率不好。

发明内容

本发明的各种示例性实施例旨在解决上述议题和/或问题和缺点的至少一部分。

在所附权利要求中阐述了本发明的示例性实施例的各种方面。

根据本发明的示例性方面，提供了一种方法，包括接收指定多个资源类型的资源组合的资源要求的请求，以及根据所述资源要求来控制来自基础设施资源池的基础设施资源的预留。

根据本发明的示例性方面，提供了一种方法，包括提供多个资源类型中的一种资源类型的来自基础设施资源池的基础设施资源的预留能力，以及预留基础设施资源。

根据本发明的示例性方面，提供了一种设备，包括接收装置（means），其被配置成接收指定多个资源类型的资源组合的资源要求的请求；以及控制装置，其被配置成根据所述资源要求来控制来自基础设施资源池的基础设施资源的预留。

根据本发明的示例性方面，提供了一种设备，包括提供装置，其被配置成提供多个资源类型中的一种资源类型的来自基础设施资源池的基础设施资源的预留能力；以及预留装置，其被配置成预留基础设施资源。

上述方面中的任何一个使得能够以增强的质量/性能要求进行复杂服务的高效部署，并且提供不仅用于处理、而且用于类似于联网和存储之类的其它资源的更好的资源优化，以从而解决关于现有技术所识别的问题和缺点的至少一部分。

经由本发明的示例性实施例，提供了统一云资源控制。更具体地，经由本发明的示例性实施例，提供了用于实现统一云资源控制的措施和机制。

因此，用使得能够实现/实现统一云资源控制的方法、设备和计算机程序产品实现了改善。

附图说明

下面，将参考附图以非限制性示例的方式更详细地描述本发明，在所述附图中：

图1是图示出根据本发明的示例性实施例的设备的框图，

图2是图示出根据本发明的示例性实施例的设备的框图，

图3是根据本发明的示例性实施例的程序的示意图，

图4是根据本发明的示例性实施例的程序的示意图，

图5是图示出根据现有技术的架构的示意图，

图6示出了根据现有技术的信号序列的示意图，

图7是图示出根据本发明的示例性实施例的架构的示意图，

图8示出了根据本发明的示例性实施例的信号序列的示意图，

图9示出了根据本发明的示例性实施例的信号序列的示意图，

图10示出了根据本发明的示例性实施例的信号序列的示意图，以及

图11示出了根据本发明的示例性实施例的信号序列的示意图。

具体实施方式

在本文中参考特定非限制性示例和目前被视为本发明的可设想实施例的内容来描述本发明。本领域的技术人员将认识到本发明绝不局限于这些示例，并且可以被更宽泛地应用。

应注意的是本发明及其实施例的以下描述主要参考被用作用于某些示例性配置和部署的非限制性示例的规范。即，主要地相对于云计算情形来描述本发明及其实施例，该云计算情形包括例如被用作用于某些示例性云计算配置和部署的非限制性示例的客户端、基础设施即服务（IaaS）和网络即服务（NaaS）。同样地，在本文中给出的示例性实施例的描述具体地参考与之直接相关的术语。此类术语仅在提出的非限制性示例的背景下使用，并且当然不以任何方式限制本发明。相反地，还可利用任何其它云计算配置和部署等，只要符合本文所述的特征即可。

在下文中，使用多个变体和/或替换来描述本发明的各种实施例和实施方式及其各方面或实施例。一般地应注意的是根据某些需要和约束，可单独地或以任何可设想组合的方式（也包括各种变体和/或替换的单独特征的组合）提供所有所述变体和/或替换。

根据本发明的示例性实施例，一般而言，提供了用于（使得能够实现/实现）统一云资源控制的措施和机制。

上述问题（即，由根据现有技术客户端尝试逐个地预留资源且IaaS实现不支持联网QoS要求而引起的那些）是彼此相关的。即，只要云基于“尽力而为”来提供资源，要按序列预留一组资源就不太可能失败。特别地，云的计算和存储能力通常是充足的，网络容量是典型的瓶颈，但是由于不存在网络QoS承诺，所以预留仍是成功的。

然而，一旦引入的资源质量属性（例如网络QoS），则瓶颈资源可影响组合预留，并且如果资源预留算法并未考虑可用资源的组合拓扑，则资源利用将质量差。

因此，根据本发明的示例性实施例，将用于云中的应用程序部署的资源预留视为单个任务。

在本说明书中，云意指跨越一个或多个数据中心和服务器的资源池（计算、存储、联网、应用程序、操作系统或其它）。云使得用户能够基于需要来访问这些资源。

此外，数据中心意指具有旨在为客户供应基础设施的内部网的服务器场。数据中心的管理和监督是集中式的，并且对客户是隐藏的。

在本说明书中，为了说明的简单起见，假设云是单个数据中心，因此可互换地使用该术语。然而，本发明可延伸至云扩展多个数据中心时的情况。也就是说，在本文档中使用术语云时，根据本发明的示例性实施例，这可意指数据中心（的资源）以及几个数据中心（的资源）。

此外，IaaS控制器意指提供对计算和关联存储资源的控制的功能。其可以是没有或具有很少修改的现有私用云实现。在本发明报告中提出的修改提供与提出的架构新部件的更好的交互。

此外，NaaS控制器意指提供对数据中心网络的控制的功能。即使数据中心网络是数据中心基础设施的一部分，在现有实施方式中也将此功能分离（如果完全存在的话）。

根据本发明的示例性实施例，提出了用于云的扩展架构以使得能够以增强的质量/性能要求来实现复杂服务的部署，并且不仅针对处理、而且针对类似于联网和存储的其它资源提供更好的资源利用率。

特别地，根据本发明的示例性实施例，此扩展的关键部分是新功能，即统一云资源控制器（UCC），其提供朝向客户端的扩展IaaS接口以使得能够经由扩展IaaSAPI来实现资源分配请求（参见图7）。扩展IaaSAPI允许在单个请求中预留所有的云基础设施资源（参见图8），并且实现保证云基础设施资源的良好利用率的预留（即，UCC消除了现有资源预留程序的分段）。

图7呈现了特别地关于统一IaaS接口的UCC功能的提议扩展架构。

图8呈现了其中由满足所有资源要求并在单个步骤中分配所需资源（UCC可与传统资源控制器相交互，但未示出）的UCC（具有根据本发明的示例性实施例的高级UCC功能）来服务于客户端的情形。

为了确保用于扩展多个数据中心的云基础设施的概念的可缩放性和利用率，根据本发明的示例性实施例的集中制UCC在其自己的管理范围内控制资源预留，同时其能够与其它UCC对接。该管理范围可以从数据中心部分至多个数据中心进行缩放。

图1是图示出根据本发明的示例性实施例的设备的框图。该设备可以是包括接收装置11和控制装置12的UCC10。接收装置11接收指定多个资源类型的资源组合的资源要求的请求。控制装置12根据所述资源要求来控制来自基础设施资源池的基础设施资源的预留。图3是根据本发明的示例性实施例的程序的示意图。根据图1的设备可执行图3的方法，但不限于这种方法。图3的方法可由图1的设备执行，但不限于由此设备执行。

如图3中所示，根据本发明的示例性实施例的程序包括接收指定多个资源类型的一种资源组合的资源要求的请求的操作（S31），以及根据所述资源要求来控制来自基础设施资源池的基础设施资源的预留的操作（S32）。

此外，图2是图示出根据本发明的示例性实施例的设备的框图。该设备可以是诸如IaaS或NaaS之类的控制实体20，其包括提供装置21和预留装置22。提供装置21提供多个资源类型中的一种资源类型的来自基础设施资源池的基础设施资源的预留能力。预留装置22预留基础设施资源。图4是根据本发明的示例性实施例的程序的示意图。根据图2的设备可执行图4的方法，但不限于这种方法。图4的方法可由图2的设备执行，但不限于由此设备执行。

如图4中所示，根据本发明的示例性实施例的程序包括提供多个资源类型中的一种资源类型的来自基础设施资源池的基础设施资源的预留能力的操作（S41），以及预留基础设施资源的操作（S42）。

根据本发明的示例性实施例，UCC可完全负责资源分配。其实现了完全集中制资源分配逻辑，并且现有NaaS和IaaS控制器仅仅执行指令。

集中制控制具有提供更接近于数据中心中的资源的最佳使用的可能。例如，将不会发生节点（例如主机A）的大多数计算资源未使用、但该节点不能在任何后续部署中被使用、因为该节点（即主机A）的联网资源已被占用。

请注意，在本替换方案中（根据示例性实施例），UCC意识到所有受控资源的状态（VM放置约束：服务器可用性、存储器可用性等；联网约束：带宽可用性、网络延迟参数等），并且基于那些参数来进行部署决策以图实现最佳资源利用率。由于UCC在这种情况下是相当复杂的功能，所以单个UCC的使用对于大规模云而言可能不是可行的解决方案。

因此，根据图3中所示的程序的变体，给出了控制操作的示例性细节，其固有地同样相互独立。

根据本发明的示例性实施例的此类示例性控制操作可包括基于所述基础设施资源池的每个基础设施资源的状态来判定要预留的基础设施资源的操作以及发射用以预留所述要预留的基础设施资源的指令的操作。

此外，根据本发明的示例性实施例，所述状态可以是服务器可用性、存储器可用性、带宽可用性以及网络延迟参数中的至少一个。

此外，根据图4中所示的程序的变体，给出了示例性附加操作，其固有地同样相互独立。根据此类变体，根据本发明的示例性实施例的示例性方法可包括接收用以预留所述要预留的基础设施资源的指令的操作。

根据本发明的示例性实施例，可以实现UCC与现有IaaS和NaaS控制器实现之间的子任务的分布。

即，根据本发明的示例性实施例，UCC可以是协调不同资源类型的控制器（例如，用于联网的NaaS、用于计算和存储的IaaS）的实体，亦即，将资源分配逻辑分布在UCC与每个特定资源类型的控制器之间（假设传统实施方式是可用且可扩展的）。

也就是说，根据图3中所示的程序的变体，给出了控制操作的示例性细节，其固有地同样相互独立。

根据本发明的示例性实施例的此类示例性控制操作可包括协调分别地与所述多个资源类型中的每一个相关联的控制实体的操作。

例如可如下扩展根据本发明的此类示例性实施例的UCC与特定资源控制器之间的接口。直接地在资源控制器之间或者经由UCC交换资源映射信息。

根据本发明的示例性实施例，资源预留的分段和因此要预留资源的所需步骤的数目被最小化，以资源控制器可以在一个“原子”操作中接受包含相同类型的一组资源的预留请求的方式来扩展UCC—IaaS接口。这种解决方案可能由于分多个步骤进行预留而仍要求对撤消预留的需要，但大大地减少了步骤的数目和因此的试错型操作的机会。根据此类实施例，UCC并不控制资源分配逻辑，其协调资源预留，并且在必要时协调试错操作模式，因此IaaS接口的用户不需要处理此类操作（参见图9）。图9呈现了其中UCC将朝向特定资源控制器的资源请求分组并在必要时协调后续资源预留试验的情形。在图9中，VM1x、VM2x和VM3x指示已修改参数，并且VM1*、VM2*和VM3*指示已修改映射。

换言之，根据图3中所示的程序的变体，给出了协调操作的示例性细节，其固有地同样相互独立。

根据本发明的示例性实施例的此类示例性协调操作可包括发射包含第一资源类型的一组资源要求的第一资源请求的操作。

根据图3中所示的程序的另一变体，给出了协调操作的示例性细节，其固有地同样相互独立。

根据本发明的示例性实施例的此类示例性协调操作包括发射包含基于所述第一资源请求而预留的所述第一类型的资源以及第二资源类型的资源要求的第二资源请求的操作、接收指示所述第二资源请求的接受或不接受的响应的操作以及在不接受的情况下撤消所述第一资源类型的所述资源的预留的操作。

此外，根据图4中所示的程序的变体，给出了示例性附加操作，其固有地同样相互独立。根据此类变体，根据本发明的示例性实施例的示例性方法可包括接收包含所述资源类型的一组资源要求的资源请求的操作。

替换地，根据本发明的其它示例性实施例，在两步解决方案中，将每个资源类型（即IaaS、NaaS）的控制器扩展至提出多个映射解决方案（并未预留实际资源）作为第一步骤，基于该映射提议，UCC确定最终资源映射，并向资源控制器发送回该选择，资源控制器仅在那时完成资源预留（参见图10）。图10呈现了其中将现有IaaS（NaaS）接口扩展至返回一组候选（即，可以满足所请求计算要求的一组资源）并基于提出的资源和联网要求而做出资源的最终选择的情形。在图10中，“联网候选”表示满足所请求联网参数的一组映射提议。

换言之，根据图3中所示的程序的变体，给出了协调操作的示例性细节，其固有地同样相互独立。

根据本发明的示例性实施例的此类示例性协调操作可包括根据所述资源要求来接收资源预留提议的操作、基于所述资源预留提议来确定要预留的基础设施资源的操作以及发射用以预留所述要预留的基础设施资源的指令的操作。

此外，根据图4中所示的程序的变体，给出了示例性附加操作，其固有地同样相互独立。根据此类变体，根据本发明的示例性实施例的示例性方法可包括接收包含资源要求的资源请求的操作、基于所述资源要求来发射资源预留提议的操作以及接收用以预留基于所述资源预留提议确定的所述要预留的基础设施资源的指令的操作。

替换地，根据本发明的其它示例性实施例，在替换两步解决方案中，将每个资源类型（例如IaaS、NaaS）的控制器都扩展至提出多个资源映射（而不预留实际资源），并接受资源预留请求中的资源限制提议。其允许UCC连续地调用每个资源控制器，并且在后续请求中，UCC可基于先前的资源映射提议来设定限制。其还允许最后被调用的资源控制器可实现资源预留（UCC可以指示且UCC可以按照适当的顺序调用特定资源控制器，因此最后一个不需要实现资源映射提议功能，而只须接受关于资源预留的附加限制）。由于来自特定资源控制器的资源映射提议可用，所以UCC（以及可选地最后被调用的资源控制器）实现映射，并且UCC告知（一个或多个）其它资源控制器关于实现的资源映射的信息，并且其又在那时完成资源预留（参见图11）。图11呈现了其中现有IaaS（NaaS）接口被扩展至（i）返回一组候选（即，可以满足所请求计算要求的一组资源）、（ii）接受关于映射的附加限制以及（iii）在指示的情况下执行映射的情形。在图11中，“Req*”表示控制器可执行资源映射的指示，在这种情况下不需要发送映射候选。

换言之，根据图3中所示的程序的变体，给出了协调操作的示例性细节，其固有地同样相互独立。

根据本发明的示例性实施例的此类示例性协调操作可包括根据所述资源要求而连续地接收资源预留提议的操作、基于先前的资源预留提议而设定用于资源请求的资源限制的操作，以及发射包括所述资源限制的资源请求的操作。

此外，根据图4中所示的程序的变体，给出了示例性附加操作，其固有地同样相互独立。根据此类变体，根据本发明的示例性实施例的示例性方法可包括接收包含资源要求和资源限制的资源请求的操作，其中，基于所述资源限制来执行所述预留所述基础设施资源。

如上文所讨论的，根据本发明的示例性实施例提出的架构解决方案克服了上文识别的问题，并提供用于电信级云的可行解决方案。

提出的IaaSAPI接受复杂资源请求的扩展可以被检测到，并且是使用本发明的明确征兆（假设此扩展IaaSAPI将明确地证明该扩展）。

如果数据中心为托管应用程序提供了关于联网的QoS保证，则其可以是使用了本发明的指示符。

NaaS和/或IaaS提供关于可用和已分配资源的详细信息并允许控制所请求资源将被分配在哪里也可以是使用了本发明的指示符。

根据本发明的示例性实施例，UCC可以充当用于（电信级）云的IaaS，可能在现有（且扩展的）IaaS实现之上。此外，可以实现数据中心的更好且更加高效的资源管理、更低的运营支出（OPEX）和基建支出（CAPEX）金额。

可用各功能元件、处理器等来实现上述程序和功能。

在实体的前述示例性描述中，仅使用功能块描述了与理解本发明的原理有关的单元。该实体可包括其各自操作所必需的其它单元。然而，在本说明书中省略了这些单元的描述。不应将设备的功能块的布置理解成限制本发明，并且该功能可由一个块执行或者进一步分成子块。

当在前述描述中说明设备、即实体（或某个其它装置）被配置成执行某功能时，应将这样的功能理解成可由用于执行各功能的具体配置电路或装置等价地实现（即，应将措辞“被配置成...的单元”理解成将等价于诸如“用于...的装置”的措辞）。

一般而言，各装置（device）/设备（和/或其各部分）可表示用于执行各操作和/或显示出各功能的装置，和/或各装置（和/或其各部分）可具有用于执行各操作和/或显示出各功能的功能。

一般地，应注意的是可分别地用任何已知装置来实现根据上述方面的各功能块或元件，用硬件和/或软件，如果其仅适合于执行各部分的所述功能的话。可以用单独功能块或用单独装置来实现所述方法，或者可以在单个功能块中或由单个器件来实现方法步骤中的一个或多个。

本发明还涵盖上述方法步骤和操作的任何可设想组合以及上述节点、设备、模块或元件的任何可设想组合，只要可应用方法和结构布置的上述概念即可。

鉴于上述内容，提供了用于统一云资源控制的措施。此类措施示例性地包括接收指定多个资源类型的资源组合的资源要求的请求，并根据所述资源要求来控制来自基础设施资源池的基础设施资源的预留。

即使上文参考根据附图的示例来描述本发明，应理解的是本发明不限于此。相反地，对于本领域的技术人员而言将显而易见的是在不脱离如在本文中公开的发明思想的范围的情况下可以以许多方式修改本发明。

缩写词和简写词列表

API应用编程接口

CAPEX基建支出

CPU中央处理单元

IaaS基础设施即服务

ID标识符

IEEE电气和电子工程师协会

IP网际协议

NaaS网络即服务

OPEX运营支出

OVF开放虚拟化格式

PaaS平台即服务

QoS服务质量

SW软件

UCC统一云资源控制器

VLAN虚拟局域网

VM虚拟机。

Claims (26)

1.一种方法，包括

接收指定多个资源类型的资源组合的资源要求的请求，以及

根据所述资源要求来控制来自基础设施资源池的基础设施资源的预留。

2.根据权利要求1所述的方法，其中

关于所述控制，所述方法还包括

基于所述基础设施资源池的每个基础设施资源的状态来判定要预留的基础设施资源，以及

发射用以预留所述要预留的基础设施资源的指令。

3.根据权利要求2所述的方法，其中

所述状态是服务器可用性、存储器可用性、带宽可用性以及网络延迟参数中的至少一个。

4.根据权利要求1所述的方法，其中

关于所述控制，所述方法还包括

协调分别地与所述多个资源类型中的每一个相关联的控制实体。

5.根据权利要求4所述的方法，其中

关于所述协调，所述方法还包括

发射包含第一资源类型的一组资源要求的第一资源请求。

6.根据权利要求5所述的方法，其中

关于所述协调，所述方法还包括

发射第二资源请求，其包含

　　基于所述第一资源请求预留的所述第一资源类型的资源，以及

　　第二资源类型的资源要求，

接收指示所述第二资源请求的接受或不接受的响应，以及

在不接受的情况下撤消所述第一资源类型的所述资源的预留。

7.根据权利要求4所述的方法，其中

关于所述协调，所述方法还包括

根据所述资源要求来接收资源预留提议，

基于所述资源预留提议来确定要预留的基础设施资源，以及

发射用以预留所述要预留的基础设施资源的指令。

8.根据权利要求4所述的方法，其中

关于所述协调，所述方法还包括

根据所述资源要求来连续地接收资源预留提议，

基于先前的资源预留提议来设定用于资源请求的资源限制，以及

发射包括所述资源限制的资源请求。

9.一种方法，包括

提供多个资源类型中的一种资源类型的来自基础设施资源池的基础设施资源的预留能力，以及

预留基础设施资源。

10.根据权利要求9所述的方法，还包括，

接收用以预留所述要预留的基础设施资源的指令。

11.根据权利要求9所述的方法，还包括，

接收包含所述资源类型的一组资源要求的资源请求。

12.根据权利要求9所述的方法，还包括，

接收包含资源要求的资源请求，

基于所述资源要求来发射资源预留提议，以及

基于所述资源预留提议来接收用以预留所述要预留的基础设施资源的指令。

13.根据权利要求9所述的方法，还包括，

接收包含资源要求和资源限制的资源请求，其中

基于所述资源限制来执行所述预留所述基础设施资源。

14.一种设备，包括

接收装置，被配置成接收指定多个资源类型的资源组合的资源要求的请求；以及

控制装置，被配置成根据所述资源要求来控制来自基础设施资源池的基础设施资源的预留。

15.根据权利要求14所述的设备，还包括：

判定装置，被配置成基于所述基础设施资源池的每个基础设施资源的状态来判定要预留的基础设施资源，以及

发射装置，被配置成发射用以预留所述要预留的基础设施资源的指令。

16.根据权利要求15所述的设备，其中

所述状态是服务器可用性、存储器可用性、带宽可用性以及网络延迟参数中的至少一个。

17.根据权利要求14所述的设备，还包括：

协调装置，被配置成协调分别地与所述多个资源类型中的每一个相关联的控制实体。

18.根据权利要求17所述的设备，还包括：

发射装置，被配置成发射包含第一资源类型的一组资源要求的第一资源请求。

19.根据权利要求18所述的设备，其中

所述发射装置还被配置成发射第二资源请求，其包含

　　基于所述第一资源请求预留的所述第一类型的资源，以及

　　第二资源类型的资源要求，

所述接收装置还被配置成接收指示所述第二资源请求的接受或不接受的响应，并且所述装置还包括

撤消装置，被配置成在不接受的情况下撤消所述第一资源类型的所述资源的预留。

20.根据权利要求17所述的设备，其中

所述接收装置还被配置成根据所述资源要求而接收资源预留提议，所述设备还包括

确定装置，被配置成基于所述资源预留提议来确定要预留的基础设施资源，以及

发射装置，被配置成发射用以预留所述要预留的基础设施资源的指令。

21.根据权利要求17所述的设备，其中

所述接收装置还被配置成根据所述资源要求而连续地接收资源预留提议，所述设备还包括

设定装置，被配置成基于先前的资源预留提议来设定用于资源请求的资源限制，以及

发射装置，被配置成发射包括所述资源限制的资源请求。

22.一种设备，包括

提供装置，其被配置成提供多个资源类型中的一种资源类型的来自基础设施资源池的基础设施资源的预留能力；以及

预留装置，其被配置成预留基础设施资源。

23.根据权利要求22所述的设备，还包括：

接收装置，被配置成接收用以预留所述要预留的基础设施资源的指令。

24.根据权利要求22所述的设备，还包括：

接收装置，被配置成接收包含所述资源类型的一组资源要求的资源请求。

25.根据权利要求22所述的设备，还包括：

接收装置，被配置成接收包含资源要求的资源请求，以及

发射装置，被配置成基于所述资源要求来发射资源预留提议，其中

所述接收装置还被配置成接收用以基于所述资源预留提议来预留所述要预留的基础设施资源的指令。

26.根据权利要求22所述的设备，还包括：

接收装置，被配置成接收包含资源要求和资源限制的资源请求，其中

所述预留装置被配置成基于所述资源限制来预留所述基础设施资源。