资源管理框架（mesos/YARN/coraca/Torca/Omega)选型分析

1 资源调度的目标和价值

1.1 子系统高效调度

任务之间资源隔离，减少争抢。 任务分配调度时结合资源分配，各个任务分配合理的资源，充分利用系统资源，减少资源利用不充分的问题。 资源调度结合优先级，优先级高的分配更多的资源。

1.2 提高全系统的资源利用率

各个子系统，存在不同时期，对资源需求不一样的情况，平滑系统资源的利用。

1.3 支持动态调整切分资源，增强系统扩展性。

系统对资源的规划很难一次性准确，通过mesos支持虚拟主机的方式，动态扩展。

2 资源调度使用限制以及难点

2.1 资源调度使用限制

资源调度是为了提高资源利用率，分配本身是存在一定的开销的，对实时性要求非常高的应用不适合(毫秒，秒级别的应用)。

2.2 应用（框架）比较难规划资源

资源框架通过算法分配资源，但是每个细粒度的具体的任务对资源的需求非常难预估。规划如果偏差比较大，反而会降低系统本身的性能。

2.3 mem使用分配难题 

JVM虚拟机存在内存回收的问题，这个不是程序本身是不能干涉的。内存很难分配准确，如果内存分配过少会导致任务失败。分配过多，造成资源浪费。

3 业界资源调度框架

3.1 Mesos

3.1.1 背景

Mesos诞生于UC Berkeley的一个研究项目，现已成为Apache Incubator中的项目，当前有一些公司使用Mesos管理集群资源，比如Twitter。

3.1.2 架构



 

总体上看，Mesos是一个master/slave结构，其中，master是非常轻量级的，仅保存了framework（各种计算框架称为framework）和mesos slave的一些状态，而这些状态很容易通过framework和slave重新注册而重构，因而很容易使用了zookeeper解决mesos master的单点故障问题。

Mesos master实际上是一个全局资源调度器，采用某种策略将某个slave上的空闲资源分配给某一个framework，各种framework通过自己的调度器向Mesos master注册，以接入到Mesos中；而Mesos slave主要功能是汇报任务的状态和启动各个framework的executor（比如Hadoop的excutor就是TaskTracker）。

整个mesos系统采用了双层调度框架：第一层，由mesos将资源分配给框架；第二层，框架自己的调度器将资源分配给自己内部的任务。

在Mesos中，各种计算框架是完全融入Mesos中的，也就是说，如果你想在Mesos中添加一个新的计算框架，首先需要在Mesos中部署一套该框架； Mesos采用linux container对内存和cpu进行隔离。

3.1.3 优点

可以同时支持短类型任务以及长类型服务，比如webservice以及SQL service。 资源分配粒度粗，比较适合我们产品多种计算框架并存的现状。

3.1.4 缺点

Mesos中的DRF调度算法过分的追求公平，没有考虑到实际的应用需求。在实际生产线上，往往需要类似于Hadoop中Capacity Scheduler的调度机制，将所有资源分成若干个queue，每个queue分配一定量的资源，每个user有一定的资源使用上限；更使用的调度策略是应该支持每个queue可单独定制自己的调度器策略，如：FIFO，Priority等。

由于Mesos采用了双层调度机制，在实际调度时，将面临设计决策问题：第一层和第二层调度器分别实现哪几个调度机制，即：将大部分调度机制放到第一层调度器，还是第一层调度器仅支持简单的资源分配（分配比例由管理员指定）？

Mesos采用了Resource Offer机制（不同于Hadoop中的基
901b
于slot的调度机制），这种调度机制面临着资源碎片问题，即：每个节点上的资源不可能全部被分配完，剩下的一点可能不足以让任何任务运行，这样，便产生了类似于操作系统中的内存碎片问题。

3.2 YARN(Coroca)

3.2.1 背景

从hadoop 1.0发展而来，解决了hadoop1.0的单管理节点两个主要问题：

1、 单管理节点性能瓶颈。一个管理节点能管理的服务器不能无上限。

2、 Hadoop 1.0按照slot来划分资源，map slot的资源不能共享给reduce slot。造成资源浪费 很多公司都切换到hadoop 2.0，如淘宝天梯已经淘汰1.0，上线2.0。

3.2.2 架构