本文用来记录自己读书的一些笔记

YARN 组件的功能概述

YARN集群主要分为三个部分：ResourceManager、NodeManager和ApplicationMaster。其中ResourceManager的重要组成部分为调度器和ApplicationMaster。

ResourceManager作为独立的进程运行在专有的机器上，负责集群中所有应用程序的资源分配。它可以为用户提供公平的、基于容量的、本地化的资源调度。在Yarn资源的分配单位为Container，它是一组内存和cpu核数的组合（目前只有内存和cpu）。RsoueceManager和运行在每个节点上的NodeManager会进行交互以便执行和跟踪资源的分配。基于可扩展性需求，ResourceManager和NodeManager之间通过心跳进行通信。NodeManager负责本地可用资源的监控，故障报告以及Container生命周期的管理（启动或终止任务）。
用户将Application提交给ResourceManager，被ResourceManager接受的Applcation会被传递给Scheduler并允许其运行。一旦Scheduler有足够的资源可以满足需求，Application的状态就会从Accepted转为Running。ResourceManager会为ApplicationMaster分配一个Container，ApplicationMaster通常被称为“Container0”.
ApplicationMaster是每个用户作业的主进程，负责管理作业的生命周期，包括动态的增加或减少Container，管理执行流程，处理故障和计算偏差，以及执行其他的本地优化。
ApplicationMaster可以运行以任何编程语言实现的用户程序。通常，ApplicationMaster需要利用多台服务器的处理能力来完成一个作业，因此ApplicationMaster会向ResourceManager进行资源请求。这些资源会包含本地化优势和Container的容量（内存和cpu）。ResourceManager根据可用资源和调度策略来为每个Application分配资源。当一个Container被分配给一个ApplicationMaster时，ResourceManager为该资源生成一个租约，ApplicationMaster通过心跳会得到该租约。基于令牌的机制，保证了ApplicationMaster在NodeManager上使用Container的可靠性。Container在运行过程中，会通过特定协议与ApplicationMaster通信，来报告状态和健康信息，以及接受框架的特定指令（杀掉任务等）。通过这种方式，Yarn提供了对Container的监控和生命周期管理的基础框架，而应用程序特定语义由每个框架独立管理。

ResourceManager

ResourceManager是集群所有资源的仲裁者。它的主要职责就是调度，即在竞争的应用程序之间分配系统中的可用资源，但是它不关心每个应用程序的状态。调度器只处理应用程序的整体资源分配，不关心局部优化和内部流程。ResouceManager不负责的职能，它没有跟踪应用程序的执行流程，没有任务容错能力。

Yarn调度器

Yarn有一个可插拔的调度器组件，根据不同的使用场景和用户需求，管理员可以选择不同的调度策略，目前支持FIFO、Capacity和Fair。具体使用哪种调度器可以在yarn-default.xml中设置。

FIFO

先进先出调度器，它不考虑作业的优先级和范围。FIFO比较适合低负载集群，当使用大型共享集群时，它的功能不佳。

Capacity

Capacity调度器允许多个组安全的共享一个大规模Hadoop集群。要使用Capacity调度器，管理员使用总槽位容量的预定值配置一个或多个队列。这种分配保证了每个队列的最小使用量。管理员为每个队列的可用资源容量配置软限制和可选的硬限制。每个队列有严格的ACL，用来控制那些用户可以向那些队列提交作业。同时也有措施来保证无法查看或修改其他用户的应用程序。
Capacity调度器允许共享集群，同时给每个用户或组一定的最小容量保证。这些最小值在不需要时可以放弃，超出的容量将会给予那些最饥饿的队列，饥饿程度用运行中或已用的队列容量来衡量。
队列的定义和属性可以由管理员以安全的方式，在运行期间修改，以尽量减少对用户的干扰。管理员可以在运行期间添加额外的队列。管理不能在运行期间删除已有队列，但是可以在运行期间停止队列，以确保现有application运行完毕后不会再有新的应用程序被提交。
当工作负载可预见的情况下，Capacity调度器效果最好，有助于分配最小容量。在每个队列内部，使用层次化的FIFO来调度多个Application，类似于在独立的FIFO调度器中使用的方式。

Fair调度器

