Hadoop3.2.0 YARN ResourceManager restart

概述

• 特征
• 配置
  • 启用RM重启
  • 配置状态存储以保持RM状态
  • 如何选择州商店实施
  • 基于Hadoop FileSystem的状态存储实现的配置
  • 基于ZooKeeper的状态存储实现的配置
  • 基于LevelDB的状态存储实现的配置
  • 保持工作的RM恢复配置
• 笔记
• 示例配置

概述

ResourceManager是管理资源和调度在YARN上运行的应用程序的中央权限。因此，它可能是Apache YARN集群中的单点故障。本文档概述了ResourceManager Restart，这是一项增强ResourceManager以便在重新启动时保持正常运行的功能，并且还使ResourceManager的停机时间对最终用户不可见。

ResourceManager有两种类型的重启：

• 非工作保留RM重启：此重新启动增强了RM以在可插拔状态存储中保留应用程序/尝试状态和其他凭据信息。RM将在重新启动时从状态存储重新加载此信息，并重新启动以前运行的应用程序。用户无需重新提交申请。

• 工作保留RM重启：重点是重新构建RM的运行状态，将NodeManagers的容器状态和ApplicationMaster的容器请求重新组合起来。与非工作保留RM重启的主要区别在于，在RM重启后，以前运行的应用程序不会被杀死，因此应用程序不会因为RM中断而丢失其工作。

特征

• 非工作保留RM重启

  在非工作保留RM重启时，RM会在客户端提交应用程序时将应用程序元数据（即ApplicationSubmissionContext）保存在可插拔的状态存储中，并保存应用程序的最终状态，例如完成状态（失败，终止或应用完成后的诊断和诊断。此外，RM还会保存安全密钥，令牌等凭据，以便在安全的环境中工作。当RM关闭时，只要在状态存储中可以获得所需的信息（即应用程序元数据以及在安全环境中运行的凭据），那么当RM重新启动时，它可以从状态存储中获取应用程序元数据并重新提交申请。如果应用程序在RM关闭之前已经完成（即失败，被杀或已完成），RM将不会重新提交申请。

  在RM停机期间，NodeManagers和客户端将继续轮询RM，直到RM出现。当RM启动时，它会向所有通过心跳与之交谈的NodeManager和ApplicationMaster发送重新同步命令。NM将杀死其所有托管容器并重新注册RM。这些重新注册的NodeManager与新加入的NM类似。AM（例如MapReduce AM）在收到重新同步命令时会被关闭。在RM重新启动并加载所有应用程序元数据，来自状态存储的凭据并将它们填充到内存中之后，它将为尚未完成的每个应用程序创建一个新的尝试（即ApplicationMaster）并像往常一样重新启动该应用程序。如前所述，

• 工作保留RM重启

  在工作保留RM重启中，RM确保应用程序状态的持久性并在恢复时重新加载该状态，此重启主要侧重于重构YARN集群的整个运行状态，其中大部分是RM内部调度程序的状态。它跟踪所有容器的生命周期，应用程序的余量和资源请求，队列的资源使用情况等。通过这种方式，RM无需终止AM并从头开始重新运行应用程序，因为它是在非工作保留的RM重启中完成的。应用程序可以简单地与RM重新同步，并从中断处继续。

  RM利用从所有NM发送的容器状态来恢复其运行状态。当NM与重新启动的RM重新同步时，NM不会杀死容器。它继续管理容器，并在重新注册时将容器状态发送到RM。RM通过吸收这些容器的信息来重建容器实例和相关应用程序的调度状态。与此同时，AM需要将未完成的资源请求重新发送给RM，因为RM可能会在关闭时丢失未完成的请求。使用AMRMClient库与RM通信的应用程序编写者无需担心AM在重新同步时向RM重新发送资源请求的部分，因为它自动由库本身处理。

配置

本节介绍启用RM Restart功能所涉及的配置。

启用RM重启

属性	描述
yarn.resourcemanager.recovery.enabled	true

配置状态存储以保持RM状态

属性

描述

yarn.resourcemanager.store.class

用于保存应用程序/尝试状态和凭据的状态存储的类名。可用的状态存储实现是org.apache.hadoop.yarn.server.resourcemanager.recovery.ZKRMStateStore，一个基于ZooKeeper的状态存储实现和org.apache.hadoop.yarn.server.resourcemanager.recovery.FileSystemRMStateStore，一个Hadoop文件系统基于状态存储的实现，如HDFS和本地FS。org.apache.hadoop.yarn.server.resourcemanager.recovery.LeveldbRMStateStore，一个基于LevelDB的状态存储实现。默认值设置为org.apache.hadoop.yarn.server.resourcemanager.recovery.FileSystemRMStateStore。

如何选择州商店实施

• 基于ZooKeeper的状态存储：用户可以自由选择任何存储来设置RM重启，但必须使用基于ZooKeeper的状态存储来支持RM HA。原因是只有基于ZooKeeper的状态存储支持防护机制，以避免多个RM假设它们处于活动状态并且可以同时编辑状态存储的裂脑情况。

• 基于文件系统的状态存储：支持HDFS和基于本地FS的状态存储。不支持防护机制。

