Ubuntu 运维系列 | 第 25 天：高可用与负载均衡——Keepalived 与 HAProxy 实战

当业务从单机走向多机、从「能用」走向「稳如磐石」时，运维面临两个绕不开的命题：一是单点故障——一台服务器挂了，整个服务就停了；二是性能瓶颈——一台服务器扛不住流量，需要把请求分散到多台机器。高可用（High Availability，HA）与负载均衡（Load Balancing，LB）正是解决这两个命题的两把钥匙。今天我们就用 Keepalived 与 HAProxy 这两款经典开源工具，在 Ubuntu 上搭建一套「前端负载 + 后端冗余」的高可用架构。

核心概念：高可用与负载均衡分别解决什么

要理解这套架构，先要分清三个容易混淆的角色。

负载均衡（LB）负责「分流」。它位于客户端与后端服务器之间，把大量请求按照一定策略分发给多台后端，从而提升整体吞吐能力，并能在某台后端故障时把流量摘除。常见的开源实现有 HAProxy、Nginx、LVS。

高可用（HA）负责「不挂」。它解决的是负载均衡器自身成为单点的问题——如果唯一的 HAProxy 挂了，分流再聪明也没用。高可用的经典做法是「主备」模式，通过 VRRP（虚拟路由冗余协议）提供一个虚拟 IP（VIP），主节点故障时备节点自动接管。Keepalived 就是 VRRP 的成熟实现。

健康检查则是二者的黏合剂。HAProxy 要持续探测后端存活，Keepalived 也要持续探测对端状态，才能在故障发生时做出正确决策。

一句话总结：HAProxy 管后端的负载均衡，Keepalived 管前端的故障切换，二者叠加才能形成一个没有单点的入口。

实战步骤：从安装到验证

第一步：安装 HAProxy 与 Keepalived

两台 Ubuntu 主机，一台作为主节点（192.168.1.10），一台作为备节点（192.168.1.11），规划一个 VIP 为 192.168.1.100。先在两台机器上安装软件：

sudo apt update
sudo apt install -y haproxy keepalived

安装完成后先关闭 HAProxy 默认的示例配置，避免干扰：

sudo systemctl stop haproxy
sudo systemctl disable haproxy

第二步：配置 HAProxy 负载均衡

编辑主节点的 HAProxy 配置，让它监听 VIP 所在端口，并把流量分发到两台后端 Web 服务器（192.168.1.20 与 192.168.1.21）：

sudo tee /etc/haproxy/haproxy.cfg > /dev/null <<'EOF'
global
    log /dev/log local0
    maxconn 4096

defaults
    mode http
    timeout connect 5s
    timeout client 50s
    timeout server 50s

frontend web_front
    bind 0.0.0.0:80
    default_backend web_back

backend web_back
    balance roundrobin
    option httpchk GET /health
    server web1 192.168.1.20:80 check inter 2s fall 3 rise 2
    server web2 192.168.1.21:80 check inter 2s fall 3 rise 2
EOF

这里 balance roundrobin 表示轮询策略，option httpchk 通过请求 /health 接口做健康检查，check inter 2s fall 3 rise 2 表示每 2 秒探测一次、连续 3 次失败摘除、连续 2 次成功恢复。把同样的配置复制到备节点，保持两边一致。

校验配置并启动：

sudo haproxy -c -f /etc/haproxy/haproxy.cfg
sudo systemctl enable --now haproxy

第三步：配置 Keepalived 实现 VIP 主备切换

在主节点编写 Keepalived 配置，声明一个 VRRP 实例并绑定 VIP：

sudo tee /etc/keepalived/keepalived.conf > /dev/null <<'EOF'
vrrp_script chk_haproxy {
    script "killall -0 haproxy"
    interval 2
    weight -20
}

vrrp_instance VI_1 {
    state MASTER
    interface eth0
    virtual_router_id 51
    priority 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1234
    }
    virtual_ipaddress {
        192.168.1.100/24
    }
    track_script {
        chk_haproxy
    }
}
EOF

关键点：vrrp_script 里的 killall -0 haproxy 用于检查 HAProxy 进程是否存活，一旦进程消失，weight -20 会让本节点优先级从 100 降到 80，从而自动把 VIP 让给备节点。备节点的配置基本一致，只需把 state MASTER 改为 state BACKUP、priority 100 改为 priority 90 即可。

第四步：启动并验证高可用切换

主备节点都启动 Keepalived：

sudo systemctl enable --now keepalived
sudo ip addr show eth0

正常情况下，主节点上能看到 VIP 192.168.1.100 绑定在 eth0 上。此时做一次故障演练：在主节点上手动停掉 HAProxy，观察 VIP 是否漂移到备节点：

sudo systemctl stop haproxy
# 在备节点上观察 VIP 是否接管
sudo ip addr show eth0

当主节点 HAProxy 恢复后，由于优先级回升到 100，VIP 会自动切回主节点（前提是未开启 nopreempt）。整个切换过程通常在一两秒内完成，对客户端几乎无感知。

常见问题

VIP 没有绑定到任何节点，怎么办？ 最常见的原因是 interface 网卡名写错。用 ip link 查看实际网卡名（Ubuntu 新版本多为 ens33、enp0s3 等），把配置里的 eth0 改成对应名称，并确认主备节点 virtual_router_id 一致、auth_pass 相同。

两个节点都认为自己拥有 VIP（脑裂）怎么办？ 脑裂往往由网络分区或防火墙阻断 VRRP 组播导致。VRRP 默认使用 224.0.0.18 的多播地址，需在防火墙放行，或改用单播 unicast_peer 指向对端真实 IP。

HAProxy 健康检查一直把后端标记为 DOWN？ 检查后端是否真的提供了 /health 路径并返回 200，必要时把 option httpchk 改为简单的 TCP 探测（option tcp-check），或去掉 httpchk 用 check 做端口级探测。

如何实现会话保持？ 在 backend 中加入 cookie SERVERID insert indirect nocache，并在 server 行添加 cookie web1，即可让同一客户端固定落到同一后端，适合需要 session 的业务。

总结

今天我们从「单点」与「瓶颈」两个问题出发，用 HAProxy 解决了后端的负载均衡与健康检查，用 Keepalived 的 VRRP 解决了前端负载均衡器自身的单点故障，最终拼出一个「VIP 入口 + 双活主备 + 多后端分流」的经典高可用架构。这套组合轻量、稳定、资料丰富，是中小规模业务落地高可用的首选方案。下一阶段你还可以考虑在 VIP 之外引入 DNS 轮询做多入口，或在后端层叠加数据库主从复制，把高可用延伸到数据层。

下期预告：第 26 天我们将进入「监控告警体系」的世界，用 Prometheus 采集指标、Grafana 可视化展示，为你的高可用架构装上「眼睛」与「警报器」，敬请期待。

文章版权归作者所有，未经允许请勿转载。

THE END