综述
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>
相关推荐
Windows10 环境下编译的Hadoop2.7.2 Windows10 环境下编译的Hadoop2.7.2 Windows10 环境下编译的Hadoop2.7.2
标签:apache、hadoop、api、yarn、jar包、java、API文档、中文版; 使用方法:解压翻译后的API文档,用浏览器打开“index.html”文件,即可纵览文档内容。 人性化翻译,文档中的代码和结构保持不变,注释和说明精准...
hadoop2.7.2 linux版本,需要在window上解压缩
Hadoop2.7.2LIUNX集群(2)所需JDK1.8.gzHadoop2.7.2LIUNX集群(2)所需JDK1.8.gzHadoop2.7.2LIUNX集群(2)所需JDK1.8.gzHadoop2.7.2LIUNX集群(2)所需JDK1.8.gz
Hadoop2.7.2 centos7 64位编译后的库文件
标签:apache、client、hadoop、yarn、jar包、java、中文文档; 使用方法:解压翻译后的API文档,用浏览器打开“index.html”文件,即可纵览文档内容。 人性化翻译,文档中的代码和结构保持不变,注释和说明精准翻译...
hadoop2.7.2安装依赖文件,用于在window下调试hadoop! hadoop2.7.2安装依赖文件,用于在window下调试hadoop hadoop2.7.2安装依赖文件,用于在window下调试hadoop
hadoop2.7.2版本对应的winutils和hadoop.dll,maven也有,不用可以删掉
hadoop2.7.2HA集群安装
Hadoop2.7.2伪分布部署 从JDK配置到SSH面密码登陆,Hadoop的详细配置
hadoop 2.7.2 的底层源码包。Welcome to Apache™ Hadoop®!
hadoop2.7.2在windows环境中相关依赖文件hadoop.dll和winutils.exe
Hadoop 资源 适合大数据开发
我的Java安装在D:\Java,hadoop安装在D:\env\hadoop-2.7.2,材料中的hadoop-2.7.2-win10是配置前的版本,材料中的hadoopbin是工具类,需要替换原文档中的D:\env\hadoop-2.7.2\bin,材料中的hadoop-2.7.2配置完成后是配置...
windows7中安装hadoop2.7.2时所需的hadoop.dll和winutils.exe
windows环境下运行hadoop的mapreduce程序需要的hadoop.dll winutils.exe等文件,使用方法见解压文件,该文件对应的hadoop版本是 2.7.2 , 请注意版本一致
hadoop2.7.2以下_winutils_exe和hadoop_dll,内含github地址
包含翻译后的API文档:hadoop-yarn-common-2.6.5-javadoc-API文档-中文(简体)版.zip 对应Maven信息:groupId:org.apache.hadoop,artifactId:hadoop-yarn-common,version:2.6.5 使用方法:解压翻译后的API文档...
hadoop 2.7.2版本的hadoop.dll和winutils.exe,,找了不少资源提示要收费,有点烦,免费分享~
hadoop2.7.2windows工具winutils.exe和hadoop.dll hadoop.exp libwinutils.lib等