Yarn架构基本概况(二)

在概况(一)中，主要简单的对Yarn的情况作了简单的介绍，今天花一定时间在某些详细的模块上呈现下面Yarn的总体情况。帮助大家更好的理解Yarn。

1）ResourceManager

在Yarn的总体架构中。他用的也是Master/Slave架构，他的Slave是NodeManager，RM在Yarn中扮演着一个很重要的角色。他是负责集群中全部资源的统一管理和分配的。

他依据各个NM的资源汇报信息。把这些信息依照一定策略分配各个应用程序。以下是ResourceManager的主要内部结构：

(1).用户交互模块

(2).NM管理模块

(3).AM管理模块

(4).Application应用管理模块

(5).安全管理模块

(6).资源分配模块

(7).状态机管理模块。ResourceManager使用有限状态机来维护状态的生命周期的。比方RMApp应用状态机，RMConta容器状态机。

1.ResourceManager事件处理

在Yarn广泛採用了事件驱动的机制。由1个中心事件分发器，对于传进来的事件做转发处理。大大的提高了效率。

2）资源调度模型

在MRV1中，资源调度默认採用的是简单的FIFO的方式，可是在需求日益多元化的条件下，这样的方式一件渐渐的没有那么完美了，于是适用于多用户的资源调度器就出现了。

主要2种设计思路。

(1).在同个集群中虚拟多个Hadoop集群，这些Hadoop集群拥有全套的Hadoop服务。典型的代表HOD(Hadoop On Demand)调度器。

(2).资源调度器以多用户多队列的形式实现。每一个队列仅仅要每一个队列执行着类似的用户群，每一个队列里有自己分配的资源和任务。可是他们是共享一整套Hadoop的资源的。

3）NodeManager

NM是Yarn上单个节点上的代理。

他有例如以下的作用

1.与ResourceManager通信

2.管理Contain容器的的生命周期

3.监控Contain的资源使用情况

4.管理节点健康状况

5.管理日志服务

与RM一样，NM也採用了事件驱动的形式来控制整个过程。有很多的事件类型经过事件处理器处理后会改变对象的状态机，进而改变了对象的声明周期。

3）在Yarn上执行多种计算框架

Yarn是一一个通用的资源管理框架，在上面执行多种计算框架才是啊他的最大的不同MRV1的地方。作为一个资源框架，有2样东西你必需要重写一个提交应用的Client，另一个是与待接入框架相适应的ApplicationMaster，后者的设计尤其是关键。由于提交程序的Client都差点儿相同的。

1.MRV1主要是通过JobTracker和TaskTracker实现的，所以他在Yarn的部署能够是以下这幅图的样子。

watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvQW5kcm9pZGx1c2hhbmdkZXJlbg==/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center" alt="">

2.Storm，实时处理框架在Yarn是怎么执行的呢。Storm与MRV1还是很类似的。通过Nimbus,Supervisor,中间加个zookeeper做协调服务就能实现了。模拟图例如以下。

当然以上还都是设计思路，终于还是通过自己实现client和自己定义的ApplicationMaster实现终于的设计。

4）Yarn的未来

在近期几年。也衍生出了一些类似于Yarn的通用计算框架，比方Apache Mesos，他相同能够支持MapReduce和Storm，在某些特性上和Yarn还是有些不同的。

只是这个框架还不是特别稳定眼下。

作为通用的计算框架，在Yarn的身上，还是有些缺点的。比方由于执行在Yarn上的计算框架是资源隔离的， 所以各个框架是不知道集群的总体资源执行情况的，就不好进行总体资源的调度。各个计算是框架不知道当在节点很繁忙的时候是应该等待自己的任务执行完了在继续以下的任务。还是向系统请求新的资源，假设系统此时也很忙，显然不适合请求，反而要等更长时间。假设系统资源此时很空。那这就是正确的策略。