在Ambari管理的Hadoop集群里一旦开启KerberosRanger Admin就成了所有组件授权策略的唯一动态来源。权限变更、用户同步、审计写入全都压在它身上。这个服务如果没做高可用NameNode挂了你可能第一时间发现Ranger挂了反而很隐蔽——它不会立刻中断数据读写而是让接下来的每一次权限更新、每一个插件启动全部卡壳。我们当时的方案是前端用Haproxy做统一入口后端挂两台Ranger Admin实例形成一套真正可用的Ranger HA。这一篇先讲规划和环境安装重点说透Kerberos场景下有哪些坑以及Haproxy到底要怎么配才不会被安全认证揍得满头包。这套内容适合正在用Ambari管理Hadoop、集群里已经开了Kerberos、又不想让Ranger变成单点故障的运维同学。哪怕你还没装Haproxy也可以先看架构思路再照着环境清单去准备。废话不多说直接从方案选型开始。1. Ranger HA 方案设计与选型1.1 Ranger 单点在 Kerberos 环境里的隐蔽性Ranger Admin 在集群里的角色很特殊。HDFS、Hive、HBase 这些组件启动时会把策略拉取到本地缓存所以即使 Ranger Admin 挂了已经运行中的组件短期内还能继续按缓存策略干活。但接下来呢新加一个用户、调一条权限、改一个库表的访问策略全部都写不进去Ranger Usersync 拉不到用户/组信息审计写入也可能断掉更麻烦的是某个插件如果重启它可能直接因为拉不到策略而用默认 deny 策略把自己锁死。换到 Kerberos 环境问题还会多一层Ranger Admin 和 KDC、插件之间走的都是加密认证链路只要有一方配置不对报错往往不是“连接失败”而是各种“GSS failure”“Server not found in Kerberos database”排查起来比普通网络问题痛苦得多。更现实的一个痛点是Ambari 默认并不像 HDFS NameNode 那样提供 Ranger Admin 的双机部署。Ambari 界面里 Ranger 组件基本固定在某一台主机上想做成 HA必须自己动手在第二台机器上把 Ranger Admin 部署起来再让它和第一台连同一个后端数据库。前端的访问入口还不能让用户和插件直接用两台机器的真实 IP否则一旦其中一台出问题客户端不知道自动切换策略拉取就会时好时坏。所以负载均衡这一层不是可选项而是必需品。1.2 为什么是 Haproxy 而不是 Nginx/Keepalived做前端统一入口可选项不少。Nginx 也能做反代Keepalived 能管虚拟 IP云环境还能直接用云负载均衡。但在 Kerberos Ranger 这个组合下我更倾向把 Haproxy 放在第一梯队。原因之一是 Haproxy 对 TCP 层的透传支持非常干净。Ranger Admin 如果开了 HTTPS很多组件拉策略走的是 6182 端口Nginx 做 HTTPS 反代时往往会忍不住做 TLS 终结、改 Host 头、或者把上游协议的细节动一遍。这些动作单看没问题一旦遇到 SPNEGO/Kerberos 认证极容易把客户端发过来的服务票据和服务端期望的 principal 搞对不上。Haproxy 的mode tcp可以原样转发字节流不碰 TLS 证书不碰 HTTP 头Kerberos 认证链路走起来最稳。Keepalived 负责的是虚拟 IP 漂移它解决的是“入口地址由谁对外发布”的问题。如果你已经有多台 Haproxy或者只有一两台 RangerKeepalived 确实可以做一层冗余但它本身不做负载均衡和健康检查。Ranger Admin 的两个实例都可以服务更需要的其实是 Haproxy 这种能把请求按一定策略分发、并且能感知后端存活的组件。Keepalived 可以和 Haproxy 配合但不是替代关系。在初期规划里我们先上一台 Haproxy 统一接入后续如果担心 Haproxy 自身单点再用 Keepalived 给 Haproxy 做 VIP 漂移也不迟。1.3 架构拓扑与依赖关系我们最后落地的拓扑大概是这样的两台 Ranger Admin 节点分别部署 ranger-admin 相关服务两个实例连接同一个 Ranger 数据库。一台 Haproxy 节点作为所有 Ranger 请求的统一入口。对外提供逻辑域名例如ranger-ha.example.com。Haproxy 监听 6080HTTP和 6182HTTPS两个端口把流量转发给两台 Ranger Admin 的对应端口。Ranger 插件侧配置的策略服务地址统一指到ranger-ha.example.com不直接写任何一台 Ranger 的真实主机名。这个架构里有一个比较容易忽略的点Ranger Admin 的两个实例并不是传统的主备关系它们都是活的都连同一个数据库策略数据本身是共享的。Haproxy 只需要保证同一个用户的会话尽量落到同一台以及在后端某台故障时自动摘除。这样的设计比“主备切换”省心得多因为不需要额外处理状态同步数据库层面已经天然统一了。数据库也是个前置条件。Ranger Admin 需要用 MySQL/PostgreSQL 作为后端存储两个 Ranger 实例都要能连这个库。很多人在搭 HA 时漏了检查数据库连接数导致第二台 Ranger 实例起来后第一台时不时报连接超时。后面搬迁案例里我会提醒大家提前把 max_connections 调大。2. 环境规划与前置检查2.1 主机、域名与端口规划做 Kerberos 相关的高可用主机名和域名一定要在动手前规划清楚。Kerberos 的 service principal 和主机名强相关用 IP 访问基本不会顺畅所有内部访问最好都走 FQDN。我当时的规划表大致如下实际环境中请替换成你们自己的主机名和 IP角色主机名IP 地址用途说明Ranger-1ranger1.example.com192.168.1.11Ambari 安装的 Ranger Admin后端节点Ranger-2ranger2.example.com192.168.1.12手工部署的第二个 Ranger Admin后端节点Haproxyhaproxy.example.com192.168.1.13Ranger 统一入口对外服务节点逻辑访问域名ranger-ha.example.com192.168.1.13指向 Haproxy 的访问域名也可做 VIP端口方面Ranger Admin 默认的 HTTP 端口是 6080HTTPS 端口是 6182。Ambari 里可以通过配置改但我们没有改直接用默认端口。Haproxy 会绑定 6080 和 6182同时开放一个 9000 端口给 Haproxy stats 监控页。这里特别提醒一下如果 Haproxy 这台机器还跑着其他服务一定要避免端口冲突。我们环境里 6080、6182 都是空着的所以压力不大。建议提前把所有主机名和逻辑域名都写进内部 DNS或者至少在所有相关节点的/etc/hosts里加好映射。特别是 Kerberos 环境KDC 里面注册的 principal 主机名必须能通过 DNS 正反向解析到同一个名字否则后面 kinit、SPNEGO 都可能出现诡异报错。2.2 版本、仓库与系统初始化我当时的 JVM 系统是 CentOS 7.9Ambari 用的是 2.7.xRanger 版本是 2.0.1Haproxy 用的是自带 yum 源的 1.8.27。如果你们的 Ambari 是 2.6 甚至 3.xRanger 端口和配置项可能会有差异但整体思路一致。安装 Haproxy 之前有几项系统初始化要先做时间同步必须的。Kerberos 认证对客户端和服务端的时间差极其敏感时钟偏移超过 5 分钟kinit 和 SPNEGO 都会失败。CentOS 7 上我建议直接启用 chronyd和集群内同一个 NTP 源对齐。关闭或放行防火墙端口。如果开了 firewalld至少放行 6080、6182 和 9000 端口。SELinux 若非必须建议先设为 permissive等全部跑通后再逐项收紧不然 Haproxy 绑定非标准端口时很容易被 SELinux 策略拦死。确认系统里有nc、curl、telnet等排障工具后面验证端口和 HTTP 状态码会反复用。Haproxy 安装很简单yum 直接装就行。如果你的系统自带源里版本太老想用 2.x 的新特性可以用官方源或者源码编译。源码编译时记得加上USE_OPENSSL1和USE_PCRE1不然后面想用 SSL 和正则功能会缺依赖。2.3 Kerberos principal 与 keytab 规划这是整篇博文里最容易被忽视、但最影响成败的部分。先理解一个核心关系客户端访问 Ranger Admin 时如果走 Kerberos SPNEGO那么它请求的服务 principal 是根据访问 URL 里的主机名生成的。用户浏览器访问的是https://ranger-ha.example.com:6182那么浏览器向 KDC 请求的服务票据就是HTTP/ranger-ha.example.comEXAMPLE.COM而不是HTTP/ranger1.example.comEXAMPLE.COM。后端 Ranger Admin 的 Tomcat 要能解开这个票据就必须持有一把包含HTTP/ranger-ha.example.com这个 principal 的 keytab。这意味着两台上游 Ranger 节点不能各自只用自己真实主机名的 HTTP principal 做 SPNEGO而是需要统一使用逻辑访问域名的 principal。我在规划 phase 的 KDC 里执行了类似这些操作kadmin.local addprinc -randkey HTTP/ranger-ha.example.com ktadd -k /tmp/ranger-ha.keytab HTTP/ranger-ha.example.com然后把/tmp/ranger-ha.keytab分发到两台 Ranger 节点的指定目录例如/etc/ranger/admin/conf/ranger-ha.keytab并确保运行 Ranger Admin 的用户通常是ranger也可能是hadoop能读取。之后再在 Ambari 的 Ranger Admin 配置里把 Kerberos/SPNEGO 相关属性指向这个 keytab 和 principal。不同 Ambari 版本的属性名称略有差异但围绕的无非是spnego.principal、ranger.admin.kerberos.principal这类配置项。还有一点要同步考虑Ranger 插件拉策略时如果策略服务地址改成https://ranger-ha.example.com:6182那么插件侧向 KDC 请求的也是HTTP/ranger-ha.example.com这个票据。后端 Ranger 只要配置了同一个 keytab就能正常工作。所以统一逻辑域名这个动作不是只改个 URL 那么简单而是要把“访问域名、服务 principal、后端 keytab”三者对齐。2.4 数据库与 Ambari 侧准备Ranger Admin 的两个实例必须共用同一个元数据库。我们用的是 MySQL在 Ambari 安装 Ranger 时已经创建了ranger库和对应的账号。第二台 Ranger Admin 实例准备接入时要确认这个 MySQL 账号允许从ranger2.example.com远程连接并且 MySQL 的max_connections足够建议比单机环境调大至少一倍。Ambari 侧还有一个容易忽略的地方。Ambari 默认生成的 Ranger 服务地址可能还指向ranger1.example.com真实主机名比如rangeradmin的 URL、Usersync 的 REST URL。第二台实例加入后如果不做任何调整Ranger 内部的组件仍可能只连着第一台。我们在这一步会把整个集群内依赖 Ranger Admin URL 的配置统一改成https://ranger-ha.example.com:6182例如 HDFS、Hive 插件里的ranger.plugin.*.policy.rest.url。改完后需要重启相关组件让插件重新加载配置。3. Haproxy 安装与核心配置3.1 安装方式选择Haproxy 安装不复杂。CentOS 7 自带的 Haproxy 1.8 对当前够用直接yum install -y haproxy haproxy -v如果你们用的是 Ubuntu/Debianapt install haproxy也可以。装完先不要急着启动先把配置写好再haproxy -c -f /etc/haproxy/haproxy.cfg做语法检查。有人喜欢用源码装新版主要目的是想要更细粒度的线程、Prometheus 暴露指标、更完善的 HTTP 健康检查。我的建议是初装阶段用系统包跑通后续确有必要再升级。原因是 Haproxy 的二进制升级不会影响后端应用完全可以二期再做。系统包的优势是 systemd 管理、日志、权限都处理好了少踩一部分“非标准安装”的坑。3.2 haproxy.cfg 设计思路Ranger 的访问流量分两类一类是普通用户打开 Ranger UI另一类是各组件插件拉策略。两者都是 HTTP(S) 请求但我特意没有把所有流量都放到 L7 处理。设计上采用“HTTP 检查 TCP 透传”的组合6080 端口可以作为 HTTP 模式处理方便做健康检查和会话保持。6182 端口使用mode tcp原样转发 TLS 流量证书仍由 Ranger Admin 自己持有Haproxy 不碰。这个取舍很重要。HTTPS 端口如果改成 HTTP 模式就不可避免地要处理 TLS 终结。一旦 Haproxy 终结 TLS它就得持有 Ranger 的证书和私钥这倒不是不行但会让证书管理分散到多台机器。更麻烦的是SPNEGO 票据是嵌在 HTTP 头里的TLS 终结本身不影响它但很多人在配置 L7 反代时顺手改了 Host、加了 X-Forwarded 头这些改动都可能让后端 Tomcat 在处理 SPNEGO 时出现意料之外的行为。与其去排查这些不如直接用 TCP 透传。健康检查方面我对 HTTP 后端用option httpchk GET /login.jspTCP 后端用tcp-check connect。/login.jsp在绝大多数 Ranger 版本下不需要额外认证就能返回 200如果你的版本会 302 到别处可以换成根路径/或者用自定义检查脚本。TCP 检查虽然只能证明端口通但胜在稳定不误报作为 HAProxy 的后端存活判断已经足够。3.3 完整配置示例下面是我直接用过的 Haproxy 配置简化版。你们按实际情况替换主机名、IP、端口即可。global log /dev/log local0 maxconn 4096 user haproxy group haproxy daemon nbproc 1 tune.ssl.default-dh-param 2048 defaults log global option redispatch retries 3 timeout http-request 10s timeout queue 20s timeout connect 5s timeout client 120s timeout server 120s timeout http-keep-alive 10s frontend ranger_frontend_http bind *:6080 mode http default_backend ranger_http frontend ranger_frontend_https bind *:6182 mode tcp default_backend ranger_https backend ranger_http mode http option httplog option httpchk GET /login.jsp http-check expect status 200 balance roundrobin stick-table type ip size 200k expire 30m stick on src server ranger1 192.168.1.11:6080 check inter 5s fall 3 rise 2 server ranger2 192.168.1.12:6080 check inter 5s fall 3 rise 2 backend ranger_https mode tcp option tcplog balance roundrobin stick-table type ip size 200k expire 30m stick on src server ranger1 192.168.1.11:6182 check inter 5s fall 3 rise 2 server ranger2 192.168.1.12:6182 check inter 5s fall 3 rise 2 listen stats bind *:9000 mode http stats enable stats uri /stats stats refresh 10s stats auth admin:your_password_here这段配置里几个细节展开说一下stick-table和stick on src的作用是让同一个来源 IP 尽量固定到同一台后端。Ranger 的 UI 登录会话存在各自的 Tomcat 里如果前两次请求落到 ranger1第三次落到 ranger2管理员登录后刷新页面可能直接丢会话。插件拉策略虽然不是交互式请求固定同一台也能减少不必要的认证切换。option httpchk GET /login.jsp是 HTTP 健康检查。HAProxy 会定期以 HTTP 请求探测后端http-check expect status 200是要求返回 200 才算存活。如果你的 Ranger 健康检查路径返回 302可以适当改成/或调整 expect 逻辑。timeout client和timeout server我设置了 120 秒。Ranger 页面操作偶尔会有长时间请求比如某条策略批量导出、用户同步刷新太短的超时容易造成前端 504 或连接被切断。但也别设得太长避免无效连接占用过多。stats 页面端口 9000 建议只对运维网段开放不要暴露公网。stats auth设置一个强密码避免监控页面里后端地址和状态泄露。3.4 启动、校验与日志配置配置写好后先做语法检查再启动haproxy -c -f /etc/haproxy/haproxy.cfg systemctl enable haproxy systemctl start haproxy ss -lntp | grep -E 6080|6182|9000我每次都会看ss确保三个端口都正常监听然后从本机 curl 一下 HTTP 前端curl -I http://127.0.0.1:6080/login.jsp如果返回 200说明 Haproxy 到后端的 HTTP 链路是通的。HTTPS 端口因为 TCP 透传从本机 curl 实际上起不到什么作用可以直接用后面提到的curl --negotiate验证。HAProxy 的日志默认通过 syslog 输出CentOS 7 上如果你发现/var/log/messages里没有 Haproxy 的访问日志需要在/etc/rsyslog.conf或/etc/rsyslog.d/haproxy.conf里配置一个独立的日志通道把local0.*写到/var/log/haproxy.log。建议一开始就把日志配上后面排查 401、503、后端 DOWN 的时候日志才是第一手证据。4. Kerberos 场景下的关键适配4.1 SPNEGO 与负载均衡之间的矛盾很多人在没有开 Kerberos 的集群上用 Haproxy 做 Ranger 反代非常轻松配完就能用。一旦开启 Kerberos问题就来了SPNEGO 认证流程里浏览器会先向 KDC 请求一个针对目标主机的服务票据然后把这个票据塞到Authorization: Negotiate请求头里。后端 Tomcat 收到后会用自己的 keytab 去解密这个票据。如果用户访问的是ranger1.example.com后端持有HTTP/ranger1.example.com的 keytab一对就对上。但如果用户访问的是 Haproxy 逻辑域名ranger-ha.example.com而请求被转发到了ranger1后端的 Tomcat 如果只持有HTTP/ranger1.example.com的 keytab它面对着HTTP/ranger-ha.example.com的票据自然是解不开的。结果就是浏览器反复弹出认证框或者直接返回 401。这个问题不是 Haproxy 特有的。只要前面任何负载均衡设备把地址换成了另一个域名都会有同样的坑。最稳妥的做法就是前面规划时提到的让两台 Ranger Admin 都持有逻辑域名的 keytab统一对外使用逻辑域名。4.2 统一访问入口的 SPN 部署方案实际操作步骤可以总结成这样在 KDC 上创建HTTP/ranger-ha.example.comprincipal 并导出 keytab。将 keytab 分发到ranger1和ranger2路径统一放同一个方便管理。修改 Ambari 中 Ranger Admin 的 Kerberos/SPNEGO 配置把 keytab 路径和 principal 都指过去。重启 Ranger Admin 服务确认/etc/security/keytabs或自定义目录里的 keytab 权限正确日志里没有 “GSSException” 或 “invalid keytab” 类报错。这里有一个细节如果一台 Ranger 之前已经用真实主机名HTTP/ranger1.example.com跑过 SPNEGOAmbari 里可能残留了旧配置。改的时候要确认服务端使用的 principal 没有再被其他模块引用否则会出现 Ranger Admin 进程自己认证没问题但 UI 登录时 SPNEGO 始终对不上的现象。验证 keytab 是否可用的最简单命令是klist -kt /etc/ranger/admin/conf/ranger-ha.keytab kinit -k -t /etc/ranger/admin/conf/ranger-ha.keytab HTTP/ranger-ha.example.com第二行如果能正常完成说明 keytab 里的 principal 和 KDC 是一致的。4.3 会话始终保持与策略拉取细节Ranger UI 的登录态保存在各自 Ranger 节点的 Tomcat session 里两个节点之间不会同步 session。为了让同一用户尽量不跳来跳去我在 Haproxy 配置里加了stick on src。这个办法对付内部管理员或少量用户足够因为 RLE 管理员的来源 IP 段就那几段。如果后续用户量变大、来源 IP 分散可以再改 HTTP 模式下的 Cookie 粘性。插件侧拉策略不一定需要会话保持。插件是纯 API 调用每次请求都带 Kerberos 认证即使用 “source” 粘性也能正常工作。插件真正要关注的是策略服务地址统一指向逻辑域名。HDFS、Hive、YARN 等组件的ranger.plugin.*.policy.rest.url属性都要改成https://ranger-ha.example.com:6182改完记得重启组件或刷新动态配置。还有一个小小的注意点Ranger 的审计信息默认会写到 HDFS 或 Solr不经过 Haproxy。所以审计不存在负载均衡问题。但如果你们的 Ranger Audit 导出或告警功能把 Ranger Admin 的地址写死了也需要检查。反正原则很简单所有“客户端访问 Ranger”的地方都走 HaproxyRanger 自身访问外部依赖数据库、HDFS、KDC不用走。4.4 curl 验证与常见 401 排查配好之后用命令行验证是最直接的。如果集群里已经有很多组件按 SPNEGO 方式跑可以在任意安装了krb5-workstation的客户端上执行curl --negotiate -u : -k https://ranger-ha.example.com:6182/login.jsp -v执行前先kinit一个用户比如rangerlookupEXAMPLE.COM。curl --negotiate会自动取当前凭证缓存里的 TGT并向 KDC 请求HTTP/ranger-ha.example.com的服务票据。如果返回 200说明整条链路通了如果返回 401重点看-v输出中WWW-Authenticate头以及后端 Ranger 的/var/log/ranger/admin/日志。常见的 401 就两种客户端没有票据或者票过期了。这种通常在输出里能看到 “GSSAPI error: An invalid name was supplied” 之类先kinit刷新凭证即可。后端的 keytab 里没有当前访问域名对应的 principal。这种通常能看到 “Server not found in Kerberos database” 或 “Unable to obtain credentials” 的关键字。回到第 4.2 节检查 keytab。如果你在浏览器里访问ranger-ha.example.com时不断弹认证框也可以在浏览器按 F12 看请求头的Authorization如果有Negotiate开头的长串说明客户端已经开始尝试认证了问题多半还是后端 keytab 不对。如果浏览器根本没有弹认证框也没有Authorization头大概率是浏览器没有加入 Kerberos 信任域或者访问地址不在受信站点列表里。5. 踩坑清单与问题速查表5.1 常见问题速查表我把自己和同事在实施过程中踩过的坑整理成了一张表按概率从高到低排列。遇到问题先对着表定位大部分都能在十分钟内找到方向。现象可能原因排查与解决办法浏览器访问 Haproxy 地址反复弹 Kerberos 认证但登录不了后端 Ranger 节点缺少逻辑域名对应的 keytab或 Ambari 配置里的 principal 没改在任一 Ranger 节点节点执行 klist -kt 查看 keytab确认包含 HTTP/ranger-ha.example.com检查 Ambari 中 SPNEGO 配置HAProxy 后端显示 DOWNRanger UI 一直转圈健康检查路径返回非 200或后端端口不通curl 后端节点的 /login.jsp 看实际状态码调整 httpchk 路径用 telnet 检查 6080/6182 端口管理员登录 Ranger 后刷新页面就掉线两台 Ranger 的 Tomcat session 不共享请求落在了不同节点在 Haproxy backend 中配置 stick on src或改为 cookie 粘性Ranger 插件报 GSS failure 或无法拉取策略插件侧的 policy.rest.url 仍指向单台 Ranger 主机名改为 https://ranger-ha.example.com:6182重启插件所在服务Ranger Admin 日志里有 “invalid keytab” 或 “keytab read failed”keytab 文件权限不对或路径变化确认运行 Ranger 用户有读权限Ambari 配置里的 keytab 路径和实际文件一致Haproxy stats 页面能打开但后端始终显示 MAINT配置里健康检查端口和实际服务端口不一致检查 server 行的端口是否对应 Ranger 的真实监听端口MAINT 多半是地址写错Kerberos 认证时好时坏且和时间告警一起出现节点时钟漂移检查 chrony 状态统一 NTP 时钟后重新 kinit5.2 几条掏心窝的实操建议第一Haproxy 这台机器本身如果只有一份配置它自己也是一个单点。虽然这一期讲的是安装但规划的时候就要想好冗余。后续可以用 Keepalived 再托管一个浮动 IP或者再起一台备用 Haproxy。别等线上 Haproxy 进程挂了才考虑。第二健康检查别看不上 TCP check。很多团队一上来就想做 HTTPS 的深度健康检查结果因为证书、SSL 握手、预期状态码的问题后端一会 DOWN 一会 UP最后反而把流量搞乱了。先用 TCP check 保命再慢慢优化成大拿级别的 HTTP 检查这样最稳。第三配置变更一定要走灰度。Haproxy reload 很容易但改 stick 策略、超时时间这些参数会影响在线用户。我在生产上一般是先haproxy -c -f检查语法再systemctl reload haproxy做平滑重载。注意是 reload 不是 restartrestart 会造成连接闪断。第四日志一定要留好。Haproxy 日志默认可能是local0需要配 rsyslog 才能落到文件。别等排查时才想起来。Ranger 侧的日志、KDC 的日志、Haproxy 的日志三者对齐才能快速找出问题是在认证环节还是负载均衡环节。最后再说一个我深有体会的点Ranger HA 这个事技术上卡人的往往不是 Haproxy 的语法也不是 Ambari 怎么部署第二台 Ranger而是你有没有把“访问域名、Kerberos principal、后端 keytab”这三件事在规划阶段就理顺。很多团队上来先装 Haproxy然后开 Kerberos等到 401 一片才回头补 principal来回折腾两三天。前期把这个三角关系想清楚后面就是按照步骤填参数的问题了。我这边现在跑着的这套方案已经经历了 Ranger Admin 单节点维护重启、Haproxy reload、KDC 密钥轮换等几次操作期间插件拉策略没有中断Ranger UI 登录也没有因为这个负载均衡层出过幺蛾子。后续如果想接着往下写可以讲讲第二台 Ranger Admin 手工部署的细节以及故障切换时后端健康检查的实际表现。这篇就当是 Ranger HA 的“第一章”把地基打扎实。