论文阅读笔记 - Mesos: A Platform for Fine-Grained ResourceSharing in the Data Center

作者：刘旭晖 Raymond 转载请注明出处

Email：colorant at 163.com

BLOG：http://blog.csdn.net/colorant/

更多论文阅读笔记 http://blog.csdn.net/colorant/article/details/8256145

 

== 目标问题 ==

 

为了提高资源的利用率以及满足不同应用的需求，在同一集群内会部署各种不同的分布式运算框架(cluster computing framework)，他们有着各自的调度逻辑。 Mesos的目标就是在不同的framework之间高效的共享硬件资源，同时简化自身的调度逻辑，使其具有尽可能大的兼容性和可扩展性，以保证在大规模集群使用环境下的鲁棒性和对各种可能的运算框架的普遍适用性。

 

== 核心思想 ==

 

Mesos本质上是一个两级的分布式资源调度框架，Mesos框架本身并不负责资源最终的具体调度，而是将这一任务交给具体的运算框架的调度逻辑来执行。不同的运算框架可以自己的调度逻辑。当然，Mesos还是需要负责将可用资源提交给各个调度框架供他们调度，所以严格的来说，也是承担了预调度的任务。

 

 

要使用Mesos管理资源调度，具体的运算框架需要将自己的调度逻辑注册到Mesos的master节点上，另外还需要将具体执行任务的逻辑注册到每一个Mesos的Slave节点上。

  

 

每个Mesos Slave节点将本节点上的可用资源报告给Master节点，Master节点再将可用资源按一定的逻辑（如公平调度，优先级调度等）提供给各个具体的运算框架的调度进程。具体的调度进程在决定将这些资源部分或全部分配给特定的任务，同时把所分配的任务-资源关系列表返回给master节点，master节点进而将这些任务提交给对应的slave节点执行。

 

== 实现 ==

 

为了保证Master节点的可用性，Mesos使用zookeeper维护多个备用Master节点。同时Master节点仅维护最简单的必需的状态如活跃的Slave节点，注册的运算框架和运行中的任务等，当前主节点失效后，Slave和Scheduler将连接新的主节点并恢复这些状态。

 

master节点上的资源预调度逻辑也是模块化的，可以按需实现不同的策略。

 

不同的运算框架对所需的资源必然会有一定的偏好和要求，为了减轻Master节点的负担，具体的调度逻辑并不向Master节点注册预分配算法，如果Master节点提供给他们的资源不满足需求的话，具体的调度进程只是简单的拒绝这些资源。不过，为了提高效率，具体的调度进程还是可以注册类似白名单列表之类的Filter供Master节点预先筛除不满足要求的资源。

 

分配给任务特定资源和该任务实际使用的资源是两回事，如果不能有效的限制任务实际使用的资源，那么资源调度的意义大概会打折扣。Mesos在Linux环境下使用Linux container来限制任务所能使用的硬件资源。

 

== 相关研究，项目等 ==

 

YARN ：做为Hadoop2.0使用的调度框架，同样采用两级的调度逻辑，解决类似的问题。

 

== 其它 ==

 

分布式调度系统的一个问题在于缺乏集中式的全局规划，可能导致各种非最优调度的情况。比如当规模大小不同的Job混合运行的时候，可能小Job的资源需求能够迅速得到满足而不断的得到执行，而大Job的资源很难得到满足而无法执行等。具体的就需要有各种对应的策略来解决这些问题（如在每个节点上设定最小保留资源等等）

 

总体而言，Mesos最适用于Job的任务持续时间短，资源需求可以灵活伸缩的运算框架，如MapReduce等，对于需要长时间占用大量资源类型的Job，其非全局式的资源调度可能较难实现近似最优的调度。Google的Omega调度框架则试图同时解决这些问题。