深入YARN系列2：剖析ResourceManager的架构与组件使用

柔光的暖阳◎ 2022-10-06 05:45 217阅读 0赞

深入YARN系列主要分为：  
[深入YARN系列1：窥全貌之YARN架构，设计，通信原理等][YARN_1_YARN]  
深入YARN系列2：剖析ResourceManaer的架构与核心源码分析  
深入YARN系列3：剖析NodeManager架构，组件机制，生产应用  
深入YARN系列4：剖析ApplicationMaster的任务管理机制与生产调优  
深入YARN系列5：YARN三大组件配合使用与YARN生产性能优化  
![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI2NDQyNTUz_size_16_color_FFFFFF_t_70][]

# 1.回顾YARN的三大组件 #

## 1.1**ResourceManager全局资源管理器** ##

**每个集群有一个RM守护进程（可HA）**，RM负责整个系统的资源分配与管理；它主要有调度器ResourceScheduler和应用程序管理器（APPlications Manager）构成；

## 1.2 NodeManger，节点资源管理器 ##

**每个节点有一个NM守护进程**，负责本节点的资源管理。其资源分配主要体现在Container模式上，根据RM分配资源。其次NM负责本地可用资源的监控，故障报告，以及Container的生命周期管理等。

## 1.3**Application Master应用程序主管理器** ##

**每个提交的应用程序都有一个AM的守护进程，**客户端每使用YARN客户端启动提交执行一个应用程序之前，先启动一个AM（其实本质就是一个运行的Container，一个程序最早启动的container实例），AM负责与RM进行资源协商，并协同NM工作以完成应用的功能。

**AM的作用就是负责向RM协商资源，并且同时和NM协同配合来运行Container，以及监控他们的资源消耗。**

# 2.从RM的通信架构剖析RM #

## **2.1ResourceManager的主要职责** ##

1.  **先与YARN客户端交互，处理来自客户端的请求（身份认证）。**
2.  **启动监控管理ApplicationMaster，包括重试等 。**
3.  **管理NodeManager，接受其资源汇报，对其资源进行统一分配；对其状态进行监控和下达指令。**
4.  **资源管理与调度，处理AM的请求。**

## **2.2ResourceManager与YARN客户端交互** ##

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI2NDQyNTUz_size_16_color_FFFFFF_t_70 1][]

**注意：****第5步，RM在响应AM的注册请求时，会将自身的资源使用情况(集群的最小容量最大容量等)发送给AM,让AM判断启动Container的策略。**

**YARN的作业，可以使用yarn application 命令来管理，包括-kill,-list,-status等等。**

## **2.3ResourceManager与AM的通信交互** ##

**    RM内部两大员工：ResourceScheduler和APPlications Manager。**

**      前者ResourceScheduler是一个可插拔的调度器组件（可更换不同的调度策略），负责为运行中的各种应用分配资源，资源受队列，容量，优先级等配置制约，它只是一个纯粹的资源调度器，不关心也不负责应用程序的监控和状态跟踪。一句话，只负责分配资源，不管应用死活。ResourceScheduler给应用程序分配的资源叫Container，在NM上启动。注意此外ResourceScheduler还可以进行资源回收，主要发生在集群资源很稀缺的时候，调度器会主动杀死那些超出使用阈值队列分配的Container,以保证其他队列的最小使用资源，一般只会杀死部分。**

**      后者APPlications Manager负责处理客户端提交的应用请求，并且它还根据应用请求分配启动对应AM,如MR任务则启动MapReduce AM等。如果监控到某个AM失败，则其会重启AM。基于如下架构，说明当一个应用提交时，RM内部的的协调机制。**

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI2NDQyNTUz_size_16_color_FFFFFF_t_70 2][]

1.  **如上，当两个不同类型的应用程序通过YARN客户端提交时给YARN时，一系列权限校验后，首先提交给YARN的RM，RM其中APPlications Manager应用管理器，它会根据这个应用程序类型，启动的对应的AM,如这里提交了MapRedcue任务，则应用管理器会跟RM中的调度器Scheduler通信，申请一个Container，如果调度有资源的话就可以满足要求。应用管理器在这个分配的Container上启动MRAPPMaster（即：MapReduce  ApplicationMaster）。所以说AM是一个应用程序启动的第一个Container，为Container0。**
2.  **MRAPPmaster启动后，会定期向RM发送心跳信息，一是为了跟RM中的应用管理器****APPlications Manager通信，报告自己的状态是否存活等，二是与RM保持通信，提交自己的资源需求，等待其ResourceScheduler给起分配资源。**
3.  **AM启动后，表示应用程序起来了，但是实际的计算并没有开始。AM会将自己需要的资源需求发给RM。这个时候如果Scheduler有资源分配给AM，返回《主机名，container数，资源大小.....》。则AM会跟对应的NM进行RPC通信，在对应的NM上启动Container进行任务计算。这些Container受AM的监管。**
4.  **默认是AM在十分钟内没有向RM的应用管理器汇报心跳，则被认为其死亡了。受这些AM管理的所有Contaier都会被置为失败，Killed。 应用管理器会重新申请分配一个Container，启动新的AM，类似于任务重新提交跑（默认配置AM尝试次数2次，可修改）。**

## 2.4 ResourceManager与NodeManager通信交互 ##

RM通过的实现的ResourceTrack接口来和NM进行通信，RM与NM的通信主要实现如下几个功能：

1.  **新节点NM向RM的注册**
2.  **接受管理已经注册的NM节点的心跳，并通过心跳下达指令**
3.  **安全身份认证只有合法的NM才可以与RM通信**

