1.Yarn基础架构

Yarn基础架构如下图所示：

包含以下四个角色：RM、NM、AM、Container。

1.1.ResourceManager——RM

RM是一个全局的资源管理器，负责整个系统的资源管理和分配。

RM主要由两个组件组成：

（1）调度器Scheduler：根据容量、队列等限制条件，将系统中的资源分配给各个正在运行的应用程序。

（2）应用程序管理器Applications Manager：负责管理整个系统中所有的应用程序，包括应用程序的提交、与调度器协商资源以启动ApplicationMaster、监控ApplicationMaster运行状态并在失败时重启它。

1.2.NodeManager——NM

NM是每个节点上的资源和任务管理器。一方面，它会定时向RM上报本节点的资源使用情况，以及Container的运行情况。另一方面，它接收来自Am的Container启动/停止等各种请求。

1.3.ApplicationMaster——AM

用于提交的每个应用程序都会包含一个AM，主要功能有：

（1）与RM调度器协商以获取资源（Container）

（2）将得到的任务进一步分配给内部的任务。

（3）与NM通信以启动/停止任务。

（4）监控所有任务运行状态，并在任务运行失败时重新为任务申请资源以重启任务。

1.4.Container

Container时YARN中的资源抽象，它封装了某个节点上的多维度资源，比如内存、CPU、磁盘、网络等。当AM向RM申请资源时，RM为AM返回的资源用Container表示。

Yarn会为每个任务分配一个Container，该任务只能使用Container中描述的资源。

Container不同于MR中的slot，它是一个动态资源划分单位，是根据应用程序的需求动态生成的。

目前，YARN仅支持CPU和内存两种资源，且使用了轻量级资源隔离机制cgroups进行资源隔离。

2.Yarn高可用架构

YARN HA架构可参考官网https://hadoop.apache.org/docs/r3.3.0/hadoop-yarn/hadoop-yarn-site/ResourceManagerHA.html

如下图所示：

Yarn采用master/slave架构，使得ResourceManager有单点故障的可能。

为了解决ResourceManager因单点故障而导致整个yarn集群不可用的问题，Yarn引入了Standby ResourceManager，通过增加冗余的方式解决RM地单点故障。

任一时刻，至多只有一个ResourceManager是Active状态，其他ResourceManager全部是Standby状态，这些Standby ResourceManager等待外部条件触发，使自己成为Active状态。这些外部事件可以是管理命令（yarn rmadmin），也可以是开启自动恢复机制下故障恢复控制器的指令。

当Active ResourceManager不可用时，Standby ResourceManager可通过Zookeeper选举成为Active ResourceManager，并通过ResourceManager Recovery机制恢复状态。

2.1.ResourceManager Recovery

在Hadoop2.2中，ResourceManager提供了Recovery机制，当ResourceManager重启，或者Active/Standby状态发生切换时，不会影响正在运行的应用程序。

Recovery机制有以下重要的处理过程：

（1）保存元数据

Active ResourceManager运行过程中，会将Application的元数据信息、状态信息、以及安全凭证等数据持久化到状态存储系统（state-store）中。当前Yarn支持以下几种可选的state-store：

• 基于zookeeper的state-store：Zookeeper是ResourceManager HA必选的state-store，其优势在于——只有Zookeeper能防止脑裂（split-brain）现象。

• 基于FileSystem的state-store：支持HDFS和本地文件系统两种方式，但不能防止脑裂，可能同一时刻会存在两个Active ResourceManager。

• 基于LevelDB的state-store：相比以上两个方案，当前方案更加轻量级。LevelDB能更好地支持原子操作，每次更新占用更少的IO资源，生成的文件数目更少。

（2）加载元数据

一旦Active ResourceManager重启或出现故障，新启动的ResourceManager将从存储系统中重新加载应用程序的相关数据，此过程中，所有运行在NodeManager的Container仍正常运行。

（3）重构状态信息

新的ResourceManager重启完成后，各个NodeManager会向他注册，并将所管理的Container汇报给ResourceManager，这样RexourceManager可动态重构资源分配信息，各个Application以及其对应的Container等关键数据。同时，ApplicationMaster会向ResourceManager重新发送资源请求，以便ResourceManager重新为其分配资源。

2.2.NodeManager Recovery

NodeManager也提供了Recovery机制，当NodeManager重启时，之前正在运行的Container不会被kill，而是由新的NodeManager进程接管，并继续正常运行。