Fair调度器是将资源公平分配给应用的方法，使得所有应用在平均情况下随着时间得到相等的份额。
在Fair调度模型中，每个Application都属于某一个队列。Yarn Container的分配是选择使用了最少资源的队列，在这个队列中，再选择使用最少资源的应用程序。默认情况下，所有的用户共享一个名为“default”的队列。应用程序可以在提交时指定想要添加的队列。另外，也可以将Fair调度器配置成根据请求中包含的用户名来分配队列。Fair调度器还支持许多功能，如队列的权重、最小份额、最大份额以及队列内FIFO策略，但基本原则就是尽可能平均共享资源。
Fair调度器也支持抢占的概念，从而可以从ApplicationMaster那里要回Container，并且根据配置和应用程序的设计，抢占和随后的资源分配可以是友好的或者强制的。
除了提供平均共享，Fair调度器还允许保证队列的最小份额，确保某些用户、组或者生产应用程序总能够得到足够的资源。当队列中有等待的Application时，它至少能够得到最小份额的资源。Fair调度器可以通过配置文件限制每个用户和每个对了中运行Application的数量。
Fair调度器允许Container请求一定量的内存资源。为了避免多个较小内存Application饿死一个较大内存应用，引入了“reserved Container”，如果由于内存不足，一个Applicaiton不能立即使用一个Container，可以将其保留给其他应用程序，这样，其他应用程序不能使用这个Container，直到它被释放。被保留的Container会等待其他本地Container被释放，然后使用这些额外的容量来完成这个作业。一个保留的Container只允许在一个节点上，并且一个节点只允许一个保留的Container。
Fair调度器也支持层次化队列，队列可以嵌套在其他队列中，每个队列将它的资源再以一种公平的调度方式分配给它的子队列。

Container

Container是单个节点上一组资源（内存、CPU等）的集合。单个NodeManager上可以有多个Container，Container由NodeManager监控，由ResourceManager调度。
每个Application都是从ApplicationMaster开始，而且这个ApplicationMaster本身也是一个Container（Container0）。启动后，ApplicationMaster会向ResourceManager请求更多的Container，在运行期间，可以动态的请求或释放Continer。

NodeManager

NodeManager的职责包括：与ResourceManager保持通信、管理Container的生命周期、监控每个Container的资源使用、跟踪节点健康状态、管理日志和不同应用程序的附属服务。
NodeManager启动时会向ResourceManager进行注册，然后发送包含自身状态的心跳，并等待来自ResourceManager的指令。
Contianer使用一个Container启动上下文来描述，这个描述包含环境变量、在远程存储上的依赖、安全令牌、NodeManager服务的載荷以及创建进程的必要命令。在验证了Container租约之后，NodeManager为Container配置环境，包括根据资源限制初始化它的监控。NodeManager可以杀死由ResourceManager指定的Container，或者资源超出限制的Container。

ApplicationMaster

ApplicationMaster是协调集群中应用程序执行的进程。每个Application都有自己独特的ApplicationMaster，负责与ResourceManager申请资源，并与NodeManager协同工作来执行和监控任务。
ApplicationMaster启动后，后周期性向ResourceManager发送心跳来报告自己的健康以及更新它资源需求。在建好需求模型后，ApplicationMaster在发送给ResourceManager的心跳中封装了它的偏好和限制。在随后的心跳应答中，ApplicationMaster会收到集群中特定节点上绑定了一定资源的container租约。根据Resourcemanager发来的租约，ApplicationMaster可以更新它的执行计划以适应资源的过剩或不足。Container可以在Application运行期间被申请或释放。

YARN资源模型

YARN资源分配模型提供了更大的灵活性，解决了静态分配的低效率问题。每个Container都有一些非静态资源，这些资源目前支持内存和CPU，还可以支持带宽GPU等。

客户端资源请求

Yarn应用程序是从客户端资源请求开始的。客户端先通知ResourceManager要提交一个Application，ResourceManager在应答中给出一个ApplicationID以及有助于客户端请求资源的集群容量信息。

ApplicationMaster分配Container

在得到ResourceManager的应答后，客户端使用“Application Submission Context”（包含ApplicationID、用户名、队列以及其他启动ApplicationMaster所需的信息）发送请求给ResourceManager，同时也会将“Container Launch Context”发送给ResourceManager。Container Launch Context中描述了资源需求（内存和CPU）、作业文件、安全令牌以及在节点上启动ApplicationMaster所需的其他信息。
ResourceManager收到“Application Submission Context”后，为ApplicationMaster调度一个可用的Container（Container0），然后启动ApplicationMaster，启动ApplicationMaster之后，ResourceManager会告诉ApplicationMaster当前的资源报告。
基于可用资源报告，ApplicationMaster会请求一定的Container。ResourceManager根据资源调度策略，尽可能最优（如本地优势）的分配Container，并作为资源请求的应答发送给ApplicationMaster。
在作业的执行过程中，ApplicationMaster会向ResourceManager发送心跳信息。ApplicationMaster还可以将申请和释放Container的信息包含在心跳中。当作业结束时会向RsourceManager发送完成信息并退出。

