YARN 开启 HA

HDFS 切到 HA 以后，下一处常见单点就是 YARN 的 ResourceManager。单 ResourceManager 模式下，NodeManager 还在各节点上运行，但调度入口只有一个；一旦 ResourceManager 不可用，新任务提交、队列调度、应用状态查询都会受影响。

Ambari Plus 里开启 YARN HA 的路径比较短：进入 YARN 运维向导，填写 YARN HA Cluster ID，选择一台新的 Standby ResourceManager 主机，预览配置后由页面自动完成停止、安装、改配置和启动。本文按页面向导把这条链路走清楚。

本次示例规划如下：

项目	本次选择
YARN HA Cluster ID	yarn-cluster
当前 ResourceManager	hadoop1.test.com
新增 Standby ResourceManager	hadoop3.test.com
ZooKeeper	从集群中自动获取 3 个 ZooKeeper Server
ResourceManager ID	rm1、rm2

注意

点击 开始执行 后，向导会停止 YARN、安装新增 ResourceManager、写入 yarn-site 和 core-site 配置，再启动 ZooKeeper 与 YARN。建议放在维护窗口操作，避免正在提交或运行的任务受到影响。

操作前看一眼

先进入 服务与组件，确认 YARN 服务处于运行中。如果 YARN 还是单 ResourceManager，服务列表或 YARN 运维向导里会看到 单 ResourceManager、ResourceManager HA 未开启 这类提示。

我会在执行前先看这几项：

检查项	期望状态
YARN 服务	运行中
ResourceManager	当前只有 1 个，并且运行中
NodeManager	所有计算节点运行中
ZooKeeper	已安装并运行，YARN HA 会依赖它做状态存储和选举
配置待生效	尽量先处理掉明显的待重启、失败任务

如果页面已经显示 ResourceManager HA 已启用，就不需要再按首次开启流程操作，直接进入结果检查即可。

进入 YARN 运维向导

进入 YARN 服务详情页，点击右上角 操作，选择 YARN 运维向导。

进入向导首页后，页面会先展示当前 YARN 的可靠性状态。这里能看到 ResourceManager HA 还没有开启，ResourceManager 数量为 1，推荐策略是优先做 HA。

点击 进入 HA 向导，开始配置 ResourceManager HA。

填写 HA 参数

配置页主要填写两块：左侧是 YARN HA Cluster ID 和 ZooKeeper 信息，右侧是 ResourceManager 主机规划。

这里按规划填写：

参数	填写方式
YARN HA Cluster ID	保持 yarn-cluster，或按自己的命名规范填写一个稳定名称。
Current ResourceManager	页面自动识别当前 ResourceManager，通常不需要调整。
Additional ResourceManager	选择另一台主机作为 Standby ResourceManager，不能和当前 ResourceManager 相同。
ZooKeeper 节点	页面从集群自动获取，用于 ZKRMStateStore 和 Leader 选举。

提示

YARN HA Cluster ID 会写入 yarn.resourcemanager.cluster-id，并参与 ZooKeeper 选举路径。这个名字建议短一些、稳定一些，不要使用临时环境名。

如果集群启用了 Kerberos，页面顶部会提示 Kerberos: 执行前提交凭据。这不是配置错误，而是后面真正执行时需要 KDC 管理员凭据，为新增 ResourceManager 准备认证信息。

预览执行计划

参数填完后，点击 下一步 进入预览页。这里先看执行流程，再看角色主机和配置差异。

预览页会把自动化流程拆成 4 个阶段：

阶段	页面会做什么
Stop YARN	停止 ResourceManager 和 NodeManager，为角色安装与配置变更做准备。
Install ResourceManager	在新增主机上注册并安装 Additional ResourceManager。
Reconfigure YARN	写入 yarn-site 的 HA 配置，以及 core-site 的 ZooKeeper quorum。
Start Services	启动 ZooKeeper，再启动 YARN，进入 Active / Standby 模式。

配置变更里重点看这些值：

配置	期望值
yarn.resourcemanager.ha.enabled	true
yarn.resourcemanager.ha.rm-ids	rm1,rm2
yarn.resourcemanager.cluster-id	本次填写的 Cluster ID
yarn.resourcemanager.hostname.rm1	当前 ResourceManager 主机
yarn.resourcemanager.hostname.rm2	新增 Standby ResourceManager 主机
yarn.resourcemanager.store.class	org.apache.hadoop.yarn.server.resourcemanager.recovery.ZKRMStateStore
yarn.resourcemanager.zk-address	ZooKeeper quorum
ha.zookeeper.quorum	ZooKeeper quorum

确认角色主机和配置差异都符合预期后，再点击 进入执行。

开始执行

进入执行页后，页面还不会马上改集群，这一步只是准备状态。真正会停止 YARN、安装 ResourceManager、改配置并启动服务的动作，是点击右侧的 开始执行。

我建议在这里最后确认三件事：

检查项	为什么要确认
维护窗口	执行过程会停止 YARN。
Kerberos 凭据	Kerberos 集群会在执行前要求提交 KDC 管理员凭据。
任务低峰	新任务提交和正在运行的应用可能会受到影响。

确认无误后点击 开始执行。如果弹出 KDC 管理员凭据，按集群实际的管理员 Principal 和密码提交即可；密码不要写进文章截图，也不要贴到公开日志里。

提交后，页面会从准备状态进入真正的自动执行流程。下面这张图能看到前三个阶段已经完成，正在执行 Start Services，也就是依次启动 ZooKeeper 和 YARN。

