适用范围 3.0.3+

本文面向带有“Ambari Server 高可用”管理页面的 Ambari Plus 3.0.3 及后续兼容版本。不同小版本的按钮文字可能略有变化，但准备条件、主备建立顺序和验收原则不变。

向导负责把第二台 Server 建起来；真正的完成还包括唯一 Active、Agent 候选、统一入口和故障接管都通过核验。

开始前

固化版本、FQDN、数据库、容量、Agent 与维护窗口，先把阻塞项处理干净。

执行中

始终跟随原 Operation；页面短暂失联时恢复读取，不重复提交开启请求。

完成后

页面、API、Agent、负载均衡和真实切换五个视角交叉验证，不只看完成页。

config:
  target: _self
data:
  - name: 开始前
    desc: 固化版本、FQDN、数据库、容量、Agent 与维护窗口，先把阻塞项处理干净。
    bgColor: '#eef6ff'
    textColor: '#1f4e79'
  - name: 执行中
    desc: 始终跟随原 Operation；页面短暂失联时恢复读取，不重复提交开启请求。
    bgColor: '#fff8e8'
    textColor: '#79520b'
  - name: 完成后
    desc: 页面、API、Agent、负载均衡和真实切换五个视角交叉验证，不只看完成页。
    bgColor: '#eefaf4'
    textColor: '#176b4d'

这一篇从一个已经运行的单节点 Ambari Server 出发，增加第二台 Server，并把页面入口、环境准备、执行阶段、结果验证和故障演练完整走一遍。

我建议先在测试环境按相同主机名、数据库和入口模式演练，再进入生产维护窗口。开启过程会安装远端 Server、准备双向 TLS，并按批次调整 Agent 的 Server 候选；第一次启用双向 TLS 时，当前 Ambari Server 也可能发生一次受控重启。

目标拓扑与示例主机

全文使用下面这组 FQDN。替换成自己的主机名时，要保证所有节点的解析结果一致。

主机或入口	规划角色	说明
hadoop1.test.com	初始 Server，启用后为 Active	当前正在管理集群的 Ambari Server
hadoop3.test.com	新增 Standby	已安装、在线且健康的 Ambari Agent 主机
ambari.test.com	可选统一入口	HAProxy、硬件负载均衡或已有网关提供的稳定地址
db.test.com	Ambari 外部数据库入口	两台 Server 使用同一地址、同一库和同一账号

如果暂时没有统一入口，可以先选择“直连端点”模式，让页面和 Agent 认识两台 Server；正式生产环境通常还会在前面接入负载均衡，使浏览器和自动化调用方只使用 ambari.test.com。

开始前的准备清单

版本和软件仓库

两台 Server 必须安装同一个 release identity 对应的软件包，不能只保证“都是 3.0.3”。先在当前 Server 核对版本和包来源，并确认离线仓库能向目标主机提供完全一致的包。

rpm -q ambari-server
rpm -qi ambari-server | sed -n '1,20p'

dpkg-query -W -f='${Package} ${Version}\n' ambari-server
apt-cache policy ambari-server

// Make sure to add code blocks to your code group

目标主机此时只需要有健康的 Ambari Agent。不要提前手工启动第二个 Ambari Server，向导会在校验软件包、下发配置和关闭选举的前提下完成安装与首次启动。

FQDN、时间与网络

在两台 Server、数据库节点和至少一台普通 Agent 主机上交叉检查解析：

hostname -f
getent hosts hadoop1.test.com
getent hosts hadoop3.test.com
getent hosts db.test.com

再确认时间同步正常：

timedatectl status
chronyc tracking
chronyc sources -v

防火墙需要放行现有 Ambari Server/Agent 通信端口、目标 Server 管理端口、两台 Server 到数据库的端口，以及环境使用的 Agent mTLS 通道。端口应以当前安装版本和安全配置为准，不要只照搬其他环境的规则。

外部数据库

数据库地址不能是 localhost、127.0.0.1 或只在当前 Server 本机可达的 Unix Socket。分别从两台候选 Server 验证：

• FQDN 解析到稳定的数据库入口；
• 数据库端口可达；
• Ambari 数据库账号具备原有权限；
• 数据库本身有备份和恢复方案；
• 连接池和数据库容量可以承担节点切换后的重连。

