如何在台湾cn2服务器 上实现高可用集群与自动故障切换

1. 概述

本指南针对在台湾 CN2 网络环境（机房或云主机）上构建高可用（HA）架构，示范主流方案：Keepalived 实现 VRRP 浮动 IP，HAProxy 做前端负载与健康检查，后端使用 GlusterFS 同步文件，数据库建议使用 Galera 或主从复制。本文以 Ubuntu 20.04 / Debian 为示例，命令可适配到 CentOS/AlmaLinux（yum/dnf）。

2. 环境与前置条件

准备至少 4 台机器：lb1、lb2（负载/浮动 IP）和 app1、app2（后端应用）。操作系统更新并开放必要端口（TCP 80/443、TCP 3306、VRRP 协议 112 占用协议号）。确保厂商/机房支持在同一网段或通过 BGP/路由将浮动 IP 转发到任一节点，若云提供商不支持 VRRP，则使用云 API 切换弹性 IP（后文说明）。

3. 网络与浮动 IP 规划

选择一个虚拟 IP（VIP），例如 10.0.0.100，保证与两台 LB 主机处于同一二层或路由可达。若为云环境（如需通过 provider API 变更 IP），准备 API Key 并写自动切换脚本。建议为每台主机固定管理 IP，并设置正确的防火墙规则及 sysctl 转发设置（例如 net.ipv4.ip_nonlocal_bind=1）。

4. 安装与配置 Keepalived（在 lb1/lb2）

步骤：1) 安装：sudo apt update && sudo apt install -y keepalived；2) 编辑 /etc/keepalived/keepalived.conf，示例配置：

vrrp_instance VI_1 { state MASTER # 在 lb1 上为 MASTER，lb2 为 BACKUP interface eth0 virtual_router_id 51 priority 100 # lb1=100, lb2=90 advert_int 1 authentication { auth_type PASS auth_pass yourpass } virtual_ipaddress { 10.0.0.100 } }\n

3) 在两台上设置不同 priority，lb1 高；4) 修改 sysctl: echo "net.ipv4.ip_nonlocal_bind=1" >> /etc/sysctl.conf && sysctl -p；5) 启动并启用：systemctl enable --now keepalived。验证：在 MASTER 节点 ip addr show 可见 VIP，模拟 MASTER down 后，BACKUP 自动接管。

5. 安装与配置 HAProxy（在 lb 节点）

1) 安装：sudo apt install -y haproxy；2) 编辑 /etc/haproxy/haproxy.cfg，示例：frontend http_front bind 10.0.0.100:80 default_backend web_back backend web_back balance roundrobin option httpchk GET /health server app1 10.0.0.11:80 check inter 2000 rise 2 fall 3 server app2 10.0.0.12:80 check inter 2000 rise 2 fall 3

3) 确保后端应用实现 /health 健康检查返回 200；4) 启动并启用：systemctl enable --now haproxy；5) 在 lb 上配合 keepalived 保证 VIP 绑定到对外节点，HAProxy 监听 VIP。

6. 后端文件同步：GlusterFS 快速部署（app1/app2）

1) 安装：sudo apt install -y glusterfs-server；2) 在两台建立信任：gluster peer probe app2；3) 创建卷并启动：gluster volume create gv0 replica 2 transport tcp app1:/data/brick app2:/data/brick; gluster volume start gv0；4) 在两台或第三方挂载：mount -t glusterfs app1:/gv0 /var/www/html；5) 将应用静态文件放在该挂载点，实现文件同步与容灾。

说明：若业务对一致性有更高要求，可考虑 NFS + DRBD + Pacemaker 或对象存储替代，但 GlusterFS 对多数 web 场景已足够。

7. 数据库高可用（建议 Galera Cluster 或主从+VIP）

推荐使用 MariaDB Galera：1) 在三台节点上安装 MariaDB 与 Galera 插件；2) 配置 wsrep_cluster_address 为所有节点列表；3) 启动第一个节点 bootstrap，然后依次加入其他节点；4) 对于只两节点的情况，需第三个仲裁节点（arbiter 或 SST 提供者），或使用云主机做仲裁。若无法部署 Galera，则使用主从复制并将 VIP 绑定到主库（由 Pacemaker+Corosync 管理 MySQL 服务与 VIP）。

8. 故障切换测试与自动化脚本

测试流程：1) 在 MASTER LB 上停止 keepalived：systemctl stop keepalived，观察 VIP 是否漂移到 BACKUP；2) 在 app1 上停止服务，确认 HAProxy 将流量切到 app2；3) 模拟磁盘损坏或网络断开，演练恢复步骤。自动化脚本建议包含：1) 基于 cloud API 的弹性 IP 切换脚本（若 VRRP 不可用）；2) keepalived 的 notify-script 与 trackscript 用于在检测到后端服务异常时自动降级 VIP；示例 trackscript 在 /etc/keepalived/track.sh 内检测 haproxy 状态并 exit 0/1。

9. 监控、告警与日常运维要点

部署 Prometheus + Grafana 监控 HA 状态（keepalived exporter、HAProxy exporter、node exporter、Gluster exporter、mysqld exporter），并设置告警（如 VIP 丢失、后端 healthcheck 失败、磁盘使用率高）。建议做常态化演练（每月一次）并记录 SOP：节点接管流程、回切策略、数据恢复步骤和联系人清单。

10.

问：在台湾 CN2 网络上使用 VRRP 会遇到的常见网络限制是什么？

答：常见限制包括机房/云提供商不允许二层广播的 VRRP（例如公有云隔离租户网络）、BGP/路由策略导致浮动 IP 无法在任意节点生效、ISP 对 VRRP 协议或 ARP 过滤。解决办法是：事先确认提供商支持；若不支持，使用云 API 动态绑定弹性 IP 或使用 BGP 路由并由路由器宣布 VIP。

11.

问：如何在 Keepalived 中把 VIP 从 MASTER 自动降级到 BACKUP 时避免会话中断？

答：结合 HAProxy 的后端健康检查与会话保持策略（sticky session）可减少中断；使用更高级的会话共享（如 Redis/session DB）或部署多活架构（多台后端共同对外）可避免单点会话丢失。并且在切换前通过 notify-script 先将流量从即将下线的节点 drain（haproxy set server ... drain），确保现有会话完成再释放 VIP。

12.

问：如果我的云平台不支持浮动 IP，我应优先选择哪种自动故障切换策略？

答：优先使用云厂商提供的弹性 IP/弹性网卡接口并通过 API 自动解绑/绑定；另一可行方案是使用全局负载均衡（GLB）或 DNS 级别健康检查（配合低 TTL）。如果需要 L2/L3 层故障切换并且云不支持 VRRP，则结合云 API 的脚本化切换是最常见且稳定的做法。

来源：如何在台湾cn2服务器 上实现高可用集群与自动故障切换