VPS知识分享站先说结论：两台云服务器做高可用，核心不是装个 Keepalived，而是解决四件事：浮动 IP 能不能用、健康检查准不准、脑裂怎么防、数据怎么同步。云环境经常不支持组播和免费 ARP，很多方案最后要落到云负载均衡或 DNS 切换上。
先明确目标：
- RTO：故障后多久恢复，30 秒和 5 分钟方案完全不同
- RPO：能接受丢多少数据，决定要不要同步复制
- 范围：只是入口高可用，还是应用、数据库都要
两种常见架构
主备：一台跑业务，一台待命，故障时切 VIP 或 DNS。简单、成本低，但备机平时闲着。
双活：两台都跑业务，前面用负载均衡分流。资源利用率高，但要求应用无状态、数据层能处理并发写。
Keepalived 怎么做
vrrp_instance VI_1 {
state BACKUP
interface eth0
virtual_router_id 51
priority 100
advert_int 1
authentication {
auth_type PASS
auth_pass 换成长密码
}
virtual_ipaddress {
10.0.0.100/24
}
}两台配置一样，优先级不同；优先级高的持有 VIP，心跳断了就切换。注意 virtual_router_id 不能和同网段其他集群冲突，密码别用默认值。
云上 VIP 的坑
传统 IDC 里 Keepalived 靠 VRRP 组播和免费 ARP 漂移 IP；云网络通常不支持组播，或者不允许随意发 ARP。结果就是：配置看起来正常，VIP 切不过去，或者切过去回不来。
- 先确认云厂商是否支持“浮动 IP/高可用 IP”
- 不支持就用云负载均衡，或 DNS + 健康检查切换
- 用 DNS 切换时把 TTL 调低，接受分钟级 RTO
健康检查
别只 ping 主机。主机活着但应用挂了，切了也没用。健康检查脚本要检查：
#!/bin/bash
curl -fsS --max-time 2 http://127.0.0.1:8080/health || exit 1
systemctl is-active --quiet nginx || exit 1脚本返回非 0 就降优先级，触发切换。检查频率和超时要调好，太敏感会抖，太迟钝恢复慢。
脑裂怎么防
两台都以为自己是主，就是脑裂。常见原因：心跳网络断、防火墙拦了 VRRP、优先级配置错。防法：
- 心跳走独立网卡或独立链路
- 加仲裁节点或检查网关可达性
- 切换脚本做幂等，避免重复挂载、重复启动
- 数据库只允许一个写节点，别让两边都写
数据层怎么办
应用无状态可以随便切，数据层不行。数据库做主从，应用写主读从；Redis 做主从或哨兵；文件放对象存储或共享盘。切换时先确认主从延迟，别把旧主的数据覆盖掉。
切换演练
- 停掉主机服务，观察 VIP/DNS 是否切换
- 确认应用、数据库、队列都恢复
- 记录切换耗时和失败点
- 恢复主机，确认不会来回抖
- 每季度演练一次
没演练过的高可用，等于没有。
常见坑
- 云网络不支持 VRRP，Keepalived 起不来
- 健康检查只 ping，应用挂了不切
- 脑裂后两边都写数据库
- VIP 切了但 ARP 缓存没更新
- 备机配置和主机不一致，切过去跑不起来
DNS 切换方案
云网络不支持 VIP 时，可以用 DNS + 健康检查：监控发现主机故障，把域名解析切到备机。TTL 调到 60 秒以内，切换通常在几分钟内生效。缺点是依赖 DNS 缓存，RTO 比 VIP 长。
双活的数据一致性
双活最难的是数据。两台都写同一个数据库，容易冲突；写各自本地库，又要同步。常见做法是应用无状态、数据库单主、文件放对象存储，所谓“双活”只活应用层。
监控和告警
监控 VIP 是否在主机、健康检查是否通过、切换次数、主从延迟。切换次数突然变多，说明网络或应用在抖，先查原因再谈优化。
成本
主备要两台机器，双活也要两台，加上负载均衡、共享存储和监控，成本至少翻倍。按业务中断损失算，值不值要提前想清楚。
备机要不要跑业务
备机可以跑只读、备份、监控、批处理，但别跑会抢 CPU、内存和带宽的核心业务。切换时备机要能立刻接管，资源得留出来。
切换脚本注意
切换脚本要幂等：重复执行不会重复挂载、重复启动、重复改 DNS。脚本里加锁和日志，出问题能看出执行到哪一步。
演练频率
至少每季度一次，业务大促前再加一次。演练要覆盖主机宕机、网络断开、数据库主从切换三种场景。
VIP 漂移失败怎么查
先看 Keepalived 日志和 VRRP 状态，再确认云网络是否允许组播和免费 ARP；然后查防火墙、安全组和网卡。很多“配置没问题”的切换失败，最后都是云平台不支持 VRRP。
高可用的目标是业务不中断，不是机器不宕机；机器一定会坏，关键是坏了能多快恢复。
切换时间要写进 SLA，和业务方对齐预期。
最后，别把高可用做成“看起来有”，切换不动等于没有。
演练记录要存档。
高可用是持续投入，不是一次性项目。
，别忘。
常见问题 FAQ
Q1：两台机器一定要 Keepalived 吗？
不一定。云负载均衡、DNS 故障转移都能做入口高可用，取决于云厂商能力和你能接受的 RTO。
Q2：Keepalived 在云上能用吗？
看网络。支持浮动 IP/组播的可以用；不支持的要用云产品，别硬配。
Q3：主备浪费一台机器吗？
是成本换可用性。备机可以跑只读任务、备份、监控，但别跑会抢资源的业务。
Q4：数据库怎么做高可用？
主从 + 自动切换（MHA/Orchestrator/云数据库），或直接用云数据库。自己搭要处理延迟和脑裂。
Q5：切换要多久？
Keepalived 秒级到几十秒；DNS 切换取决于 TTL，通常几分钟。按业务能接受的时间选方案。
总结
两台云服务器做高可用，先确认云网络支不支持 VIP，再定主备还是双活；健康检查要查应用，脑裂要有仲裁，数据层要有主从。最后，必须演练。
需要两台机器做切换演练，可以按小时开萤光云香港 CN2 VPS，先把 Keepalived 和健康检查跑通。
