深入YARN系列3：剖析NodeManager架构，组件与生产应用

￡神魔★判官ぃ 2022-10-06 05:58 158阅读 0赞

深入YARN系列主要分为：  
[深入YARN系列1：窥全貌之YARN架构，设计，通信原理等][YARN_1_YARN]  
[深入YARN系列2：剖析ResourceManager的架构与组件使用][YARN_2_ResourceManager]  
深入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.NodeManager的功能与服务架构 #

## 2.1NodeManager主要职责 ##

NodeManager的概述与核心功能，Hadoop官网一言以蔽之：NodeManager 负责启动和管理节点上的容器。这些容器用来执行 AppMaster 指定的任务。实际使用中,NM的主要功能如下：

1.  **启动后向RM注册，然后与之保持通信，通过心跳汇报自己的状态以及接受来自RM的指令。**
2.  **监控节点的健康状态，并与RM同步**
3.  **管理节点上所有的Container的生命周期，监控Container的资源使用情况，以及Container运行产生的日志（核心）,NM会向RM汇报Container的状态信息。**
4.  **管理分布式缓存（对Container运行需要的依赖，依赖库如jar,配置文件等进行本地缓存），以及不同应用程序的其他附属要求**

## 2.2 NodeManager服务架构组成 ##

**NodeManager内部也有很多组件构成，核心的组件主要NodeStatusUpdater,ContainerManager,NodeHealthCheckService这三大块构成。**

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI2NDQyNTUz_size_16_color_FFFFFF_t_70 1][]

### 2.2.1NodeStatusUpdater解析 ###

**这个组件是NM和RM通信的唯一渠道，主要是用来NM刚启动或者重启后向RM进行注册使用的，NM刚启动时会向RM注册，然后汇报本节点的资源情况。后面面周期性地汇报节点的健康状态，Containers运行情况，正在运行的，已完成，待清理的等等。RM会在NM注册时给其发送一个令牌KEY，NM保存这个KEY,用这个令牌KEY为AM请求的Container做认证。**

其次当一个节点退役或者程序完成时，RM会通过NodeStatusUpdater通知NM杀死正在运行的Container或者清理已经完成应用程序的资源，然后将应用程序的运行日志进行聚合。

### 2.2.2 ContainerManager解析 ###

NM的核心是Container的分配与管理，而ContainerManager就是这个核心。一个Container从拉起运行，到最终结束需要很多服务配合，比如通信，资源管理，运行策略等等。而这些服务都有ContainerManager提供管理，具体则由内部的组件完成。![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI2NDQyNTUz_size_16_color_FFFFFF_t_70 2][]

**         其中的ContainerLauncher类似RM中的ApplicationMaster launcher，区别是前者只拉起AM。而这里的ContainerLauncher同样也是维护一个线程池，主要用来杀死或者启动Container。杀死的请求主要来自RM通过NodeStatusUpdater或者AM通过RPC服务要求清理某个Container时，来杀死Container。而通过ContainerLauncher启动Container则只有AM通过RPC Server通信发送的请求。**

**  ContainerMonitor就是管理NM上运行中的Container的资源使用情况，如果有Container资源使用情况超过申请的值，就会被杀死.**

**     ResourceLocaliazationService资源本地化服务其实就是，在启动Container前将其需要的所有的资源安全地下载到本地磁盘，比如从HDFS上下载的文件（程序提交YARN时，YARN会返回一个路径，一个应用所需资源的HDFS提交路径）**

### 2.2.3NodeHealthCheckService节点健康检查 ###

节点的健康检查通过YARN提供的脚本，定期运行，将检查结果通过NodeStatusUpdater汇报给RM,以方便RM做节点的监控管理，进一步操作,比如拉黑这个NM，不在给它分配计算任务，直到恢复为止。

# 3.要了解Container的这些 #

## 3.1Container是什么？ ##

Container是什么？一般会说Container是NM中抽象的资源集合（包含cpu，内存等）。但实际AM向RM请求的Container是什么呢？NM上启动一个Container需要哪些信息？

其实YARN中的Container实例实际是Container Launch Context，包含依赖库，运行资源（文件，配置信息，运行资源大小），创建进程的必要命令以及安全令牌TOKEN等。具体可参考Container的生命周期。

**     某种程度上说 Containers其实是一种资源分配形式，它授权应用程序可以在分布式集群中使用某台机器的某些资源。但目前YARN仅支持内存和CPU两种资源，而且CPU的资源隔离还是使用的Linux的轻量级资源隔离机制CGroup，进行资源隔离的**

## 3.2Container的生命周期 ##

一个Container的生命周期大致可以分成三个过程：

