Omega:flexible,scalable schedulers for large compute clusters论文理解

摘要：
问题：当下中央单一调度方式很难满足规模迅速增长和需求变更快速响应的需要
带来的后果：限制了新特性的部署、降低了效率和可用性，最终会限制集群的发展
解决方法：论文提出了并发、共享状态和乐观锁并发控制来满足这些需求
实验方法：将该方法与现存的集群调度设计相比较，提出他们可能存在的问题和解决方法，最终证明我们的方法的优势。
1.Introduction
大规模的计算集群是很昂贵的，所以充分利用它们很有必要。有用性和效率可以增加在同一台机器的负载量。整体设计减少了硬件的工作量，但是却是得调度问题更加复杂化：需要考虑变化的需求和方案，同时集群和负载持续增长，当负载接近于集群的大小时，调度程序会成为瓶颈。

Figure 1 中，中央单一调度程序为所有任务提供单一的、集中化的调度算法，两层调度器有一个活动的资源管理器，可以为多个平行的调度框架提供计算资源。但是这两种方式并不能满足我们的需要，第一种方式在添加新的策略会比较困难，并且不能把集群增加到我们计划的大小。第二种方式虽然提供了灵活性和并行性，但是他们对于资源的可见性和锁算法并不是很理想，很难防止有特殊要求的任务，不能查看整个集群的状态。我们的方法是Omega的方案是围绕着资源状态共享的思想，多个并发的调度进程以乐观锁的方式访问这些共享状态来获得调度框架的可扩展性。
1.1 贡献
本论文要讨论的要点包括：
1.为集群调度开发提供轻量级的选择空间
2.介绍一种基于乐观锁和共享状态的新型调度方法
3.采用模拟和合成的负载来对比三种方法
4.更进一步探索贡共享状态方式
5.通过一个案例展示共享状态的灵活性
2.Requirement
集群调度要满足的目标：硬件资源的高利用率、用户定义调度策略、快速调度决策过程以及兼顾各种层面的公平调度
2.1负载不均匀性
在大型计算集群中，硬件和负载的不均匀性是很常见的。为了展示，我们选取了谷歌中三个有代表性的集群，集群A是中等规模的集群，业务很繁忙；集群B是大型集群，目前在谷歌中使用

