选择资源分配策略和解决资源冲突

技术领域

本发明涉及云计算基础架构，更特别地，涉及用于使用并行调度器的在云计算基础架构中的工作负载管理的技术，以及用于冲突解决的自动资源分配和策略选择器。

背景技术

云计算基础架构已经促使了在相同服务器中的混合工作负载的执行，从而促进更好的资源利用和效率。然而，在相同集群中适应异构工作负载、例如何时安排、放置在哪里、以及如何分配它们的资源仍然是挑战。此外，一些工作负载增加了对它们的资源使用的需求，使该问题甚至更难以解决。

集群管理的目前的解决方案可以被分为三个主要的调度器体系架构：(1)单片(monolithic)、(2)两级和(3)共享状态。单片调度器对所有工作只使用单一的集中调度算法，诸如高性能计算(HPC)调度器。两级调度器由单个活跃资源管理器组成，该单个活跃资源管理器将资源提供给接受或拒绝资源的多个并行、独立的调度器框架。参见，例如，Hindman等，“Mesos:A Platform for Fine-Grained Resource Sharing in the Data Center”，网络化系统设计与实现方式(NSDI'11)第8届USENIX会议论文集，第295-308页(2011年3/4月)。共享状态体系架构由并发访问作为交易的集群资源的多个并行的调度器组成。参见，例如，M.Schwarzkopf等，"Omega:flexible，scalable schedulers for large compute clusters"，计算机系统(EuroSys'13)第8届ACM欧洲会议论文集，第351-364页(2013年4月)(以下简称"Schwarzkopf")。在这些调度器体系架构之间有显著的权衡。例如，单片调度器具有集群的全面控制并且可能计划最佳全局布局，但难以通过添加新的策略和专门的实现方式来多样化，并不会随集群大小而缩放。通过提供调度器并行，两级调度器比单片调度器更灵活，但它们减少了资源能见度，并基于更加难以执行的集群资源的整体视图做出决定(诸如为工作负载计划局部布局，或基于性能、能效和安全性执行工作负载迁移)。而且，当资源被预先分配用于调度器时，未使用的资源被浪费。共享状态具有群集资源的全局视图以做出所有的整体决定并且是可扩展的。然而，共享状态调度器对资源竞赛是非常敏感的，也不可能对一些工作负载保证资源分配。

目前，已知没有技术能结合先前的体系架构的所有优点并减轻上述缺点。在目前的方式中，调度器具有所有预分配的资源，诸如在单片和两级方式中，或者它们诸如在共享状态的方式中仅竞争资源。

此外，复杂的调度器引起诸如可扩展性、可维护性和灵活的适应性等问题。为了解决这个问题，共享状态的方式(参见，例如，Schwarzkopf)将复杂的调度器分成许多较小的调度器，而不是只具有带有所有工作负载的逻辑的一个单片调度器。一方面，这个共享状态的方式通过为所有工作负载部署提供集群的全局视图可能有益于执行最佳全局部署。也可能通过并行响应工作负载来增加可扩展性并且可能减少响应时间(由于减少的复杂性)。另一方面，如果多个调度器试图同时要求相同的资源，将只有一个是成功的，其他将必须再次重启调度过程。因此，如果冲突发生太频繁，则调度时间和响应时间将增加。

某些技术将工作负载分类，检测冲突，或者选择一般策略。分别参见，例如，J.Bobba等，“Performance Pathologies in Hardware Transactional Memory”，计算机体系架构第34届国际研讨会论文集(ISCA'07)，第81-91页(2007年6月)；M.F.Spear等，“Conflict Detection and Validation Strategies for Software Transactional Memory”，分布式计算第20届国际会议论文集(DISC'06)，第179-193页(2006年)；以及C.Delimitrou等，“Paragon:QoS-Aware Scheduling for Heterogeneous Datacenters”，编程语言和操作系统的体系架构支持(ASPLOS)第18届国际会议论文集(2013年3月)。然而，目前不存在基于基础架构状态共同考虑到所有的这些因素以改进和自动化工作负载冲突解决的解决方案。而且，目前的解决方案不考虑从共享状态集群中的工作负载冲突(诸如，应用程序干扰、服务器超载等)产生的特定能力。

