hadoop-4：hadoop-flink实时计算集群生产级优化

发布于

目录：

(1).woker资源节点需要优化的配置

1./app/3rd/hadoop-3.3.1/etc/hadoop/capacity-scheduler.xml 优化项

(2).ResourceManager节点配置优化

1./app/3rd/hadoop-3.3.1/etc/hadoop/yarn-site.xml 优化项

(3).NodeManager节点配置优化

1./app/3rd/hadoop-3.3.1/etc/hadoop/yarn-site.xml 优化项

(1).woker资源节点需要优化的配置

1./app/3rd/hadoop-3.3.1/etc/hadoop/capacity-scheduler.xml 优化项

原值：0.1；优化值：0.3。

代码语言：javascript
复制
<property>
   <name>yarn.scheduler.capacity.maximum-am-resource-percent</name>
    <value>0.3</value>
    <description>
      Maximum percent of resources in the cluster which can be used to run
      application masters i.e. controls number of concurrent running
      applications.
    </description>
</property>

这也是因为碰到一个问题，启动flink任务时，c和g都够，但是最后一个job死活启动不了，怀疑是有相关的配置限制了内存与之，最好找到是这个配置。

修改意义：集群中可用于运行application master的资源比例上限，这通常用于限制并发运行的应用程序数目，它的默认值为0.1。

遇到的问题陈述： 查看了下集群上目前的任务总数有9个，每个任务分配有一个2G的jobmanager（jobmanager为flink Application master），占18G左右，而集群上的总内存为175G，那么18>175 * 0.1 ，从而导致jobmanager的创建处于pending状态。

日志信息：

显示信息：2021-09-23 19:10:48,094 INFO org.apache.flink.yarn.YarnClusterDescriptor [] - Deployment took more than 60 seconds. Please check if the requested resources are available in the YARN cluster

严重注意：此配置修改并不是该问题的唯一解，需要具体分析当前集群的使用情况。根据你自己的内存占用情况进行设置。

(2).ResourceManager节点配置优化

参考资料：

a.YARN ResourceManager重启作业保留机制

https://developer.aliyun.com/article/505402

b.ResourceManager Restart

https://hadoop.apache.org/docs/stable/hadoop-yarn/hadoop-yarn-site/ResourceManagerRestart.html?spm=a2c6h.12873639.0.0.49ba57a9IU2OVi

1./app/3rd/hadoop-3.3.1/etc/hadoop/yarn-site.xml 优化项

YARN可以通过相关配置支持ResourceManager重启过程中，不影响正在运行的作业，即重启后，作业还能正常继续运行直到结束。之前运行的应用程序不会在 RM 重新启动后被杀死，因此应用程序不会因为 RM 中断而丢失其工作。

需要修改三个配置：

yarn.resourcemanager.recovery.enabled：true

yarn.resourcemanager.store.class：

org.apache.hadoop.yarn.server.resourcemanager.recovery.ZKRMStateStore 有三种StateStore，分别是基于zookeeper, HDFS, leveldb, HA高可用集群必须用ZKRMStateStore

yarn.resourcemanager.work-preserving-recovery.scheduling-wait-ms：

10000。 默认10000，用默认值即可

开启了Recovery后，ResourceManger会将应用的状态等信息保存到yarn.resourcemanager.store.class配置的存储介质中，重启后会load这些信息，并且NodeManger会将还在运行的container信息同步到ResourceManager，整个过程不影响作业的正常运行。

代码语言：javascript
复制
<property>
   <name>yarn.resourcemanager.recovery.enabled</name>
   <value>true</value>
 </property>

<property>

<name>yarn.resourcemanager.store.class</name>

<value>org.apache.hadoop.yarn.server.resourcemanager.recovery.ZKRMStateStore</value>

</property>


<property>

<name>hadoop.zk.address</name>

<value>zookeeper-1:2181,zookeeper-2:2181,zookeeper-3:2181</value>

</property>

(3).NodeManager节点配置优化

1./app/3rd/hadoop-3.3.1/etc/hadoop/yarn-site.xml 优化项

该特性使 NodeManager 能够在不丢失节点上运行的活动容器的情况下重新启动。在高级别上，NM 在处理容器管理请求时将任何必要的状态存储到本地状态存储。当 NM 重新启动时，它通过首先加载各个子系统的状态，然后让这些子系统使用加载的状态执行恢复来恢复。

yarn.nodemanager.recovery.enabled：true

Enable NM to recover state after starting.启用NM启动后恢复状态。

yarn.nodemanager.recovery.supervised：true

如果启用，运行的 NodeManager 将不会在退出时尝试清理容器，并假设它将立即重新启动并恢复容器 默认值设置为“false”。

yarn.nodemanager.address：

Ephemeral端口(默认port 0)不能用yarn.nodemanager.address的设置来作为NodeManager的rpc服务端口，因为它会导致NM在重启前后使用不同的端口。这会导致之前运行的client无法通信。显式的设置一个带端口号的地址参数(比如0.0.0.0:45454)是开启NM重启功能的前置条件。

代码语言：javascript
复制
<property>

<name>yarn.nodemanager.recovery.enabled</name>

<value>true</value>

</property>


<property>

<name>yarn.nodemanager.recovery.supervised</name>

<value>true</value>

</property>


<property>

<name>yarn.nodemanager.address</name>

<value>${yarn.nodemanager.hostname}:45454</value>

</property>

#hadoop#xml#yarn#flink#node.js