[Step1] Haproxy 规划与环境安装Kylin V10

# 一、环境规划与角色定位

# 1.1 本章范围说明

本章只讲 Haproxy 的安装与配置，用于给 Ranger Admin 提供统一访问入口。

范围界定

不讨论 Keepalived
不实现 Haproxy 自身高可用
不涉及 Ranger Admin 的安装过程

# 1.2 现有 Ambari 环境说明

当前集群已通过 Ambari 完成 Ranger 的部署规划：

角色	主机
Ranger Admin	dev2
Ranger Admin	dev3

说明如下：

Ranger Admin 服务由 Ambari 统一管理
Admin 服务端口使用默认 6080
dev2 / dev3 仅作为 后端服务节点 存在

最终效果：

# 1.3 Haproxy 在当前环境中的定位

Haproxy 在本环境中承担的职责非常明确：

Client
  |
Haproxy
  |
Ranger Admin
  |—— dev2:6080
  |—— dev3:6080

1
2
3
4
5
6
7

定位总结

Haproxy 只负责 请求转发
不参与 Ranger 组件管理
不干预 Ambari 的服务生命周期

# 二、Haproxy 安装与配置

# 2.1 节点选择原则

在现有 Ambari 集群中，Haproxy 作为 Ranger Admin 的统一访问入口，需要单独部署在一台独立节点上，而不是与后端服务混部。

# 2.1.1 节点部署目标

本次节点选择的核心目标如下：

目标	说明
职责清晰	Haproxy 只负责请求转发，不参与 Ranger 服务管理
架构解耦	访问入口与后端服务分离，避免角色混叠
易于扩展	后续可引入 Keepalived 或多入口方案

# 2.1.2 节点选择基本要求

部署 Haproxy 的节点需要满足以下条件：

与 dev2 / dev3 网络可达 能直接访问 Ranger Admin 服务端口（默认 6080）
节点运行稳定 作为访问入口，对稳定性要求高，但资源消耗较低
不与 Ranger Admin 混部 避免将入口节点与后端服务节点绑定在一起

设计说明

这里选择“独立节点”，并不是因为性能瓶颈，而是为了 明确访问入口与服务节点的职责边界。

# 2.1.3 统一访问域名规划

为了保证 Ranger Admin 的访问地址在整个集群中保持一致，本环境中统一规划如下访问域名：

ranger-ha.hadoop.com

该域名在本章中承担的角色是：

项目	说明
访问对象	Ranger Admin
实际指向	Haproxy 节点
使用范围	Ranger UI / Ranger API / Ambari 配置

笔记

在本章中，仅使用 hosts 文件完成解析，不涉及 DNS、VIP 或 Keepalived。

# 2.1.4 /etc/hosts 配置要求（必须）

在 dev2 / dev3 两台 Ranger Admin 节点 上，需要提前完成 /etc/hosts 配置，确保该域名可以被正确解析。

# Ranger Admin 统一访问入口
<haproxy-ip>  ranger-ha.hadoop.com

1
2

配置完成后，需保证以下行为成立：

验证项	期望结果
域名解析	`ranger-ha.hadoop.com` 能正确解析
访问路径	Ranger Admin 可通过该域名访问
主机名一致性	不出现主机名漂移

必须提前完成

如果 dev2 / dev3 无法解析 ranger-ha.hadoop.com，可能导致：

Ranger Admin 返回的访问地址不一致
Kerberos / SPNEGO 场景下主机名校验失败
后续接入 Haproxy 后出现隐性访问问题

因此，该 hosts 配置属于前置必备条件。

# 2.2 安装 Haproxy

dnf install -y haproxy

安装完成后确认版本：

haproxy -v

# 2.3 haproxy.cfg 配置说明

配置文件路径：

/etc/haproxy/haproxy.cfg

# 2.3.1 全量配置示例

global
  log /dev/log local0
  maxconn 4096
  daemon

defaults
  log global
  mode http
  option httplog
  option dontlognull

  timeout connect 5s
  timeout client  120s
  timeout server  120s
  timeout http-request 10s
  timeout http-keep-alive 10s

frontend ranger_http_front
  bind 0.0.0.0:16080
  mode http

  option forwardfor
  http-request set-header X-Forwarded-Proto http
  http-request set-header X-Forwarded-Port 16080

  stats enable
  stats uri /haproxy?stats
  stats refresh 5s

  default_backend ranger_admin_pool

backend ranger_admin_pool
  mode http
  balance roundrobin

  cookie LB insert indirect nocache

  option httpchk GET /login.jsp
  http-check expect status 200

  server radmin_dev2 dev2:6080 check inter 3s fall 3 rise 2 cookie 1
  server radmin_dev3 dev3:6080 check inter 3s fall 3 rise 2 cookie 2

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42

# 2.4 关键配置点拆解

# 2.4.1 后端 Ranger Admin 节点

server radmin_dev2 dev2:6080
server radmin_dev3 dev3:6080

1
2

笔记

dev2 / dev3 即 Ambari 中已规划的 Ranger Admin 节点， Haproxy 仅作为访问入口，不改变其部署形态。

# 2.4.2 会话保持配置（必须）

cookie LB insert indirect nocache

警告

Ranger Admin UI 强依赖 Session。若未开启会话保持，常见现象包括：

登录态频繁丢失
页面操作异常
Kerberos / SPNEGO 场景不稳定

# 2.4.3 健康检查方式

option httpchk GET /login.jsp

不只是端口存活
直接校验 Ranger UI 页面可访问性

# 三、服务启动与访问验证

# 3.1 配置校验

haproxy -c -f /etc/haproxy/haproxy.cfg

# 3.2 启动并设置自启

systemctl enable --now haproxy
systemctl reload haproxy

1
2

# 3.3 状态页验证

systemctl status haproxy

#Haproxy #Ranger Admin #Ambari #Kylin V10 #负载均衡

[Step2] 统一访问域名的 Kerberos 票据生成→