此外，用于冲突检测和策略选择的大多数目前的解决方案使用需要用于预测的大数据集的线性编程，或依赖于用于测试阶段的庞大数量的数据的机器学习，这两者都不是实际用于现实世界的应用。另外，大多数目前的冲突检测和策略选择技术具有缺失项而表现不好。在这方面，一些方式存在用于分类和对数似然函数的矩阵分解的结合算法，以填充缺失项的预测。然而，这些方式不选择基于用于中央处理单元(CPU)、存储器、网络、磁盘的资源使用密集型的工作负载分类的冲突解决策略；工作负载执行时间；以及可能的不确定性和确定性冲突的检测。

因此，期望用于数据中心集群工作负载管理的改进的技术，包括用于冲突检测和策略选择的改进的技术。

发明内容

本发明提供了用于在云计算基础架构中的工作负载管理的技术。在发明的一个方面，提供了一种在数据中心集群中分配计算资源的方法。所述方法包括以下步骤：基于工作负载概要、用户要求和所述数据中心集群的状态中的一个或多个为每个调度器自动选择资源分配方法，其中为至少第一一个或多个调度器选择乐观资源分配方法，且为至少第二一个或多个调度器选择悲观资源分配方法。

在发明的另一个方面，提供了另一种在数据中心集群中分配计算资源的方法。所述方法包括以下步骤：创建多个并行的调度器；基于工作负载概要、用户要求和所述数据中心集群的状态中的一个或多个为每个调度器自动选择资源分配方法，其中为至少第一一个或多个调度器选择乐观资源分配方法，且为至少第二一个或多个调度器选择悲观资源分配方法；接收新的工作负载；将所述新的工作负载分类；基于所述新的工作负载的分类，确定i)是否将所述新的工作负载分配到现有的一个调度器或者ii)是否创建一个或多个新的调度器并且将所述新的工作负载分配到所述一个或多个新的调度器；识别调度器决定中的冲突；以及选择用于冲突的解决策略。

本发明的更加完整的理解以及本发明的进一步的特征和优点将通过参照下面的详细描述和附图来获得。

附图说明

图1是示出了根据本发明的实施例的使用自动资源分配选择器在数据中心集群中分配计算资源的示例性方法的示意图；

图2是示出了根据本发明的实施例的自动资源分配选择器的示例性实现方式的图；

图3是示出了根据本发明的实施例的用于调度器的可能的资源分配类型的图；

图4A是示出了根据本发明的实施例的对于给定的工作负载类型如何通过降低调度器的数目来增加服务质量(QoS)的图；

图4B是示出了根据本发明的实施例的对于给定的工作负载类型如何通过增加调度器的数目来增加数据中心效率的图；

图5是示出了根据本发明的实施例的用于乐观并行工作负载部署的自动选择冲突解决策略的示例性方法的图；以及

图6是示出了根据本发明的实施例用于执行本文所提出的一个或多个方法的示例性装置的图。

具体实施方式

本文提供的是用于基于工作负载概要、用户要求和数据中心的状态的并行调度器的自动选择乐观或悲观资源分配方法的技术(即，本技术可以用于管理多个数据中心的状态)。更具体地，本技术保证悲观充分资源预分配、半悲观局部资源预分配或乐观非资源预分配，其中预分配意味着封锁资源(即，保持资源以便能够将资源分配给工作负载)。可以在提交时，竞争未在分配阶段预先分配(即，由于乐观资源分配)的资源，因为具有可能在彼此之间竞争相同的资源的并行调度器。资源竞争——一旦被识别——可能基于用于解决可能出现的冲突的本文提供的策略和技术来解决。可选地，用户可以基于数据中心的表现或状态从乐观切换到半悲观或悲观资源分配。此外，本技术通过不具有所有的调度器预分配来改进资源利用率(并从而避免封锁空闲资源)。本技术可以延伸到多个/混合的云资源计算分配。

