YARN学习总结

阅读量：5058 次

发布时间：2019-06-12

本文共 20655 字，大约阅读时间需要 68 分钟。

YARN学习总结

前言

YARN（Yet Another Resource Manage，另一种资源协调者）是hadoop-0.23版本引入的的一个新的特性，可以说它是对原有Hadoop Mapreduce（Hadoop 1.0）架构的一种里程碑式的改革。它在整个Hadoop生态体系中负责资源管理和作业调度，支持各类分布式应用程序的执行。

本文档的大部分内容参考于Apache Hadoop 2.7.2——YARN官方网站，是对网站内容的翻译加上本人自己的理解，有些内容可能会因为本人的知识水平和英文水平有限而导致理解上存在偏差或不足的地方，还望指正。

概况

Apache Hadoop YARN 是一种新的 Hadoop 资源管理器，它是一个通用资源管理系统，可为上层应用提供统一的资源管理和调度。它将Hadoop 1.0架构中的JobTracker的两块主要功能（资源管理和任务生命周期管理）拆分成了两个单独的组件：ResourceManager和Application Master。它的引入为集群在利用率、资源统一管理和数据共享等方面带来了巨大好处。

本篇文档主要从以下几个方面介绍YARN。

MRv1架构及其存在的缺陷

YARN架构及其优点

调度器（Scheduler）

RM重启机制（ResourceManager Restart）

RM高可用（ResourceManager HA）

YARN常用命令

1. MRv1架构及其存在的缺陷

1.1 MapReduce和HDFS简介

在第一代Hadoop系统中，一个Hadoop集群可以分解为两个抽象实体：MapReduce计算引擎和分布式文件系统(HDFS)。其中MapReduce引擎能够在整个集群上执行Map和Reduce任务并报告结果，而HDFS分布式文件系统则提供了一种存储模式，可跨节点复制数据以进行处理。HDFS一般由一个NameNode和多个DataNode组成，其中NameNode是文件系统的主系统，提供元数据服务来执行数据分发和复制，而DataNode是实际储存数据的节点。客户端通过连接NameNode来请求对文件的元数据的访问或修改，而实际的数据复制存储都是发生在DataNode。

查看NameNode所在机器：

查看hadoop-home/etc/hadoop/hdfs-site.xml的配置文件。

查看DataNode所在机器及状态信息：

在hadoop-home/bin目录下执行命令./hdfs dfsadmin -report。

1.2 MRv1架构分析

MRv1架构

图1 MRv1的架构

图1所示是Hadoop 1.0的架构，它的架构体系主要由一个Job Tracker进程和多个TaskTracker进程组成。

其中JobTracker主要负责：

调度从客户端提交的任务

跟踪各个TaskTrackers的资源使用情况（可用的map/reduce插槽数）

监控各个任务的执行情况，包括指导TaskTracker启动任务、重启失败任务。

TaskTrackers主要负责：

执行各个map和reduce任务

向JobTracker汇报任务的执行情况。

当一个客户端向一个Hadoop集群发出一个请求时，此请求由JobTracker管理。JobTracker与NameNode联合将工作分发到离它所处理的数据尽可能近的位置。JobTracker将Map和Reduce任务安排到一个或多个TaskTracker上的可用插槽中。TaskTracker与DataNode一起对来自DataNode的数据执行Map和Reduce任务。当Map和Reduce任务完成时，TaskTracker会告知JobTracker，后者确定所有任务何时完成并最终告知客户作业已完成。

1.3 MRv1架构存在的缺陷

在实践中，依据Yahoo!，在集群中有5000个节点和40000个任务同时运行时，会出现一定的不可预测性，其中最大的一个问题就是会出现“级联故障”。

从我个人的理解，第一代Hadoop系统存在的缺陷主要可以归纳为三个方面：

1.3.1 中心化管理，对JobTracker过分依赖

从图1中我们可以看到，整个集群只有一个JobTracker，既要负责整个集群的资源调度，又要负责监控各个计算节点的任务的执行情况。所有的客户端要通过JobTracker来提交应用，然后将应用的各个map/reduce任务安排到TaskTracker的不同插槽中执行。这种中心化的管理，当水平扩展的计算节点非常多时，JobTracker的负载会非常繁重。如果JobTracker发生故障，结果将是灾难性的。

1.3.2 资源利用率低

在MRv1中，计算资源（内存、cpu）是以插槽的形式存在于TaskTracker中，插槽的数量、每个插槽的大小、甚至是分别用于map和resuce任务的插槽的数量都是由集群管理员配置的。考虑以下两种场景，就可以体会资源的浪费：

一个计算节点中有10个map slot和10个 reduce slot。但是当前的应用需要执行100个map任务，只需要执行1个resuce任务。显然，10个map slot会被完全占满，而reduce slot会处于完全空闲状态。由于它们相互不兼容，即map任务不能占用reduce的插槽，这就导致了严重的资源浪费。

