Google集群管理系统Omega详细解读

0. 前言

本文根据 Omega论文整理总结得到

一个灵活可扩展的大规模集群调度系统，其出现主要用于解决可扩展性问题以及一些任务对于响应时间的高要求。在Omega出现之前我们知道有两个典型的资源管理和调度框架，分别是YARN和Mesos，这两个系统虽然是两层的调度系统，但是其master节点仍然是集群进行大规模扩展的瓶颈，如果集群规模很大，那么对于某些请求将不能及时作出回应。同时这两个调度系统只是根据当前的情况进行资源分配，其分配的结果也不能保证全局最优。

omega的出现就是为了解决这个问题，其设计的核心主要包含两个方面。第一，在调度系统中存在多个调度器，这些调度器中缓存集群资源的全量信息，可以单独进行调度，这种方式可以显著提高集群的并发度和扩展性。第二，采用无锁乐观并发的方式进行资源分配，每个调度器根据集群当前的全量资源信息进行调度，并将调度的结果发送给控制节点，由控制节点根据其分配的资源是否已经被占用来决定是否允许本次分配。如果资源已经被占用，则返回失败结果，调度器可以再进行分配。在这个过程中每个调度器中都需要维护一个全量的资源信息。

目前该系统并没有真正的运用到实践当中，论文并没有针对Omega的架构进行详细说明，论文主体主要是分析对比目前调度系统的优缺点，以及通过实验的方式证明共享状态调度架构的优势，其实验结果也是基于模拟的。但是从borg的论文中可以得知，在borg系统中的资源分配模块就是利用了Omega的思想，但是具体的实现细节并没有公布。

1. abstract & introduction

背景：

• 大规模集群资源非常宝贵，为了提高资源利用率和效率往往将不同类型的负载混合部署运行，例如CPU密集型和内存密集型、大任务和小任务、延迟敏感和延迟不敏感任务，这样做虽然会减少基础设施成本，但是给调度层带来了巨大的挑战。
• 集群的规模越来越大目前的调度系统很容易出现瓶颈，另外随着集群规模的扩大，集中式和两层调度系统无法满足对任务请求的快速响应。
• 目前的集中式调度器很难进行扩展、实现复杂、不利于集群大规模扩展。对于两层调度器虽然提供了灵活性和并行性，但是其保守的资源可见度（不能根据全局的资源情况进行分配）和锁机制（采用串行轮询的方式进行）存在缺陷。

采取的方法：

• 共享状态。存在多个调度器，这些调度器可以共享集群的全量资源信息，并根据这个信息进行资源分配。
• 无锁乐观并发机制。每个调度器可以根据自己的集群信息副本进行分配，然后将分配结果提交给控制器，由其决定是否可以进行分配。

2. 需求

对于一个集群调度系统来说其需要满足高资源利用率、用户设置的约束、快速决策、不同程度的公平、一些商业因素以及健壮和高可用性。

对于集群调度系统来说，一个首要的问题就是资源和负载的异质性问题，在这里我们仅仅将负载分为两类一类是长服务一类是批处理任务，其中长服务一般不会停止或者运行很长的时间，而批处理任务的运行时间较短。下图是Google三个集群的任务运行情况和资源使用情况。


从上图可以看到有80%的任务时批处理任务，但是有55-80%的资源被分配给了长服务，这个结果与雅虎、Facebook和Google trace中的分析结果相似。

为什么说这个是严重的呐？因为对于批处理任务来说，其主要进行计算任务，并且运行时间较短，这些任务可以运行在性能较差的机器上，即便任务失败也可以重新调度到其他机器上不会造成很大的开销。但是对于长服务则不同，长服务的运行时间一般较长，为了保持服务的持续稳定，在一开始选择放置点的时候就应该选择性能稳定的机器，通常的做法是根据机器的历史表现情况来判断节点的稳定性和可靠性，因为长服务应用一方面是面向客户的，如果存在较大的延迟会影响用户体验直接影响销售，另外一方面，长服务的重新调度的开销非常大，其是一个服务由很多的组件构成，重调度需要将所有的组件都进行搬迁。这种优化是一个NP难的问题，虽然可以通过计算的方式获得最优解，但是这个过程往往需要很长的时间，这在实际系统中是不被允许的。

因此我们需要的调度器架构要能够同时满足不同类型的任务、自由支持不同任务的需求、能够进行扩展。

3. 分类

该部分首先分析了资源管理和调度系统中涉及的一些基本问题，包括调度系统的划分标准、资源分配机制、资源分配策略（乐观锁方式、悲观锁方式、all-or-nothing方式、增量满足方式）及集群的一些其他行为特征等，这些信息可以在下面文章中进行详细了解。
集群资源管理与调度基础理论综述
后面主要针对不同类型的调度架构进行分析，包括集中式调度系统、静态划分调度系统、两层调度系统和共享状态调度系统。