1.  **资源本地化：主要是Container在启动前，先将Container运行应用程序需要的各种"资源"下载缓存到本地,供后续Container启动使用。**
2.  **Container拉起/启动：身份验证后，服务由ContainerLauncher拉起，启动Container，执行应用程序的代码。**
3.  **资源清理：对已经运行完成后者不需要的资源进行清理，防止“爆盘”，跟资源本地化是逆过程。同时NM对Container资源进行回收。**

其实内部一个Container生命周期内的状态远比这复杂的多，分成很多状态阶段,，从new...Localizing.....Done还有很多细化到状态，由Container的专门状态机制维护。

# 4. NodeManager生产主要参数解析与优化 #

## 4.1数据/日志目录 ##

### 4.1.1数据目录 ###

NodeManager上的存储目录主要两种，一是数据存储目录，用于存储Container运行前需要依赖的文件（jar，配置文件等等），Container运行中产生的临时数据，比如MR任务运行中落盘的数据。二则是日志数据目录，存储该节点所有Container运行中产生的日志。

yarn.nodemanager.local-dirs
    --NodeManager 存储中间数据文件的本地文件系统中的目录列表
    
      <property>
            <name>yarn.nodemanager.local-dirs</name>
            <value>
                /hadoop/data/tmp/nodemanager,/hadoop1/data/tmp/nodemanager,/hadoop2/data/tmp/nodemanager,/hadoop3/data/tmp/nodemanager,/hadoop4/data/tmp/nodemanager,/hadoop5/data/tmp/nodemanager,/hadoop6/data/tmp/nodemanager,/hadoop7/data/tmp/nodemanager,/hadoop8/data/tmp/nodemanager,/hadoop9/data/tmp/nodemanager,/hadoop10/data/tmp/nodemanager,/hadoop11/data/tmp/nodemanager
            </value>
        </property>

**注意：一般会将该节点的所有挂载盘（除/根目录外）都会配置成数据目录，用逗号分隔即可，一般所有的数据目录结构都一致，如上所示，挂载了12块盘的集群数据目录，具体目录的名称可以自定义；这样配置是为了提高读写和负载均衡性能。**

**      这样配置后实际使用时会采用轮询的方式将不同的磁盘分配给不同的Container写入数据。而且为了防止Container的数据被删除，YARN统一规定必须等Application完成以后，才会清理掉临时文件。**

### **4.1.2 日志目录** ###

yarn.nodemanager.log-dirs
    --日志目录，也可以配置多个，提高负载，但会限制大小，防止爆盘。
    
    --注意，一般也可以直接配置一个目录
      <property>
            <name>yarn.nodemanager.log-dirs</name>
            <value>            
    /var/log/hadoop-yarn/container
            </value>
        </property>

**注意：和数据目录一样，YARN也支持将日志目录配置成多个目录，提高读写负载均衡。注意这个日志是Container运行日志，不止NodeManager运行日志。一般一个节点一天都会有大量的Container分配，运行，所以也会聚集大量的Container运行日志，所以本地日志必须定期清理，否则迟早会爆盘，当然也可以启动聚合日志，将日志上传的HDFS进行分布式存储，方便后面进行查看分析**。**Yarn提供了如下参数，对日志进行处理：**

1.yarn.nodemanager.log.retain-seconds=10800
    保留用户日志的时间（以秒为单位）。仅适用在日志聚合已禁用的情况下。
    一旦超出时间，NodeManager会将该应用程序的所有日志进行删除。
    
    2.yarn.log-aggregation-enable 
    默认false，不启用聚合日志，生产一般启动true
    yarn.log-aggregation.retain-seconds 
    启用聚合日志后，聚合日志保留多久，建议7天，根据实际制定
    
    3.yarn.nodemanager.remote-app-log-dir
    默认值hdfs上：/tmp/logs，
    
    4.yarn.nodemanager.remote-app-log-dir-suffix
    默认值是logs
    最后聚合日志的目录就是由这个目录由参数3值++用户名+参数4的值等合成而来

**如下图HDFS上聚合日志目录：关于聚合日志的设置使用还有很多参数，具体可以参考hadoop官网yarn-site.xml文件：**

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI2NDQyNTUz_size_16_color_FFFFFF_t_70 3][]

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI2NDQyNTUz_size_16_color_FFFFFF_t_70 4][]

## 4.2资源参数优化 ##

### 4.2.1计算节点NM可使用资源配置，节点级别 ###

**1.yarn.nodemanager.resource.memory-mb**

这个值是NM节点可以使用当前服务器的最大内存，一般可以设置服务器内存的70%-85%之间，比如服务器内存256G,只有NM服务可以设置成200G。