一个slot包含10G的内存，但是我的一个任务只要求1G内存。由于每个slot的大小是固定的，这就可能会导致一个任务所需的内存远小于slot的容量，从而造成资源浪费。

1.3.3 单一应用限制

第一代Hadoop架构中，限制了应用只能以Hadoop MapReduce的形式执行。无法支持Storm、Spark、Giraph等其他分布式应用程序，限制了资源共享。

2. YARN架构及其优点

YARN架构引入的核心思想就是将“资源管理”和“任务调度监控”这两大块主要功能拆分成两个独立的进程。在该思想的指导下，在YARN的架构中有了一个全局的ResourceManager和每个应用独有的ApplicationMaster。在YARN中，每个应用由一个单独的任务或由多个任务构成的有向无环图（DAG）组成。

2.1 YARN的架构及其重要组件

YARN的架构

图2 YARN的架构

从图2可用看到，YARN的架构主要由五部分组件组成：ResourceManager（RM）、NodeManager（NM）、ApplicationMaster（AM）、Container、Client。

2.1.1 ResourceManager

在YARN中，ResourceManager的主要作用是管理和分配资源。它的主要职责有：

跟踪各个可用的NodeManager节点及其可用资源

分配可用资源给各个应用及其任务

监控各个ApplicationMaster的健康状况，并负责启动和重启失败的AM

实际上，RM也可以拆分成两个主要组成部分：Scheduler和ApplicationsManager。

Scheduler根据一定的限制（资源容量、队列、数据位置、ACL等）负责给各个在集群运行的应用分配资源。它是一个纯资源的调度器，不会去对应用的状态执行监控或是跟踪。并且，它不保障当任务因为应用或硬件出现故障而导致失败时去重启失败的任务。它仅基于应用所需要的资源来执行调度。

Scheduler还是一个可插拔的组件，当前Hadoop提供了几种不同的现成的调度器，如CapacityScheduler和FairScheduler等，它们根据不同的算法在不同的队列和应用间分配集群的资源。

而ApplicationsManager负责接受任务提交，协商用于启动应用的ApplicationMaster所需的第一个container，并且提供当AM出现故障时重启AM container的服务。

2.1.2 NodeManager

NodeManager是MRv1架构中TaskTracker的一种更加普通和高效的版本。它没有固定数量的map和reduce插槽，而是拥有许多动态创建的资源容器。容器的大小取决于它所包含的资源量（内存、CPU、磁盘和网络IO）。目前，仅支持内存和CPU。未来可使用cgroups来控制磁盘和网络IO。NodeManager的主要职责有：

以container的形式提供任务计算所需要的资源

管理在container中执行的任务的资源使用

一个节点上的容器数量，由配置参数与专用于从属后台进程和操作系统的资源以外的节点资源总量（比如总CPU数和总内存）共同决定。MRv1通过插槽管理Map和Reduce任务的执行，而NodeManager管理抽象容器，这些容器代表着可供一个特定应用程序使用的针对每个节点的资源。

2.1.3 ApplicationMaster

当一个应用程序从client提交到ResourceManager，RM就会启动一个称为ApplicationMaster的轻量级进程来协调应用程序内的所有任务的执行，它管理着该应用程序的整个生命周期。每个特定的在集群运行的应用程序都会由一个特定的AM来管理。它的主要职责有：

协调一个应用程序内的所有任务的执行

向RM请求各个任务执行所需要的资源(container)

监视任务执行状况，重启失败的任务

在任务完成后注销容器

ApplicationMaster和属于它的应用程序的任务，都是在受NodeManager控制的资源容器container中运行的。

ApplicationMaster可在容器内运行任何类型的任务。例如，MapReduce ApplicationMaster请求一个容器来启动map或reduce任务，而Giraph ApplicationMaster请求一个容器来运行Giraph任务。它还支持用户实现一个自定义的ApplicationMaster来运行特定的任务，进而可以发明出一种全新的分布式应用程序框架。

在YARN中，MapReduce降级为一个分布式应用程序的一个角色，现在称为MRv2，运行在YARN之上。实际上，在hadoop-2.x版本的API设计中，保持了对hadoop-1.x版本MapReduce的兼容，所有的旧的MapReduce任务都可以不需要作任何改变就可以运行在YARN之上。

2.1.4 Container

在YARN中，资源是以容器container的形式提供给各个应用程序的任务。它是一个抽象的概念，主要包含内存、CPU、磁盘和网络IO。每个特定任务的执行都是在一个给定的container中完成。container的主要特性有：

运行不同类型的任务（包含ApplicationMaster本身）

动态创建，具有不同的大小（内存、cpu等）

2.1.5 Client