基于并行调度器的实现方式，本技术可以利用单片、两级和共享状态调度器体系架构的好处而不遭受上述的缺点。更具体地，本发明依赖于可能具有在悲观方式中预分配所有资源的调度器的混合方法；在半悲观方式中预分配资源的一部分的调度器；和/或在乐观方式中在彼此之间共享资源的调度器。预分配意味着资源的预留。根据工作负载的概要、用户的要求和/或数据中心的状态，调度器资源分配类型可以互换。选择一个或另一个调度器资源分配类型的决定可能依赖于将提供多少资源分配保证和调度器可扩展性(基于，例如，调度器能够考虑不同要求并满足那些要求的灵活性)。基于工作负载的概要的决定将确保为某类工作负载的资源分配。根据服务等级协议(SLA)，基于用户的要求的决定将确保资源分配。基于数据中心状态的决定将在资源短缺期间减轻调度器竞争问题。此外，本技术通过不允许所有的调度器预分配资源(将从而减少空闲资源的封锁)来改进资源利用率。

仅通过示例的方式，本教导的一些显著的优点包括：1)通过资源的悲观完全预分配、资源的半悲观部分预分配、或资源的乐观非预分配来自动创建调度器实例；2)基于工作负载概要、用户要求和数据中心/集群状态，适应地选择资源分配类型；3)基于i)用户的决定(手动地或自动地-即，如用户请求中说明的)和/或ii)数据中心状态的变化，从乐观到半悲观或悲观资源分配动态地切换；以及4)用相同的逻辑扩展到多个云/混合。

因此，根据本技术，通过使用多个并行调度器可以获得数据中心可扩展性。对于给定组的调度器，保证的资源分配是可能的。为调度器手动或自动选择悲观、半悲观或乐观资源分配是可能的。此外，由于调度器保持空闲资源，因此资源浪费最小化。相比之下，用于集群资源分配的常规的解决方案仅为调度器预分配所有资源或不为调度器分配任何资源。而且，没有预分配资源的调度器不能保证资源分配。最后，没有办法为调度器从悲观资源分配切换到半悲观或乐观资源分配。

现在提供本技术的详细描述。如上所强调的，本资源分配技术依赖于由在悲观、半悲观和乐观资源分配方式中的(多个并行)调度器组成的混合方法。悲观方式预分配所有资源以便于保证部署。半悲观方式仅预分配部分资源从而确保仅有一部分的资源的可用性。乐观方式没有预分配资源并且仅在交易提交时分配资源。可能通过分析工作负载分类、用户SLA和/或数据中心状态来决定何时在这些方式之间选择。仅通过示例的方式，一方面一些工作负载或用户可能具有优先权，并且对于那些工作负载/用户，调度器将优选地总是预分配资源。通过优先权意味着，例如一些(高优先权)工作负载对延迟可能具有较少的容忍，并因此可能被要求在与高优先权工作负载同时到达或比高优先权工作负载更快到达的其他更低优先权工作负载之前放置。另一方面，资源预分配过程可能引入延时，且乐观并行方式可能具有更快的分配，导致一些冲突。根据用户和工作负载目标以及基于资源充裕或短缺的数据中心状态，预分配、部分预分配和后分配可以互换。如上所强调的，预分配包含在完成布局之前预留资源，因此保证将那些资源递给请求。在后分配中，调度器采用的资源不能保证——意味着当调度器在做决定时它们可能被其他请求占用。

