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

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

   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资源调度器中实际上有一个全局锁，这大大限制了系统并发性。

   (3) 共享状态调度器(Shared State Scheduler)

   为了克服双层调度器的以上两个缺点，Google开发了下一代资源管理系统Omega，Omega是一种基于共享状态的调度器，该调度器将双层调度器中的集中式资源调度模块简化成了一些持久化的共享数据(状态)和针对这些数据的验证代码，而这里的“共享数据”实际上就是整个集群的实时资源使用信息。一旦引入共享数据后，共享数据的并发访问方式就成为该系统设计的核心，而Omega则采用了传统数据库中基于多版本的并发访问控制方式(也称为“乐观锁”, MVCC, Multi-Version Concurrency Control)，这大大提升了Omega的并发性。

   由于Omega不再有集中式的调度模块，因此，不能像Mesos或者YARN那样，在一个统一模块中完成以下功能：对整个集群中的所有资源分组，限制每类应用程序的资源使用量，限制每个用户的资源使用量等，这些全部由各个应用程序调度器自我管理和控制，根据论文所述，Omega只是将优先级这一限制放到了共享数据的验证代码中，即当同时由多个应用程序申请同一份资源时，优先级最高的那个应用程序将获得该资源，其他资源限制全部下放到各个子调度器。

   引入多版本并发控制后，限制该机制性能的一个因素是资源访问冲突的次数，冲突次数越多，系统性能下降的越快，而google通过实际负载测试证明，这种方式的冲突次数是完全可以接受的。

   Omega论文中谈到，Omega是从Google现有系统上演化而来的。既然这篇论文只介绍了Omega的调度器架构，我们可推测它的整体架构类似于Mesos，这样，如果你了解Mesos，那么可知道，我们可以通过仅修改Mesos的Master将之改造成一个Omega。

   除了以上讨论的几点外，Omega论文还谈到了集群管理系统的其他方面，比如不同的资源分配方式的优缺点，当前有两种资源分配方式，分别是：“all-or-nothing”和“incremental placement”，在此举例说明：一个任务需要2GB内存，而一个节点剩余1GB，若将这1GB内存分配给该任务，则需等待将节点释放另外1GB内存才可运行该任务，这种方式称为“incremental placement”，Hadoop YARN采用了这种增量资源分配的方式，而如果只为该任务选择剩余节点超过2GB内存的节点，其他不考虑，则称为“all-or-nothing”，Mesos和Omega均采用了这种方式。两种方式各有优缺点，“all-or-nothing”可能会造成作业饿死(大资源需求的任务永远得到不需要的资源)，而“incremental placement”会造成资源长时间闲置，同时可也能导致作业饿死，比如一个服务需要10GB内存，当前一个节点上剩余8GB，调度器将这些资源分配给它并等待其他任务释放2GB，然而，由于其他任务运行时间非常长，可能短时间内不会释放，这样，该服务将长时间得不到运行。

   从Omega论文发表时间和使用的数据时间可看出，Omega在google内部是一个比较新的系统，而开源界(Mesos，YARN)的类似系统已经在开发中，虽然当前不稳定，但稳定版不久将推出，由于Omega与Mesos/YARN架构的不同主要体现在资源分配模块，因此，我们很容易通过改造Mesos或者YARN的“Resource Master”模块将其改造成一个类似于Omega的系统。我说这句话的意思是，开源软件已走得很快，普通公司，如果人力不足的话，就跟着开源走吧。

   5. 推荐阅读

   (1)http://www.wired.com/wiredenterprise/2013/04/google-john-wilkes-new-hackers/

   (2)Multi-agent Cluster Scheduling for Scalability and Flexibility

   (3)Omega: flexible, scalable schedulers for large compute clusters

   (4)Return of the Borg: How Twitter Rebuilt Google’s Secret Weapon

   (5)Google Omega PPT： http://vdisk.weibo.com/s/yLOtZ

建议继续学习：