Client，即YARN客户端，通过它可以向RM发送各种不同的请求，用于向RM提交不同类型的应用程序，并且还可以通过它向RM发送一些控制命令，如查询应用的状态，停止应用等。

2.2 YARN的工作流程

YARN中的应用程序的提交处理，可以依次分为以下步骤：

（1）用户通过client向RM提交应用程序

（2）RM在接收到一个新的应用程序后，会先选择一个container用于启动该应用程序特有的AM

（3）AM启动后，向RM请求运行应用程序所需要的资源

（4）RM会尽可能地分配AM所请求的资源的容器，表达为容器ID和主机名

（5）AM根据给定的容器ID和主机名，要求对应的NodeManager使用这些资源启动一个特定于应用程序的任务。

（6）NodeManager启动任务，并监视该任务使用资源的健康状况。

（7）AM持续监视任务的执行情况。

（8）当任务执行完成时，AM会向RM汇报并注销执行任务的容器，以及注销自己。

下面这幅流程图描述了上述过程：

图3 YARN中的应用程序提交流程

2.3 YARN各个组件之间的关系小结

2.3.1 ResourceManager负责管理ApplicationMaster

（1）RM不会对应用程序内的任务执行作任何监视，但它会检查AM的健康状况。如果AM失败，RM可在一个新容器中重新启动它。

（2）RM实际上由两部分组成：Scheduler和ApplicationsManager

（3）Scheduler负责调度，分配应用程序需要的资源。在指定的机器上分配Container，从而减少数据移动。包含FairScheduler、CapacityScheduler等。

（4）ApplicationsManager负责接受任务提交，协商用于启动AM的container，提供重启AM container的服务。

2.3.2 AM负责向RM请求应用所需的资源，要求NodeManager启动任务

每个应用程序有自己特定的AM，AM负责管理应用的整个生命周期，它会监视应用的所有任务的执行情况，并负责重启失败的任务。当应用的所有任务执行完成时，会向RM汇报，然后注销任务所需的容器，并注销自己。

2.3.3 NodeManager负责管理容器资源container

NodeManager不会监视任务的具体执行情况，但它会监视容器中的资源使用情况。举例而言，如果一个容器消耗的内存比最初分配的更多，它就会结束该容器。

2.3.4 NodeManager与RM的通信，是为了同步资源情况。

2.3.5 AM与RM的通信，是为了同步任务的运行情况。

2.4 YARN相对MRv1的优势（个人观点）

这一节与1.3中MRv1架构的缺陷相对应：

2.4.1 去中心化单进程管理。

在YARN中将原来MRv1的JobTracker的职责（资源调度和任务监视、追踪、管理）分为两个独立的守护进程，ResourceManager和ApplicationMaster。其中ResourceManager负责管理整个集群的资源，负责给每个应用分配资源，并通过NodeManager监控各个节点的资源状态。且在YARN中已经实现了RM的高可用，具有更好的稳定性。而ApplicationMaster负责各个应用的整个生命周期，每个单独的应用对应一个单独的ApplicationMaster，管理和监视各个应用的子任务的执行，并负责重启失败的任务。

相对于以前一个JobTracker既要负责资源的管理调度，又要监视所有任务的执行，YARN中将任务执行状况监视的职能分发到多个不同的ApplicationMaster去管控，将各个计算节点的资源状况也交由各个节点的NodeManager自己去管控。RM只要负责整个集群的资源协调。

2.4.2 提升资源利用效率

在MRv1中，在集群配置时管理员会为每个TaskTrackers设置固定数量的槽，每个任务(map或reduce)在一个特定的槽上运行。而每个槽的内存分配是固定的，当一个任务使用较少内存时会使得一部分内存资源的浪费，而这部分空闲的内存也不能够分配给其他等待的任务。此外，由于分配的槽限定了该槽只能运行map任务或只能运行reduce任务，互相不可替代，这就可能会导致一种极端的情形：当该计算节点上有大量的map任务，而没有reduce任务时，此时即使该节点上的map槽已经被占满，而reduce槽全为空闲状态，也不能在reduce槽上运行map任务。反之亦然。

而在YARN中，所有的资源申请由ApplicationMaster去向RM申请，各个应用程序（如MR、Spark）各自实现的、对应的特定AM会包含其所需要的资源信息。

另外，AM根据该应用需要的资源，如果该任务是“小任务”（默认情况下，小于10个mapper且只有一个reducer且输入大小小于一个HDFS块的任务），AM会选择在与它相同的JVM上直接运行，从而大大减少了请求资源、数据移动等额外的开销；如果不是小任务，会根据任务需要的资源向RM申请相对应的资源，RM根据集群中的资源状况向其分配合适的、且包含所需资源的container，告知AM用于执行其任务的资源容器containerId.

在YARN中，资源是动态分配的，大大提高了资源利用率。