图1的方法100为包含一个数据中心云的示例性实施例提供本技术的高级概述。在步骤102中提供用户输入。根据示例性实施例，在步骤102中，用户可以提供关于用户要求(诸如服务质量(QoS))、工作负载概要(例如，工作负载类型、什么工作负载应该得到优先权等)的输入。根据本技术，可以采用用于评估工作负载性能的本领域已知的任何合适的QoS指标(metrics)(即，由用户看到的)。

将用户输入数据提供给自动资源分配选择器。如上所提供的，本资源分配技术还考虑数据中心的状态。因此，在步骤104中，还将数据中心效率监测数据提供给自动资源分配选择器。数据中心效率监测收集关于数据中心的状态的数据，诸如CPU利用率、存储器利用率等等。可以经由数据中心效率监控器来完成该监测。数据中心效率监控器可以将这些指标传到调度决定发生之处的资源分配类型选择器。参见例如如下描述的图2中的数据中心效率监控器218和资源分配类型选择器206。评估该数据的一个方式为资源管理者分配关于利用率级别的情况以采取行动。例如，如果CPU利用率低于x％，则调度器可能执行更多的乐观调度，以便于以更快的方式将更多的请求分配给资源。

在步骤106中，资源分配类型选择器自动决定调度器的数目和它们的设置。具体地，根据示例性实施例，资源分配类型选择器(基于从步骤102和步骤104收集的数据)为(多个并行)调度器的每个自动选择(乐观、悲观或半悲观)资源分配方法。

图2是根据示例性实施例示出了自动资源分配选择器如何操作的逻辑流程图。如图2所示，工作负载分类器204将新的工作负载202分类。如上所述，本资源分配过程考虑用户输入201(以及数据中心的状态——例如，由数据中心效率监测来确定的)。基于来自工作负载分类器204的工作负载分类，资源分配类型选择器206确定调度器的数目和它们的设置。这包含决定是否需要添加新的调度器和/或需要移除现有的调度器、以及使用哪个资源分配模型。为了这个目的，可能实现的示例性功能模型和基于规则的机制如下所述。为了解决这个问题的另一种方式可以通过使用机器学习算法，用于选择资源分配类型。

因此，之后，资源经由悲观资源分配器208、半悲观资源分配器210和乐观资源分配器212被分配到调度器。具有预分配资源的调度器(即具有悲观资源分配类型的调度器)将没有冲突，并因此没有问题以提交决定。另一方面，没有预分配资源或预分配资源的至少部分的调度器(即分别具有乐观或半悲观资源分配类型的调度器)将捕获目前可用的资源的快照并基于快照来计划决定。做出决定后，调度器将(即，经由资源分配尝试器214)试图提交遭受在其他并发调度器之间竞争情况的决定。如图2所示，这可能导致冲突。如果(即，经由冲突识别器216)识别冲突，该冲突和其特性被存储在数据中心状态中，以便于(即，经由数据中心效率监测器218)监测数据中心的效率。如上所提供的，数据中心效率监测器收集关于数据中心的状态的数据，诸如CPU利用率、存储器利用率等等——该数据传递到调度决定发生之处的资源分配类型选择器。

图3是示出了用于调度器(S1、Si...Sn)的可能的资源分配类型的图。在图3，做出以下假设：

-R是所有数据中心资源的集合；

-A_i是调度器i的预分配资源，其中i表示0到n个调度器；

-B_i是调度器i的后分配资源，其中i表示0到n个调度器；

-∩ⁿ_i＝1A_i＝0；

-

-Uⁿ_i＝1以及

-Uⁿ_i＝1

如果数据中心集群具有单片调度器，则i＝1且A_i＝B_i＝R。如果数据中心集群具有多个调度器，所有的调度器具有所有的预分配资源(悲观)，则Uⁿ_i＝1，A_i＝R且B_i＝A_i。如果调度器仅具有预分配资源的部分(半悲观)，则A_i<B_i。最后，如果调度器不具有预分配资源(乐观)，则A_i＝0。当创建调度器时，根据工作负载的概要、用户要求和数据中心集群状态来定义A_i和B_i。然而，A_i和B_i的大小还可以基于来自数据中心集群的用户决定或反馈(例如，关于数据中心效率)来改变。如果A_i改变，调度器将具有或多或少的预分配资源，如果B_i改变，调度器将或多或少竞争资源。