**2.yarn.nodemanager.resource.cpu-vcores**

这个值是NM节点可以使用当前服务器的最大CPU核数，一般可以设置服务器核数的70%-85%之间，比如服务器64核,可以设置50

**下面是HDP官网给的推荐预留内存设置，如果节点不单存是NM,则需要预留更多**

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI2NDQyNTUz_size_16_color_FFFFFF_t_70 5][]

### 4.2.1节点NM上Container的大小设置 ###

**如上，我们知道Container是NM上资源分配的形式，一个NM可以看成很多个不同的Container构成，下面是控制AM申请的Container大小的控制。**

**1.yarn.scheduler.minimum-allocation-mb**

单个容器的最小物理内存量（以 MiB 为单位），一般看公司数据量，我们公司设置3g,一般公司2g也可，且居多都是2g。注意如果申请的资源小于这个值，也按这个值去分配。

**2.yarn.scheduler.maximum-allocation-mb **

可为容器请求的最大物理内存数量（以 MiB 为单位）。这个值建议可以为单节点NM的可使用的最大内存值。即等于**yarn.nodemanager.resource.memory-mb这个值，尤其对于数据量大，计算复杂的公司而言,防止因为内存不足任务报错。因为使用FAIR公平调度器，如果容器内存不足重试后还不足，直接任务报错，而使用Capcity调度器可以根据实际Container需要的大小动态调整。具体可参考我的博客。一般公司数据朗不大的话，可以配置NM值的一半也可，即一个NM最小时可以启动两个Container。比如以MR任务为例，这个值会限制单个MAP可以使用的最大内存**

**3.yarn.scheduler.maximum-allocation-vcores**

**  yarn.scheduler.minimum-allocation-vcores**

**一般服务器64核，最小可配置1，最大可配置48，****同样，上面两个参数是确认一个Container可使用的NM上CPU的大小，一般可参考和cpu：内存=1:3配置，比如Container内存最小值是3g，可以配置1核，当然不能超过NM最大的CPU使用核数限制。**

**5..yarn.scheduler.increment-allocation-mb=512Mb**

**  yarn.scheduler.increment-allocation-vcores=1**

**这两个参数是请求资源超出Container最小值后，如何进行动态增加，这两个参数只对Fairl公平调度器有用，比如YARN的container最小资源内存量为3G，上面的规整化因子是512Mb，如果一个应用程序申请3.2G内存，则会得到3.5内存。但对Capcity调度没用作用，容量调度器直接增加最小资源的整数倍，同样申请3.5，后者直接分配7G。具体参考:[大数据架构师一定要弄清楚Fair Scheduler和Capacity Scheduler调度器][Fair Scheduler_Capacity Scheduler]**

**如下是HDP官网给的配置推荐**

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI2NDQyNTUz_size_16_color_FFFFFF_t_70 6][]

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI2NDQyNTUz_size_16_color_FFFFFF_t_70 7][]

[YARN_1_YARN]: https://blog.csdn.net/qq_26442553/article/details/117709982?spm=1001.2014.3001.5501
[YARN_2_ResourceManager]: https://blog.csdn.net/qq_26442553/article/details/117815763?spm=1001.2014.3001.5501
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI2NDQyNTUz_size_16_color_FFFFFF_t_70]: /images/20221005/93123395b84f4d6aa475e7f8d7fc30c4.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI2NDQyNTUz_size_16_color_FFFFFF_t_70 1]: /images/20221005/ed566f1e71c44af2ab2fb146c8ad1d20.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI2NDQyNTUz_size_16_color_FFFFFF_t_70 2]: /images/20221005/41a50019a6c142799e0a6104f93fa30f.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI2NDQyNTUz_size_16_color_FFFFFF_t_70 3]: /images/20221005/7b993d23f904460da992566991d245f8.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI2NDQyNTUz_size_16_color_FFFFFF_t_70 4]: /images/20221005/7f61fc9f8c224c239e3cdaac2627f5fe.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI2NDQyNTUz_size_16_color_FFFFFF_t_70 5]: /images/20221005/ccafd041d8864db984fddce90fa2a3bc.png
[Fair Scheduler_Capacity Scheduler]: https://blog.csdn.net/qq_26442553/article/details/117284107?spm=1001.2014.3001.5501
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI2NDQyNTUz_size_16_color_FFFFFF_t_70 6]: /images/20221005/0b38ab7a20a74570a897785fdba24eae.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI2NDQyNTUz_size_16_color_FFFFFF_t_70 7]: /images/20221005/c95a093101a44ecd971be94ed3f934de.png