7.4.2　Mesos和Yarn简介

1.Mesos介绍

我们在第2章谈到Spark的时候提及过Mesos，Mesos最初是加州伯克利大学的一个研究项目，后来加入到Apache孵化器成为开源产品。Mesos的目标是提供一个分布式应用的资源隔离框架，能在它上面运行Hadoop、MPI、Hypertable、Spark以及其他的分布式计算产品，Mesos通过提供一个编程API框架，让其他产品扩充实现这个框架接口内容去完成这一目标，如图7-2所示。

图7-2　Mesos产品图

Mesos通过Zookeeper提供Master的故障恢复。Mesos对于资源隔离的实现是采用Linux Containers完成，也就是我们前面介绍的Cgroup进程组方式隔离。Mesos目前主要是提供CPU和内存的资源管理，其他资源如网络带宽和硬盘使用不支持。

Mesos对MPI的默认支持是mpich2版本，也表示能支持Torque方式启动，但是它修改了部分Torque代码，在淘宝内部的MPI应用中，多数是Openmpi版本，而且Torque的版本使用官方的，经过我们尝试，发现存在不兼容。Openmpi实现的MPI应用最好去扩充Mesos提供的资源调用接口（Scheduler和Executor），不要直接采用Mesos默认的MPI支持方式。

下面我们讲述一下Mesos的架构和完成一个资源分配的流程，如图7-3所示。

图7-3　Mesos架构

通过图7-3，我们可以看到Mesos是一个Master/Slave的分布式结构的延伸设计，Slave负责资源的注册，Master负责资源的分配（offer）。另外为了让分布式应用获取资源跑起来，Mesos还设计了Scheduler和Executor两个组件，Scheduler向Master注册并接受资源的分配，Executor用于在Slave上执行任务。

我们看看一个资源分配的流程：

1）Slave向Master注册资源，这里是细粒度的，包括CPU和内存；

2）Master发送资源Offer给Framework；

3）Framework判断资源是否合适，并反馈给Master需要运行的任务及其资源；

4）Master发送任务到Slave上的Executor上执行。

图7-4　Mesos流程

提示

通过这个完整流程，我们可以发现，“资源的分配策略”和“运行任务逻辑”实际上由开发者自己实现Scheduler和Executor。

尽管Mesos在其官网上醒目提示：本产品仍然还不稳定。但是Mesos的论文还是值得参考的，目前资源隔离领域并没有太好的做法（资源隔离方案实现上跟操作系统也存在很大的绑定性），Mesos是这块技术领域探索上的先行者。

（请参考http：//www.mesosproject.org/papers/nsdi_mesos.pdf）

目前运行在Mesos上的主要是他们同出一门的产品Spark，虽然Mesos很想让Hadoop运行在其上面，但是显然Hadoop社区在情感上难以接受这样，它们自己搞了一个Yarn的框架。

2.Yarn介绍

也许大家都注意到了，Hadoop2.0跟1.0比有了巨大的变化，或许为了弥补某些方面的不足，Hadoop2.0痛下决心，将原来根据Google Map/Reduce和GFS论文实现的Hadoop1.0版，翻天覆地改装成了一个资源和任务调度的框架，如果不是还继续姓Hadoop，看上去真的不像一个父母生的孩子了。2.0版的Hadoop看上去像如图7-5所示。

图7-5　Yarn架构

Hadoop官方说1.0版里JobTracker设计的不好，需要一分为二，资源分配和任务分配功能不能合在一起。他们想做成一个资源请求和分配，再加上容器隔离执行任务的一套框架，这个框架不仅可以运行适合Map/Reduce按行分析的计算，也可以运行其他各种计算框架（这样就没人再攻击Hadoop1.0的Map/Reduce缺点了）。

这个新框架的名字叫做Yarn，它包括下面核心的组件：

❏　ResourceManager：负责资源管理和调度。

❏　NodeManager：负责各节点的资源汇报。

❏　ApplicationMaster：负责资源请求和判断。

❏　Container：隔离资源的单元，用于运行任务。

我们再结合上面的架构图描述一个资源请求的流程：

1）NodeManager向ResourceManager注册各机器资源。

2）客户端向ResourceManager提交作业。

3）ApplicationMaster向ResourceManager请求资源，并判断是否满足需要。

4）ResourceManager以Container的形式将资源反馈给ApplicationMaster。

5）Container做为资源单元保证作业隔离运行。

到这里，我们是否感觉这些流程与上面的Mesos有点像呢：

❏　Mesos　有点像　Yarn

❏　master　有点像　ResourceManager

❏　slave　有点像　NodeManager

❏　framework　有点像　ApplicationMaster

❏　executor　有点像　Container

当然，它们是不同的产品，很多功能并不等同，只是相似而已。不过我们因此更容易理解一个资源调度框架的主要结构和职责。

Yarn官网里介绍有这么一句话：“In addition it can optionally specify location preferences such as specific machine or rack;this allows for first class support of the MapReduce model of performing the computation close to the data being processed…”表示ApplicationMaster在进行资源请求时，可以指定一些位置的属性，比如特定的机器和机架，为了让计算靠近数据存放的机器。对于MPI等迭代计算的应用，计算初始时需要下载大量的数据到本地，非常耗费时间和带宽，这个功能或许能有所改观。

Yarn目前还没有最稳定版本发布，当前也只支持内存隔离，还不支持CPU、网络等其他资源隔离，不过Yarn社区正准备尝试用Linux上的Cgroup进程组方式改进。