如上所强调的，用户的要求可能涉及基于用于本领域中已知的工作负载性能的任何标准QoS指标的指标。仅通过示例的方式，参见由Zhu等、题为“Performance Interference Model for Managing Consolidated Workloads in Qos-Aware Clouds”的美国专利申请公开号2015/0012634(其描述了合适的基于时间的QoS指标)。用户的要求可能还涉及基于取消调度器的决定的数目的指标、调度器的实际吞吐量(即，吞吐量——诸如每单位时间递送到目的地的信息比特数的数目)、部署工作负载的时间、调度器的数目等。工作负载概要将描述这些指标加上基于：优先权、要求的保证的资源的数量、灵活的资源分配的数量(部分工作负载可能去往另一个)等的更具体的指标。数据中心状态指标涉及：取消的调度器的决定的数目、可用的资源、资源使用与资源预分配的数目等。调度器的数目是控制实际吞吐量的一种方式——调度器越多、一次(吞吐量)处理的请求越多，尽管冲突可能引起一些请求失败从而实际吞吐量可能下降。一些用户可能指示他们想要云供应商使用的调度器的数目，以便于增加吞吐量。

所有的这些指标用于(例如，通过资源分配类型选择器206——参见图2)决定由悲观、半悲观或乐观资源分配组成的调度器。此外，指标用于通过建立新的并行调度器来定义可扩展性级别。那些决定基于在调度器可扩展性、调度器性能、调度器保证的资源分配和集群资源使用之间的权衡。更具体地，可扩展性涉及具有更多的并行调度器。调度器性能依赖于调度器响应时间、取消的决定和资源的全局视图以更好地计划部署。调度器保证的资源分配直接涉及数据中心资源使用。即，调度器通过在预分配池中使用很少的资源可能浪费资源，这阻碍了最佳集群利用率。因为一些调度器浪费资源，集群可能无法扩展到需求。共享资源可能解决这个问题，但是包括上述的资源竞争问题。因此，通过这些权衡，将定义调度器资源分配类型。仅通过示例的方式，给定了这些权衡，可以使用功能模型确定乐观的解决方案。使用功能模型确定的示例性乐观的解决方案给出如下。

如上所述，功能模型和/或基于规则的机制可能用于决定是否需要添加新的调度器和/或需要移除现有的调度器、以及使用哪个资源分配模型。现在描述示例性功能模型和基于规则的机制。

功能模型：本质上，用户通过查看系统状态将带来一组要求以及工作负载特性。本技术将决定n、B和A的大小。

用户参数(QoS、工作负载等)->要求

QoS(期望的拒绝率、冲突率等)

