两台服务器设置一个漂移IP，核心方案是部署keepalived软件，借助VRRP协议虚拟出一个浮动IP，这个IP在主备服务器之间自动漂移，对外始终可用。
漂移IP到底解决什么问题
先理解场景,你手上有两台服务器，一台跑业务，一台闲置，业务这台突然宕机了，用户访问的IP不变，但请求自动切到了另一台，这就是漂移IP（也叫浮动IP、VIP）的价值，它不是某个网卡上的固定IP，而是运行在keepalived这样的软件里，由主备服务器共同持有的虚拟地址。
行业内给的方案其实很统一：keepalived加VRRP协议，据行业共识，90%以上的自建高可用架构都跑在keepalived上，这是Linux生态里最成熟的漂移IP方案，它做的事儿很简单主服务器定时发送心跳包，备服务器收不到心跳，就立刻把VIP抢到自己身上，整个过程控制在1到3秒内。
keepalived vrrp配置漂移ip完整实操
配置漂移IP的核心是写好keepalived.conf文件，下面用的是CentOS系统，Ubuntu同样适用，命令差别不大。
两台服务器都装keepalived
yum install -y keepalived # CentOS apt install -y keepalived # Ubuntu
装完先别急着配置,记住一个原则：配置文件要从主备两侧分别编写，VRRP实例名字和虚拟IP必须完全一致，优先级不能一样。
主服务器配置
主服务器的/etc/keepalived/keepalived.conf这样写：
global_defs {
router_id LVS_MASTER
}
vrrp_instance VI_1 {
state MASTER
interface eth0 # 换成你实际网卡名
virtual_router_id 51
priority 100
advert_int 1
authentication {
auth_type PASS
auth_pass 123456
}
virtual_ipaddress {
192.168.1.100/24 dev eth0
}
}
priority是优先级,主服务器给100，备服务器要给低一点的数字，比如90，virtual_router_id在同一个网段内要保持唯一，如果别的keepalived集群用了51，你就得换52、53之类。
备服务器配置
备服务器除了state改成BACKUP,priority改成90，其他完全一致，注意备服务器的state一定写BACKUP，这样即使它先启动也不会抢占VIP，避免脑裂场景下的地址冲突。
启动验证
systemctl enable keepalived systemctl start keepalived ip addr show eth0
主服务器上能看到192.168.1.100/24绑定在eth0上，备服务器上这个IP不存在，手动停掉主服务器的keepalived：
systemctl stop keepalived
然后去备服务器上执行ip addr show eth0，3秒内VIP已经出现在备服务器上，这个漂移过程就完成了。
业务服务要跟着VIP走
VIP切过去了,但你的Nginx、MySQL这些服务不会自动跟着切，需要让keepalived监控业务进程，进程挂了就自动切VIP，在vrrp_instance里加一段：
vrrp_script check_nginx {
script "/etc/keepalived/check_nginx.sh"
interval 2
}
vrrp_instance VI_1 {
track_script {
check_nginx
}
}
核心就一行：
#!/bin/bash
if [ $(systemctl is-active nginx) != "active" ]; then
killall keepalived
fi
两台服务器做热备用什么方案
这里延展一下,两台服务器做热备，不只有keepalived一种方案，按场景选适合自己的。
Nginx加keepalived：最适合Web网关
适合做反向代理、API网关、静态资源服务的高可用，Nginx负责转发流量，keepalived负责IP漂移，具体架构是：两台Nginx服务器，VIP绑定在它们之间，请求先打到VIP，VIP落在哪台，Nginx就从哪台处理。
配置顺序有讲究：先装Nginx并确认业务正常，再配keepalived，很多新手先配keepalived，结果VIP漂过去了Nginx没起来，服务照样不可用，Nginx本身要把监听端口改为0.0.0.0:80，这样才能接收来自VIP的访问。
LVS加keepalived：扛高并发流量
只用两台服务器做LVS,是性价比很高的方案，Keepalived整合了LVS的配置管理，不需要额外装ipvsadm工具，VIP承载入口流量，两台LVS做负载均衡，后端挂真实业务服务器，二三十万并发以内，两台LVS加keepalived的组合足够撑住。
云厂商高可用IP方案：不想运维就交给云平台
酷番云和简米云有HAVIP（高可用虚拟IP）产品。HAVIP的精髓是能绑定到云服务器的主网卡和弹性网卡上，配合云平台的API自动切换，区别在于，自建keepalived得自己写脚本监控业务，云厂商HAVIP在控制台点几下手动绑定就行。
自建和云平台的区别主要在这几个维度：
| 对比项 | keepalived自建 | 云厂商HAVIP |
|---|---|---|
| 费用 | 服务器费用，无额外收费 |
免费创建，但占用配额 |
| 切换时间 | 1-3秒 | 秒级（通常在1秒内） |
| 维护成本 | 需要自己管理VRRP | 控制台操作，免运维 |
| 适用场景 | 物理机、混合云、IDC机房 | 纯云上环境 |
这两者还有一个选择标准：自建方案支持跨机房、跨地域，只要二层能通就能跑；HAVIP严格绑定同一可用区和同一VPC，所以混合云架构下的漂移IP，基本都得靠keepalived。
数据库做热备的漂移IP
两台MySQL或两台Redis做主从,也需要漂移IP让应用层无感知切换，MySQL双主模式加keepalived是常见架构，VIP漂移时主从切换脚本跟着执行，把备库提升为新的主库，这个场景要特别关注脑裂问题两台服务器都认为自己是主，都持有VIP，请求就会被打到两个节点上，解决思路是加fencing脚本，检测到对端存活但自己接收不到心跳时，主动关闭自身业务或释放VIP。
漂移IP切换后的验证清单
配置漂移IP不是配完就完事,要反复做演练，以下是完整的验证步骤：
验证VIP地址归属
- 在主服务器执行
ip addr show | grep 192.168.1.100，确认VIP存在 - 在备服务器执行同样的命令,确认VIP不存在
验证业务可用性
- 在外部机器执行
curl http://192.168.1.100/health，确认业务返回200 - 持续循环请求VIP地址,同时手动停掉主服务器
while true; do
curl -s -o /dev/null -w "%{http_code}n" http://192.168.1.100/
sleep 1
done
循环期间观察输出,最多出现2到3个错误请求，之后恢复200，说明切换和回切都正常。
检查日志确认切换原因
tail -f /var/log/messages | grep Keepalived
日志中会明确记录Entering BACKUP STATE或Entering MASTER STATE，判断切换是否由预期事件触发。
局域网里设置漂移IP注意什么
如果你在两台内网服务器上配漂移IP,有几件事比配置本身更容易踩坑：
网卡名称要一致，一台服务器网卡是ens33，另一台是eth0，keepalived配置里interface写死了，必须分别适配各自的网卡名。
防火墙要放行VRRP协议，VRRP跑在IP协议号112上，不是TCP也不是UDP，CentOS用firewalld的话：
firewall-cmd --direct --permanent --add-rule ipv4 filter INPUT 0 --protocol vrrp -j ACCEPT
这个不放行,两台服务器永远互相发现不了，VIP自然也不会漂移。
交换机端口如果开了端口安全或静态绑定，需要把VIP加入白名单，否则VIP广播出去的ARP包会被交换机直接丢弃，业务机器感知不到漂移。
云服务器漂移ip和高可用组区别
这个问题经常出现在生产环境选型时,云服务器漂移IP是思路上的差异高可用组是云厂商把两台云服务器放在同一个故障域里，底层物理机出问题时自动迁移到健康的物理机上，漂移IP则是把VIP绑定在服务器网卡上，故障时利用VRRP协议把VIP从故障机器切到存活机器上。
这两者并不互斥,生产环境最稳的做法是同时启用高可用组保证物理层面的故障切换，漂移IP保证应用层面的快速切换，双保险。
常见问题解答
漂移IP的切换时间一般多长？
默认配置下,keepalived每1秒发送一次心跳，连续3次未收到即触发切换，整体切换时间在3秒左右，如果业务对中断极其敏感，可以把advert_int调整为0.3秒，切换时间能压缩到1秒内，但对网络质量和CPU占用要求会提高。
主备服务器配置漂移IP后，VIP会出现在备机上吗？
正常情况下不会,备机的keepalived会监听主机的组播心跳，心跳正常时不进入MASTER状态，VIP只绑定在主服务器上，只有主服务器的keepalived挂掉或者链路中断，备机才会接管VIP。
一台物理服务器需要配置几张网卡接漂移IP？
最少一张网卡就够了,VIP绑定在物理网卡上做二层广播，同网段内生效，如果你需要VIP跨网段访问别的子网，需要交换机配置对应的ARP代理，并且业务服务器要明确路由指向，多网卡场景可以绑定在虚拟网桥或独立管理网卡上，但至少要保证VIP所在的网卡和业务通信链路是通的。
两台服务器配一个漂移IP,本质上就是用keepalived的VRRP协议模拟出一个不会宕机的虚拟网络入口，自建用keepalived，云上用HAVIP，核心都是让IP自身具备故障转移能力，把握好主备优先级、防火墙放行、业务监测这三个关键点，一个稳定的漂移IP架构就能落地。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/603556.html
