重新启动ResourceManager

Hadoop 文档

General

Common

HDFS

MapReduce

MapReduce REST APIs

YARN

YARN REST APIs

YARN Service

Submarine

Hadoop Compatible File Systems

Auth

Tools

Reference

Configuration

总览
特征
构型
笔记
样本配置

总览

ResourceManager是管理资源并计划在YARN上运行的应用程序的中央机构。因此，它可能是Apache YARN群集中的单点故障。本文档概述了ResourceManager重新启动，此功能可增强ResourceManager使其在重新启动后仍能正常运行，并且还使ResourceManager的停机时间对最终用户不可见。

ResourceManager有两种重新启动类型：

不保留工作的RM重新启动：此重新启动增强了RM，以将应用程序/尝试状态和其他凭据信息保留在可插拔状态存储中。RM将在重新启动时从状态存储中重新加载此信息，并重新启动以前运行的应用程序。不需要用户重新提交应用程序。
保留工作的RM重新启动：此操作着重于通过结合NodeManagers的容器状态和重新启动时来自ApplicationMaster的容器请求来重建RM的运行状态。与不保留工作的RM重新启动的主要区别在于，RM重新启动后，先前运行的应用程序不会被杀死，因此应用程序不会因为RM中断而失去工作。

特征

不保留工作的RM重新启动

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

在RM停机期间，NodeManager和客户端将继续轮询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通过吸收这些容器的信息来重建容器实例和关联的应用程序的调度状态。同时，由于RM在关闭时可能会丢失未满足的请求，因此AM需要将未完成的资源请求重新发送给RM。使用AMRMClient库与RM进行通信的应用程序编写者无需担心AM会在重新同步时将资源请求重新发送给RM的部分，因为库本身会自动处理。

构型

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

启用RM重新启动

属性	描述
`yarn.resourcemanager.recovery.enabled`	`真正`

配置状态存储以保留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中未指定scheme（hdfs：//或file：//），则要使用的存储类型由core-site.xml中定义的fs.defaultFS确定。

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

属性	描述
`yarn.resourcemanager.fs.state-store.uri`	指向将存储RM状态的FileSystem路径位置的URI（例如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`	以逗号分隔的Host：Port对列表。每个都对应于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重试`	如果连接丢失，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工作保留重新启动的最低配置集。

 <属性>
   <description>启动后使RM恢复状态。如果为真，则
   必须指定yarn.resourcemanager.store.class </ description>
   <name> yarn.resourcemanager.recovery.enabled </ name>
   <value> true </ value>
 </ property>

 <属性>
   <description>用作持久性存储的类。</ description>
   <name> yarn.resourcemanager.store.class </ name>
   <value> org.apache.hadoop.yarn.server.resourcemanager.recovery.ZKRMStateStore </ value>
 </ property>

 <属性>
   <description>用逗号分隔的Host：Port对列表。每个都对应一个ZooKeeper服务器
   （例如，“ 127.0.0.1:3000,127.0.0.1:3001,127.0.0.1:3002”）被RM用于存储RM状态。
   使用org.apache.hadoop.yarn.server.resourcemanager.recovery.ZKRMStateStore时必须提供此文件
   作为yarn.resourcemanager.store.class </ description>的值
   <name> hadoop.zk.address </ name>
   <value> 127.0.0.1:2181 </ value>
 </ property>