2.4.3 支持跨应用的分布式集群

在MRv1原先的架构中，只支持Hadoop MapReduce一种应用程序，而在YARN中没有这种限制。NodeManager分配的container没有限制执行的任务的类型，container只负责提供任务所需要的资源。任何应用程序只要实现其对应的Application Master就可以在YARN上执行。这样不同的应用程序(mr，spark，storm等)在同一个集群上运行，共用相同的底层存储服务（HDFS），给相互之间的资源访问共享提供了很大的便利，减少了资源相互传输复制的很大开销。另外相对来说更“环保”，只需要部署和维护一套环境，减少了机器资源的占用和运维成本。

3. 调度器（Scheduler）

3.1 Capacity Scheduler

3.1.1 What is Capacity Scheduler?

一个可插拔的调度器（scheduler），它允许不同租户安全地共享一个大的集群，使得它们的应用（applications）可以在分配资源的约束下及时地分配到资源。

3.1.2 关键词

queue

hierarchical queues / sub-queue

3.1.3 概况

Capacity Scheduler是为了在共享、多租户的集群下以一种操作友好的方式，同时又能最大化吞吐量和集群利用率，来运行Hadoop应用而设计的。

传统情况下，各个租户拥有它们自己独有的计算资源集，从而拥有充足的资源满足其极限或接近极限条件下的SLA。这通常会导致较低的平均利用率以及管理多个独立集群的开销（一个租户一个集群）。在各个租户之间共享集群是运行多个大型Hadoop实例的一种具有成本效益的方式，因为可以不需要去创建独立的集群，从而获得大规模的经济收益。但是，租户们又会担心共享同一个集群，因为他们担心其他使用这些资源的机构对于它们自己的SLA非常重要。

设计Capacity Scheduler是为了在共享一个大集群的情况下同时又可以保障各个租户各自的资源使用。核心思想是将Hadoop集群中的可用资源在各个租户之间共享，而这些租户分别根据自己的计算需求共同资助这个集群。这样带来的好处是一个租户可以使用超过其资源上限的资源（当其他租户的资源空闲时）。这样租户（使用资源）变得更有弹性，并且提高了资源使用效率。

在不同机构间共享集群迫使对“多租户”提出了强烈需求，因为每个机构的资源必须得到保证并且安全保障。为了保证公平性和稳定性，Capacity因此对每个应用/队列的资源使用作了限制。

核心概念——队列（queues），这些队列通常是由hadoop管理员配置，来反映各个租户的利益。

为了提供未来控制和可预见性，Capacity Schedule提供了按等级划分的队列来保障资源可以在一个机构的不同子队列里共享。

3.1.4 Capacity Schedule支持的特性

（1）Hierarchical Queues 分等级的队列

保证在其他队列可使用免费资源之前，使得这部分资源可以在相同组织的不同子队列间共享。从而提供更好的可控性和可预测性。

（2）Capacity Guarantees 资源保证。

所有提交到队列的应用都可以使用队列的资源

（3）Security 安全性。

每个队列有严格的ACL控制，每个队列允许哪些用户提交应用，并且用户不能查看和修改其他用户的应用。并支队列管理员和系统管理员角色。

（4）Elasticity 伸缩性

空闲的资源可以分配给其他队列。

（5）Multi-tenancy 多租户

全面的限制条件保证任一单独的应用，或单独的用户，或单独的队列不会垄断整个队列或集群的资源。

（6）Operability 可操作性

Runtime Configuration 可运行时修改配置，包括更改capacity，ACL，甚至增加队列。但是不能删除队列。

Drain applications 停止队列，队列中正在执行的任务会继续执行直到完成，但是该队列及其子队列都不会再接受新的任务。当然，管理员也可以启动停止的队列。

（7）Resource-based Scheduling

对一些资源要求较高的应用，支持可调节地满足其不同程度的资源需求。当前仅支持资源的维度为：“内存”

（8）Queue Mapping based on User or Group

根据用户或组，将job映射到特定的队列执行。

3.1.5 配置方式

（1）RM配置

通过下面配置可以使RM使用CapacityScheduler:

在conf/yarn-site.xml中加入：


      
     
      yarn.resourcemanager.scheduler.class
       
     
      org.apache.hadoop.yarn.server.resourcemanager.scheduler.capacity.CapacityScheduler

（2）队列配置

CapacityScheduler的配置文件为etc/hadoop/capacity-scheduler.xml。它拥有一个预先定义的队列root，所有队列都是root队列的子队列。

队列的配置：yarn.scheduler.capacity.root.queues，以逗号分隔。示例：


      
     
      yarn.scheduler.capacity.root.queues
       
     
      a,b,c
       
     
      The queues at the this level (root is the root queue).  
     
    
      
     
      yarn.scheduler.capacity.root.a.queues
       
     
      a1,a2
       
     
      The queues at the this level (root is the root queue).  
     
    
      
     
      yarn.scheduler.capacity.root.b.queues
       
     
      b1,b2,b3
       
     
      The queues at the this level (root is the root queue).

