企业官网建设流程全解析

在Ambari管理的Hadoop集群里，一旦开启Kerberos，Ranger 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，或者只有一两台 Ranger，Keepalived 确实可以做一层冗余，但它本身不做负载均衡和健康检查。Ranger Admin 的两个实例都可以服务，更需要的其实是 Haproxy 这种能把请求按一定策略分发、并且能感知后端存活的组件。Keepalived 可以和 Haproxy 配合，但不是替代关系。在初期规划里，我们先上一台 Haproxy 统一接入，后续如果担心 Haproxy 自身单点，再用 Keepalived 给 Haproxy 做 VIP 漂移也不迟。

1.3 架构拓扑与依赖关系

我们最后落地的拓扑大概是这样的：

• 两台 Ranger Admin 节点，分别部署 ranger-admin 相关服务，两个实例连接同一个 Ranger 数据库。
• 一台 Haproxy 节点，作为所有 Ranger 请求的统一入口。对外提供逻辑域名，例如ranger-ha.example.com。
• Haproxy 监听 6080（HTTP）和 6182（HTTPS）两个端口，把流量转发给两台 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：

端口方面，Ranger Admin 默认的 HTTP 端口是 6080，HTTPS 端口是 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.9，Ambari 用的是 2.7.x，Ranger 版本是 2.0.1，Haproxy 用的是自带 yum 源的 1.8.27。如果你们的 Ambari 是 2.6 甚至 3.x，Ranger 端口和配置项可能会有差异，但整体思路一致。

安装 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_OPENSSL=1和USE_PCRE=1，不然后面想用 SSL 和正则功能会缺依赖。

2.3 Kerberos principal 与 keytab 规划

这是整篇博文里最容易被忽视、但最影响成败的部分。先理解一个核心关系：客户端访问 Ranger Admin 时，如果走 Kerberos SPNEGO，那么它请求的服务 principal 是根据访问 URL 里的主机名生成的。用户浏览器访问的是https://ranger-ha.example.com:6182，那么浏览器向 KDC 请求的服务票据就是HTTP/ranger-ha.example.com@EXAMPLE.COM，而不是HTTP/ranger1.example.com@EXAMPLE.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/Debian，apt 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.jsp，TCP 后端用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 部署方案

实际操作步骤可以总结成这样：

1. 在 KDC 上创建HTTP/ranger-ha.example.comprincipal 并导出 keytab。
2. 将 keytab 分发到ranger1和ranger2，路径统一放同一个，方便管理。
3. 修改 Ambari 中 Ranger Admin 的 Kerberos/SPNEGO 配置，把 keytab 路径和 principal 都指过去。
4. 重启 Ranger Admin 服务，确认/etc/security/keytabs或自定义目录里的 keytab 权限正确，日志里没有 “GSSException” 或 “invalid keytab” 类报错。

这里有一个细节：如果一台 Ranger 之前已经用真实主机名HTTP/ranger1.example.com跑过 SPNEGO，Ambari 里可能残留了旧配置。改的时候要确认服务端使用的 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”的地方都走 Haproxy，Ranger 自身访问外部依赖（数据库、HDFS、KDC）不用走。

4.4 curl 验证与常见 401 排查

配好之后，用命令行验证是最直接的。如果集群里已经有很多组件按 SPNEGO 方式跑，可以在任意安装了krb5-workstation的客户端上执行：

curl --negotiate -u : -k https://ranger-ha.example.com:6182/login.jsp -v

执行前先kinit一个用户，比如rangerlookup@EXAMPLE.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 常见问题速查表

我把自己和同事在实施过程中踩过的坑整理成了一张表，按概率从高到低排列。遇到问题先对着表定位，大部分都能在十分钟内找到方向。

5.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 不是 restart，restart 会造成连接闪断。

第四，日志一定要留好。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 的“第一章”，把地基打扎实。