工作负载(#的虚拟机(vms)、约束、需求等)

数据中心参数(数据中心位置(ID)、空闲的机器速度、冲突的数量)

资源分配参数(A、B、n)

F(用户、数据中心、资源分配参数)＝主要目标

主要目标＝权重1*用户目标(obj)+权重2*数据中心目标(obj)

用户obj(目标)＝归一化(定义的SLA、QoS等)

数据中心obj＝归一化(高的机器利用率等)

对于给定的主要目标值，用户参数、数据中心参数和期望的资源分配参数可以从F函数中导出。

示例：用户可能指定QoS具有少于10％的冲突，并且具有大量交易的存储强大的工作负载。数据中心可以处于在共享状态A＝B中有3个并行调度器的状态中，因此我们具有A_i＝B_i，其中i＝1、2、3。例如说，当新的请求到来时，数据中心具有40％的空闲机器(vms)。

F(0.1、存储、高交易(high transaction)、0.4、(A_i＝B_i，n＝3))＝期望的目标值

用户目标＝1-冲突＝1-0.1＝0.9

数据中心目标＝无

期望的目标＝0.9，因此

F(0.1、存储、高交易、0.4、(A_i＝B_i，n＝？))＝0.9

此时对于(A_i＝B_i，n＝？)解出F并找到A_i、B_i和n的值。

因此，根据本技术，可以容易地确定A_i、B_i和n的值——并且用A、B和n的子集定义乐观、悲观和半悲观。基于规则的模型：这是更简单的模型，其中根据用户QoS、工作负载类型和数据中心状态定义规则。例如，如果用户在冲突率方面正经受低的QoS，可以降低调度器的数目并设置A＝B。如果数据中心正经受低的效率，则可以增加调度器的数目并设置A<B。图4A和4B描绘出每个工作负载类型的这些行为。

如上提供的，本主动资源分配选择器(即，经由工作负载分类器204——参见图2)将新的工作负载分类，在半悲观或乐观资源分配的情况下(即，经由冲突识别器216)为预分配资源识别冲突，以及制定冲突解决以解决冲突。现在描述的技术用于自动分类工作负载瓶颈，识别调度器的决定之间的冲突，并且选择策略以解决那些冲突。

工作负载分类、冲突识别和解决策略选择阶段考虑不同类型的冲突、工作负载特性和基础架构信息。根据本技术，所有的那些阶段配置为建议冲突解决策略，该冲突解决策略最满足用户的要求并减少调度器的取消的决定——从而改进实际吞吐量。本技术不仅为冲突解决策略选择提供过程，而且为从基础架构(诸如，取消的决定的数目、分配响应时间和工作负载服务质量(QoS))提取指标提供详细的方法，以反馈学习机制。此外，为了冲突解决，本文建议通过考虑工作负载迁移和资源放弃来行动——从而提供很多更加可能的策略。

为了执行每个(分类、识别和策略选择)阶段，本技术采用基于存储器的和/或基于模型的协同过滤算法以处理稀疏(sparse)输入，并建议工作负载分类、碰撞/冲突识别和策略选择。如将在下面详细描述的，每个阶段采用特定矩阵。例如，通常，分类阶段将包含由作为行的工作概要和作为列的CPU、网络、存储器或磁盘以及作为密集资源使用等级的元素来组成的多个效用(utility)矩阵。

识别阶段由具有将行为调度器的决定组合以及在先前提到的属性(即，CPU、网络、存储器或磁盘)和数据中心集群状态之间变化的列的多个矩阵组成。用于具有CPU、网络、存储器或磁盘作为列的矩阵的元素是工作负载性能干扰等级。矩阵的一个由数据中心集群状态组成，并具有元素服务器超载，该元素服务器超载是工作负载资源分配和服务器可用资源的比例。将数据中心集群状态作为行的其他矩阵具有作为缺失资源的元素，这种情况下如果服务器符合工作负载，则元素为1，否则为0。

最后，在策略选择阶段，有将行为冲突的调度器的决定加上延时的决定、列为策略解决类型以及元素为工作负载取消等级或工作负载性能的两个矩阵。最初，在每个矩阵中可能仅有几个元素填充。似然算法将用于填充从矩阵分解得到的效用矩阵的所有列中的缺失元素。初始元素可以由专家提供、或者来自具有由专业用户提供的任何可选的参数的工作负载概要、或者使用离线仿真和/或随机值。包括使用随机值的选项，因为即使没有专家或仿真数据，至少要求一个值以执行协同过滤。此外，管理员可以使用效用函数为每个特性提供值，该每个特性具有在最大和最小等级之间归一化的结果。最后，将提供一些元素，并使用动态自学习机制从在先前的部署中收集的参数来更新它们。

仅通过示例的方式，本教导的一些显著的优点包括：1)冲突处理策略的自动选择使用从云计算环境中的基础架构输入先前的工作负载分类和动态矩阵以解决分配冲突；2)基于在工作负载之间的干扰的冲突的自动识别、服务器超载的概率和在云计算环境中的资源可用性；3)基于CPU、网络、存储器和磁盘使用密集性的工作负载的自动分类；4)通过从先前的部署观察取消的决定的数目、应用干扰和数据中心集群状态的用于工作负载分类的学习机制、冲突识别和策略选择；以及5)通过考虑作为工作负载迁移和资源放弃的行动的无限冲突处理策略组合。