ApplicationMaster与Container管理器的通信

在这个阶段，ResourceManager已经将启动NodeManager的控制权交给了ApplicationMaster。ApplicationMaster将单独联系NodeManager并提供Container Launch Context（包含依赖文件、安全令牌以及启动进程所需的命令）。启动Container时，所有数据文件、可执行文件以及必要的依赖文件都会拷贝到节点的本地存储上，依赖文件可以被相同节点上相同Application的Container共享。
一旦启动Container，ApplicationMaster会检查它们的状态，ResourceManager不参与Application的执行，只处理调度以及监控其他资源。Container可以被ResourceManager给Kill掉，当Container被Kill掉之后，NodeManager会清理它的本地工作目录。如果是Applicaiton完成，ResourceManager会通知NodeManager聚合日志病清理Container专用的文件。

管理Application的依赖文件

当启动一个Container时，ApplicationMaster可以指定该Container所需文件，因此，这些文件会被本地化处理，而Yarn负责本地化处理的所有操作。

LocalResource的定义

这部分包含两个操作

Localization：拷贝/下载远程资源到本地文件系统的过程。
LocalResource：LocalResource代表运行Container所需的本地资源。NodeManager负责在启动Container之前将这些资源本地化。
LocalCache：NodeManager维护和管理所有已下载文件的几种本地缓存，这些资源基于最初拷贝该文件时使用的远程URL作为唯一标识。

对于每种资源，应用程序都可以指定下面的信息：

URL：待下载的LocalResource的远程地址。
Size：LocalResource的大小，以byte为单位。
Creation timestamp：资源在远程文件系统上创建的时间。
LocalResourceType：NodeManager本地化的资源类型，包括FILE、ARCHIVE和PATTERN。
Patten：用于从存档文件中提取条目的样式（只对PATTERN类型适用）。
LocalResourceVisibility：指定NodeManager本地化资源的可见性，包括：PUBLIC、PRIVATE和APPLICATION。

LocalResource时间戳

NodeManager在下载资源文件之前，会检查这些文件有没有被修改过，这个检查可以确保LocalResource的一致性–应用程序在整个运行期间使用相同的文件内容。
一旦文件从远程位置拷贝到NodeManager的本地磁盘，它失去了除了URL之外所有与原始文件的联系，不再对远程文件的修改进行跟踪。为了避免不一致的问题，Yarn会让依赖于被修改的远程文件的Container失败。
ApplicationMaster在一个节点上启动Container时，会向NodeManager指定资源的时间戳。

LocalResource类型

FILE：一个普通文件，文本或二进制文件。
ARCHIVE：压缩文件，会被NodeManager自动解压缩。目前可以识别jar、tar、tar.gz以及zip。
PATTERN：ARCHIVE和FILE类型的组合。目前只有JAR文件支持PATTERN类型。

LocalResource的可见性

由LocalResource-Visibility指定，LocalResource有三种可见性：

PUBLIC

标记为PUBLIC的LocalResource可以被任何用户的Container访问。这些文件被拷贝到公共的LocalCache，之后本地上任何Container都可以直接从这个公共的LocalCache中读取文件，在LocalCache被清除之前，都不需要再次下载文件。

PRIVATE

使用PRIVATE标记的LocalResource可以被节点上同一用户的应用程序共享。这些LocalResource被复制到特定用户的私有缓存中。由同一个用户的不同应用程序的所有Container都可以访问这些文件。

APPLICATION

使用APPLICATION标记的资源可以被同一节点上相同Application的Container所共享。这些LocalResource被复制到应用程序专有的LocalCache。

LocalResource的生命周期

不同类型的LocalResource具有不同的生命周期：

PUBLIC LocalResource 在Container或者应用程序结束时都不会被删除，但是在磁盘容量紧张时会删除。这个阈值可以通过yarn.nodemanager.localizer.cache.target-size-mb来指定。
PRIVATE LocalResource 与PUBLIC LocalResource的生命周期相同。
APPLICATION LocalResource会在应用程序结束后立即被删除。

注意：APPLICATION LocalResource生命周期是以Application来界定，而不是ApplicationAttempt。

Apache Hadoop YARN的管理

基本的Yarn管理

Yarn环境的基本配置文件如下：

core-default.xml 系统范围的配置
hdfs-default.xml 分布式文件系统的配置
mapred-default.xml YARN的MapReduce框架配置
yarn-default.xml YARN的配置

YARN的管理工具

