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

标签: 技术资料 | 发表时间:2013-04-24 13:10 | 作者:唐福林
分享到:
出处:http://blog.fulin.org

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

(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。

4. 总结

除了以上讨论的几点外,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

转载自董的博客: http://dongxicheng.org/mapreduce-nextgen/google-omega/  作者:Dong

相关 [解析 google 集群] 推荐:

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

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

Quartz集群实战及原理解析

- - CSDN博客推荐文章
  选Quartz的团队基本上是冲着Quartz本身实现的集群去的, 不然JDK自带Timer就可以实现相同的功能, 而Timer存在的单点故障是生产环境上所不能容忍的. 在自己造个有负载均衡和支持集群(高可用、伸缩性)的调度框架又影响项目的进度, 所以大多数团队都直接使用了Quartz来作为调度框架.

Galera:多主同步MySQL集群原理解析

- - 进击的程序猿
Galera Cluster是基于MySQL/innodb二次开发而成的一个支持“多主同步”的数据库主从集群. 强调主从集群意味着Galera Cluster的每个节点充当一个数据冗余,而没有在节点间做分库分表的水平扩展. Galaer官网中为Galera Cluster洋洋洒洒罗列了10大优势,其实总结下来无非上文用引号注明的两点:.

解析世界之搜索—新Google Trends

- - Google China Blog
发表者:Yossi Matias,高级搜索主管,以色列研发中心负责人. 自我们推出Google Trends和Google Insights for Search以来,我们已经看到数百万的用户使用Google Trends紧跟在线趋势热点;全球还有许多记者、企业家及研究人员使用Google Insights for Search来对比不同时代、不同地区的搜索热词.

Google的GSON框架解析JSON数据

- - JavaScript - Web前端 - ITeye博客
JSON即JavaScript Object Natation, 它是一种轻量级的数据交换格式, 与XML一样, 是广泛被采用的客户端和服务端交互的解决方案. JSON中对象(Object)以"{"开始, 以"}"结束. 对象中的每一个item都是一个key-value对, 表现为"key:value"的形式, key-value对之间使用逗号分隔.

[在线体验]谷歌社交产品google+功能全解析

- xbin999 - SocialBeta
据国外媒体报道,google推出新的社交产品Google+,Google+与Facebook在外观界面上有一些相似之处. Google+是在过去的一年中google的最高机密,虽然有很多消息被泄露出来. Google+ 目前正在进行小范围的试用. 下面我们来逐一简单介绍下google+有哪些功能. 我们经常会遇到的一个问题是:有些内容只想分享给特定的人,但是现实中很多社交产品都不能解决这个问题.

谷奥: Google 为我们解析“不可思议”是什么

- Jo - 谷奥聚合——谷奥主站+谷安 aggregator
想知道什么是不可思议,Google 来告诉你. 将“不可思议”作为关键词,扔进 Google.com.hk 的搜索框,别急着按回车,将鼠标移动到 Google 搜索按钮上,闭上眼,深呼吸~手指在鼠标上用力的按一下. 看到结果上方计算器的 onebox 了吗. 不可思议 = 1.0 x 10^64. UPDATE:感谢读者 francis 在留言中的提醒,原来这个火星了,与G共舞早在2008年就做过相关报道并且解释过:.

集群概念

- - 开源软件 - ITeye博客
        集群是一组协同工作的服务实体,用以提供比单一服务实体更具扩展性与可用性的服务平台. 在客户端看来,一个集群就象是一个服务实体,但 事实上集群由一组服务实体组成.         与单一服务实体相比较,集群提供了以下两个关键特性:.        1.可扩展性--集群的性能不限于单一的服务实体,新的服 务实体可以动态地加入到集群,从而增强集群的性能.

谷奥: Google = Google+

- 吞佛 - 谷奥聚合——谷奥主站+谷安 aggregator
在上周举办的Google Zeitgeist 2011大会上,John Battelle问Larry Page:在Google大部分的历史里,人们会想到搜索,那么Google品牌=搜索. 但在随后Google的发展史里,Google品牌会等于什么. Larry Page并未直面回答这个问题,至少没有从市场角度来回答.

MYSQL集群介绍

- - 企业架构 - ITeye博客
MySQL Proxy是一个处于你的client端和MySQL server端之间的简单程序,它可以监测、分析或改变它们的通信. 它使用灵活,没有限制,常见的用途包括:负载平衡,故障、查询分析,查询过滤和修改等等. MySQL Proxy就是这么一个中间层代理,简单的说,MySQL Proxy就是一个连接池,负责将前台应用的连接请求转发给后台的数据库,并且通过使用lua脚本,可以实现复杂的连接控制和过滤,从而实现读写分离和负载平衡.