hadoop 2.7.2 yarn中文文档——ResourceManger Restart

综述

ResourceManager是管理资源和调度YARN中运行的application的中心机构。因此，它在Apache YARN 集群中存在潜在的单点故障。本文档给出有关ResourceManager Restart特性的概述，该特性强化ResourceManager可以跨越重启操作继续运转，另外让ResourceManager的停机时间对终端用户不可见。

ResourceManager Restart特性分成两个阶段：

• ResourceManager Restart阶段1（Non-work-preserving RM restart）：RM在插件化的 state-store中持久化application/attempt状态以及其他证书信息。在重启过程中RM会从state-store中重载这些信息，并且重新启动之前Running的application。用户不需要重新提交这些application。
• ResourceManager Restart 阶段 2 (Work-preserving RM restart):聚焦在通过结合重启过程中来自NodeManager的容器状态和来自ApplicationMaster的容器请求重新构建ResourceManager的运行状态。与阶段1的关键不同是之前运行中的应用程序在RM重启中不会被kill，所以application不会因为RM的中断丢失它的工作内容。

 

特性

• 阶段1：Non-work-preserving RM restart

到Hadoop 2.4.0发布为止，只有ResourceManager Restart 阶段1是实现完成的，下面对此进行描述.

整体思路是在client提交application，以及application完成时保存application最终状态（完成状态，如failed, killed, finished）和排错信息，RM会在插件化的 state-store 持久化application的元数据(如ApplicationSubmissionContext)。此外，RM也会存储证书信息，如在安全环境下工作需要的security keys, tokens 。RM任何时间关闭，只要必需的信息（如application 元数据和其在安全环境下运行所需的证书）在 state-store中可用，那么当重启时，RM能从state-store获取application元数据并且重新提交application。如果applications在RM关闭前已经完成（如failed, killed, finished），RM不会重新提交application。

NodeManagers和Clients在RM的宕机时间内保持轮询RM状态直到RM恢复。当RM重新启动之后，它会通过心跳发送 re-sync命令到所有的NodeManagers和ApplicationMasters。到Hadoop2.4.0发布为止，NodeMansger和ApplicationMaster处理这个命令的行为是：NMs会杀死它管理的所有容器，然后重新注册到RM。在RM看来，这些重新注册上来的NodeManager就相当于新加入的NMs。AMs（如MapReduce AM）在收到re-sync命令之后会关闭。在RM重启并从state-store加载所有application的元数据、证书，在内存中重新组装这些信息之后，它将会为每个未完成的application创建一个新的的attempt （如ApplicationMaster）并且像普通application一样重新触发该application。如上所述，之前running的application的中间工作内容会丢失，因为它们被RM在重启过程中通过re-sync 命令杀死了。

 

• 阶段2：Work-preserving RM restart

到hadoop2.6.0发布，进一步增强了RM start功能来解决如何RM重启可以不杀死任何在集群中运行的applications。

超越了阶段1已经完成的基础性工作，即持久化和重新加载、恢复application状态元数据，阶段2主要聚焦在重新构建完整的集群运行时状态，主要就是RM内部的中心调度器保持跟踪所有容器的生命周期，application的上下文和资源请求，队列的资源使用情况等。这种方式下，RM不再需要像在阶段1中那样杀死AM并重新运行。Application能够简单的与RM re-sync，并继续它的剩下的工作。

RM利用NMs发送的容器状态信息恢复自身的运行状态。在与RM re-syncs时NM不会杀死容器。在重新注册之后,NM继续管理容器，以及发送容器状态到RM。RM利用这些容器的信息重新构建容器实例和相关Application的调度状态。同时，AM需要重新发送未完成的资源请求到RM，因为在RM停机时，可能会丢失未得到满足的请求。Application利用它的AMRMClient 库与RM通信，不用担心AM 在re-sync时重新发送资源请求，因为它是通过工具库自身自动完成。

 

配置

本部分描述启用 RM Restart特性的配置。

启用RM Restart

Property	Description
yarn.resourcemanager.recovery.enabled	true

为持久化RM状态配置state-store

Property

Description

yarn.resourcemanager.store.class