Yarn有一些内置管理功能，通过yarn rmadmin -help 命令行命令可以查看具体的命令说明。

增加或关闭YARN节点

有两个文件决定了哪些节点属于集群内，哪些节点数据不属于集群内：yarn.resourcemanager.nodes.include-path和yarn.resourcemanager.nodes.exclude-path。当这两个文件修改之后，可以通过下面的命令行命令来刷新ResourceManager，对节点进行容纳或踢出。

1	yarn rmadmin -refreshNodes

执行刷新命令需要管理员权限，管理员是通过ResourceManager上配置项 yarn.admin.acl 来指定的。

Capacity调度器的配置

调度器的详细配置会在稍后介绍，这里我们介绍重新配置和添加队列。
要重新配置或添加队列，可以使用前面提到的confidence-haddoop2.sh或者直接编辑$Hadoop_conf_dir/etc/hadoop/capacity-scheduler.xml来实现。修改后，执行如下命令行命令来进行刷新：

1	yarn rmadmin -refreshQueues

注意不能够删除队列，只能增加或重新配置队列。

YRAN的Web代理

默认情况下，代理是作为ResourceManager的一部分运行的，但是也可以通过配置项 yarn.web-proxy.address 来使其独立运行。配置项默认为空，表示在ResourceManager运行。独立运行时，通过 yarn.web-proxy.principal 和 yarn.web-proxy.keytab 两个配置项可以控制使用 Kerberos 进行安全认证。

使用 JobHistoryServer

。。。

更新用户到用户组的映射关系

配置项 hadoop.security.group.mapping 决定了 ResourceManager 中使用的用户与用户组的映射关系的定义类。默认为org.apache.hadoop.security.ShellBasedUnixGroupsMapping，如果用户想要实现自己的类，需要实现org.apache.hadoop.security.GroupMappingServiceProvider接口。如果修改了映射关系，则需要使用下面的命令来更新ResourceManager：

1	yarn rmadmin -refreshUserToGroupMapping

更新超级用户代理群映射关系

通过配置 hadoop.proxyuser.< proxy-user-name >.groups ，可以让用户$proxy-user-name 成为具有特殊权限的用户，它可以模拟配置值中的任意用户。配置项 hadoop.proxyuser.< proxy-user-name >.hosts 的配置值为逗号分隔的主机列表，只有配置在这里的这些主机，才可以使用前面的 $proxy-user-name 来模拟所配置的用户。如果修改这两个配置，则需要使用下面的命令行命令来更新ResourceManager：

1	yarn rmadmin -refreshSuperUserGroupsConfiguration

$proxy-user-name用户在模拟其他用户时，自己必须使用Kerberos认证。

更新ResourceManager管理的ACL

配置项 yarn.admin.acl 指定了谁是YRAN集群的管理员。管理员可以更新队列、管理节点列表、用户-群组映射、管理列表本身以及服务级别的ACL。还可以查看任何用户的Application、访问所有的Web界面、调用任何Web服务，以及杀掉任何队列中的Application。
这个配置项的值是一个用逗号分隔的用户列表和一个用逗号分隔的用户组列表，用户列表和用户组列表使用空格分隔，如：

1	user1,user2 group1,group2

当这个配置项变更后，管理员需要使用下面的命令行命令来刷新ResourceManager

1	yarn rmadmin -refreshAdminAcls

重新加载服务级授权策略文件

管理员可以使用下面的命令行命令来重新加载授权策略文件：

1	yarn rmadmin -refreshServiceACL

管理YARN作业

Yarn的作业可以通过 yarn application 命令来管理。可以使用的子命令有：kill、list、status、appTypes和help。如

1	yarn application -list

各个子命令的作用，通过名字我们也可以看出来。

设置Container的内存

通过 yarn-site.xml 中的三个重要的配置，可以控制Container的内存：

yarn.nodemanager.resource.memory-mb 指定了NodeManager可以给Container使用的内存总量（机器上可以用来给Container分配的最大内存）。
yarn.scheduler.minimum-allocation-mb 是ResourceManager允许分配给Container的最小内存。如果请求的Container的内存值小于这个值，则使用这个值，默认为1024MB。
yarn.scheduler.maximum-allocation-mb 是ResourceManager允许分配给Container的最大内存，默认为8192MB。

设置Container核数

通过 yarn-site.xml中的配置，我们可以控制Container的核数：

yarn.scheduler.minimum-allocation-vcores 指定了Container使用的最小core数。
yarn.scheduler.maximum-allocation-vcores 指定了Container使用的最大core数。
yarn.nodemanager.resource.cpu-vcores 指定了节点上可以用来给Container分配的总core数。