3.1 集中式调度器

特点：一个单一的进程负责所有的工作（资源调度、任务管理、通信等）、没有并行、在一份代码中实现所有的调度策略。
应用：在HPC领域中有广泛的应用，还有Hadoop2.0之前的版本。
缺点：扩展性差，新的调度策略难以融入现有的代码中，不能够支持不同类型的任务。
一种可行的改进：可以将不同的调度策略单独放置在不同的模块或者路径中，然后根据不同的任务选择不同的调度策略进行分配，这种方式可行但是调度策略仍然集中在一个集中式的组件中，实现和扩展性都很差。
需要考虑因素：要最小化任务从提交到执行之间的等待时间，这个时间通常是调度系统用于调度的开销；在调度过程中要尊重不同任务的优先级和软硬约束；并且要考虑到容错和扩展性等问题。

3.2 静态划分

静态划分很好理解，根据需求将一个大集群划分为几个不同的小集群，每个集群中有单独的调度器负责调度特定类型的任务，各个集群之间互不干扰独立运行。这种方式的缺点很明显，集群之间的资源不能够共享，导致有的集群资源空闲有的集群资源一直忙碌，并且对于多个集群的维护开销也很大。

3.3 两层调度器

该类调度器的主要代表是mesos和yarn。
对于mesos的详细总结可以参考下文：
资源管理与任务调度系统Mesos论文及架构详细解读

mesos基于DRF策略和offer-based（主动提供）的方式由master向各个计算框架分配资源，并且提供了过滤器机制，计算框架可以事先描述自己需要的资源特征。该架构适用于短任务，并且存在一定的缺点：（1）offer-based的方式是悲观锁实现的，每次只能给一个计算框架分配资源，导致并发度低；（2）每次的分配都是基于当前状况进行的，计算框架并不能感知到系统的资源情况，所以分配不是全局最优的；（3）逐个计算框架进行分配导致系统不能够支持资源抢占；（4）当系统中被短任务填充时，会导致长任务饿死；（5）资源保持可能会导致死锁现象的发生；

关于YARN的基本内容可以参考下文：
YARN简介—目前使用最为广泛的资源管理系统

yarn是基于资源申请的方式进行资源分配的。AM向RM请求资源，RM基于NM的心跳触发分配，按照一定的策略将资源分配给AM，AM与NM通信运行任务。目前的yarn还存在一些缺点：目前的AM只负责进行任务管理并没有提供调度的能力，这也是一部分人将YARN划分为集中式调度器的原因；目前仅支持对内存的分配；虽然现在yarn支持AM在进行资源申请的时候选择放置偏好点，但是并没有说明这些偏好是根据什么标准得到的。

3.4 共享状态

针对两层调度系统存在的并行性和不能进行全局最优的调度问题，共享状态系统进行了优化。主要有两点措施，第一存在多个调度器，每个调度器都拥有系统全量的资源信息，可以根据该信息进行调度。第二调度器将其调度的结果以原子的方式提交给cell state维护模块，由其决定本次提交是否成功，这里体现了乐观并发的思想。

一些优化：

• 每个调度器会定期以私有的方式更新自己副本中的cell state；
• 每个调度器可以设置其私有得调度策略，有很大的自由度；
• Omega只是将优先级这一限制放到了共享数据的验证代码中，即当同时由多个应用程序申请同一份资源时，优先级最高的那个应用程序将获得该资源，其他资源限制全部下放到各个子调度器。
• 对整个集群中的所有资源分组，限制每类应用程序的资源使用量，限制每个用户的资源使用量等，这些全部由各个应用程序调度器自我管理和控制。
• 引入多版本并发控制后，限制该机制性能的一个因素是资源访问冲突的次数，冲突次数越多，系统性能下降的越快，而google通过实际负载测试证明，这种方式的冲突次数是完全可以接受的。

4. 比较设计

基于一个轻量级的模拟器，这个模拟器中使用一些合成的负载，并通过trace数据中的某些分布来决定先关参数。

首先分析了真实trace数据中的负载信息，包括一个job包含的task个数，一个task的持续时间，每个task申请的资源量，任务的提交时间间隔。

论文后续内容主要通过模拟器方式和基于trace数据的方式对不同类型的调度框架进行对比，通过多维度的指标信息比较相互之间的差异。这里不再详细阐述，有兴趣的可以查看其论文。

5. 总结

• Omega的出现为调度系统的设计指明了一个方向。通过共享状态的方式来提高并发和扩展性，降低调度延迟。并且通过无锁乐观并发的方式来解决冲突，也能够在一定程度提高并发度。
• 腾讯目前的调度系统就采用了Omega的某些思想。例如基于虚拟机的调度问题，其主要看重的是用户体验，所以要保证调度延迟最低，因此可以通过多个调度器的方式进行实现。