Server HA 不替数据库兜底

如果共享数据库不可用，两台 Server 都无法安全确认 Lease 和任务状态。Server HA 会让无法确认租约的节点进入围栏状态，而不会拿本地缓存继续写。

目标主机容量与 Agent

页面默认会检查目标主机至少有 4096 MiB 可用内存、2048 MiB 可用磁盘，并确认 Ambari Agent 在线。下面的命令可以提前排除最常见的问题：

free -m
df -h /var /var/lib /var/log
systemctl status ambari-agent --no-pager

目标节点还要满足这些条件：

• 不是当前 Ambari Server；
• 没有残留的旧 Ambari Server 进程、数据库配置或 systemd 覆盖；
• 与当前 Server 使用兼容的操作系统、JDK 和软件源；
• 能通过 Agent 正常执行主机命令；
• 主机上的安全策略不会阻止目标目录、端口和证书权限。

控制面必须处于安静状态

开启前暂停新的安装、升级、扩容、批量重启和安全配置变更，并等待已有任务结束。页面会检查当前 Server 是否可写、是否存在运行中的控制任务，以及其他高可用操作是否持有变更锁。

我还会在维护窗口开始前保存三份基线：

1. Ambari 数据库备份及恢复说明；
2. 当前 Server 与 Agent 的配置备份；
3. 集群服务、主机和未完成 Request 的快照记录。

备份的意义不是让人随时手工覆盖运行配置，而是在正式回退或故障分析时有可信基线。

从页面进入启用向导

使用具备管理权限的账号登录 Ambari Plus，依次进入：

系统设置 → 高可用管理 → Ambari Server → 开启 Server 高可用

如果没有看到入口，先确认版本是否包含 Server HA 能力，以及当前账号是否具备高可用管理权限。不要通过手工拼接 URL 绕过版本或权限检查。

上图展示了向导的第一个业务步骤：选择备用节点。页面会列出具备 Agent 基础条件的候选，但“出现在列表中”不等于所有预检查已经通过，后面仍会核对容量、版本、数据库、安全和运行任务。

第一步：选择备用节点

在候选列表中选择 hadoop3.test.com。我会重点核对以下信息：

• 当前服务节点明确显示为 hadoop1.test.com；
• 备用节点不是数据库或统一入口的单点承载主机；
• 目标 Agent 最近心跳正常，没有待处理的重启或升级；
• 目标主机故障域尽量与当前 Server 分开，例如不同物理机或可用区；
• 目标主机的 CPU、内存和磁盘能够承接 Active 负载。

如果页面显示多个候选，优先选择故障域独立、网络路径稳定、运维权限清楚的节点，不要只按空闲内存排序。

第二步：确认配置计划

进入确认页后，页面会把即将使用的主备、数据库、入口和安全决策汇总出来。至少检查：

配置项	应看到的结果
当前 Server	hadoop1.test.com
新 Standby	hadoop3.test.com
Server 版本	两端目标 release identity 完全一致
数据库	指向同一个外部数据库入口
入口模式	DIRECT_ENDPOINTS 或 EXTERNAL_LB 与实际部署一致
Agent 候选	包含当前 Server 和 Standby，顺序与计划一致
TLS	Agent 启用证书校验，mTLS 材料来源可确认
故障接管	自动接管策略与维护窗口选择一致

DIRECT_ENDPOINTS 适合先建立主备或已有调用方能自行发现 Active 的场景；EXTERNAL_LB 适合通过稳定域名统一访问。选择后者时，要确保负载均衡已经能够以 /readiness 判断节点，而不是只做 TCP 探活。

第三步：处理环境检查

环境检查会把问题分为阻塞项和提示项。阻塞项必须先处理，常见结果如下：

检查结果	常见原因	处理建议
当前 Server 不可写	当前节点不是 Active Ready，或数据库异常	先恢复唯一 Active 与数据库，不要继续启用
版本身份不一致	目标仓库包来自其他构建或版本	修正仓库并重新检查，禁止混装
数据库不是共享入口	使用 localhost、本机地址或目标节点不可达	先迁移/修正外部数据库配置并验证两端连接
目标 Agent 不健康	Agent 停止、证书或心跳异常	恢复 Agent，确认主机页状态稳定
资源不足	可用内存或磁盘低于基线	清理空间或更换目标节点
存在运行任务	安装、升级、启停等 Request 未结束	等待完成或按原任务处理失败，不要强行清锁
mTLS 不满足要求	证书过期、自定义材料不可安全复用	修复正式证书链或由平台重新准备材料