用户日志管理

在应用完成后，Yarn通过NodeManager提供的将日志安全的移动到HDFS上的功能，解决了日志管理问题。

Yarn上的日志聚合

有了Yarn，对于同一个应用的所有Container的日志，可以聚合并写到指定文件系统的指定目录中的一个单独文件中。用户可以通过命令行工具、web用户界面或直接从文件系统来访问这些日志。在MapReduce的JobHistoryServer中运行着一个AggregatedLogDeletionService服务，会周期性的删除聚合日志。

Web用户界面

在应用运行期间，用户可以通过ApplicationMaster的用户界面看到日志，它将用户重定向到NodeManager的用户界面。一旦Application运行结束，完整的信息就交由JobHistoryServer管理。

命令行访问

用户还可以使用命令行工具来与日志进行交互。可以运行下面的命令来查看可用命令：

yarn logs

命令的格式为：

1	yarn logs -applicationId < application ID > [Options]

常用的选项有：-appOwner、-containerId、-nodeAddress，例如下面的命令可以打印出整个Application的全部日志：

1	yarn logs -applicationId XXXXXXX

使用命令行工具的优点是可以通过Shell工具来帮助处理日志信息。

日志的管理和配置

yarn.nodemanager.log-dirs 决定了在Container运行时，它的日志在节点上保存的位置。应用的本地化日志目录在{yarn.nodemanager.log-dirs}/application${applicationId}下。各个Container的日志目录位于{yarn.nodemanager.log-dirs}/application${applicationId}/container_{$containerId}子目录中。
yarn.log-aggregation-enable 指定了是否开启日志聚合功能。如果关闭了，NodeManager会本地化保存日志，不会进行聚合操作。

如果开启了日志聚合功能，那么下面的配置也将生效：

yarn.nodemanager.remote-app-log-dir：指定了NodeManager将在哪里聚合日志。
yarn.nodemanager.remote-app-log-dir-suffix：将在${yarn.nodemanager.remote-app-log-dir}/${user}下创建远程日志的后缀,默认为log。需要注意，这里的${user}是指Container创建用户的用户名。比如一个ThriftServer，可能使用xiaomao启动的，那么这里的user就是xiaomao。
yarn.log-aggregation.retain-seconds：删除聚合日志的延迟，将在这个时长之后删除日志。如果为负数则表示不删除。
yarn.log-aggregation.retain-check-interval-seconds：定义检查日志删除的周期，如果为0或负数，那么将会按照聚合日志保留时间的十分之一来计算。
yarn.log.server.url：Application完成后，NodeManager用来将Web用户界面重定向的URL。

如果关闭了日志聚合功能，那么下面的配置将生效：

yarn.nodemanager.log.retain-seconds：日志聚合功能关闭的情况下，各个节点上保留用户日志的时长（单位：秒）。
yarn.nodemanager.log.deletion-threads-count：日志聚合功能关闭情况下，NodeManager用于清理日志所启动的线程数量。

日志权限

远程日志目录需要其所有者是${NMUser}，权限为1777，并且目录和组属于${NMGroup}。每个Application级的目录都是770。

Apache Hadoop YARN的架构指南

Yarn将它的功能分为两层：资源管理平台和程序调度执行。ResourceManager只是简单地基于应用程序的请求做中心的资源配置，而不关心应用程序是如何使用这些资源的。它把这个职责委托给了ApplicationMaster，由ApplicationMaster来协调单个应用程序从ResourceManager请求来的资源的逻辑执行，产生应用程序自己的具体的工作计划，ApplicationMaster利用接收到的资源，协调这个具体计划的执行。

概述

ApplicationMaster和响应的Container一起组成了一个YARN的应用程序。ResourceManager提供应用程序的调度。每个应用程序由一个ApplicationMaster管理，以Container的相识请求每个任务的计算资源。Container由ResourceManager调度，在NodeManager上运行。

ResourceManager

ResourceManager和如下的组件一起工作：

每个节点上的NodeManager：从ResourceManager中获取指令，管理单个节点上可用资源，并接收ApplicationMaster的资源请求。
每个应用程序的ApplicationMaster： ApplicationMaster向ResourceManager申请资源并和NodeManager一起工作，启动、监控和停止Container。

ResourceManager组件概述

ResourceManager会向客户端、NodeManager、ApplicationMaster和其他内部核心组件提供服务。

客户端与ResourceManager交互

用户和平台的第一次交互点是客户端与ResourceManager的交互。这个交互可以分为下面几个部分：

Client Service

