概述

ResourceManager 是管理资源和调度运行在YARN上的应用程序的中心机构。因此，它可能会是YARN集群中的单点故障。yarn提供了一种ResourceManager Restart功能，这是一个ResourceManager在重启过程中保持正常工作的增强功能，同时最终用户感知不到 ResourceManager 的停机时间。
ResourceManager 提供了2种类型的重启方式：

Non-work-preserving RM restart: 这种重启方式中，RM 会在可插拔的state-store中保存客户端提交应用时的元数据（即ApplicationSubmissionContext）和应用的最终完成状态（failed,killed,finished），此外，还会保存认证凭证，例如，security keys，token。只要这些信息保存了，当重启后，RM会从state-store中获取这些信息，然后重新提交应用。在RM停止之前已经完成（failed,killed,finished）的应用则不会被再次提交。在RM停止之后到启动前这段时间内，NM和clients会保持轮询。当RM启动后，会通过心跳发送一个re-sync命令给所有的NM和AM。NMs将会杀死其上所有的container，然后重新向RM注册，这些重新注册的NM就像是新加入的NM。而AM（如MapReduce AM）在收到re-sync命令时会关闭。RM重启后，会重新把应用的元数据和认证信息等相关数据从state-store中加载到内存后，它会重新创建一个AM，让未完成的应用重新可用。所以，如前所述这种方式会使得之前运行的应用程序丢失，因为它们本质上是由RM在重新启动时通过re-sync命令kill掉的。
Work-preserving RM restart：在这种模式下，RM会确保应用状态的持久化，然后在恢复的时候重载。这种重启方式主要关注YARN集群中的整个运行状态的重建。其中主要部分是RM中central scheduler的状态，它会跟踪所有container的生命周期、应用程序的空间和资源请求、队列的资源使用情况等。这样，RM就无需kill AM并从头开始重新运行应用程序。应用程序可以简单地与RM 重新同步，并从中断的位置恢复。RM利用从所有NMs发送来的container状态来恢复自己的运行状态。NM也不会在与重启时的RM re-sync时kill掉其上运行的container，它会继续管理其上的container，并在重新注册时将container的状态发送给RM。RM通过吸收这些container的信息来重构container实例和相关应用程序的调度状态。与此同时，AM需要将未完成的资源请求重新发送给RM，因为RM在关闭时可能会丢失未完成的请求。使用AMRMClient库与RM通信的用户（Application writer）无需担心AM在re-sync时向RM 重新发送资源请求的事情，因为它会由库本身自动处理。

默认使用的是 Work-preserving 重启方式，这可以通过配置项 yarn.resourcemanager.work-preserving-recovery.enabled 配置。

配置

配置步骤

启用RM Restart
修改 yarn.resourcemanager.recovery.enabled 为true
配置持久化RM状态的存储方式
yarn.resourcemanager.store.class,有三种可选的配置分别是
- 基于zookeeper的存储 org.apache.hadoop.yarn.server.resourcemanager.recovery.ZKRMStateStore;
- 基于HDFS或本地文件系统的存储org.apache.hadoop.yarn.server.resourcemanager.recovery.FileSystemRMStateStore;
- 基于leveldb的存储 org.apache.hadoop.yarn.server.resourcemanager.recovery.LeveldbRMStateStore

默认值是 org.apache.hadoop.yarn.server.resourcemanager.recovery.FileSystemRMStateStore。高可用集群必须使用ZKRMStateStore。

配置基于ZK存储的state-store
hadoop.zk.address ： zk的地址信息，如 127.0.0.1:3000,127.0.0.1:3001,127.0.0.1:3002
（说明：原有的配置项 yarn.resourcemanager.zk-address 在hadoop2.9.x 已经deprecated ，由 hadoop.zk.address 取代，见https://issues.apache.org/jira/browse/HADOOP-15093。）
yarn.resourcemanager.zk-state-store.parent-path：存储RM状态的znode路径，默认是 /rmstore
hadoop.zk.num-retries ：当连接丢失时，RM连接ZK的重试次数，默认是 500
hadoop.zk.retry-interval-ms：重试连接的间隔时间,单位是milliseconds ，默认是 2 s
hadoop.zk.timeout-ms：ZK会话的超时时间，单位是milliseconds ，默认是 10 s
hadoop.zk.acl： znode的权限，默认是 world:anyone:rwcda

配置示例

<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>127.0.0.1:3000,127.0.0.1:3001,127.0.0.1:3002</value>
 </property>

补充说明

如果使用 work-preserving recovery 方式，则ContainerId 的字符串格式会发生变化。原有的格式是

Container_{clusterTimestamp}_{appId}_{attemptId}_{containerId}, 如 Container_1410901177871_0001_01_000005.

现在格式变为：

Container_e{epoch}_{clusterTimestamp}_{appId}_{attemptId}_{containerId}, 如 Container_e17_1410901177871_0001_01_000005.

这里，新增的epoch数是一个单调递增的整数，从0开始，RM每重新启动一次增加1。如果epoch number为0，将会忽略它，这样containerID的字符串格式就与以前是相同的。

参考：
https://yq.aliyun.com/articles/505402
https://hadoop.apache.org/docs/stable/hadoop-yarn/hadoop-yarn-site/ResourceManagerRestart.html

看得出的就是

发布了57 篇原创文章 · 获赞 3 · 访问量 1万+

私信关注

YARN ResourceManager Restart 特性

目录

概述

配置

配置步骤

配置示例

补充说明

猜你喜欢