Google于2013年和2015年分别公开了它的实验和生产环境中使用的数据中心资源管理系统Omega和Borg,其中Omega是一个实验产品,由几个实习生博士做出了原型, 比较新颖地提出了share state架构,是一种非常理想的架构,但个人认为离完全替换Borg还有一段距离,即使替换,在短时间内仍然不能完全替换,因此本文不会过多讨论(关于Omega的细节,也可参考我的这篇文章:“解析Google集群资源管理系统Omega”,链接:http://dongxicheng.org/mapreduce-nextgen/google-omega/)。 而Borg作为一个成熟的系统,已经在google内部使用了相当长的时间,Borg论文称,google内部不仅像计算型的应用,比如MapReduce,FlumeJava,Millwheel,和Pregel 运行在Borg上,存储类的应用,比如GFS,BigTable和Megastore等也运行在上面,真正做到了批处理作业和长服务混合部署动态调度。本文从笔者角度,对比了开源资源管理系统YARN/Mesos与Borg的差距(我曾经写过一篇非常浅显的对比文章,可参考“浅谈Borg/YARN/Mesos/Torca/Corona一类系统”,链接:http://dongxicheng.org/mapreduce-nextgen/borg-yarn-mesos-torca-corona/),由于笔者能力的局限性,文中很多观点可能会片面,浅显,望各位本着交流的心态,客观地阅读本文。

建造数据中心非常昂贵,因此我们必须用好它。 各大公司都在尝试用好自己的数据中心。根据几家互联网巨头这些年的实践,用好数据中心的常用手段是构建资源管理系统,对上次的各类应用进行统一管理和调度,进而达到简化数据中心运维,提高集群利用率的目的。细数国内外互联网巨头,他们都有自己的资源管理系统,比如Google的Borg,Twitter的Mesos,阿里巴巴的Fuxi,微软的Apollo等。本文涉及到的Google Borg相关内容,主要参考了论文“Large-scale cluster management at Google with Borg”,不了解Borg的读者,可自行阅读该论文。

1.架构对比

Google Borg采用了集中式master/slave架构 (Borgmaster和Borglet),其中Borgmaster负责集群资源管理和调度,Borglet负责执行实际的任务,Borgmaster通常有5个实例,通过Paxos协议组成一个高可用分布式集群;Borgmaster会周期性地主动poll各个Borglet以获取其状态和资源使用情况,一旦发现其出现问题,会触发容错,之所以采用poll,而不是像YARN/meso采用心跳机制,主要是考虑到这种方式能够更容易地控制网络通信开销,避免active Borgmaster选举时出现网络风暴等。前面提到Borg中存在5个Borgmaste,他们每个会分管一部分Borglet的状态获取和探测,并将收到的信息压缩和求差后,交给active Borgmaster,以分摊active Borgmaster压力。从这种细粒度的设计可以初探端倪:Borg尽管采用了集中式架构,但扩展性仍很好,对应Borg论文中这句话“We are not sure where the ultimate scalability limit to Borg’s centralized architecture will come from; so far, every time we have approached a limit, we’ve managed to eliminate it.”

开源系统YARN和Mesos均采用了双层调度架构,需要注意的是,google在论文omega和borg中均认为YARN是集中式架构,而把Mesos划归为双层调度架构,个人认为这是不准确的,YARN跟Mesos类似,ResourceManager负责集群调度,ApplicationMaster负责framework和应用程序内部调度,相比Mesos,由于YARN的ResourceManager要维护各个分配出去的Container的状态和位置等信息,因此,要比Mesos Master重一些。YARN和Mesos的Master均采用Zookeeper解决高可用问题,其中active master进行资源管理和调度,而backup master仅仅是backup作用,不会协助active master做任何事情;Slave会主动通过周期性心跳向Master汇报状态信息。

  • 扩展性

Borg对所管理的所有borglet进行了水平分片,让每个 Borgmaster分管一部分,这些borgmaster共享集群元信息,每个Borgmaster均可以为应用程序分配资源,但backup Borgmaster需要将分配信息发送给active Borgmaster进行审批,这个地方与Google Omega中的share state是一致的。在这方面,YARN和Mesos均是做不到,他们只有一个master进行资源管理和调度,在超大集群中,master可能会成为瓶颈,这是YARN和Mesos需要改进的方向。

  • 高可用

应用程序方面:Borg内置了各种错误重试机制,确保在机器故障,网络故障等情况下,应用程序不会失败。

服务方面:Borgmaster和Borglet挂掉后,其上正在运行的应用程序和任务不会受影响,这一点,目前Mesos和YARN已经做到。

2.对批处理作业和长服务的支持

为了简化应用程序分类,Borg把应用程序分成两类,批处理作业和长服务,批处理作业是类似于MapReduce和Spark的作业,在一定时间内会运行结束,长服务则类似于web service,HDFS service等,可能会永久运行下去,永不停止。批处理作业和长服务是绝配,混合部署它们对提高集群利用率是非常有帮助的,长服务占用大块资源,而批处理作业穿插到长服务未使用的小块资源中,当高优先级的应用需要资源时,可直接杀死抢占批处理作业。根据borg和omega论文的描述,在google集群中,长服务占用了集群中70%~80%的资源。

Mesos和YARN均对批处理作业有良好的支持,这类应用的支持也是最简单的,而难点在于长服务,一旦引入长服务,会带来以下问题:

(1)资源竞争与饿死问题。 当一个集群中只存在批处理作业时,资源调度是很容易做的,因为资源释放和申请是不断在进行中的,任何资源的申请都可以得到满足。但存在长服务后则不同,因为目前主流的调度器均采用资源预留的调度机器,比如一个作业需要10G内存,目前没有任何节点存在10GB内存呢,为了避免永远拿不到资源,调度器会找一个存在部分资源的节点,比如node1存在6GB内存,则会为该作业预留着,一直等到再次释放出4GB ,则将node1上的10GB内存分配给该作业,整个过程在批处理场景中能自然的发生,一旦加入长服务后,则可能产生饿死现象,也就是说node1上的4GB内存可能永远等不到,因为可能被长服务占着。在这方面,Borg做得很好,但mesos和YARN均存在饿死问题,目前无法解决。

(2)服务高可用问题。 资源管理系统一旦支持长服务后,应保证系统服务出现故障时,上层的长服务不会受到应用,比如在YARN中,ResourceManager或者NodeManager出现故障后,其上运行的长服务,比如MySQL,不应受到影响,到恢复后,重新接管这些服务。这一点,Borg/Mesos/YARN(本文指的是Hadoop 2.6.0之后的版本)均已经支持。

(3)日志收集和滚动。 长服务永不停止,为了方面排错和监控,长服务的日志收集也是需要解决的,Borg/Mesos/YARN在这一块均有很好地支持,其中mesos/YARN可通过上层框架解决,比如Mesos中的 aurora和Marathon(apache顶级项目),YARN中的Twill和Slider(Apache二级项目)。

(4)服务发现。长服务部署到资源管系统中后,可能被调度运行到任意一个节点上,为了让外界的访问者(客户端)发现自己的位置,需要有一个服务注册组件登记这些长服务,Borg/Mesos/YARN均对服务注册有支持,Mesos可通过上层框架,比如Aurora,YARN内核内置了对服务注册的支持。

(5)资源伸缩。长服务运行一段时间后,由于访问量的增加或减少,可能需要动态调整所使用的资源量。资源伸缩有两个维度:一个是横向的,即增加实例数目;另一方面是纵向的,即原地增加正在运行实例的资源量。这方面Borg/Mesos/YARN均已经支持,其中横向支持是通过上层框架实现的,而纵向支持是通过资源管理系统内核支持的(https://issues.apache.org/jira/browse/YARN-1197 )。

(6)服务配置更新和在线升级。 这一块均与资源管理系统无直接关系,一般通过上层的框架实现。

3.其他实现机制

(1)资源预申请(在borg论文中,称之为“alloc”)。应用程序可以预申请一些资源,可用于快速启动一些低延迟task,动态扩容等方面使用。 这一块mesos和yarn没有直接支持。在mesos和yarn中,应用框架申请到资源后,必须在一定时间内使用,如果未使用,mesos和yarn会进行回收。 实际上,mesos和yarn可以在上层框架层面解决这一问题,比如hive on Tez则实现了资源预申请,具体可参考我的这篇文章:“Tez:运行在YARN上的DAG计算框架”:http://dongxicheng.org/mapreduce-nextgen/tez-yarn-dag/。

(2)作业优先级与资源抢占。在一个混合应用部署的集群中,抢占是必须要支持的,为了支持抢占,必须提前合理规划好应用程序的优先级,以便于在一些情况下,为高优先级的作业抢占低优先级作业的资源。 资源抢占在YARN中以及得到了支持,但没能够用在批处理和长服务混合资源调度中。实际上,在YARN中,资源抢占仅仅用于队列回收资源的场景中。

(3)份额限制(Quota)和进入控制(admission control)

为了防止应用程序无限制申请资源,满足长服务的SLA,需要由一套完善的admission control机制,在开源实现中,YARN在2.6.0开始加入了这一套机制,具体参考:https://issues.apache.org/jira/browse/YARN-1051

4.总结

目前看来,Mesos/YARN的架构和设计上,与Google Borg仍有一定的差距,但需要注意的是,很多细节之处,都是tradeoff的结果,很难说哪种机制更适合我们的场景,对于搭建中小型的集群和数据中心,Mesos/YARN已经搓搓有余了。

5.参考资料

(1)google paper:Large-scale cluster management at Google with Borg

(2)google paper:Omega: flexible, scalable schedulers for large compute clusters

(3)YARN paper:Apache Hadoop YARN: Yet Another Resource Negotiator

(4)YARN书籍:“Hadoop技术内幕:深入分析YARN基本架构和原理”

(5)Apache slider:http://slider.incubator.apache.org/

(6)Apache Twill:http://twill.incubator.apache.org/

(7)Apache Aurora:http://aurora.apache.org/

(8)Apache marathon:https://mesosphere.github.io/marathon/

(9)Mesos paper:Mesos: A Platform for Fine-Grained Resource Sharing in the Data Center

原创文章,转载请注明: 转载自董的博客

本文链接地址: Apache YARN/Mesos与Google Borg差距多远?

微信公众号:hadoop-123,专注于大数据技术分享,欢迎加入!

说点什么

avatar
  Subscribe  
提醒