解析Google集群资源管理系统Omega

　　1. 背景

　　Google的第一代/第二代集群(资源)管理系统被称为Borg，Borg设计细节因零零星星出现在各种文章中而知名，但一直未公开(比如发一篇paper)。然而，我们可从腾讯公布的Torca(Torca是google华人老员工朱会灿加入搜搜后，仿照google borg开发的资源管理系统, 链接是：“Torca：Typhoon上的分布式集群调度系统”)设计文档中可猜测一二。

　　而在近期，Google公布了它的下一代集群管理系统Omega(下载地址)的设计细节。论文中谈到Google经历的三代资源调度器的架构，分别是中央式调度器架构(类似于Hadoop JobTracker，但是支持多种类型作业调度)、双层调度器架构(类似于Apache Mesos和Hadoop YARN)和共享状态架构(就是Omega)，并分别讨论了这几个架构的优缺点。同Google公布的其他系统类论文不同，这次它并没有公布Omega的设计架构，只是介绍了它的资源管理组件的设计思想和关键技术，个人认为这主要是因为Omega整体架构与现有的资源管理系统，比如Apache Mesos，非常类似(比如各个slave上会部署一个代理用户接收任务，向master汇报任务状态和资源使用情况等)，主要不同集中在资源管理器上，所以重点介绍这个组件。

　　另外，从论文作者看，Omega主要是由剑桥大学和加州大学伯克利分校的两个实习生在google实习时完成的。

　　2. 集群管理(或者叫资源管理)系统的设计动机

　　集群资源管理系统是对底层硬件的进一步抽象，它屏蔽了硬件的异构性，对上层各种应用提供资源统一管理和调度。从当前公认的云计算划分看，它属于IAAS(Infrastructure-as-a- Service)。

　　我在“浅谈Borg/YARN/Mesos/Torca/Corona一类系统”一文中已经详细介绍了这类系统的设计动机，主要有两个，分别是提高系统利用率和服务自动化部署，google在Omega论文中也谈到了这些。

　　这类系统不同于现在的Hadoop，Hadoop运行的任务是快短类型的，可以运行在任何很烂的机器上，一旦任务失败后，可以很快地将之调度运行到另外一个机器上;而类似于Omega或者Mesos的资源管理系统则不同，它不仅要运行这种短类型的任务，更多的是运行一些长类型的服务，比如web service、MySQL Server等，对于这类服务，Omega应尽量将其调度到一个性能稳定可靠的节点上，这通常是通过跟踪每个节点的历史表现情况判断节点的稳定性和可靠性实现的，比如，如果你向通过Omega运行一个大约工作1个月的web service(一个月后可能会弃用)，那么，Omega会通过分析历史数据，得到一个月内出现故障的可能性最低的节点，并将该节点的资源分配给该web service，而对于一个MapReduce作业，可将任何节点分配给他，但从资源合理使用上看，应尽可能将一些表现差的节点分配给MapReduce作业或者一些性能好的节点上的琐碎资源分配给它。

　　3. 三类集群管理系统

　　Omega论文描述了Google经历的三代资源管理系统，并探讨了各自的优缺点，这三代系统分别如下：

　　(1) 中央式调度器(Monolithic scheduler)

　　中央式调度器的特点是，资源的调度和作业的管理功能全部放到一个进程中完成，开源界典型的代表是Hadoop JobTracker的实现。这种设计方式的缺点很明显，扩展性差：首先，集群规模受限，其次，新的调度策略难以融入现有代码中，比如之前仅支持MapReduce作业，现在要支持流式作业，而将流式作业的调度策略嵌入到中央式调度器中是一项很难的工作。

　　Omega论文中提到了一种对中央式调度器的优化方案：将每种调度策略放到单独一个路径(模块)中，不同的作业由不同的调度策略进行调度。这种方案在作业量和集群规模比较小时，能大大缩短作业相应时间，但由于所有调度策略仍在一个集中式的组件中，整个系统扩展性没有变得更好。

　　(2) 双层调度器(Two-level scheduler)

　　为了解决中央式调度器的不足，双层调度器是一种很容易想到的解决之道(实际上是分而治之策略或者是策略下放机制)。双层调度器仍保留一个经简化的中央式调度器，但调度策略下放到各个应用程序调度器完成。这种调度器的典型代表是Apache Mesos和Hadoop YARN。Omega论文重点介绍了Mesos，Mesos是twitter开源的资源管理系统，它的详细设计架构我已在多篇博文中进行了介绍，在此简要介绍一下：

　　Mesos资源管理部分由两部分组成：分别是Mesos Master和Mesos Slave，其中，Mesos Slave是每个节点上的代理，负责向Master汇报信息和接收并执行来自Master的命令，而Master则是一个轻量级中央化的资源管理器，负责管理和分配整个集群中的资源。如果一个应用程序想通过Mesos资源管理系统申请和使用资源，需编写两个组件：框架调度器和框架执行器，其中，框架调度器负责从Mesos Master上获取资源、将资源分配给自己内部的各个应用程序，并控制应用程序的执行过程;而框架执行器运行在Mesos Slave中，负责运行该框架中的任务。当前很多框架可以接入Mesos中，包括Hadoop、MPI、Spark等。

　　双层调度器的特点是，各个框架调度器并不知道整个集群资源使用情况，只是被动的接收资源;Mesos Master仅将可用的资源推送给各个框架，而框架自己选择使用还是拒绝这些资源;一旦框架(比如Hadoop JobTracker)接收到新资源后，再进一步将资源分配给其内部的各个应用程序(各个MapReduce作业)，进而实现双层调度。

　　双层调度器的缺点是：

　　1) 各个框架无法知道整个集群的实时资源使用情况。

　　很多框架不需要知道整个集群的实时资源使用情况就可以运行的很顺畅，但是对于其他一些应用，为之提供实时资源使用情况可以为之提供潜在的优化空间，比如，当集群非常繁忙时，一个服务失败了，是选择换一个节点重新运行它呢，还是继续在这个节点上运行?通常而言，换一个节点可能会更有利，但是，如果此时集群非常繁忙，所有节点只剩下小于5GB的内存，而这个服务需要10GB内存，那么换一个节点可能意味着长时间等待资源释放，而这个等待时间是无法确定的。

　　2) 采用悲观锁，并发粒度小。

　　在数据库领域，悲观锁与乐观锁争论一直不休，悲观锁通常采用锁机制控制并发，这会大大降低性能，而乐观锁则采用多版本并发控制(MVCC ,Multi-Version Concurrency Control)，典型代表是MySQL innoDB，这种机制通过多版本方式控制并发，可大大提升性能。在Mesos中，在任意一个时刻，Mesos资源调度器只会将所有资源推送给任意一个框架，等到该框架返回资源使用情况后，才能够将资源推动给其他框架，因此，Mesos资源调度器中实际上有一个全局锁，这大大限制了系统并发性。

原文转自：http://blogread.cn/it/article/6387?f=wb