其中a，b，c为root队列的子队列；a1，a2为a的子队列；b1，b2，b3为b的子队列。

其他的关于Capacity Scheduler的配置可参考。

3.2 Fair Scheduler

3.2.1 简介

Hadoop中一个可插拔的调度器，允许YARN中的应用在同一个大的集群中公平地共享资源。

公平调度

默认情况下，公平调度器是基于内存的公平调度，也可以配置为同时基于内存和cpu的公平调度（使用Ghodsi等人提出的新概念Dominant Resource Fairness）。当只有一个应用在运行时，该应用会占用整个集群的资源；当有其他应用也提交到集群时，一些资源就会释放出来分配给这些新的应用，使得每个应用最终会获得大体相同的资源数量。

队列

支持queue，使得queue中的每个应用的资源公平分配。默认情况下，所有用户共享一个称为“default”的队列。默认是给予内存的公平调度，也可以配置为FIFO或Dominant Resource Fairness的多种资源调度模式。队列可以被划分为不同的等级并且被设置不同的权重。

最少份额保障VS最大化集群资源使用

还可以给每个队列分配受保障的最少资源份额，以保障一部分用户的应用可以始终得到充足的资源。如果某个队列拥有一些正在运行的应用，那么该队列就可以确保获得设定的最少资源份额，但是如果该队列获得的这部分最少资源份额超过了该队列的所有应用所需的资源，超出的资源也可以被划出去给其它正在执行的应用使用。这就使得调度器在保证各个队列的各自所需资源的同时又可以提高整个集群的资源使用效率。

限制每个用户和每个队列并行执行的应用数

通过配置文件可以限制每个用户和每个队列并行执行的应用数，以防止某个用户可能同时提交上百个应用，进而可能导致过多的即时数据创建或过多的上下文转换。通过限制单个用户并行执行的应用数，使得一部分应用等待之前的应用执行完成后再开始执行，可以防止这种情况下的一些应用失败。

3.2.2 Hierarchical queues with pluggable policies

所有的队列是从一个称为"root"的队列分化出来的，即所有队列都是root队列的孩子队列。队列的命名以它的父亲队列开头，以句号分隔。举例：root队列下的一个子队列queue1的命名方式为"root.queue1"；queue1下的子队列queue2命名为"root.queue1.queue2"。当引用一个队列时，root可以被隐藏，比如"queue1"就指代了"root.queue1"，"queue1.queue2"就指代了"root.queue1.queue2"。

不同队列还允许使用不同的调度策略，通过扩展类org.apache.hadoop.yarn.server.resourcemanager.scheduler.fair.SchedulingPolicy类可以实现定制化的策略。FifoPolicy、FairSharePolicy(default)、DominantResourceFairnessPolicy是几种已经内置的策略。

需要注意的是，MRv1中的Fair Scheduler有一些policy在YARN中还不支持。

3.2.3 Automatically placing applications in queues

管理员可以配置一些policy使得针对特定的用户或属于特定组的用户提交的应用自动放入到合适的队列中。每个policy由许多规则组成，每个应用提交时按照policy中由上至下的顺序适配合适的规则。

3.2.4 部署

在yarn-site.xml中配置:


      
     
      yarn.resourcemanager.scheduler.class
       
     
      org.apache.hadoop.yarn.server.resourcemanager.scheduler.fair.FairScheduler

查看YARN配置的方法：查看/hadoop_home/etc/hadoop/yarn-site.xml

3.2.5 配置

两种配置方式：

全局配置：影响整个调度器，在yarn-site.xml中配置

局部配置：创建allocation file列出存在的队列，及其各自的权重和资源容量。

allocation file每隔10秒重载一次，使得可以在运行中更新配置。

3.2.6 管理方式

三种管理方式：

运行时更新配置：更改allocation file

通过RM web UI监控：http://ResourceManagerURL/cluster/scheduler

每个队列可监控的项：
- 已使用的资源：已分配给containers的资源总和
- 活跃的应用数：至少被分配了一个container的应用数
- 待定的应用数：进入了队列，但还未分配到任何container的应用数
- 最小资源：队列配置的受保障的最小资源
- 最大资源：队列配置的允许获得的最大资源
- Instantaneous Fair Share ——consider only actives queues（those with running applications）
- Steady Fair Share --consider all queues
备注：最后两种的含义不太明白。

在队列中移动应用

