@changedi
2017-11-23T11:31:57.000000Z
字数 3094
阅读 4021
大数据
YARN
ResourceManager是资源管理和应用调度的中央枢纽。因此它是YARN集群的故障单点。
本文给出一个ResourceManager重启的概览,以及在重启时保持运行的增强特征同时在down机时对终端用户不可见。
ResourceManager重启特性分为两个阶段:
ResourceManager重启阶段1:增强RM使其将应用和尝试的状态以及其他私密信息持久化保存到一个可插拔的状态存储里。RM在重启后从状态存储里重新加载这些信息然后踢掉之前运行的应用。不要求用户重新提交应用。
ResourceManager重启阶段2:在重启时通过从NodeManager和ApplicationMasters的容器请求中读回容器状态来重建ResourceManager的正在运行的状态。与阶段1的关键不同在于之前运行的应用在RM重启后不会被杀死,这样应用作业就不会因为RM的不工作而丢失。
Hadoop2.4.0 release时,只有重启阶段1被实现过。
整体概念说明当客户端提交应用时RM会持久化应用的元数据(比如ApplicationSubmissionContext)到一个可插拔的状态存储,同时也会在应用结束时保存应用的最终状态比如完成态(失败、杀死、结束)和诊断信息。RM当然在安全环境下也会保存私密信息比如安全密钥、token。在任何时候RM关闭,只要这些需要的(应用元数据和安全环境下的私密信息)信息在状态存储中可用,当RM重启时,它就可以从状态存储中恢复应用的元数据并重新提交应用作业。如果在RMdown掉之前就已经完成的应用,RM重启后不会重新提交。
NodeManager和客户端在RM宕机的时间内会持续发请求给RM直到RM恢复。当RM恢复后,它会发送一个re-sync的命令给全部和RM保持心跳的NodeManager和ApplicationMaster。现在NodeManager和ApplicationMaster处理这个命令的做法是:NM杀死全部容器并且重新注册RM。从RM的视角来看,这些重新注册的NodeManager和新注册没有区别。AM在接到re-sync命令后会自己关闭。当RM重启并从状态存储中加载全部的应用元数据和私密信息到内存后,它会为每个没有运行结束的应用作业创建一个新的尝试并像平常一样re-kick那个应用。如前所述,之前运行的应用会丢失,因为他们在接收到RM的re-sync命令后被杀死了。
本节描述了开启RM重启特性的配置。
启动RM重启功能
要启动RM重启功能,需要设置conf/yarn-site.xml文件中的下面这个属性为true:
Property | Value |
---|---|
yarn.resourcemanager.recovery.enabled | true |
配置RM状态存储来持久化RM的状态
Property | Description |
---|---|
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.FileSystemRMStateStore |
当使用HDFS做状态存储时的配置。
配置URI来设置RM的状态存在Hadoop文件系统的哪个位置。
Property | Description |
---|---|
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文件系统。
Property | Description |
---|---|
yarn.resourcemanager.fs.state-store.retry-policy-spec | Hadoop文件系统客户端重试策略声明。Hadoop文件系统客户端重试策略总是开启的。用一对睡眠时间和重试次数的数据对来表示,比如(t0, n0), (t1, n1), ..., 其中前n0次重试会平均休眠t0毫秒,接下来n1次重试平均休眠t1毫秒,以此类推。默认是(2000,500) |
当使用ZooKeeper时的配置。
配置存储RM状态的Zookeeper服务地址和root路径。
Property | Description |
---|---|
yarn.resourcemanager.zk-address | 逗号分隔的主机:端口列表。每个对应了一个Zookeeper的server(类似"127.0.0.1:3000,127.0.0.1:3001,127.0.0.1:3002") |
yarn.resourcemanager.zk-state-store.parent-path | RM状态存储的root znode全路径。默认是/rmstore。 |
配置zookeeper的重试策略。
Property | Description |
---|---|
yarn.resourcemanager.zk-num-retries | 连接丢失后RM重试连接zk服务器的重试次数。默认是500。 |
yarn.resourcemanager.zk-retry-interval-ms | 连接zk服务器的重试间隔时长,单位毫秒。默认是2秒。 |
yarn.resourcemanager.zk-timeout-ms | ZooKeeper session超时时长,单位毫秒。该配置设置zk服务器决定是否session过期。当服务器在该配置的时间范围内收不到client的心跳时,会触发session过期。默认值是10秒。 |
配置zookeeper的znode的权限ACL。
Property | Description |
---|---|
yarn.resourcemanager.zk-acl | 配置zookeeper的znode的权限ACL。默认是world:anyone:rwcda |
配置应用尝试的最大重试次数。
Property | Description |
---|---|
yarn.resourcemanager.am.max-attempts | 应用尝试的最大次数。这是个全局配置,对所有应用master都生效。每个应用master可以通过API来设置自己独立的最大重试次数,但是自己设置的不能超过全局的上限。如果超过了,RM会覆盖它。默认值是2,也就是允许AM至少1次重试。 |
这个配置的影响事实上超过了RM重启的范围。它控制了应用能够最大尝试的次数。在RM重启阶段1需要这个配置,因为如前面所述每次RM重启,它会杀死之前正在运行的AM尝试并创建一个新的尝试。因此,每次RM重启就会导致尝试次数递增1次。在RM重启阶段2,这个配置不需要了,因为之前运行的AM不会被杀死,AM只会在RM重启后进行re-sync。