ResourceManager 重启

概述

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

ResourceManager 有两种类型的重启

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

  • 工作保留 RM 重启：此重启重点在于通过在重启时结合来自节点管理器和来自应用程序主节点的容器请求的容器状态来重建 RM 的运行状态。与非工作保留 RM 重启的关键区别在于，先前运行的应用程序在 RM 重启后不会被终止，因此应用程序不会因 RM 中断而丢失其工作。

功能

  • 非工作保留 RM 重启

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

    在 RM 宕机期间，节点管理器和客户端会持续轮询 RM，直到 RM 启动。当 RM 启动时，它会向所有通过心跳与之通信的节点管理器和应用程序主节点发送重新同步命令。NM 会终止其管理的所有容器并重新向 RM 注册。这些重新注册的节点管理器类似于新加入的 NM。当 AM（例如 MapReduce AM）收到重新同步命令时，应关闭。在 RM 重新启动并从状态存储加载所有应用程序元数据、凭据并将其填充到内存后，它将为每个尚未完成的应用程序创建一个新的尝试（即应用程序主节点），并像往常一样重新启动该应用程序。如前所述，以前运行的应用程序的工作会以这种方式丢失，因为它们实际上是在重新启动时通过 RM 的重新同步命令终止的。

  • 工作保留 RM 重启

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

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

配置

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

启用 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 和本地文件系统）和 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 和本地文件系统的状态存储。不支持隔离机制。

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

基于 Hadoop 文件系统的状态存储实现的配置

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

  • 配置将 RM 状态保存在 Hadoop 文件系统状态存储中的 URI。
属性 说明
yarn.resourcemanager.fs.state-store.uri 指向存储 RM 状态的文件系统路径位置的 URI（例如，hdfs://localhost:9000/rmstore）。默认值为 ${hadoop.tmp.dir}/yarn/system/rmstore。如果未提供文件系统名称，则将使用 *conf/core-site.xml 中指定的 fs.default.name。
  • 配置状态存储客户端用于连接到 Hadoop 文件系统的重试策略。
属性 说明
yarn.resourcemanager.fs.state-store.retry-policy-spec Hadoop 文件系统客户端重试策略规范。Hadoop 文件系统客户端重试始终启用。以睡眠时间和重试次数成对指定，即 (t0, n0)、(t1, n1)、…，前 n0 次重试平均睡眠 t0 毫秒，后 n1 次重试平均睡眠 t1 毫秒，依此类推。默认值为 (2000, 500)

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

  • 配置 ZooKeeper 服务器地址和存储 RM 状态的根路径。
属性 说明
hadoop.zk.address 以逗号分隔的主机：端口对列表。每个对对应一个 ZooKeeper 服务器（例如，“127.0.0.1:3000,127.0.0.1:3001,127.0.0.1:3002”），由 RM 用于存储 RM 状态。
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 znode 权限的 ACL。
属性 说明
hadoop.zk.acl 用于设置 ZooKeeper znode 权限的 ACL。默认值为 world:anyone: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 保留工作恢复的最小配置集。

 <property>
   <description>Enable RM to recover state after starting. If true, then
   yarn.resourcemanager.store.class must be specified</description>
   <name>yarn.resourcemanager.recovery.enabled</name>
   <value>true</value>
 </property>

 <property>
   <description>The class to use as the persistent store.</description>
   <name>yarn.resourcemanager.store.class</name>
   <value>org.apache.hadoop.yarn.server.resourcemanager.recovery.ZKRMStateStore</value>
 </property>

 <property>
   <description>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</description>
   <name>hadoop.zk.address</name>
   <value>127.0.0.1:2181</value>
 </property>