这个服务实现了基本的客户端到ResourceManager的接口ApplicationClientProtocol。ClientService处理来自客户端到ResourceManager的RPC通信，包括：

Application的提交
Application的终止
获取Application队列、集群统计，用户ACL以及更多信息。

ClientService为ResouceManager提供额外的保护。当管理员在安全模式下运行Yarn时，ClientService确保所有来自用户的请求都已经得到认证，并且通过查找Application的ACL及后续队列层的ACL对每个用户进行授权。对于不能直接通过Kerberos认证的客户端，ClientService也提供了API，包括ResourceManager代理令牌。

Administration Service

为了确保管理员的请求不会被一般用户的请求饿死，提供高优先级的操作命令，Yarn为所有管理员操作服务提供了一个接口：Administation Service。管理员客户端与Administration Service之间使用ResourceManagerAdministrationProtocol协议通信。
一些重要的管理员操作：

刷新队列。
刷新ResourceManager处理的节点列表。
添加新用户组，添加/更新管理员的ACL。

Application ACL Manager

对于面向用户的API，ResourceManager需要进行控制，只有经过认证的用户才可以访问。ApplicationACLManager管理了每个Application的ACL。ResourceManager可以通过配置yarn.acl.enable为true来启用Application的ACL。
ACL用于控制Application的查看和修改：

查看，决定了通过RPC接口查看一些或所有Application的相关细节，Web UI及Web服务。
修改，决定了哪些用户可以“修改”（杀死）应用程序。

ACL时一个剋执行特殊操作的用户和组列表。用户可以通过他们提交的应用的ApplicationSubmissionContext信息的一部分来指定ACL，这些ACL由ACL Manager对每一个Application进行维护。所有管理员（由yarn.admin.acl属性配置的）可以忽略这些ACL来执行任意操作。
同样的ACL传递给ApplicationMaster，这样ApplicationMaster可以使用该信息让用户访问ApplicationMaster内部的一些服务。
作为ContainerLaunchContext的一部分，当启动一个Container时，也可以使用相同ACL来控制对Application和Container的请求。

ResourceManager Web Application和Web Service

ResourceManager有一个Web应用程序来输出集群的状态信息、指标、节点活跃列表、健康/非健康的节点列表、应用程序列表以及他们的状态和结果、指向ApplicationMaster Web接口的超链接及一个调度的专用接口。

应用程序和ResourceManager的通信

一旦客户端向ResourceManager提交的服务被纳入系统，它穿过ResourceManager内部负责拉起ApplicationMaster的状态机。下面描绘了当ApplicationMaster启动后如何与ResourceManager通信。

ApplicationMaster Service

ApplicationMaster Service用于响应所有来自ApplicationMaster的请求。它与ApplicationMaster之间通过ApplicationMasterProtocol协议，也是唯一的协议。ApplicationMaster Service主要负责如下功能：

注册新的ApplicationMaster。
来自任意正在运行的ApplicationMaster的终止／取消注册请求。
认证来自不同ApplicationMaster的所有请求，确保只有合法的ApplicationMaster发送的请求传递给ResourceMaster中的应用程序对象。
获取来自所有运行ApplicationMaster的Container的分配和释放请求，异步的转发给Yarn调度器。

ApplicationMasterServer有额外的逻辑来保证在任意时间只有一个ApplicationMaster能够发送请求给ResourceManager。

ApplicationMaster 存活监控

为了管理死掉的ApplicationMaster，这个监控跟踪每个ApplicationMaster以及它的最后心跳。在配置的时间间隔外，没有产生心跳的ApplicationMaster会被认为死亡切在ResourceManager中超时。所有处于运行中/分配状态且从属于这个超时的ApplicationMaster的Container也会被标记为死掉。ResourceManager重新调度这个Application，在一个新的Container上重新运行一个ApplicationMaster实例，这样的尝试最多允许两次。

节点和ResourceManager的通信

NodeManager会与下面的RsourceManager的组件进行通信。

Resource Tracker Service

ResourceManagerTracker负责对NodeManager的心跳请求进行响应。它实现了ResourceTracker接口。它负责以下任务：

注册新节点
接收前面注册节点的心跳
确保只有合法的节点可以和ResourceManager通信。

ResouceManager会拒绝任意非法或退役的节点的需求。不满足ResourceManager最小资源配置的请求也会被拒绝。
一旦注册成功，ResourceManager在它的响应信息中会将用于对ApplicationMaster进行认证的相关信息发送给NodeManager。NodeManager会对ApplicationMaster提交的启动Container请求中的NodeManager令牌和Container令牌。处于安全考虑，这些令牌会在之后的心跳中进行同步更新。
Resource Tracker Service转发合法的心跳給YARN调度器，Yarn调度器随后根据节点的空闲可用资源对不同的资源请求作出调度响应。
Resource Tracker Service跟NodeManager存活监控、nodes-list-manager紧密合作。