不要为了通过检查修改数据库里的状态

运行任务、变更锁、HA epoch 和 Operation 都是恢复判断的一部分。直接删除记录可能暂时让按钮变亮，却会破坏幂等和回退依据。应从页面展示的首个失败步骤开始处理。

修复外部条件后重新执行环境检查。计划内容如果发生变化，例如更换了目标主机或入口模式，应该重新确认整份计划。

第四步：启动自动配置

确认执行后，页面会创建一笔后台 Operation。浏览器可以离开再回来，但不要重复点击开启。执行过程中通常会依次看到：

1. 锁定本次高可用变更；
2. 准备当前 Server 与 Agent 的双向 TLS；
3. 对目标主机进行远端预检查；
4. 安装同版本 Ambari Server，并保持停止；
5. 安全下发数据库、主密钥和允许复用的证书材料；
6. 以关闭选举的方式启动 Standby；
7. 当前 Active 提交新的 HA epoch；
8. 分两阶段写入并激活 Agent 候选配置；
9. 开启 Standby 选举；
10. 验证唯一 Active、Standby 和接管准备度。

有些阶段的超时时间会达到数分钟，例如 Standby 启动、Agent 重启和故障验收。只要页面仍显示后台任务在执行，就让服务端继续；刷新页面不会加快进度，重复创建操作反而会被变更锁拒绝。

页面短暂失联时怎么办

若恰好发生 Server 重启或角色切换，页面可能进入“正在恢复管理连接”。这时正确的行为是：

• 暂停新的写操作；
• 等待新的 Active readiness 成功；
• 使用原 Operation 标识继续读取进度；
• 超过恢复窗口后再查看两台 Server 和数据库状态。

不要在另一个浏览器窗口重新提交一遍，也不要让外部代理自动重试写请求。

某一步失败时从哪里查

先在页面展开首个失败阶段，记录业务错误、目标主机和时间点。再按阶段检查对应对象：

阶段	优先检查
mTLS 准备	当前 Server 是否恢复、证书有效期与信任链、Agent 证书校验
远端预检查	目标 Agent、系统环境、仓库、磁盘和权限
软件安装	目标包版本、包管理器日志、残留 systemd 服务
安全引导	目标 Server 是否停止、清单/哈希/权限、mTLS 通道
Standby 启动	Server 日志、数据库连接、HA 配置、liveness 与角色
Agent 切换	失败主机批次、候选配置标记、Agent 重启结果
选举或验收	Lease、Term、epoch、唯一 Active 和 readiness

页面提供“继续”时，应继续原 Operation；只有计划明确失效或页面要求重新规划时，才创建新操作。

第五步：完成页只是验收起点

页面完成后进入 Ambari Server 高可用概览。下面这张图来自一套已经形成主备的环境：当前服务节点为 hadoop1.test.com，备用节点为 hadoop3.test.com，故障接管显示“已准备”。

概览页至少要同时确认：

• 当前服务节点与备用节点都明确可见；
• Server 节点总数为 2；
• 只有一个节点标记为当前服务节点；
• 备用节点运行正常；
• 自动接管策略符合预期；
• 页面没有遗留的失败或待恢复后台任务。

但这仍然是控制台视角。正式验收还要从 API、Agent、入口和真实故障四个方向交叉验证。

用 API 核对角色、Term 和 Ready

下面的命令使用占位域名和端口。-u '<admin-user>' 会交互式询问密码，不要把密码直接写进命令历史。

curl --fail --silent --show-error \
  --cacert /path/to/ambari-ca.pem \
  -u '<admin-user>' \
  'https://hadoop1.test.com:<server-port>/api/v2/control-plane/ha/agent-status' \
  | jq

对两台节点分别执行，并记录这些字段：

• role：一台 Active，一台 Standby；
• ready：只有当前 Active 对业务就绪；
• term：两台观察到同一个最新 Term；
• epoch：与本轮 HA 配置一致；
• instanceId：两个节点身份不同且稳定。

再分别验证 liveness 和 readiness：