用于存储application/attempt状态和证书的state-store 类名。可用的state-store实现包括: org.apache.hadoop.yarn.server.resourcemanager. recovery.ZKRMStateStore，一个基于zookeeper的实现; org.apache.hadoop.yarn.server.resourcemanager. recovery.FileSystemRMStateStore,基于hadoop文件系统的state-store实现，类似于HDFS和本地FS; org.apache.hadoop.yarn.server.resourcemanager. recovery.LeveldbRMStateStore，一个基于LevelDB的state-store实现。默认值是org.apache.hadoop.yarn.server.resourcemanager. recovery.FileSystemRMStateStore。

 

如何选择state-store实现

• ZooKeeper based state-store:用户可以自由选择任一存储建立RM restart，但是必须使用基于zookeeper的state-store来支持RM HA。原因是只有该实现可以避免多RMs时的脑裂问题。
• FileSystem based state-store: 基于HDFS和本地FS的state-store，不支持RM的HA机制。
• LevelDB based state-store:基于LevelDB比基于HDFS和Zookeeper的state-store更加轻量级。LevelDB更好的支持原子操作，每次状态更新时需要更少的IO操作，以及在文件系统中非常少的文件总数。不支持RM HA。

基于Hadoop文件系统的state-store实现的配置

支持HDFS和本地FS的state-store实现. 文件系统的类型用URL的schema来判断。如hdfs://localhost:9000/rmstore表明勇hdfs作为存储，file:///tmp/yarn/rmstore 表明勇本地FS存储. 如果在URL中没有schema（hdfs:// 或者file://）指定，存储的类型通过 core-site.xml文件中定义的fs.defaultFS来判定。

• 配置RM状态在Hadoop 文件系统中保存的URI

Property	Description
yarn.resourcemanager.fs.state-store.uri	指定RM状态将被保存在文件系统的位置，如hdfs://localhost:9000/rmstore。默认值是${hadoop.tmp.dir}/yarn/system/rmstore。如果文件系统name未指定，将会使用*conf/core-site.xml中fs.default.name的定义。

 

• state-store客户端连接Hadoop文件系统的重试策略

Property	Description
yarn.resourcemanager.fs.state-store.retry-policy-spec	hadoop文件系统客户端重试策略设置。hadoop文件系统客户端重试一直是启用的。 指定sleep-time 和 number-of-retries对，如(t0, n0), (t1, n1), …,首先的n0次重试平均sleep t0毫秒，接来下的n1次重试平均sleep t1毫秒，以此类推。默认值是(2000, 500)。

 

基于zookeeper的state-store实现配置

• 配置RM状态存储的Zookeeper服务器地址和根目录

Property	Description
yarn.resourcemanager.zk-address	逗号分隔的host:port对。zookeeper server（如“127.0.0.1:3000, 127.0.0.1:3001, 127.0.0.1:3002”）用来存储RM的状态.
yarn.resourcemanager.zk-state-store.parent-path	RM状态存储的根znode的完整路径。默认值是/rmstore.

 

• 配置state-store 连接zookeeper server的重试策略

Property	Description
yarn.resourcemanager.zk-num-retries	如果连接断开，RM尝试连接Zookeeper server的次数。默认值是500.
yarn.resourcemanager.zk-retry-interval-ms	重试连接Zookeeper server的间隔毫秒数。默认是2秒。
yarn.resourcemanager.zk-timeout-ms	Zookeeper会话超时时间，单位毫秒。这个配置用于Zookeeper server判断何时会话过期。当server在指定的会话超时内不能感知到client。默认值是10秒。

 

• 配置设置Zookeeper znode权限的ACLs

Property	Description
yarn.resourcemanager.zk-acl	用来设置Zookeeper znode权限的ACLs。默认值是 world:anyone:rwcda

基于LevelDB的State-Store实现的配置项

Property	Description
yarn.resourcemanager.leveldb-state-store.path	RM状态存储的本地路径，默认值是 ${hadoop.tmp.dir}/yarn/system /rmstore

work-preserving 方式的RM recovery配置项

Property	Description
yarn.resourcemanager.work-preserving-recovery.scheduling-wait-ms	设置RM在 work-preserving recovery场景下分配新容器前的等待时间。这个周期让RM在为application分配新容器前，有机会去安心的与集群中的NMs进行同步。

备注

在work-preserving recovery启用的情况下，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。这里新增的epoch数字是一个单调递增的整数，从0开始每次重启增长1.如果epoch 数字是0，它将会被忽略，containerId 字符串保留之前的格式。

 

配置样例

以下是一个基于Zookeeper的state-store启用 RM work-preserving restart的最小的集合。

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

 

下一篇： hadoop 2.7.2 yarn中文文档——ResourceManager High Availability