1 概述

来自著名的加州大学伯克利分校，解决多样化环境里资源隔离和分享的问题。官网的介绍非常形象：

Program against your datacenter like it’s a single pool of resources

mesos源码是用c++写的，但是API支持Java, Python, c++。

1.1 mesos组件

mesos与yarn组件对比：

mesos yarn
master Resource Manager
slave Node Manager
framwork scheduler Application MAster
framwork executor Node Manager

1.2 资源

与yarn一样，mesos的资源分配也是双层调度框架：Mesos Master分配资源给Framwork，Framwork Scheduler将这些资源分配给不同的任务。 目前资源仅指cpu和内存，通过cgroups资源隔离。内存资源的监控与yarn不同，yarn采用了更灵活的线程监控方案。

2 底层通信协议

mesos使用了libprocess，在socket之上的封装；序列化使用了protocal buffers(业界用的很多，感兴趣可以看这篇文章)。 以server为例说明流程：

  • 继承ProtobufProcess，实际就是定义message server
  • 注册消息处理器(回调)
  • 定义PB消息
  • 编写消息处理器
  • main启动server

跟普通的socket编程相比，mesos将消息格式化为PB消息。

3 mesos四大服务：

Master, Slave, Scheduler Process, Executor Process （框架实现Allocator, Framework Scheduler, Framwork Executor） mesos主要服务组件

框架注册过程： Framwork创建一个Driver对象，由此对象探测到mesos的master，并与之注册，并返回注册结果给Framwork。 Framwork Executor的过程类似，不同的是与mesos的slave注册。

任务运行过程：Framwork Scheduler向Master申请资源，申请到后launch task到Master，由Master封装RunTaskMessage给Slave，Slave提交到Executor process。 Executor Process收到消息后查看是否已经启动了Framwork Executor，若否则启动之，然后启动任务。 任务状态更新：由Framwork Executor报给Slave，Slave提交给Master，Master发送updateStatus消息给Framwork Scheduler，任务状态更新后发送ack消息给Slave。 (Q: 为什么不直接由Framwork Executor更新状态给Scheduler？)

4 资源分配策略

背景：不同的框架，需要的资源是不一样的。考虑这样一种情况：MR和spark在一个集群上的情况，spark希望得到内存更大的资源。 解决办法：mesos只实现基础的资源分配策略DRF主资源公平，将资源授权给框架后，由框架决定如何给任务分配资源。 三种机制：

  • 资源拒绝：Framwork可以拒绝master分配的资源，要求重新分配
  • 资源过滤：当master发现该Framwork总是拒绝某种资源，则设置规则，只分配给该框架特定类型的资源，减少通信压力。
  • 资源回收：要了不用，过期回收

对比yarn的label schedule算法：yarn将不同的服务器打上不同的标签，application申请时带上标签，解决异构环境资源随机分配的问题。

5 容错机制

  • master:zookeeper监控master节点，发现故障后重新选举master，各slave重新注册，master重构；Framwork Scheduler重新注册。
  • slave:超时检测+快照机制

slave故障，master与slave之间有心跳，发现slave故障后通知给Framwork Scheduler，认为该slave之上的任务失败； slave升级，将之前的信息做了快照，重启后从快照恢复（类似V7的DBM）。具体来说，slave启动带-checkpoint参数，会适时的将信息保存起来；重新启动时带-recovery参数会先从快照来恢复相应信息。slave不会关闭正在跑的任务。

mesos比yarn优秀的地方是实现在slave的快照，可以比较好的快速恢复。

6 应用实例

目前可以在mesos上运行的实例比较多：MR/Spark/Storm/MPI。 mesos为了支持MR、Storm，提供了不同的组件，看起来不太自然。（还需要再了解：是否每个框架都需要自己的组件？） 下图摘自董西成博客，比较好的总体概括了各框架是如何跑在mesos上的。 mesos-arch

7 mesos与YARN对比

从机制上来看，mesos与YARN很相似（mesos出现的更早），不同主要体现在以下几点：

  • 资源分配策略 对比来说，yarn走了一条比较艰难的路，有新的分配需求，yarn就需要提供新的特性（例如yarn新引入了label based scheduling，用来解决异构环境下，不同计算模型的不同需求），但可能这样会吸引更多的计算框架，生态会更加丰富。
  • 内存资源的监控

参考 1 Mesos实战总结 2 Hadoop YARN新特性—label based scheduling 3 董西成的博客mesos分类