终止型作业和服务型作业。终止型作业就是运行时间短、优先级较低、“尽力而为”的作业，例如MapReduce批处理作业；服务型作业是指在概念上一直运行的作业，例如Web Server和数据服务器，流式计算作业也可包括在内。每一个作业包含多个任务，80%以上的作业是终止型作业，而55%-80%的资源分配给了服务型作业。服务型作业比终止型作业运行时间要长得多，如图3，并且服务型作业比终止型作业包含的任务数要少。
运行时间长的、高优先级的服务型作业必须满足严格的可用性和性能目标，这意味着小心放置它们以最大化提高容错性和良好的性能是很有必要的。当调度器花费几秒钟时间去判断哪个程序会运行几周时间的时候，终止型作业不得不等待这种计算，这将会引起线头阻塞，而解决这个问题的方法就是并行化处理。
3.分类
3.1 中央单一调度器
中央单一调度器具有一个单一的调度器，所有的工作都在中央调度器中串行化的完成，没有并行化，并且所有的作业都采用一样的算法，它的主要问题在于灵活性和可扩展性。由于只有一个调度器，它很难兼容多样化的调度需求，而且只有一个调度队列（也可能有多个调度队列，但是最终要在单一调度器上串行化执行），这使得调度器容易成为系统瓶颈，影响系统的可拓展性。）
中央单一调度存在一种优化变种，即“多代码路径（multiple code path）的中央单一调度”。该调度机制为每种类型的作业提供一个单独的“代码路径”，对于不同作业调度器实际上运行的是不同的调度代码，这样就可以满足不同类型负载的调度需求和策略，在灵活性（兼容性）上有所改善，但是其可拓展性仍然受限。虽然这些年，谷歌在内部并行性和多线程处理以解决线头阻塞和稳定性方面进行了很多优化，谷歌当前的集群调度系统依旧是中央单一调度。这使得本来复杂的工作更加复杂化：调度器必须减少一个任务的等待时间，同时尊重优先级，每个任务的限制、容错、负载等一系列其他的目标。
3.2 静态分区Statically partitioned schedulers
也被成为云计算中的调度，资源集合的全面控制。部署在专门的，静态划分的集群的一个子集上。或者把集群划分为不同的部分，分别支持不同的行为。
3.3两层调度器
为了解决中央单一调度器在兼容性和可拓展性上的缺陷，两层调度器应运而生。Mesos是其中的典型代表，计算框架运行在Mesos之上，Mesos向上层框架提供resource offer，上层框架根据Mesos提供的资源进行任务调度。Mesos Master是一个中心化的资源管理器，我们也可以将其看做“元调度器”，即对计算框架进行调度；上层框架的调度器实际为任务进行调度，因此Mesos属于两层调度系统。
在Mesos中，一个中央资源分配器动态的划分集群，分配资源给不同的调度框架（scheduler frameworks）。资源可以在不同的调度框架之间以“offers”的形式任意分配，offers表示了当前可用的资源。资源分配器为了避免不同调度框架对同一资源冲突申请，只允许一次只能分配给一个调度框架。在调度决策的过程中，资源分配器实质上起到了锁的作用。因此Mesos中的并发调度是悲观策略的。
双层调度器的特点是，各个框架调度器并不知道整个集群资源使用情况，只是被动的接收资源；Mesos Master仅将可用的资源推送给各个框架，而框架自己选择使用还是拒绝这些资源；一旦框架（比如Hadoop JobTracker）接收到新资源后，再进一步将资源分配给其内部的各个应用程序（各个MapReduce作业），进而实现双层调度。
mesos在任务运行时间较短并且任务大小远远小于集群大小的时候运行效果较好。但是向之前介绍的，我们的集群负载没有这样的属性，尤其是在服务型任务中。
但是mesos也有一些缺点，主要表现在以下两个方面：
1) 无全局资源视图
Mesos向框架提供resource offer，resource offer中只包含当前可用资源，因此框架只能看到局部资源视图，调度结果通常不具有全局最优性。对于约束调度或者挑剔调度（pickyscheduling），局部资源视图会限制其调度结果或者反应速度。此外，局部资源视图天然不支持抢占。
2) 悲观并发控制
Mesos定期向框架提供resource offer，这是一个串行化的过程。在任意时刻，Mesos只会将当前所有可用资源提供给一个框架，在该框架反馈后Mesos才会将可用资源提供给另一个框架。这种串行化相当于悲观并发控制，限制了系统并发性和可拓展性。
3.4共享资源调度
Mesos主要针对终止型作业的应用场景，作业多为短任务，通常不需要抢占，不涉及挑剔调度，因此非全局的资源视图不会有太大问题。但是Google内部的应用场景是混合负载，即终止型作业和服务型作业的混合，这样Mesos的问题就成为了缺点，需要进行解决。
为了解决两层调度器在全局资源视图和并发控制方面的问题，Google提出了共享状态调度，其典型代表就是Google下一代调度系统Omega。运行在Omega之上的计算框架调度器具有全局资源视图，具有整个集群的完全访问权限。Omega元调度器维护着一个全局共有的集群状态，每个调度器具有一个私有集群状态副本。为增加系统的并发性，Omega采用乐观并发控制机制，运行在Omega上的计算框架调度器根据下述步骤进行调度：
1) 如果作业队列不为空，从中取出一个作业；
2) 同步：开始一个事务，同步私有集群状态副本和共有集群状态；
3) 调度：调度器尝试为作业中所有任务创建任务——资源分配，在这个过程中修改私有集群状态；
4) 提交：根据私有集群状态尝试提交作业事务到共有集群状态，作业事务可能成功或失败；
5) 如果作业事务提交失败，则将该作业重新加入作业队列，准备在未来事务中再次处理。
Omega采用乐观并发控制，但是在并发调度过程中，不同的任务可能会使用相同的资源，这样就引入了一个新问题——调度冲突。产生调度冲突后作业需要被重新调度，代价较高。
Omega中没有中心的资源分配器，所有的资源分配决策都是由应用的调度器自己完成的。Omega维护了一个成为cell state的资源分配状态信息主拷贝。每一个应用的调度器都维护了一个本地私有的，频繁更新的cell state拷贝，用来做调度决策。调度器可以看到全局的所有资源，并根据权限和优先级来自以为是的要求需要的资源。当调度器决定资源方案时，以原子的方式更新共享的cell state：大多数时候这样commit将会成功（这就是乐观方法）。当冲突发生时，调度决策将会以事务的方式失败。无论调度成功还是失败，调度器都会重新同步本地的cell state和共享的cell state。然后，如果需要，重启调度过程。
Omega的调度器完全是并行的，不需要等待其他调度器。为了避免冲突造成的饥饿，omega调度器使用增量调度——accept all but the conflictthings，这样可以避免资源囤积。如果使用all or nothing 的策略可以使用gang调度（either all tasks of a job are scheduled together, or noneare, and the scheduler must try to schedule the entire job again.）。gang调度要等待所有资源就绪，才commit整个任务，就造成了资源囤积。
Monolithicschedulers为所有任务都使用一个中心调度算法。其缺点是不易增加新的调度策略，也不能随着集群的扩展而扩展。
Two-levelschedulers使用一个动态资源管理器提供计算资源或者存储资源给为多个并行的调度框架。每一个调度框架所拥有的都是一个整个资源的一个子集。为什么是一个动态资源管理器呢？是相对于静态的集群分区来说的。我们可以静态的把集群分为几个区，分别服务于不同的应用。上面的动态资源管理器完成工作就是把静态的分区工作动态化。由于两层调度无法处理难以调度的挑剔任务，且不能根据整个集群的状态做出决策，google引入下面的调度架构。
sharedstate schedulers使用无所的乐观并发控制算法。那么对比起来，Two-level schedulers本质上是悲观调度算法。Omega,google的下一代调度系统中使用了该架构。
在omega看来，mesos的offer 的机制本质上是一个动态的过滤机制，这样mesos master向应用框架提供的只是一个资源池的子集。当然可以把这个子集扩大为一个全集，也是share state的，但其接口依然是悲观策略的。这一点可以讨论。
在omega看来，YARN中的applicationmasters提供的仅仅是一个任务管理服务，并不是一个真正的二层调度器。其次到目前为止，YARN只支持一种资源类型。另外，尽管YARN中的application masters可以请求一个特定节点的资源，但是其具体策略是不清晰的。