curl --cacert /path/to/ambari-ca.pem -o /dev/null -sS -w 'liveness=%{http_code}\n' \
  'https://hadoop1.test.com:<server-port>/api/v2/control-plane/ha/liveness'

curl --cacert /path/to/ambari-ca.pem -o /dev/null -sS -w 'readiness=%{http_code}\n' \
  'https://hadoop1.test.com:<server-port>/api/v2/control-plane/ha/readiness'

预期结果是：两台 Server 的 liveness 都成功，只有 Active Ready 的 readiness 返回成功；Standby 的 readiness 明确拒绝。如果两台 readiness 都成功，应立即停止继续写操作并按脑裂风险处理。

核对 Agent 已进入候选模式

在几台不同机架、不同服务类型的 Agent 上抽查 /etc/ambari-agent/conf/ambari-agent.ini：

sudo sed -n '/^\[server\]/,/^\[/p' /etc/ambari-agent/conf/ambari-agent.ini
sudo sed -n '/^\[security\]/,/^\[/p' /etc/ambari-agent/conf/ambari-agent.ini
systemctl status ambari-agent --no-pager

期望看到：

• ha_enabled=true；
• ha_candidates 同时包含 hadoop1.test.com 和 hadoop3.test.com；
• 状态探测路径是正式 HA agent-status 接口；
• ssl_verify_cert=1；
• Agent 当前连接的是 Active，主机心跳在页面恢复正常。

不要只抽查当前 Server 主机上的 Agent。至少覆盖普通工作节点、边缘节点和承载关键服务的主机，避免某一批 Agent 在切换阶段遗漏。

接入 HAProxy 或已有负载均衡

统一入口只应把流量转发到 readiness 成功的节点。下面是表达关键原则的 HAProxy 片段，证书、端口和超时要按自己的环境调整：

backend ambari_servers
  option httpchk GET /api/v2/control-plane/ha/readiness
  http-check expect status 200
  default-server inter 2s fall 2 rise 2 on-marked-down shutdown-sessions

  server ambari-1 hadoop1.test.com:<server-port> check ssl verify required ca-file /etc/haproxy/ambari-ca.pem
  server ambari-2 hadoop3.test.com:<server-port> check ssl verify required ca-file /etc/haproxy/ambari-ca.pem

on-marked-down shutdown-sessions 可以让入口摘除旧 Active 时关闭遗留会话。代理层不要为 POST、PUT、PATCH、DELETE 配置自动重试；读取请求是否重试也应限定在明确安全的路径。

配置完成后，从统一入口验证登录、集群概览、主机列表和一条只读 API。不要一上来就通过代理发起批量重启，以免把入口问题和控制任务问题混在一起。

做一次真正的故障接管演练

只在批准的维护窗口执行

停止当前 Active 会中断短时间的管理连接。演练前确认没有安装、升级、启停等写任务，数据库和 Standby 健康，并准备好恢复原 Server 的命令与现场观察人。

演练前记录

记录当前 Active、Standby、Term、epoch、两台 readiness、统一入口和 Agent 连接分布。保留一个已经存在但只用于观察的 Operation 或页面状态，便于验证接管后读取能否继续。

停止当前 Active

在 hadoop1.test.com 上执行：

sudo systemctl stop ambari-server

从另一台运维主机持续观察 hadoop3.test.com 的 agent-status 和 readiness。预期顺序是：

1. 旧 Active 停止续租；
2. Lease 到期后 Standby 获取更高 Term；
3. 新 Active 完成集群与任务状态恢复；
4. readiness 成功，统一入口恢复；
5. Agent 在分散窗口内连接新 Active；
6. 页面重新读取原状态，没有重复创建写任务。

恢复原节点

新 Active 稳定后，在 hadoop1.test.com 上执行：

sudo systemctl start ambari-server

原节点应读取到更新后的 Term，以 Standby 身份回归。它不能把自己恢复成旧 Active，也不能让统一入口同时把两台节点标记为 Ready。

故障验收表

验收点	通过标准
Active 唯一性	任意时刻最多一个 readiness 成功
Term 推进	接管后 Term 增加，原节点接受新 Term
晋升完成	新节点先恢复再 Ready，没有提前接流量
Agent 重连	Agent 自动迁移，未出现同 Term 多 Active 或持续失联
页面恢复	短暂失联后自动继续读取，不重复弹同一错误
写入安全	没有重复 Request、Stage 或 Agent 命令
旧节点回归	原 Active 以 Standby 稳定加入
统一入口	地址不变，恢复后只转发新 Active

