当前位置: 首页>>hadoop 2.0之YARN>> 阅读正文

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

Category: hadoop 2.0之YARN View: 22,637 Author: Dong
, ,

  • 评论 (5)
  • 引用通告 (0)
发表评论 发起引用

  • 1楼Binos_ICT 回复

    Post: 2013-04-24 01:14

    1)Mesos在任何一个时刻,只能将所有资源推送给一个框架?

    2)个人感觉,OMega更像是安装了Zookeeper的协同资源管理器,这里通过自治把控制权限下方给各个资源实体。但是,我觉得这个更像是实验产品,google大规模使用的应该还是第二代。

    [回复]

    Dong 回复:

    1)是,Mesos用的是悲观锁。
    2)Mesos很容易改造成Omega:Mesos Master同时将集群所有状态并发推送给各个Scheduler,然后Scheduler提交资源请求给Master,Master再解决冲突(可采用MVCC),这就变成了Omega,具体流程见我参考资料的第二篇论文,这是Omega论文作者之一,博士毕业论文。
    Omega确实还没有开始投入使用,但已经进入测试阶段(具体见我的第一参考文献,原话:Google is only just beginning to test the system in its data centers),但它2011年就已经在开发中了(具体见我的地5个参考文献)。

    [回复]

  • 2楼Francis 回复

    Post: 2013-04-24 02:39

    非常感谢博主把这么好的内容如此及时的总结出来。

    [回复]

  • 3楼实习生 回复

    Post: 2013-04-25 07:26

    谢谢博主总结,关于omega与yarn怎么比较呢,yarn是每一个AM采用的request+RM响应的方式更接近于omega中子调度器decision-making+atomic commit的方式。还有就是为什么omega论文中会将yarn归结于单层调度器?

    [回复]

    Dong 回复:

    我读录论文的时候,感觉到这个Omega作者不太熟悉YARN,YARN应该归结到双层调度器的范畴。另外,YARN跟mesos类似,同属双层调度器,但还不是共享状态,因为每个AM收到的是整个集群的部分资源,且所有AM用的资源不会交叉,且不会竞争同一个资源,换句话说,在YARN中,资源调度时串行的(由RM中的调度器统一分配,是串行进行的),而资源在AM中二次分配是并行的(各个AM相互独立,并行进行),而Omega则不同,它的资源调度和资源二次分配都是并发的,这就是它更高效的原因,此外,它的每个调度器可看到全部的资源使用信息,并参与资源竞争。推荐你看我在本文中最后的参考文祥中的第二个参考文献,这是Omeaga作者之一的博士论文。

    [回复]

    实习生 回复:

    博士论文已经开始看了,不过关于yarn又有迷惑了,分派给am的资源是不会动态改变了,一次资源的划分就是am的生命周期?
    还有就是关于mesos/yarn改造为类omega,就是omega关于任务划分后对service job的性能保护措施主要在什么方面体现?

    [回复]

    Dong 回复:

    (1)在YARN中,资源的分配是动态的,AM向RM申请10个2GB内存,RM不一定一下子全给它,可能先给2个,过段时间再给3个,等等,这取决于RM中的调度策略。对于AM而言,收到分配的资源后,可以拒绝这些资源,重新申请。当AM对应的作业运行完成后,AM才退出,也就是,生命周期结束,关于YARN的更多知识,可参考我的文章:http://dongxicheng.org/recommend/
    (2)我没明白你说的Omega任务划分什么的 啥意思。 任务划分是各个scheduler的事情,比如MapReduce的scheduler负责MR作业的任务划分,MPI的scheduler负责MPI作业的任务划分。在Omega中,所有scheduler(或者叫做framework)可看到整个系统的资源,然后竞争这些资源,而YARN是每个scheduler(或者叫做framework)看不到集群整体资源,RM给他分什么,他就用什么。

    [回复]

    实习生 回复:

    非常感谢您不断的教导,任务划分是我自己的叫法,可能有问题。就是omega中workload heterogeneity部分,介绍说任务主要分为throughout sensitive的batch job,数量多,耗时少和latency sensitive的service job,需要更多的可用性和新能要求。然后关于service job的性能保护措施体主要有哪些方面体现?这中保护在看yarn中我也比较疑惑?

    [回复]

    Dong 回复:

    YARN现在的假设是只擅长运行短作业,这种作业有个特点是,当其失败后,可以通过重新计算的方式快速容错。 但是service类型的就不行,比如说一个web service,要一直对外提供服务,不能随便失败,因此,这种作业应该运行在质量较好的节点上,而YARN是不区分节点质量的。
    另外,我的新书已经可以在当当网上预订了,欢迎预订,具体可参见:http://dongxicheng.org/hadoop-internals-mapreduce/

    [回复]

    Francis 回复:

    分析的好!

    [回复]

  • 4楼一见 回复

    Post: 2013-05-05 04:14

    Torca在朱慧灿来之前就有了,真正的创始人是现高德副总裁陈军(http://t.qq.com/junche88)

    [回复]

    Dong 回复:

    你说的对,不过,陈军也是美国google过来的,属于朱会灿的手下, 朱会灿在google内部是华人工程师中级别最高的。另外,陈军离职于torca上线不稳定时(出现若干次故障),作为leader,这也许。。。

    [回复]

  • 5楼Roy 回复

    Post: 2013-05-09 18:45

    博主你好,
    在看这类论文的时候有些疑问,

    1. 这些集群资源管理系统实务上会搭配虚拟化技术吗?意思是会把这套系统用在虚拟化机器上吗?虚拟化技术有项优点是利用Migration调整负载平衡,虽然会有虚拟化的负担这项缺点。想知道博主的看法

    2. 在当今有些IaaS Cloud的出现,像Yarn或者Omega 的架构适合在集群负荷不了的时候像这些IaaS 供应商暂时租借机器来应付工作量吗?还是实务上这不实际? 我个人认为在YARN这种架构上,因为资料量很大,资料传输速度以及价格会让这样的方法显的不实际,不知道博主的看法?

    感谢!

    [回复]

    Dong 回复:

    1. 虚拟化是重量级解决方案,这种系统采用轻量级方案linux container或者cgroups, 又称为轻量级弹性计算平台
    2. YARN这种系统一般是公司内部使用的,不涉及到共有云之类的,如果资源不够,可以自己购买机器进行扩容。

    [回复]

    Roy 回复:

    谢谢博主的指教,想再请教一个问题,
    这边博主指的LXC,是指Yarn里面task执行时NodeManager所开的container环境吗?还是指Yarn的Component会架在LXC的container之上?
    这边想请教的是,博主在上面的回覆讨论串中,指出YARN所支援的Software Framework是属于短作业类型,不支援Service类型。因此我归结出,Service Job的资源管理不在YARN的架构内,这样的话,如何让Service 跟YARN一起共享到整个集群的资源? 有什么方式做资源分配决定的自动化吗?我想的到的方式就是每台机器上面先利用起如博主所说的轻量级方案LXC开启Containers,在Containers里面在分别架设yarn (Node Manager) 或者是service,在利用Container监控的软体,动态的调整实体机器上Container的资源分配(以Service为优先考量)。不知道这样的作法常不常见,还是说一般都会用更简单直接的方法,把机器一群给Service,一群拿来架设YARN?
    感谢

    [回复]

    Dong 回复:

    不是service job不可以运行在YARN中,由YARN进行管理,而是由于service job对容错性和资源质量有更高的要求,而这时YARN没有考虑的,比如,如果是service job,应尽量运行在质量高的节点上,且失败后,应尽量在本地重启,如果重启失败,再在别的节点启动,等等。YARN中container只是一种表示方式,不同于LXC,container中有任务的运行命令,是运行在LXC中的。

    [回复]

    Dong 回复:

    你的问题比较混乱,希望能重新组织一些,有条理一些,比如(1)(2)(3)。。。。

    [回复]

    Roy 回复:

    了解,非常抱歉没有把问题组织好,谢谢Dong的指教!

    [回复]

目前还没有任何Trackbacks和Pingbacks.
发表评论