因此，根据本技术，可以使用稀疏输入执行工作负载冲突解决，该稀疏输入最小化调度器决定取消、应用干扰和服务器超载。动态工作负载分类的过程、冲突检测和策略选择可以使用机器学习机制加上从先前的部署收集的知识。可以基于工作负载迁移、决定的否认和取消和/或资源放弃和等待来推荐用于冲突解决的新的策略。

用于冲突解决策略选择的现有的解决方案基于机器学习机制和分类仅集中于分类，该机器学习机制要求用于测试阶段的大数据集，该分类为了更精确的决定不同时考虑工作负载约束、表现和数据中心状态。此外，现有的冲突解决方案没有考虑学习机制，该学习机制考虑调度器决定取消的数目、工作负载性能和/或来自先前的部署的数据中心集群状态。而且，在所有的阶段中，本技术将问题分解成用于分类的很多部分，该分类具有并行执行的协同过滤示例以加速过程并改进调度器的响应时间。最后，现有的解决方案不考虑冲突解决活动的特定类型，诸如工作负载迁移和资源放弃。

现在提供用于工作负载分类、冲突识别和冲突解决策略选择的详细描述。本技术提出了用于乐观(即，乐观或半悲观——参见以上)并行工作负载部署的自动选择冲突解决策略的框架。根据方法500，该过程在图5中示出，并且考虑三个阶段。在第一阶段(1)中，新的工作负载在步骤502中到达，并且在步骤504中，工作负载基于它们的资源需求来被分类(例如，CPU、存储器、网络和/或磁盘密集——参见以下)。步骤504可以例如通过工作负载分类器204来实现(参见图2)。

第二阶段(2)以在步骤506中做出关于工作负载是否应该被转发到现有的调度器或为工作负载创建的新的调度器的确定为开始。当这样的工作负载类型的需求高时，优选地创建新的工作负载特定调度器以扩展到需求。在这种情况下，工作负载在步骤508中被分配到新的调度器。另一方面，如果不需要新的工作负载特定调度器，则工作负载在步骤510中被分配到现有的调度器(即，当前的调度器)。

在调度器作出决定后，在步骤511中，调度器将决定转发到冲突识别器(即，冲突识别器216——参见图2)，在步骤512-516中，该冲突识别器执行用于工作负载、可能的服务器超载和缺失资源之间的冲突(干扰)的并行识别。完成资源验证以检查是否有足够的资源以完成部署(placement)。这也是检测到冲突之处，因为一个部署变得成功，并且由于没有足够的容量，因而另外一个失败。根据示例性实施例，分别使用工作负载干扰冲突识别器、服务器超载冲突识别器和资源缺失冲突识别器来实现步骤512-516，工作负载干扰冲突识别器、服务器超载冲突识别器和资源缺失冲突识别器可以都是冲突识别器216的组件。当多个调度器的决定选择相同的主机来放置请求时发生冲突，这种情况下主机仅可以容纳决定中的一个。如果识别调度器的决定之间的冲突，则第三阶段开始。在第三阶段(3)，基于在步骤512-516中识别的可能的冲突，在步骤518中推荐策略以解决冲突，以便于减轻取消并保持更高的工作负载性能。根据示例性实施例，使用策略选择器和实施者执行步骤518。

在已经解决冲突之后，在步骤520中，工作负载被提交到数据中心基础架构。如将在下面详细描述的，自学习机制用于基于来自该方法的一个或多个先前迭代的数据来更新工作负载分类和/或策略选择过程。参见图5。