所有项目通过，才可以把“HA 已开启”升级为“故障接管已验收”。

常见问题与恢复方向

两台 Server 都存活，但页面说没有可用 Active

先看数据库连通性和 Lease，而不是反复重启两台 Server。如果两边都无法确认租约，自我围栏正是在保护数据。恢复数据库后观察哪台节点取得最新 Term，并等待晋升完成。

Standby liveness 正常，readiness 返回 503

这是正常现象。Standby 进程应该存活，但不能对普通业务就绪。负载均衡若把 503 当成“整个后端故障”，需要检查是否为每个节点独立维护健康状态。

Agent 在切换后持续离线

抽查 Agent 候选、证书校验、状态探测路径和当前 Term。确认 DNS 能同时解析两台 Server，Agent 能访问新 Active 的 mTLS/服务端口。不要先把 ssl_verify_cert 改成 0 来绕过证书错误。

页面一直停在后台任务执行中

先打开任务进度查看当前阶段。若 Server 刚刚发生接管，等待页面重新连接并读取原 Operation；若后台已明确失败，从首个失败步骤处理。不要凭一个旋转图标判断整笔操作已经卡死。

恢复节点回来后抢占了 Active

正常情况下，恢复节点会观察到更高 Term 并成为 Standby。如果出现两个 readiness 成功或 Agent 报告同 Term 多 Active，应立即停止新的管理写入，保留数据库、两台 Server 和 Agent 日志，按高优先级一致性故障处理。

想把备用节点移除

使用高可用管理页面提供的成员恢复或移除流程，让 Agent 从候选模式正式收敛。不要直接卸载 Standby 或批量手改 ha_candidates，否则仍在线的 Agent、入口和数据库 epoch 可能保留不同拓扑。

日常运维要持续看什么

启用完成后，我会把下面几项加入巡检和告警：

• Active/Standby 角色、Term 和 epoch 一致性；
• 两台 liveness、唯一 readiness；
• Lease 续租延迟和数据库连接异常；
• Standby 进程、磁盘、JVM 和证书有效期；
• Agent 候选配置覆盖率和重连失败数；
• 统一入口的后端健康、会话摘除和 5xx；
• 最近一次故障演练时间与结果。

升级、证书轮换、数据库迁移和入口变更也要按主备顺序执行，并在变更后重新验证唯一 Active。高可用不是启用一次就永久有效，它依赖两台节点、共享数据库、Agent 与入口长期保持同一套协议。

最后的判断标准

我会用一句话判断这套 HA 是否真正成立：

当前 Active 消失后，系统能在不重放任何写操作的前提下，选出更高 Term 的唯一新 Active；Agent 与入口自动迁移，旧节点恢复后只作为 Standby 回归。

只要其中一段还依赖临时改地址、手工复制证书或重新点击操作，就还没有完成闭环。把预检查、自动配置和故障验收都走通，Ambari Server 才从“第二个进程”变成真正可接管的管理控制面。

回到专题目录

按动机、架构、实现和实战顺序阅读完整 Ambari Server HA 系列。

理解唯一 Active

复习 Lease、Term、写围栏、晋升屏障和 Agent 选主。

深入启用实现

沿持久化 Operation 查看远端安装、安全引导和两阶段切换。

config:
  target: _self
data:
  - name: 回到专题目录
    desc: 按动机、架构、实现和实战顺序阅读完整 Ambari Server HA 系列。
    link: /v/custom/thoughts/ambari-server-ha/
    bgColor: '#eef6ff'
    textColor: '#1f4e79'
  - name: 理解唯一 Active
    desc: 复习 Lease、Term、写围栏、晋升屏障和 Agent 选主。
    link: /v/custom/thoughts/ambari-server-ha/architecture/
    bgColor: '#eefaf4'
    textColor: '#176b4d'
  - name: 深入启用实现
    desc: 沿持久化 Operation 查看远端安装、安全引导和两阶段切换。
    link: /v/custom/thoughts/ambari-server-ha/implementation/
    bgColor: '#fff8e8'
    textColor: '#79520b'