RM中的ResouceTrack Service会将AM心跳的的资源请求发送给ResouceScheduler调度器，调度器会根据NM节点的实际资源使用情况以及应用程序实际资源请求调度分配资源。

**NM在默认10分钟内没有像RM发送心跳，就会被标记死亡。RM将不会在往这个节点分配Container，直到这个节点重启，重新加入RM.**

## 2.5 RM,AM,NM的协同合作架构 ##

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI2NDQyNTUz_size_16_color_FFFFFF_t_70 3][]

**如上图所示：**

**第1步.用户通过YARN客户端向提交YARN支持的应用程序，其中包括了Application Master程序，启动AM的名命令，用户程序，对应的资源等。具体内部的流程参考上面。**

**第2步：通过AM的安全校验后，Resource Manager为该AM分配一个Container,然后与对应的NM通信，要求在上面启动这个Container，启动运行AM程序**

**第3步：AM首先向RM进行注册，其实就是RM中ResourceManager应用管理器注册（这个时候用户就可以通过RM的YARN日志界面查看这个AM了）。然后AM开始为应用程序的各个任务（比如一个MR任务有2000maps,1099reduces）申请运行资源，监控管理运行任务的状态,直到任务运行结束。后面就是重复4-7步了。**

**第4步：AM在监控管理已经运行的任务实例时（如map task），同时保持RM周期性心跳，通过RPC通信向RM提交自己的资源需求，顺便通过心跳领取资源（RM返回对应的主机，启动对应的Containers，大小等）**

**第5步：AM领取到资源时，便与对应的NM通信，要求NM启动该应用程序对应Container，执行相关任务实例。**

**第6步：NM会为第5步AM要求即将启动的任务，设置好运行环境，下载好需要的资源（环境变量，JAR包，配置文件，依赖的文件等），最后通过任务的启动脚本启动任务。（具体参考 剖析NodeManager篇）**

**第7步:拉起后的任务，通过心跳机制向AM汇报自己的运行的状态进度，AM对其监控，包括失败重启，推测执行等等。同时NM监控各个Container的运行状态，像RM进行汇报。**

**第8步：应用程序执行完成后，AM通知RM作业完成，然后RM通知NM聚集日志（一般上传HDFS）,并且清理Container专用文件。如果还有推测执行的Container，则会被直接杀死。**

**尖叫提醒：AM管理的是应用程序相关的任务实例，以MapReduce为例，其MRAM管理的是运行在Container上里的maptask/reducetask，运行状态，会否成功等；而NM管理的是Container，监控Container的状态；RM则管理的是更上层的NM节点的的状态。**

# 3.**ResourceManager内部其他组件** #

**     RM内部两大员工：ResourceScheduler和APPlications Manager。除此之外，还有大量的组件，配合保证RM与客户端，NM,AM进行通信，协调资源分配，任务执行等。**

## 3.1身份验证SecretManager ##

因为yarn的客户端部署安装很简单，是不是大家只要在内网随便参考生产集群的配置文件，模拟一个客户端就可以与之通信了呢？那么如何防止外部伪装呢？

RM内部的SecretManager提供了一系列AM,NM与之通信的令牌与私钥管理机制，进而三者通过RPC通信时进行安全认证与授权。

比如ContainerToken SecretManager保证RM通过AM下发申请，向NM申请Container时的安全性，具体内部使用还是比较复杂的，后期再详细讲解。

比如AMRMToken SecretManager 保证了AM与RM申请资源时的验证与授权，RM会在起始阶段给每个AM分配一个令牌，这些令牌会保存起来直到AM管理的程序执行完毕，在此期间，RM都会通过保存的令牌进行验证。

## 3.2 Administration Service ##

这个主要是用来给管理员使用，通过ResourceManagerAdministrationProtocol通信协议实现管理员动态操作或者刷新YARN配置使用的。比如：

1.  **刷新队列：新增队列，重新配置队列的资源分配，权重，用户ACl限制，队列删除等等。默认YARN10s重新加载一次配置文件，实现冬天刷新，不需要重启集群。**
2.  **用户管理：添加管理员，修改管理员权限等**
3.  **动态刷新YARN管理的节点列表。比如节点退役，有个exclude文件，将需要剔除计算节点的节点剔除集群，停止提交YARN任务。同样维护哪些节点可以进行资源分配的等等，做存储计算分离等。**

## 3.3 ApplicationMaster launcher ##

AM本质是一个运行的Container，且是提交应用程序的第一个Container，Container0 。 应用程序启动时，会向RM申请Container,RM分配对应的Container和节点ip后，APPlications Manager应用管理器会在该节点启动AM。而与NM通信拉起AM的这个角色就是ApplicationMaster launcher。

**该组件维护了一个线程池，通过与NM通信，来处理所有新提交应用程序启动的AM。当然同时如果有AM失败，也靠它重新拉起。此外，如果一个应用程序跑完以后，或者应用程序主动被停止，需要杀死AM,也是通过它和NM通信发送命令干的。**

[YARN_1_YARN]: https://blog.csdn.net/qq_26442553/article/details/117709982?spm=1001.2014.3001.5501
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI2NDQyNTUz_size_16_color_FFFFFF_t_70]: /images/20221005/314111176b8549b08ffda1bad54f5ca7.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI2NDQyNTUz_size_16_color_FFFFFF_t_70 1]: /images/20221005/10ae0b5d4f9a44859851c564d7f68e84.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI2NDQyNTUz_size_16_color_FFFFFF_t_70 2]: /images/20221005/fe79ef6f873b4d98876ea37b1c723242.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI2NDQyNTUz_size_16_color_FFFFFF_t_70 3]: /images/20221005/1984b1f979894b25bc7b9764b8d07e71.png