NodeManager 存活监控

Resource Tracker Service跟踪每一个节点（通过ID）的最后心跳时间，任何没有在配置的时间间隔内发送心跳的节点认为死亡，且在ResourceManager中超时。所有运行在超时节点上的Container也会被标记为死亡，并且不再有新的Container调度到此节点。

Nodes-List Manager

Node-list manager是在ResourceManager内存中的一个集合，包括有效的节点和被排除的节点。它通过读取yarn.resourcemanager.nodes.include-path和yarn.resourcemanager.nodes.exclude-path指定的文件来初始化节点列表。

ResourceManager 核心组件

ApplicationsMaster

ApplicationsManager负责管理已经提交的应用程序的集合。在应用程序提交后，首先检查应用程序的规格，拒绝ApplicationMaster资源请求不合法的Application，确定Applicaiton id的唯一性，最后将通过检查的Application转給调度器。
该组件还负责记录和管理已结束的Application，过一段时间才会从ResourceManager的存储中清除。当一个Application结束后，它将一个ApplicationSummary放到后台的日志文件中。ApplicationSummary是一个Application在结束时的信息总结。
ApplicationsManager保存已经结束的应用程序的缓存，以便用户请求这些应用程序的数据。yarn.resourcemanager.max-completed-applications 指定了ResourceManager存储完成的Application的个数。存储在ResourceManager中的已完成的Application是先进先出的。

ApplicationMaster Launcher

Yarn中，非运行ApplicationMaster的Container都是由ApplicationMaster启动的，而运行ApplicationMaster的Container是由ResourceManager分配并启动的。ApplicationMaster Launcher负责此任务，该组件维护一个线程池来设置环境，且和NodeManager通信启动新提交的ApplicationMaster的Container。在Application结束时，它还会通知NodeManager清理ApplicationMaster对应的Container。

YarnScheduler

Yarn调度器负责为正在运行的Application分配资源，应用程序资源的调度受到容量、队列等多方面的影响。Yarn scheduler基于Application的资源申请请求来执行调度，这些资源包含内存、cpu、磁盘、网络等，当前只支持内存和cpu。

ContainerAllocationExpirer

该组件负责确保所有分配的Container最终都被ApplicationMaster使用，并在相应的NodeManager上启动。ContainerAllocationExpirer包含了一个已经分配但未在相应NodeManager上启动的Container的列表。对于任何一个刚分配的Container，如果在设置的时间内，指定运行Container的NodeManager没有向ResourceManager发送Container已经启动的报告，ResourceManager将会把这个Container标记为死亡且超时。
此外，NodeManager也会在启动Container时对上面所说的超时进行认证（超时信息绑定在Container的ContainerToken中），对于已经超时的Container，NodeManager拒绝启动。

ResourceManager 安全相关的组件

ResourceManager有一系列的组件叫做SecretManager，负责管理令牌和私钥，这些令牌和私钥用于对各个RPC接口上的请求进行认证／授权。

ContainerToken secretManager

SecretManager负责管理ContainerToken。ContainerToken是ResourceManager提供给ApplicationMaster的一个特殊的令牌集合，这样ApplicationMaster可以在特定的节点上使用申请到的Container。SecretManager负责对密钥进行跟踪和更新。
从安全角度来说，在启动一个Container之前，我们不能信任ApplicationMaster传递给NodeManager的信息是正确的，因为ApplicationMaster可能会编造的内存或CPU。为此，ResourceManager发送信息给ApplicationMaster之前，在Container令牌里加密了Container的相关信息。因此一个Container令牌由下面的字段组成：