执行过程中不要刷新页面，也不要再去手动停止、启动同一个服务。页面右侧的请求编号和阶段进度能帮助判断当前卡在哪一步；如果失败，先点开对应阶段看 Ambari 任务详情，再决定是重试还是回滚。

当 4 个阶段全部完成，页面会显示 ResourceManager HA 已成功启用，进度条也会变成完成状态。

回到页面确认结果

执行完成后，回到 YARN 运维向导 或 服务与组件 看结果。正常情况下应该能看到：

位置	期望看到
YARN 运维向导首页	ResourceManager HA 显示已开启
ResourceManager 数量	2
服务列表中的 YARN 卡片	显示 HA 已启用，或双 ResourceManager 自动切换拓扑
YARN 服务状态	运行中
ResourceManager 实例	两个实例运行中
NodeManager 实例	原有 NodeManager 运行中
配置待生效	YARN 及相关客户端没有明显待刷新配置

这次执行后，我在 Ambari API 里复核到的关键结果如下。写教程时我更愿意把这类结果贴出来，因为它比“页面显示成功”更能说明 HA 是否真的落到了集群配置里。

检查项	结果
YARN 服务状态	STARTED
ResourceManager 实例	2 / 2，hadoop1.test.com 与 hadoop3.test.com 都是 STARTED
NodeManager 实例	3 / 3，保持 STARTED

配置侧重点看这些值：

yarn.resourcemanager.ha.enabled=true
yarn.resourcemanager.ha.rm-ids=rm1,rm2
yarn.resourcemanager.hostname.rm1=hadoop1.test.com
yarn.resourcemanager.hostname.rm2=hadoop3.test.com
yarn.resourcemanager.store.class=org.apache.hadoop.yarn.server.resourcemanager.recovery.ZKRMStateStore
yarn.resourcemanager.zk-address=3 个 ZooKeeper 节点组成的 quorum

这几项能说明 ResourceManager 已经从单点入口切到 rm1 / rm2 的主备拓扑，其中 ZKRMStateStore 表示 ResourceManager 状态交给 ZooKeeper 保存。

API 复核项

配置项	结果
yarn.resourcemanager.ha.enabled	true
yarn.resourcemanager.ha.rm-ids	rm1,rm2
yarn.resourcemanager.hostname.rm1	hadoop1.test.com
yarn.resourcemanager.hostname.rm2	hadoop3.test.com
yarn.resourcemanager.store.class	ZKRMStateStore
yarn.resourcemanager.zk-address	3 个 ZooKeeper 节点组成的 quorum

完成后，如果 MapReduce2、Tez、Hive、Spark、Flink 这些依赖 YARN 的服务提示客户端配置待生效，按页面提示刷新客户端配置或重启对应服务。YARN HA 的核心目标，是让应用提交和调度入口从单点 ResourceManager 切换到 rm1 / rm2 的自动主备。

Kerberos 集群多看一眼

Kerberos 环境里，我还会额外看 core-site 里的 hadoop.proxyuser.yarn.hosts。YARN 的 Kerberos 描述通常会让这个值跟 ResourceManager 主机列表保持一致；也就是说，开启 HA 后它应该覆盖两个 ResourceManager 主机，或者按你的安全策略配置成等价范围。

如果这里还只保留旧 ResourceManager 主机，建议在 HDFS 的 core-site 配置里补齐两个 RM 主机，然后刷新客户端配置，并按实际影响范围重启或刷新相关服务。这个检查不影响你判断“HA 是否已经开启”，但会影响后续 failover 演练时的代理用户授权是否足够完整。

可选：命令复核

页面状态已经能完成主要判断。生产变更后如果还想从服务器侧复核一次，可以用 YARN 客户端查看配置和主备状态。

如果使用 Bigtop 常见的 Hadoop 配置路径，可以先看客户端侧的 yarn-site.xml 是否已经拿到 HA 配置：

grep -A1 -E 'yarn.resourcemanager.ha.enabled|yarn.resourcemanager.ha.rm-ids|yarn.resourcemanager.cluster-id' /etc/hadoop/conf/yarn-site.xml

期望能看到这些值：

true
rm1,rm2
yarn-cluster

Kerberos 集群先使用有权限的账号完成认证，再看两个 ResourceManager 的主备状态：

yarn rmadmin -getServiceState rm1
yarn rmadmin -getServiceState rm2

正常情况是一个返回 active，另一个返回 standby。最后再看 NodeManager 和应用入口：

yarn node -list
yarn application -list

yarn node -list 应该能看到已注册的 NodeManager；yarn application -list 能正常返回应用列表，说明客户端也已经通过 HA 配置访问 YARN。

常见卡点

现象	处理思路
不能进入下一步	检查是否选择了 Additional ResourceManager，且不能和当前 ResourceManager 在同一台主机。
页面提示没有 ZooKeeper 节点	先安装并启动 ZooKeeper，YARN HA 需要 ZooKeeper 做状态存储和选举。
Kerberos 凭据提交失败	核对 KDC 管理员 Principal、Realm 和密码，确认 KDC 服务可用。
执行阶段停在 Stop YARN	点开阶段任务，看是否有 NodeManager 或 ResourceManager 停止失败。
新增 ResourceManager 安装失败	检查目标主机 Agent、仓库、组件包和主机健康状态。
执行完成后客户端仍访问旧地址	刷新 YARN Client 配置，并重启依赖 YARN 的服务客户端。

YARN HA 做完以后，资源调度入口就不再只依赖单个 ResourceManager。下一步如果继续补控制面的高可用，可以再规划 Ranger Admin HA，让权限入口和审计入口也具备更好的容灾能力。