所有的阶段包含使用描述调度器的决定的效用矩阵。例如，第一阶段具有将工作负载作为行的矩阵，并且第二和第三阶段具有将调度器的决定的组合作为行。根据示例性实施例，三个步骤过程用于填充矩阵元素。在第一步骤中，如以上强调的，从工作负载概要、专家、离线仿真、效用函数或者认知一些随机值提供对矩阵的初始的元素。

在第二步骤中，从矩阵分解推导出的矩阵的缺失元素将使用对数似然算法来填充。对数似然函数由∑_i>i))给出，其中f(x_i)是在x_i处的概率密度函数且x_i表示第i个观察。矩阵分解可以使用在很多其他之间的方法单值分解(SVD)、非负矩阵分解(NMF)、贝叶斯矩阵分解来获得。矩阵分解用于降维，这种情况下共享子结构的项的表示变得彼此更加相似，并且发散的项可能也变得更加发散。定义发散和相似的过程用于推荐。

最后，第三和连续步骤基于先前的部署和来自如取消率和工作性能的数据中心集群状态的措施来更新一些元素。然而，如果先前的项和新的项的差异大于h，其中h>0，尝试计数器(attempt counter)n与字段相关联，其中n>0。然后，在n个尝试后，元素将通过尝试值(除了异常值(即，异常值——使用，例如，探索性数据分析(EDA)发现的、在使用用于预测的数据之前被淘汰))来更新。这个第三阶段提供自学习机制。

现在进一步详细描述用于填充从矩阵分解推导出的矩阵的缺失元素的第二步骤。

在阶段(1)中，工作负载分类特性可以包括：

i.CPU密集率(intensiveness)，表示平均CPU使用和CPU对工作负载性能的影响的组合；

ii.存储器密集率，表示在兆字节MB或千兆字节GB的平均存储器使用和存储器对工作负载性能的影响的组合；

iii.磁盘密集率，表示在MB、GB或兆兆字节TB的平均磁盘使用和存储器对的影响的组合；

iv.网络带宽密集率，表示在MB或GB的平均带宽使用和网络对工作负载性能的影响的组合；

v.网络响应时间密集率，表示平均响应时间和响应时间对工作负载性能的影响的组合；

vi.网络抖动密集率，表示平均抖动和抖动对工作负载性能的影响的组合；

vii.可以包括更多的参数。

工作负载分类能够为新传入的工作负载类型推荐几个先前的工作负载给定的分类。推荐将表明工作负载的特性。多个矩阵组成这个阶段，该多个矩阵将工作负载概要作为行，将工作负载特性作为列并且将密集资源使用率作为元素。一些初始的元素依赖于由专家使用的归一化的效用函数。效用函数可以由在工作负载概要、专家或可以成为本文提出的那些人来提供。所有的工作负载特性在一些从0到1的间隔内分类，其中0表示与旧的(历史的)特性有0％的相关性，1表示与旧的(历史的)特性有100％的相关性。

示例性实现方式描述了效用函数以评估每个工作负载特性，另一个实现方式一起评估所有的工作负载特性，如下：

对于CPU密集性评估：

其中ExcTime_normal参数是当工作负载所有的可用CPU被分配时的平均(avg)执行时间；ExcTime_max参数是当工作负载仅有z％的CPU被分配时的平均执行时间，其中z<最大的CPU数目；j参数是CPU使用(usage)的权重，k参数是执行时间的权重。

对于存储器密集性评估：

其中ExcTime_normal参数是当工作负载所有的可用存储器(memory)被分配时的平均(avg)执行时间；ExcTime_max参数是当工作负载仅有z％的存储器被分配时的平均执行时间，其中z<可用存储器的最大值；j参数是存储器使用(usage)的权重，k参数是执行时间的权重。

对于磁盘密集性评估：