允许将一个正在运行的应用移到另一个队列。根据应用的重要性人为地将其移到更高或更低优先级的队列中执行。移动的命令：
```
yarn application -movetoqueue appID -queue targetQueueName
```
为了计算公平性，如果一个应用被移动了队列，该应用当前被分配的资源会计算到新的队列，而不再计入旧队列。受到新队列的最大并行运行应用数或最大资源的限制，移动应用到新的队列的操作可能会失败。

其他的关于Fair Scheduler的配置可参考。

3.3 Capacity Scheduler与Fair Scheduler的比较

3.3.1 资源分配模型

无论哪种调度器，它们的核心资源分配模型都是一样的。调度器维护一群队列的信息，用户可以向一个或多个队列提交应用。每次NodeManager心跳的时候，调度器根据一定的规则选择一个队列，再在队列上选择一个应用，尝试在这个应用上分配资源。

不同的是，不同的调度器在选择队列的方式以及选择应用的方式上有所不同。

3.3.2 调度器比较

调度器	CapacityScheduler	FairScheduler
设计目的	多租户下，最大化集群的吞吐和利用率	多租户下，强调用户公平地共享资源
队列组织方式	无论父队列还是子队列都会有资源参数限制，子队列的资源限制计算是基于父队列的。应用提交到叶子队列。	每个叶子队列有最小共享量，最大资源量和最大活跃应用数。
队列ACL限制	可以限制应用提交权限和队列开关权限，父子队列间的ACL会继承	可以限制应用提交权限和队列开关权限，父子队列间的ACL会继承
队列排序算法	按照队列的资源使用量最小的优先	公平排序算法
应用选择算法	先进先出	先进先出或公平排序

4. RM重启机制（ResourceManager Restart）

4.1 简介

RM作为YARN中最核心的组建，管理和调度着整个YARN集群中的资源。它的可靠性对所有在YARN集群上运行的应用都至关重要。这一章介绍RM的重启机制，该机制保障了应用在RM发生重启后可以继续可靠执行并且不会被终端用户察觉。

RM的重启机制的发展经历了两个阶段：

阶段1：非工作保存（non-work-preserving）

该阶段通过可插拔的状态持久化组建使得RM可以将应用的状态和重要信息持久化。当RM重启时从持久化组建中恢复应用的信息然后重新执行之前运行的应用。保障了用户不需要再重新提交应用。

阶段2: 工作保存（work-preserving）

该阶段通过结合来自NodeManagers的各个container状态信息和来自ApplicationMasters的各个container请求信息，聚焦于让RM重启时可以重建RM的运行状态。与阶段1的核心区分是，RM重启之前运行的那些应用不会在RM重起后被kill，从而保证了应用不会因为RM的故障而停止工作。

个人小结：RM主要是负责管理整个集群的资源信息，以及调度不同应用到不同的计算节点上去执行。它自己不负责任务的执行，所以其宕机并不会影响正在执行的应用的继续执行。当RM重启时如果可以重新同步各个节点的资源使用状态和任务运行状态即可继续正常工作。

4.2 Feature

4.2.1 阶段1: Non-work-preserving RM restart

在Hadoop2.4.0发行的时候，只有阶段1实现了。简要描述阶段1的过程如下：

RM通过state-store在client提交应用时记录application metadata（如ApplicationSubmissionContext等），并记录应用完成时的状态（如failed,killed,finished），以及保存用户的私密信息（如security keys, tokens）在一个安全的环境。

任何时候RM停止了工作，当它重启时重新载入state-store中的信息，重新提交RM停止工作前那些会完成的应用。

NodeManager和client会持续发送心跳信息给RM直到RM恢复。当RM恢复时，会根据心跳信息给所有的NM和AM发送一个重启同步的命令。

在Hadoop2.4.0发行时，NM和AM对RM的同步命令的处理方式如下：NM会kill它管理的所有container，然后重新向RM注册。从RM的视角，这些重新注册的NM就跟新加入的NM一样；而AM则会立即停止。

在RM完成重载所有应用的metadata、credential信息到内存后，它会为每个未完成的应用重新创建新的AM，然后重新执行应用。

这种方式会导致之前正在执行的应用的工作丢失。

疑问：并不是所有应用都是允许被重复执行的，这些任务怎么办？

4.2.2 阶段2: Work-preserving RM restart

随着Hadoop2.6.0的发布，RM重启的功能得到了加强，解决了之前存在的必须kill执行中应用的缺陷。

除了阶段1完成的状态持久化工作之外，阶段2聚焦于重建YRAN集群的整个运行时状态，主要是核心调度器scheduler（跟踪所有containers的生命周期，应用的headroom以及资源请求，队列的资源使用情况等）的状态。这样使得RM不需要kill AM以及从头开始重跑应用。应用可以直接与RM同步恢复执行。

