【CDH】CDH5.16 配置 yarn 任务集中分配设置不生效问题

前言

记录下 CDH 集群 yarn 服务任务集中分配配置不生效问题。

环境信息

• CDH 5.16
• Hadoop 2.6.0
• yarn 为公平调度模式

问题经过

近日，系统运维反馈说我们的大数据集群有一个节点（nodemanager）内存使用率超过报警阈值，触发告警。

排查后发现计算节点（nodemanager）与节点（nodemanager）的负载差距较大，当即就想到了是因为 Yarn 开启了批量分配导致的。

加之由于我们的任务都是流式计算任务，单个任务需要用到的 container 数量不多。所以更会加重这一现象。有点节点已经使用了 175G内存，有的节点才 40G。

解决步骤

1. 参考网上解决方案

此时，我们已经定位到时 Yarn 开启了批量分配，并且我们的任务类型会加重这一现象。我们就解决这个问题就OK了。

网上的解决方案大多是如下解决：

方法一：

将 yarn.scheduler.fair.assignmultiple 设置为 false。

方法二：

1. 将 yarn.scheduler.fair.assignmultiple 设置为 true。

2. 将 yarn.scheduler.fair.max.assign 设置为 一个较小值 （如 3 - 5）。

注：这个值根据自身的计算节点数量和任务启动的容器数量来定，并不是一个所谓的固定值。

2. 配置不生效

我们这里是参考了方法二，然后将 yarn.scheduler.fair.max.assign 设置为了 2。重启了 resource manager 服务后，重新调度任务，发现配置并没有生效，单个任务的所有的 container 都被集中调度到了一台节点上。说明这个批量分配 yarn.scheduler.fair.max.assign 配置并没有生效 。

于是又测试将 yarn.scheduler.fair.assignmultiple 设置为 false。然后重复执行上述操作，发现批量分配这个功能果然关闭了，一个任务下面的container 都被分到了不同的节点。

此时的问题就来了，同时设置了 yarn.scheduler.fair.assignmultiple 为 true 和 yarn.scheduler.fair.max.assign 为 2，不会同时生效。

3. 为什么会忽略？

经过各种搜索，最后发现

从 CDH 5.9 开始，对于新的集群（即没有从 CDH 5.8 升级到更高版本的 CDH 的集群），不管集群中运行的 NodeManager 的数量如何，默认禁用连续调度，即yarn.scheduler.fair.continuous-scheduling -enabled设置为false，yarn.scheduler.fair.assignmultiple设置为true并且 yarn.scheduler.fair.dynamic.max.assign默认也设置为true。

由上文得知，对于 CDH 5.9 - Hadoop 2.6.0 开始以后的版本来说，yarn.scheduler.fair.dynamic.max.assign 这个配置已经默认加入到了服务配置中，并且为 true ，但是对于开源版本的 Hadoop 来说，hadoop 2.6.0 并没有这个配置，而是在 hadoop 2.8.0 以后加入了这个配置。

这里我们之前参考配置都是参考的开源版本的对应的版本配置，所以忽略了 yarn.scheduler.fair.dynamic.max.assign 这个配置，导致配置没有生效。

这里也使我明白，CDH版本与 开源版本的真正区别，之前只是片面的以为 CDH 仅仅只是封装的比较好，代码的改动不是很大，现在看来理解的有些偏差。

注意：从 C6.1.0 开始，设置 yarn.scheduler.fair.dynamic.max.assign 和 yarn.scheduler.fair.max.assign 在 Cloudera Manager 中公开，因此不需要安全阀。

4. 最终解决

也就是说，对于在 C5.x 中运行 CDH 5.8 及更高版本（或从 CDH 5.8 升级到更高版本）的集群：

1. 将属性yarn.scheduler.fair.assignmultiple设置为true。
2. 可选：将属性yarn.scheduler.fair.dynamic.max.assign设置为true。这需要使用安全阀来完成 - ResourceManager Advanced Configuration Snippet (Safety Valve) for yarn-site.xml。
3. 如果从上面设置了yarn.scheduler.fair.dynamic.max.assign ， 即使设置了属性yarn.scheduler.fair.max.assign也会被忽略。

原理

问题原因

FairScheduler 连续调度在有许多应用程序提交或运行的大型集群上花费的时间太长。这可能会导致 ResourceManager 出现无响应，因为持续调度所花费的时间支配了 ResourceManager 的可用性。

随着应用程序数量的增加和/或集群中节点数量的增加，迭代节点可能需要很长时间。由于连续调度获得了锁，这减少了 ResourceManager 在其他功能（包括常规容器分配）上花费的时间比例。

YARN 性能下降的原因

NodeManager -> ResourceManager 心跳
在 YARN 集群中，每个 NodeManager(NM) 都会定期向 ResourceManager(RM) 发送心跳。这些基于 yarn.resourcemanager.nodemanagers.heartbeat-interval-ms

属性定期发生在此心跳期间，每个NM 告诉RM 有多少未使用的容量，并且FairScheduler 将分配一个或多个容器在该NM 上运行。默认情况下，心跳间隔为 1 秒（即每秒 1 次心跳）。

心跳和容器分配
分配的容器数量将取决于 fair-scheduler.xml 设置。流程图如下：

属性yarn.scheduler.fair.dynamic.max.assign是在 CDH 5.9（和YARN-5035）中引入的。

连续调度的容器分配

除了常规（基于心跳的）容器分配外，FairScheduler 还支持连续调度。这可以通过属性 yarn.scheduler.fair.continuous-scheduling-enabled 开启。当此属性设置为 true 时，会在 FairScheduler 中开启连续调度。

对于连续调度，有一个单独的线程执行容器分配，然后根据属性 yarn.scheduler.fair.continuous-scheduling-sleep-ms 休眠数毫秒。

在 CDH 中，此值设置为默认值 5 毫秒。在此期间执行非调度 RM 功能。

引入了连续调度，将调度的延迟降低到远低于节点心跳默认值1s。连续调度线程将通过迭代提交和运行的应用程序来执行调度，同时在集群中的节点上寻找空闲资源。这适用于小型集群。调度程序可以非常快速地（在几毫秒内）遍历所有节点。

随着应用程序数量的增加和/或集群中节点数量的增加，迭代节点可能需要很长时间。由于连续调度会获取锁，这减少了 RM 在其他功能（包括常规容器分配）上花费的时间比例。

在上面的三个图中，我们以红色显示了连续调度线程的运行时间，以绿色显示了剩余的 RM 可用性。在小型且负载较轻的集群上，RM 可用性将如图 A 所示。在更大且负载更重的集群上，RM 可用性将更像图 B。这已经表明 RM 仅在一半的时间可用。在图 C 表示的负载严重的集群上，RM 可能看起来没有响应，因为所有时间都可以花在连续调度上。这可能会导致其他客户端（例如：Cloudera Manager、Oozie 等）也出现无响应。

总结：

1. 连续分配是 yarn 的一个优化，能加快任务的容器分配调度。
2. 连续分配容易导致集群负载不均衡。
3. 需要根据自身的集群大小和计算任务大小来合理配置，不要让这优化成为"绊脚石"。
4. 属性yarn.scheduler.fair.dynamic.max.assign是在 CDH 5.9 - Hadoop2.6.0 和 开源 Hadoop-2.8.0 中引入的。

参考：

1. https://my.cloudera.com/knowledge/FairScheduler-Tuning-With-assignmultiple-and-Continuous?id=76442
2. https://hadoop.apache.org/docs/current/hadoop-yarn/hadoop-yarn-site/FairScheduler.html
3. https://blog.csdn.net/nazeniwaresakini/article/details/105137788