• 基于LevelDB的状态存储：基于LevelDB的状态存储被认为比基于HDFS和ZooKeeper的状态存储更轻。LevelDB支持更好的原子操作，每个状态更新更少的I / O操作，以及文件系统上的总文件更少。不支持防护机制。

基于Hadoop FileSystem的状态存储实现的配置

支持HDFS和基于本地FS的状态存储实现。要使用的文件系统类型由URI方案决定。例如 hdfs://localhost:9000/rmstore  使用HDFS作为存储和 file:///tmp/yarn/rmstore  使用本地FS作为存储。如果URI中未指定方案（ hdfs:// or file:// ），则要使用的存储类型由core-site.xml中定义的fs.defaultFS确定。

• 配置将在Hadoop FileSystem状态存储中保存RM状态的URI。

属性	描述
yarn.resourcemanager.fs.state-store.uri	URI指向将存储RM状态的FileSystem路径的位置（例如 hdfs://localhost:9000/rmstore ）。默认值为$ ${hadoop.tmp.dir}/yarn/system/rmstore 。如果未提供FileSystem名称，则将使用   *conf/core-site.xml  中指定的fs.default.name。

• 配置状态存储客户端用于连接Hadoop FileSystem的重试策略。

属性	描述
yarn.resourcemanager.fs.state-store.retry-policy-spec	Hadoop FileSystem客户端重试策略规范。始终启用Hadoop FileSystem客户端重试。设置格式 (睡眠时间,重试次数)，即（t0，n0），（t1，n1），...，第一个n0重试平均休眠t0毫秒，以下n1重试平均休眠t1毫秒，所以上。默认值为（2000,500）

基于ZooKeeper的状态存储实现的配置

• 配置ZooKeeper服务器地址和存储RM状态的根路径。

属性	描述
hadoop.zk.address	以逗号分隔的主机列表：端口对。每个对应于RM用于存储RM状态的ZooKeeper服务器（例如“127.0.0.1:3000,127.0.0.1:3001,127.0.0.1:3002”）。
yarn.resourcemanager.zk-state-store.parent-path	将存储RM状态的根znode的完整路径。默认值为 /rmstore。

• 配置状态存储客户端用于连接ZooKeeper服务器的重试策略。

属性	描述
hadoop.zk.num-retries	如果连接丢失，RM尝试连接到ZooKeeper服务器的次数。默认值为500。
hadoop.zk.retry-interval-ms	连接到ZooKeeper服务器时重试之间的间隔（以毫秒为单位）。默认值为2秒。
hadoop.zk.timeout-ms	ZooKeeper会话超时（以毫秒为单位）。ZooKeeper服务器使用此配置来确定会话何时到期。当服务器在此配置指定的会话超时期限内没有从客户端收到消息（即没有心跳）时，会发生会话到期。默认值为10秒

• 配置用于在ZooKeeper znodes上设置权限的ACL。

属性	描述
hadoop.zk.acl	用于在ZooKeeper znodes上设置权限的ACL。默认值为world：everyone：rwcda

基于LevelDB的状态存储实现的配置

属性	描述
yarn.resourcemanager.leveldb-state-store.path	将存储RM状态的本地路径。默认值为 ${hadoop.tmp.dir}/yarn/system/rmstore

保持工作的RM恢复配置

属性	描述
yarn.resourcemanager.work-preserving-recovery.scheduling-wait-ms	设置RM在RM工作保留恢复上分配新容器之前等待的时间。在将新容器分配给应用程序之前，这样的等待期使RM有机会在恢复时解决与集群中的NM重新同步的问题。

笔记

如果RM重新启动并启用了工作保留恢复，则会更改ContainerId字符串格式。它曾经是这样的格式：Container_ {clusterTimestamp} _ {appId} _ {attemptId} _ {containerId}，例如Container_1410901177871_0001_01_000005。

它现在更改为：Container_e {epoch} _ {clusterTimestamp} _ {appId} _ {attemptId} _ {containerId}，例如Container_ e17 _1410901177871_0001_01_000005。

这里，附加纪元号是单调递增的整数，从0开始并且每次RM重新启动时增加1。如果纪元号为0，则省略它，并且containerId字符串格式保持与以前相同。

示例配置

以下是使用基于ZooKeeper的状态存储启用RM工作保留重启的最小配置集。

 
   Enable RM to recover state after starting. If true, then
   yarn.resourcemanager.store.class must be specified
   yarn.resourcemanager.recovery.enabled
   true
 

 
   The class to use as the persistent store.
   yarn.resourcemanager.store.class
   org.apache.hadoop.yarn.server.resourcemanager.recovery.ZKRMStateStore
 

 
   Comma separated list of Host:Port pairs. Each corresponds to a ZooKeeper server
   (e.g. "127.0.0.1:3000,127.0.0.1:3001,127.0.0.1:3002") to be used by the RM for storing RM state.
   This must be supplied when using org.apache.hadoop.yarn.server.resourcemanager.recovery.ZKRMStateStore
   as the value for yarn.resourcemanager.store.class
   hadoop.zk.address
   127.0.0.1:2181
 

原文链接: https://hadoop.apache.org/docs/r3.2.0/