1. 背景

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

而在近期,Google公布了它的下一代集群管理系统Omega下载地址)的设计细节。论文中谈到Google经历的三代资源调度器的架构,分别是中央式调度器架构(类似于Hadoop JobTracker,但是支持多种类型作业调度)、双层调度器架构(类似于Apache MesosHadoop 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 MesosHadoop YARN。Omega论文重点介绍了MesosMesos是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/

解析Google集群资源管理系统Omega的更多相关文章

  1. 如何提升集群资源利用率? 阿里容器调度系统Sigma 深入解析

    阿里妹导读:为了保证系统的在线交易服务顺利运转,最初几年,阿里都是在双11大促来临之前大量采购机器储备计算资源,导致了双11之后资源大量闲置点现象.是否能把计算任务与在线服务进行混合部署,在现有弹性资 ...

  2. 利用yarn capacity scheduler在EMR集群上实现大集群的多租户的集群资源隔离和quota限制

    转自:https://m.aliyun.com/yunqi/articles/79700 背景 使用过hadoop的人基本都会考虑集群里面资源的调度和优先级的问题,假设你现在所在的公司有一个大hado ...

  3. dubbo源码解析五 --- 集群容错架构设计与原理分析

    欢迎来我的 Star Followers 后期后继续更新Dubbo别的文章 Dubbo 源码分析系列之一环境搭建 博客园 Dubbo 入门之二 --- 项目结构解析 博客园 Dubbo 源码分析系列之 ...

  4. Keepalived详解(四):通过vrrp_script实现对集群资源的监控【转】

    一.通过vrrp_script实现对集群资源的监控: Keepalived基础HA功能时用到了vrrp_script这个模块,此模块专门用于对集群中服务资源进行监控.与此模块一起使用的还有track_ ...

  5. 部署AlwaysOn第三步:集群资源组的健康检测和故障转移

    资源组是由一个或多个资源组成的组,WSFC的故障转移是以资源组为单位的,资源组中的资源是相互依赖的.一个资源所依赖的其他资源必须和该资源处于同一个资源组,跨资源组的依赖关系是不存在的.在任何时刻,每个 ...

  6. Prometheus 监控K8S集群资源监控

    Prometheus 监控K8S集群中Pod 目前cAdvisor集成到了kubelet组件内,可以在kubernetes集群中每个启动了kubelet的节点使用cAdvisor提供的metrics接 ...

  7. 在 TKE 中使用 Velero 迁移复制集群资源

    概述 Velero(以前称为Heptio Ark)是一个开源工具,可以安全地备份和还原,执行灾难恢复以及迁移 Kubernetes 群集资源和持久卷,可以在 TKE 集群或自建 Kubernetes ...

  8. 使用 Velero 跨云平台迁移集群资源到 TKE

    概述 Velero 是一个非常强大的开源工具,可以安全地备份和还原,执行灾难恢复以及迁移Kubernetes群集资源和持久卷,可以在 TKE 平台上使用 Velero 备份.还原和迁移集群资源,关于如 ...

  9. 使用 Admission Webhook 机制实现多集群资源配额控制

    1 要解决的问题 集群分配给多个用户使用时,需要使用配额以限制用户的资源使用,包括 CPU 核数.内存大小.GPU 卡数等,以防止资源被某些用户耗尽,造成不公平的资源分配. 大多数情况下,集群原生的 ...

随机推荐

  1. Java 8 – Filter a null value from a Stream

    Java 8 – Filter a null value from a Stream package com.mkyong.java8; import java.util.List;import ja ...

  2. mysql存储过程基础

    存储过程简介 SQL语句需要先编译然后执行,而存储过程(Stored Procedure)是一组为了完成特定功能的SQL语句集,经编译后存储在数据库中,用户通过指定存储过程的名字并给定参数(如果该存储 ...

  3. 关于Big Endian 和 Little Endian

    Big Endian 和 Little Endian 一.字节序 来自:http://ayazh.gjjblog.com/archives/1058846/ 谈到字节序的问题,必然牵涉到两大CPU派系 ...

  4. [Golang] 从零开始写Socket Server(1): Socket-Client框架

    版权声明:本文为博主原创文章,未经博主允许不得转载. 第一次跑到互联网公司实习 ..感觉自己进步飞快啊~第一周刚写了个HTTP服务器用于微信公共号的点餐系统~ 第二周就直接开始一边自学Go语言一边写用 ...

  5. Eclipse maven问题汇总

    在使用eclipse+maven的过程中,遇到一系列问题,先汇总记录如下: 1. 在java工程中,缺少Maven依赖: 这个问题比较棘手,一般都对eclispe的工程结构不是很了解,后来经过长时间的 ...

  6. Vue(七):computed计算属性

    简介 计算属性关键词: computed. 计算属性在处理一些复杂逻辑时是很有用的. 实例1 可以看下以下反转字符串的例子: <div id="app"> {{ mes ...

  7. memcached(一):linux下memcached安装以及启动

    一. 安装文件 Linux系统安装memcached,首先要先安装libevent库. 下载memcached与libevent的安装文件 http://memcached.org/files/mem ...

  8. 开始学习使用 Semantic UI

    最近在找一个功能比较丰富的前端框架,之前一直使用的Bootstrap,感觉组件还是不够丰富,很多东西都需要不少自定义.于是就发现了 Semantic UI. 不过感觉网上相关的中文资料好少,官方网站( ...

  9. Android: TextView 及其子类通过代码和 XML 设置字体大小的存在差异的分析

    原因: 在代码中通过 setTextSize(float size) 设置,使用的是 sp 为默认单位. 而 XML 中使用了 px,所以需要使用先把做好 sp 和 px 的转换工作. 最近在做 ap ...

  10. Vue2 原理解析

    现代主流框架均使用一种数据=>视图的方式,隐藏了繁琐的dom操作,采用了声明式编程(Declarative Programming)替代了过去的类jquery的命令式编程(Imperative ...