omega论文 译文

翻译于2013/7/23 仅供参考，

Omega ：灵活的，可扩展的大型计算集群的调度程序

 

 

摘要

规模越来越大，需要快速响应不断变化的要求，难以满足当前中央式集群调度架构。这就限制了可部署的速度，新的功能，降低效率和利用率，并最终将限制集群增长。我们提出了一个新的方法来满足这些需求，使用并行，共享状态，且无锁的乐观并发控制。

我们来比较现有的集群调度设计。

1） 评估调度器之间有多少干扰

2） 目前一些减轻在实践中的技术的重要性，

3） 最后讨论使用案例，突出我们的方法的优点 -通过实时谷歌工作负载所有驱动。

分类和主题描述

D.4.7[操作系统]：组织和设计--分布式系统;

K.6.4[计算和信息系统管理：系统管理-Centralization/decentralization

关键词 集群调度，乐观并发控制

 

1.    介绍

大型计算集群是昂贵的，所以重要的是要很好地使用它们。相同的机器上运行混合工作负载，可提高利用率和效率的CPU和内存密集型工作，小型和大型的，批次和低延迟的工作 - 那些为最终用户请求或提供基础设施的混合如存储服务，命名或锁定。此合并减少工作负载所需的硬件量，但它使更复杂的调度问题的（分配工作机器）都必须考虑到更广泛的要求和政策。同时，集群和他们的工作负载不断增加，由于调度的工作负载大约是簇的大小成正比，调度器风险成为可扩展性的瓶颈。

 

谷歌的生产机作业调度已经经历了这一切。多年来，它已演变成一个复杂的，尖端的系统，很难改变。作为一个重写这个调度的一部分，我们寻找一种更好的方法。

 我们确定了在图1中所示两个普遍的调度器架构。

中央式调度器，使用一个单一的，为所有作业集中的调度算法（我们现有的调度是其中之一）。两层调度器，有一个活动的资源管理器，提供了多个平行的，独立的“调度框架”计算资源，如Mesos[13]和Hadoop的需求[4]。

 

这些模型都不符合我们的需求。中央式调度器并不可以很容易地添加新的策略和专门的实现，并可能扩大我们策划的簇大小。出现两层调度器架构提供灵活性和并行性，但在实践中，他们保守的的资源可视性和锁算法限制，使其将难以如期“挑剔”的工作或做出决定，需要进入状态整个集群。

 

我们的解决方案是一种新的并行调度架构围绕共享状态，采用无锁乐观并发控制，达到既实现可扩展性和性能可扩展性。omega，Google的下一代的集群管理系统中正在使用这种架构。

 

1.1贡献

本文的贡献如下。我们：

1） 提出了一种轻量级集群调度开发操作空间分类（第3章）;

2）介绍一个新的调度架构，使用共享的状态和无锁的乐观并发控制（第3.4章）;

3）中央式，两层和共享状态调度，使用模拟和合成的工作负载（第4章）的性能进行比较;

4）探索生产调度的基础上，由现实世界中的工作负荷跟踪（第5章）驱动使用代码共享状态的方法更详细的行为;

5）演示共享状态的灵活性的方法，通过一个用例：我们添加一个调度，使用知识的全局群集的利用率来调节资源运行MapReduce作业（5233）。

我们发现，omega状态共享架构能够提供性能，竞争力与或优于其他架构的，在现实世界中的设置，干扰低。访问整个集群状态在调度能力，也带来了其他的好处，MapReduce作业如何使用空闲资源，可以加速我们证明这一点。

 

 

2 需求

集群调度的目标，同时必须满足：资源利用率​​高，用户提供的放置位置的限制，快速决策，以及不同程度的“公平”和业务重要性 - 而稳健并始终可用。随着时间的推移这些要求，而且，在我们的经验，在中央式调度器增加新的政策变得越来越难。这不只是由于积累的代码的功能随着时间的推移增长，但也因为我们的一些用户已经开始依赖一个详细的了解系统的内部行为，以完成他们的工作，这使得它的功能和结构很难改变。

 

2.1工作负载的异构性

一个重要的驱动因素的复杂性是硬件和工作负载的异构性，这是司空见惯的大型计算集群[24]。

为了证明这一点，我们审查组合三个谷歌生产机计算集群的工作负载。群集A是一个中等规模的，相当繁忙，而集群B目前在谷歌使用的是一个更大的集群，集群C是一个调度工作负载跟踪，是最近被发布。 [24，27]。

工作负载是从2011年5月。所有的集群执行各种各样的工作，有些是通过手工配置如MapReduce [8],Pregel [19] 和Percolator [23].。

 

分区群集的不同调度的工作负载的方法有很多。在这里，我们挑一个简单的双向分裂之间的长时间运行的服务工作，提供最终用户操作（例如，Web服务等）和内部的基础设施服务（如BigTable的[5]），批处理作业进行计算，然后完成。虽然很多其他分裂是可能的，简单起见，我们把所有低优先级jobs¹的那些标记为“best effort”或“批处理”在批处理类，其余的服务类作业。

 

作业是由一个或多个任务 - 有时数千任务。大多数（> 80％）的作业是批处理作业，但大部分资源（55-80％）分配给服务作业（图2），后者通常运行更长的时间（图3），并有较少的任务比批处理作业（图4）。这些结果大致相似，其他集群的痕迹分析，从雅虎，facebook[7]和谷歌[20，24，25，29]。

 

为什么做这件事？许多批处理作业很短，快速周转是很重要的，所以一个轻量级的，低质量的方法安置工作就好。但长期运行的，高优先级的服务作业（20-40％的运行超过一个月）必须满足严格的可用性和性能指标，这意味着关心他们的任务地方是，以需要最大化的抗故障，并提供良好的性能。事实上，omega服务调度会尝试将任务抵御既相互独立又协调的失败，这是一个NP-hard的机会约束优化问题的数万故障域的嵌套和重叠。我们以前的实现可能需要数十秒响应。虽然这是非常合理的花费几秒钟，作出决定时，其效果持续几个星期，也可以是有问题的，如果一个交互式的批处理作业等待这样的计算。此问题通常称为“head of line blocking”，并且，引入并行可避免。

 

综上所述，我们所需要的是一个调度架构，可以容纳这两种类型的工作，灵活地支持工作的具体政策，也是规模不断增长的量调度工作。下一节将讨论一些更详细的要求，以及满足他们的一些方法。

图1：原理概述本文探讨的调度架构。

图2：批处理和服务的工作负载的集群A，B和C：归一化的作业数（J）和任务（T），CPU核心秒（C）和RAM GB-seconds（R）和总的要求。条纹部分是服务作业，其余的是批处理作业。

 

图3：集群A，B，和C线不达到1.0，部分时间超过30天的范围内作业运行和作业到达间隔时间的累积分布函数（CDF）。在这和随后的图表中，实线代表批处理作业，虚线是服务作业。

 

图4：在作业中的任务数积分图函数的集群A，B和C。右图是左图的尾部一个展开，看≥95 ^th 百分比^, ≥100个任务。

 

3 分类

首先，我们用一个简短的调查设计集群调度必须解决的问题，然后由一些不同的调度架构可能通过实验来看。

分区调度工作。

（1）负载均衡工作负载类型，是无视，可以遍布的调度工作;

（2）针对不同的分区有专门的调度器，或

（3）两者的结合。

有些系统使用多个作业队列处理作业的请求（例如，对于不同的优先级），但是，这并不影响调度的并行性：我们更感兴趣的是多少的调度被分配来处理队列。

 

资源的选择。调度器可以允许选择所有群集资源，或有限的一个子集，以简化决策选择。前者增加了机会，以做出更好的决策，并且当“挑剔”的工作需要放置到一个几乎满集群是重要的，或依赖于整体的状态决策时，比如未使用的资源总量。调度器可以放置任务，如果他们能够抢占现有的分配，而不是仅仅考虑闲置资源有更大的灵活性，但是这浪费了一些工作在抢占任务的花销。

 

干扰。如果调度器独占资源，多个调度器可能会尝试同时请求相同的资源。避免了这个问题的悲观的策略，通过确保特定资源仅提供一个调度一次。一个乐观的检测（有望罕见）的冲突，并撤消一个或多个的冲突。乐观的策略增加的并行性，但如果发生冲突过于频繁，潜在的增加了调度工作的大量花销。

 

分配粒度。由于作业通常包含许多任务，调度器对如何调度他们可能有不同的策略：一个极端是原子全有或全无在作业的调度的任务，在其他资源被发现为他们的任务是增量式布局。一个全有或全无的策略可以近似通过增量请求资源来囤积他们，直到可以开始工作，在此期间，这些资源的花销是浪费的。

 

有缺点：一些作业可能需要群调度（如MPI程序），但其他的开始只有请求一小部分资源（例如，MapReduce作业），的作业没有必要延迟，增量资源请求可能导致死锁，如果没有回退机制，而囤积集群利用率降低，也会导致死锁。

 

集群范围内的行为。有些行为跨越多个调度。例子包括实现各种类型的公平性和通用协议，在工作中的相对重要性，特别是如果一个调度器可以抢占其他的任务。严格执行这些行为可以实现中央式控制，但它也有可能依靠紧急行为近似所需的行为。技术，如可运用的限制优先级调度器，可以提供部分强制性行为，符合集群范围内的策略，可以 post facto审计，为了消除在一个调度器的关键代码路径需求检查。

此空间是明显大于在单个文件被探索，我们关注在总结于表1，接下来的几节中更详细地描述。

 

3.1中央式调度器

我们的比较基准是中央式调度器有且仅有一个实例，没有并行，而且在一个单一的代码库，必须实现所有的策略选择。这种方法常见于高性能计算（HPC）的世界里，通常中央式调度器

运行调度代码的单个实例，并采用相同的算法对所有进入的作业。 HPC调度器，如Maui[16]和Moab，以及平台LSF[14]，提供不同的策略支持，通过复杂的计算涉及多个权重因子计算出一个整体的优先级后，“调度器能够达到目标是通过开始于作业的优先顺序”[1]。

 

另一个方式来支持不同的调度策略是提供多个代码路径调度，运行独立的不同作业类型的调度逻辑不同。但是，这是比它可能会出现困难。目前谷歌的集群调度实际上是有效的中央式调度器，虽然它已经解决许多优化，多年以来提供内部的并行多线程处理地址head-of-line阻塞和可扩展性。这困难作业的复杂性：调度器在作业运行前已经最小化地缩短等待的时间花销，同时关于优先级，每个作业约束[20，25]，以及一些其他的策略目标，如故障容忍和扩展到成千上万的机器的工作负载。虽然取得了巨大的成功，我们的调度已经经历了几年的演变和软件的发展，以可持续的方式使用一个单一算法实现，支持范围广泛的策略，我们发现它是令人惊讶的困难。最后，这种软件工程的考虑，而不是性能的可扩展性，是我们的首要动机移动到支持并发，独立调度​​组件一个架构上。

 

表1：比较的并行集群调度方法。

 

3.2 静态分区调度器

大多数云计算调度器（eg.,Hadoop[28],和Dryad’s Quincy[15]）他们已经完全控制资源集，像他们通常的部署到专用的，静态分区机器集群，或者通过单个集群分区到提供不同行为不同部分。这导致碎片和子操作性能，对于我们来说它是不可行，因此我们没有进一步研究这个操作。

 

3.3两层调度器

静态分区的问题，一个明显的修复是每个调度器动态调整资源的分配，使用一个中央协调，以决定​​每个子集群可以有多少资源。这两层调度方法被一些系统所使用，包括：Mesos [13]和Hadoop-on-Demand (HOD)[4]。

 

Mesos，一个集中的资源分配动态分区集群，资源分配给不同的调度框架。资源以“offers”形式分配到框架，其中包含只有“可用”资源 - 那些当前未使用的框架。分配器避免冲突，只提供一个给定的资源在一个时间框架，并试图实现优势资源的公平性（DRF）[11]通过选择的顺序和offers 的大小.因为只有一个框架，在同一时间实验一个资源，它有效地控制在调度选择期间的资源的锁。换句话说，悲观并发控制。(Mesos简单的分配器提供了所有可用的资源，以一个框架，每一次它的报价，并没有限制一个框架，可以接受的资源量。负面影响：Mesos框架决定时间的增长)

 

Mesos效果最好，当任务是短命的，频繁放弃资源时，作业大小是比较小规模的集群。正如我们在 第2.1章表达的，我们的集群工作负载不具有这些属性，尤其是在服务性作业的情况下，将第4.2章来呈现基于要约两层调度方法不适合我们的需求。

 

虽然Mesos框架可以使用“过滤器”来形容提供的各种资源，它没有访问一个集群整体状态的视图 - 只是它已经提供的资源。因此，它不能支持抢占或需要访问整个集群的状态的策略：一个框架，根本没有任何知识资源已分配到其他调度。mesos使用资源囤积实现群调度，结果产生潜在的死锁。

 

 

也有可能看YARN[21]是一个两层调度。YARN，资源请求来自于“applicationmasters”每个作业，被发送到“resource master”的单一的全局调度器，这在虚拟机分配资源，关键是特定应用程序约束。但是，应用程序的master提供的作业管理服务，而不是调度，从而YARN实际上是一个中央式调度架构。在写作的时候，YARN只支持一种资源类型（固定大小的内存块）。我们的经验表明，它最终将对资源Master需要丰富的API，以满足多样化的应用需求，包括多个资源维度，约束和故障容忍放置选择。虽然YARNappliacation masters可以要求在特定的机器上的资源，目前还不清楚他们是如何获取和保持状态，需要做出这样的放置决定。

 

3.4共享状态调度

omega使用的是另一种共享状态的方法：我们给予每个调度整个群集的完全访问权限，允许他们自由参加各种形式的竞争，并用乐观并发控制调解冲突时，他们更新群集状态。这立即消除两个的两层调度方法的问题 - 由于有限的并行悲观并发控制，资源调度框架能见度受限 - 重做乐观并发的假设是不正确的工作时，潜在的成本。探索这种折衷是本文的主要目的。

 

有没有中央资源分配器omega所有的资源分配决策调度。我们维持有弹性的主副本在集群中的资源分配，我们称之为cellstate。每个调度是一个私有的，本地化的，频繁修改的cell state的副本，为调度决定所使用。调度可以看到整个cell 状态，并有完全的自由主张提供任何可用的群集资源有适当的权限和优先级 - 甚至其他调度器已经被请求。一旦调度作出放置决定，它在一个原子提交上更新cellstate的共享副本。在发生冲突的情况下最多只能有一个这样的提交会成功：状态同步到尝试提交的一个事务有效时间。交易成功与否，调度器重新同步的cellstate后本地副本，如果有必要，重新运行调度算法并再次尝试。

 

omega调度完全并行操作，不必等待其他调度的作业，也没有跨调度head of line blocking。为了防止冲突，omega调度通常选择使用增量交换，接受所有冲突的变更（即交换提供了原子，但不是独立）。调度器可以使用一个全有或全无的交换实现群调度：要么作业的全部任务，一起被调度，或者没有被调度，调度器必须再次尝试整个作业。这有助于避免资源的囤积，因为群调度作业可以抢占低优先级任务，一旦有足够的资源，其交换提交，并允许其他的调度作业同一时间使用的资源。

 

不同的omega调度可以实现不同的策略，但都必须同意允许资源分配（例如，一台机器是否是一个共同的概念），作业的相对重要性共同尺度，称为precedence。这些规则是故意保持在最低限度。这两个层集中资源分配组件，从而简化持久性数据存储验证代码执行这些共同规则。由于没有中央式策略执行引擎，为高集群范围内的目标，我们依赖这些涌现行为呈现，从个别调度的决定。在这方面，它有助于公平是不是在我们的环境中的一个主要问题：我们正在带动更多的需要，以满足业务需求。为了支持这些，个别调度配置设置来限制他们可能会请求的总资源量，并限制他们承认的作业。最后，我们还依赖于postfacto的强制性，因为我们监测系统的任何途径行为。

交换失败的频率和故障花销是最终确定的性能的共享状态的方法的可行性。本文的其余部分将探讨在谷歌这些典型的集群工作负载问题。