在这个阶段，NM继续管理containers，并发送containers的状态给新的RM。RM通过吸纳containers的信息，重建container实例以及相关联的应用的调度状态。同时，AM需要重新发送未完成的资源请求给RM，因为RM可能已经丢失了这些未完成的请求。编写应用的作者使用AMRMClient库与RM通信，不需要去考虑AM重新发送资源请求的部分，这些已经包含在库本身了。

疑点： RM宕机时，AM和NM发现其宕机了，contaner中的应用是会继续执行还是暂停等待RM恢复？——更合理的方式应该是暂停执行

4.3 配置

Enable RM Restart


        
     
      yarn.resourcemanager.recovery.enabled
         
     
      true

Configure the state-store for persisting the RM stats


        
     
      yarn.resourcemanager.store.class
         
     
      org.apache.hadoop.yarn.server.resourcemanager.recovery.ZKRMStateStore

可选值：

org.apache.hadoop.yarn.server.resourcemanager.recovery.ZKRMStateStore

org.apache.hadoop.yarn.server.resourcemanager.recovery.FileSystemRMStateStore

org.apache.hadoop.yarn.server.resourcemanager.recovery.LeveldbRMStateStore

默认是第二种，基于Hadoop文件系统（HDFS或本地FS）。

但是只有第一种ZKRMStateStore方式可以支持RM HA。

Configurations for Zookeeper based state-store implementation


        
     
      yarn.resourcemanager.zk-address
         
     
      classb-ds-bigdata9.server.163.org:2181,classb-ds-bigdata10.server.163.org:2181,classb-ds-bigdata11.server.163.org:2181
     
    
        
     
      yarn.resourcemanager.zk-state-store.parent-path
         
     
      /rmstore-hp8

其他的关于ResourceManager Restart的配置可参考。

5. RM高可用（ResourceManager HA）

5.1 简介

这一章简单介绍RM的高可用特性，以及如何配置和使用该特性。RM负责集群的资源管理，和应用（如MapReduce作业）的调度。在Hadoop2.4发行前，RM是整个YARN集群的一个单点故障（single point of failure）。高可用特性以一对Active/Standby RM的形式增加了备份，从而有效避免了单点故障的风险。

5.2 RM HA架构

RM-HA

图4 RM-HA Architecuture

RM高可用通过Active/Standby的架构实现。在任一时间点，只有一个RM处于Active状态，但可以有一个或多个RM处于Standby模式。一个Standby状态的RM想成为Active，有两种方式：

接收来自client的管理员命令

通过集成的failover-controller自动成为Active

5.2.1 手动故障转移（Manual transitions and failover）

当自动failover没有开启时，管理员可以手动的转移RM的状态。通过"yarn rmadmin"命令先将Active-RM转为Standby状态，然后将一个Standby-RM转为Active。

5.2.2 自动故障转移（Automative failover）

RM可以委托基于Zookeeper的主从选举器（ActiveStandbyElector）来决定哪个RM可以成为Active。当Active-RM宕机了变得无响应时，另一个RM可以自动成为Active然后接管之前的工作。

需要注意的是，跟HDFS中的情形不同，不需要再去起一个单独的Zookeeper FC进程，因为ActiveStandbyElector已经嵌入到里RM中作为一个失败检测器和主选举器（leader elector）。

5.2.3 Client, ApplicationMaster and NodeManager on RM failover

当存在多个RM时，各个客户端和节点使用的配置文件（yarn-site.xml）中必须列出所有的RM。Client、AM、NodeManager在连接RM时，会以“圆桌轮询”（round-robin）的方式一个个去遍历各个RM，直到命中Active-RM。当一个Active-RM出故障里，它们又会继续以“圆桌轮询”的方式继续寻找新的Active-RM。这块默认的重试逻辑在org.apache.hadoop.yarn.client.ConfiguredRMFailoverProxyProvider中实现。你也可以重写这一块逻辑，然后设置配置文件中yarn.client.failover-proxy-provider的值为你重写的类名。

5.2.4 恢复之前的active-RM的状态

随着之前介绍的RM重启机制的应用，RM可以在失败后重新启动时从state-store中恢复到失败之前的状态。而基于Zookeeper的RM高可用和使用基于Zookeeper的state-store相得益彰，我们只要保证Zookeeper上存储RM状态信息的节点对所有的Active/Standby RM都可见即可。并且，ZKRMStateStore实现了在任一时间点只允许单个RM节点拥有写的权限。所以，在使用RM HA的集群，强烈推荐使用基于Zookeeper的state-store。

5.3 部署

5.3.1 配置

大部分的高可用特性都有众多可调的参数。下面是一些常用的重要的参数。yarn-default.xml中包含了完整的参数列表，想要了解更多的其他参数可以去查阅yarn-default.xml。对于state-store的配置可以去看前一章的RM Restart。

