文章目录
本文主要描述了:
- yarn HA架构细节:active/standby、故障转移的方式、故障转移客户端
- 怎么恢复之前提交的任务
- 怎么部署配置YARN HA
- 手动切换主备
一. 架构
1. RM故障转移( Failover)
ResourceManager HA通过Active / Standby体系结构实现-在任何时间,RM之一都处于活动状态,并且一个或多个 RM处于Standby模式,等待切换为active。启用自动故障转移后,通过admin(通过CLI:手动)或 failover-controller (自动) 将RM转换为active。
1.1. 手动切换故障转移
如果未启用自动故障转移,管理员必须通过手动的方式将其中一个RM转换为Active。要从一个RM到另一个RM进行故障转移,应该先将Active-RM转换为Standby,然后将Standby-RM转换为Active。所有这些可以使用“ yarn rmadmin ” CLI完成。
1.2. 自动故障转移
RM可以选择嵌入基于Zookeeper的ActiveStandbyElector来确定哪个RM是Active。当Active发生故障或无响应时,另一个RM被自动选为Active,然后接管。请注意,无需像HDFS那样运行单独的ZKFC守护程序,因为嵌入在RM中的ActiveStandbyElector充当了故障检测器和领导选举人,而不是单独的ZKFC守护进程。
1.3. RM故障转移的客户端:ApplicationMaster和NodeManager
当有多个RM时,预计客户端和节点使用的配置(yarn-site.xml)会列出所有RM。客户端,ApplicationMaster(AM)和NodeManager(NM)尝试以循环方式连接到RM,直到它们到达活动RM。如果活动服务器出现故障,他们将继续轮询,直到命中“新”活动服务器为止。
默认重试逻辑实现为
org.apache.hadoop.yarn.client.ConfiguredRMFailoverProxyProvider
。
可以通过实现org.apache.hadoop.yarn.client.RMFailoverProxyProvider
并设置yarn.client.failover-proxy-provider
:(实现类名)来覆盖默认重试逻辑。
2. 恢复以前的活动RM的状态
启用yarn.resourcemanager.recovery.enabled
(ResourceManagerRestart)后,RM变为active后,它会加载RM的内部状态,并尽可能地处理之前active未处理的请求。
对于之前提交给RM的托管任务,晋升的RM都会重新尝试运行这些任务。
Applications可以定期检查来避免丢失任何任务。
RMStateStore
- Active RM和Standby RM要都能访问状态存储。
- 目前,对RMStateStore的实现有两种FileSystemRMStateStore和ZKRMStateStore。
- ZKRMStateStore隐式允许在任何时间点对单个RM进行写访问,因此建议在HA群集中使用该存储。使用ZKRMStateStore时,无需使用单独的防护机制来解决潜在的裂脑情况,在这种情况下,多个RM可以潜在地充当主动角色。
tips
使用ZKRMStateStore时,建议不要在Zookeeper群集上设置“ zookeeper.DigestAuthenticationProvider.superDigest ”属性,以确保Zookeeper管理员无法访问YARN应用程序/用户凭证信息。
二、部署方式
1. 配置说明
配置属性 | 描述 |
---|---|
hadoop.zk.address | ZK仲裁的地址。用于状态存储和leader选举。 |
yarn.resourcemanager.ha.enabled | 启用RM HA。 |
yarn.resourcemanager.ha.rm-ids | RM的逻辑ID列表。例 |