Container ID：Container的唯一标识。NodeManager使用此信息与特定应用程序绑定。
NodeManager地址：Container令牌编码了目标NodeManager的地址，这样就绑定了NodeManager与Container的关系。
应用程序提交者：提交Application到ResourceManager的用户。NodeManager使用这个用户身份执行所有Container相关的活动。
资源：通知NodeManager给Container分配的资源。NodeManager使用这个信息计算Container的可用资源，并对Container使用的资源进行监控，超出这个分配限制，就会杀掉Container。
超时时间戳：NodeManager根据这个时间戳判断Container是否已经过期，过期的Container会被拒绝启动。
主键标识符：NodeManager用来验证发送给它们的Container令牌。ResourceManager生成密钥，并为密钥分配一个唯一标识。这个密钥和它的唯一标识会通知所有的NodeManager。在NodeManager注册时会发送给NodeManager，之后会在心跳中进行更新通知。密钥更新时，ResourceManager不会立即使用新的密钥，只有在所有NodeManager都得到新的密钥或经过密钥启动时间，才会启用新的密钥。对于NodeManager，可以同时存在两个密钥，具体使用哪个，会根据密钥的唯一标识进行区分。
ResourceManager标识符：ResourceManager也可能会重启，为了区分Container的分配关系，所以将ResourceManager标识符信息编码到Container令牌中。ResourceManager重启会杀掉之前分配的所有的Container，NodeManager也会拒绝之前ResourceManager分配的Container的启动。

AMRMToken 密钥管理器

只有ApplicationMaster可以以Container的形式来请求资源。为了避免恶意程序模仿ApplicationMaster，ResourceManager使用一个叫做AMRMToken的令牌，每个ApplicationAttempt对应一个令牌。密钥管理器在内存中保存每个令牌直到ApplicationMaster结束，在此期间，使用这些令牌来对ApplicationMaster的请求进行认证。
ApplicationMaster可以通过加载一个由YARN本地化的证书来得到这个令牌。这个本地化文件由ApplicationConstants.CONTAINER_TOKEN_FILE_ENV_NAME指定。
与Container的令牌不同，AMRMToken不与系统中的其他实体共享，出于安全的原因，令牌也会每隔一段时间滚动更新，但是不需要激活间隔。

NMToken 密钥管理器

Container令牌用来对来自ApplicationMaster的启动Container的请求进行授权。它们只在为了启动Container而建立的ApplicationMaster到NodeManager的连接中有效。Container令牌的的关键作用是为了防止资源滥用。
除了启动Container时ApplicationMaster和NodeManager建立连接，NodeManager还允许ApplicationMaster停止Container或获取Container状态。但是需要注意的是，ApplicationMaster与每个Container都创建到NodeManager的持久连接是不现实的。
NMToken服务用来解决这个问题，ApplicationMaster使用NMToken来管理跟一个NodeManager的连接，使用这个令牌想这个节点发送请求。

ResourceManager给每个NodeManager和每个Application的Attempt生成一个NMToken。
当Container创建，ResourceManager生成对应NodeManager的NMToker给applicationMaster。
为了优化网络，不是每分配一个Container就把对应NodeManager的NMToker发送给ApplicationMaster，只会在ApplicationMaster的Container首次在NodeManager上创建时才会发送，除此之外，就是在主密钥更新，NMToker失效的情况下才会在此发送给ApplicationMaster。
当ApplicationMaster接收到新的NMToken，它会将对应于NodeManager的旧令牌替换掉。ApplicationMaster内部使用NMTokenCache库来管理令牌。
ApplicationMaster应该始终使用最新的NMToker。如果ApplicationMaster从ResourceManager收到新的NMToken，那么ApplicationMaster应NodeManager的旧连接应该关闭并创建新的连接。如果连接是使用旧的令牌创建的，在发起请求时，NodeManager会简单的拒绝。
和ContainerToken一样，ApplicationMaster与NMToker也是有绑定关系的，会将Application Attempt集成到NMToken中。

RMDelegationToken密钥管理器

这个组件是ResourceMananger上代理令牌的密钥管理。它负责给客户端生成代理令牌，代理令牌可以传递给想要和ResourceManager通信，但没有经过Kerberos认证的Application。

DelegationToken Renewer

在安全模式下，ResourceManager应该开启Kerberos认证，此组件在应用程序运行期间更新应用程序的令牌，知道令牌不能再更新。

NodeManager

NodeManager是Hadoop YARN在每个计算节点上的代理，它根据YARN Application的要求，使用节点上的资源来运行Contianer。NodeManager本质上是Yarn的工作守护进程，主要职责如下：

保持与ResourceManager的同步。
跟踪节点的健康状况。
管理各个Container的生命周期，监控每个Container的资源使用情况。
管理分布式缓存。
管理各个Container生成的日志。
不同的Yarn应用可能需要的辅助服务。

NodeManager 各个组件概述

NodeManager的核心功能是对Container的管理。NodeManager接受来自ApplicationMaster的启动或停止Container的请求，对Container令牌进行鉴权，管理Container执行的依赖库，监控Container的执行过程。管理员

YARN 的HA

参考地址：https://hadoop.apache.org/docs/r2.7.1/hadoop-yarn/hadoop-yarn-site/ResourceManagerHA.html