Configureation Properties	Description
yarn.resourcemanager.zk-address	ZK地址，同时用于state-store和内置选主器。
yarn.resourcemanager.ha.enabled	启用RM HA.
yarn.resourcemanager.ha.rm-ids	指定RM的逻辑ID.如：rm1,rm2。
yarn.resourcemanager.hostname.rm-id	为每个rm-id，指定默认host。
yarn.resourcemanager.address.rm-id	指定client提交作业时的专属host（即ApplicationsManager地址）。设置后，会覆盖hostname.rm-id配置。
yarn.resourcemanager.scheduler.address.rm-id	指定AM请求资源的host(即Scheduler地址)。设置后，会覆盖hostname.rm-id配置。
yarn.resourcemanager.resource-tracker.address.rm-id	指定NodeManager连接RM的端口。设置后，会覆盖hostname.rm-id配置。
yarn.resourcemanager.admin.address.rm-id	指定接收管理员命令的host。设置后，会覆盖hostname.rm-id配置。
yarn.resourcemanager.webapp.address.rm-id	设定webapp的host。设置后，会覆盖hostname.rm-id配置。
yarn.resourcemanager.webapp.https.address.rm-id	设定webapp的https host。设置后，会覆盖hostname.rm-id配置。
yarn.resourcemanager.ha.automatic-failover.enabled	启用自动失败转移（failover）。如果HA启用了，该设置会默认启用
yarn.resourcemanager.ha.automatic-failover.embedded	使用内嵌的选主器来推荐Active RM。如果HA启用了，该设置会默认启用
yarn.resourcemanager.cluster-id	集群的id，供选主器使用，以防选择Active RM给错误的集群。
yarn.client.failover-proxy-provider	指定Client、AM、NM取轮询Active RM时的处理逻辑类。
yarn.client.failover-max-attempts	最大轮询尝试次数。

5.3.2 Admin commands

在hadoop-current/bin或yarn-current/bin目录下可以执行一些HA相关命令：

（1）yarn rmadmin -getServiceState rmId 获取rmId对应的RM状态

示例：

hadoop@classb-ds-bigdata9:~/hadoop-current/bin$ ./yarn rmadmin -getServiceState rm1activehadoop@classb-ds-bigdata9:~/hadoop-current/bin$ ./yarn rmadmin -getServiceState rm2standby

（2）yarn rmadmin -transitionToStandby rmId 切换rmId对应的RM的状态为Standby

（3）yarn rmadmin -transitionToActive rmId 切换rmId对应的RM的状态为Standby

需要注意的是，当automatic failover设置为enabled时，默认不能使用手动的状态转移命令。如果非要强制使用，可以加-forcemanual参数（不推荐，须谨慎）。

6. YARN常用命令

6.1 简介

YARN的命令通过bin/yarn脚本命令执行。不带任何参数直接执行yarn命令，可以打印所有命令的描述。运行yarn命令的标准姿势是：yarn COMMAND COMMAND_OPTIONS。按照命令的使用场景可以划分为两个不同的类型：User Commands和Administration Commands。

6.2 User Commands

用户使用的一些有用命令。

6.2.1 application

使用方式： yarn application [options]

常用的参数：

Options	Description
-list	默认列出所有未完成(SUBMITTED, ACCEPTED, RUNNING)的应用
-appStates	与-list配合使用，用于过滤应用的状态（多个状态用逗号分隔）。如：yarn application -list -appStates ALL
-appTypes	与-list配合使用，用于过滤应用类型。如：yarn application -list -appTypes MAPREDUCE
-kill	杀死应用
-status	获取应用的状态

备注：有效的应用状态包括：ALL, NEW, NEW_SAVING, SUBMITTED, ACCEPTED, RUNNING, FINISHED, FAILED, KILLED。有效的应用类型包括SPARK、MAPREDUCT等。

6.2.2 applicationattempt

使用方式： yarn application [options]

Options	Description
-list	列出该应用的每次attempt信息
-status	列出应用的某次attempt的状态信息

6.2.3 yarn classpath

使用方式：yarn application [options]

打印获取hadoop jar以及一些库文件所必需的class path。

6.2.4 container

使用方式：yarn container [options]

Options	Description
-list	列出应用的某次attempt的的container信息
-status	打印container的状态

6.2.5 jar

使用方式: yarn jar [mainClass] args...

将YARN的代码绑定在jar文件中，通过命令行来执行。

6.2.6 logs

使用方式：yarn logs [options]

Options	Description
-applicationId	查看指定应用的日志
-appOwner	按照AppOwner过滤日志，默认是当前用户
-containerId -nodeAddress	查看指定container的日志

6.2.7 node

使用方式：yarn node [options]

Options	Description
-list	列出所有运行中的计算节点。
-all	与-list配合使用，列出所有计算节点。如：yarn node -list -all
-states	与-list配合使用，按states过滤，多个states则用逗号分隔
-status	查看指定Node的状态信息