两台服务器集群成一台后，对外只需提供一个虚拟IP（VIP）作为唯一入口，物理IP仅用于内部通信，具体配置取决于你选的集群软件和架构。
服务器集群后的IP逻辑：为什么对外只有一个地址
两台服务器组成集群后,业务视角上它是一台“逻辑主机”，外部客户端、数据库连接串、域名解析都指向这个逻辑主机，而不是某台物理机器，这个逻辑主机的IP就是虚拟IP，行业共识认为它由集群软件统一管理，哪台机器当前承担主角色，VIP就绑定在哪台机器上，另一台机器则处于热备状态，时刻准备接管。
物理IP和VIP的分工：物理IP负责集群自身的心跳检测、数据同步、节点间通信；VIP负责对外提供服务，这种拆分能让故障切换对用户完全透明主节点宕机后，备用节点在数十秒内接管VIP，客户端可能只感觉到一次短暂的网络抖动。
两台服务器集群 虚拟IP怎么设置才算正确
Linux环境下的Keepalived配置方案
在Linux服务器上搭建双机集群,Keepalied是最常用的工具，它通过VRRP协议实现VIP的自动漂移，配置过程不复杂，但需要按顺序操作。
第一步：检查两台服务器的网络环境
确认两台机器的物理IP在同一网段,且能互相ping通，假设两台机器信息如下：
- 主节点：物理IP 192.168.1.10，主机名node1
- 备用节点：物理IP 192.168.1.11，主机名node2
- 需要对外提供的VIP：192.168.1.100
第二步：安装Keepalived
两台机器都需要安装,CentOS/RHEL系统使用：
yum install keepalived -yUbuntu/Debian系统使用：
apt install keepalived -y第三步：配置主节点
编辑主节点上的/etc/keepalived/keepalived.conf文件，核心配置段如下：
global_defs {
router_id node1
}
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
}
}第四步：配置备用节点
备用节点的配置与主节点整体相似,只有两处关键差异：state改为
BACKUP，priority改为90（比主节点低），router_id改为node2。
第五步：启动服务并验证
两台机器都启动服务后,在主节点上执行ip addr show eth0，能看到VIP绑定在eth0网卡上，此时从外部ping 192.168.1.100可以通，手动重启主节点的Keepalived服务，备用节点会在几秒内接管VIP，实现了IP的无缝漂移。
Windows Server环境的故障转移集群配置
Windows服务器做双机集群,使用系统自带的故障转移集群功能，配置路径为“服务器管理器→工具→故障转移集群管理器”，在创建集群的过程中，系统会引导你指定集群名称和虚拟IP地址，需要注意的是，Windows集群的VIP通常在创建集群网络时设置，后期可以在“角色→资源→IP地址”中修改。
核心操作路径：验证故障转移集群功能是否满足条件→创建集群→添加节点→配置集群网络→设置VIP→配置角色和依赖关系，Windows的图形界面比Linux直观，但底层逻辑一致VIP归属于集群资源组，跟随当前主节点在线。
双机热备VIP配置的完整步骤和验证方法
配置前需要确认的硬件与网络要素
两台服务器之间需要一条独立的心跳链路,这是整个集群稳定运行的基础。心跳链路负责节点间的健康监测和数据同步，如果复用业务网络，一旦交换机故障，两个节点会同时认为对方失联，继而发生“脑裂”两个节点同时抢占VIP，造成业务冲突。
建议使用双网卡方案：业务网卡走VIP和客户端流量，专用心跳网卡直连两台服务器（用网线直接对连，不经过交换机），心跳网卡可以设置独立的私有网段，比如主节点10.10.10.1，备用节点10.10.10.2。
配置过程中的关键参数对照表
| 配置项 | 主节点 | 备用节点 | 说明 |
|---|---|---|---|
| 物理IP | 168.1.10 | 168.1.11 | 用于业务网络通信 |
| 心跳IP | 10.10.1 | 10.10.2 | 用于节点间状态同步 |
| 虚拟IP | 168.1.100 | 168.1.100 | 对外唯一入口 |
| 优先级 | 100 | 90 | 数值大者优先成为主节点 |
| 抢占模式 | MASTER | BACKUP | 决定了故障恢复后的角色归属 |
验证VIP切换的实操方法
配置完成后,需要主动验证故障切换能力，而不是等真出问题时才发现配置有问题。
验证方法：在客户端持续ping VIP，同时强制关闭主节点的网络服务（如执行systemctl stop keepalived或直接拔掉主节点业务网线），观察ping的丢包情况正常情况下只会丢2-3个包，随后恢复通信，接着检查备用节点，VIP已经绑定到它的网卡上。
多个节点状态查询命令,Keepalived环境使用systemctl status keepalived或ip addr show，Windows集群在故障转移集群管理器中查看“节点→状态”即可。
服务器集群ip配置常见坑和分析
网卡名称不一致导致VIP绑定失败
两台服务器的网卡名称可能不同,比如主节点是eth0，备用节点是ens192，配置virtual_ipaddress时如果统一写dev eth0，备用节点会绑定失败，解法方式是在配置文件中使用dev eth0前先各自查看网卡名，或者不指定dev参数，让Keepalived自动选择路由网卡。
ARP缓存问题导致VIP切换后客户端无法访问
主节点宕机后,VIP虽然漂移到备用节点，但交换机或客户端的ARP缓存还记录着VIP与主节点物理MAC地址的对应关系，多数情况下，Keepalived会发送免费ARP通告更新缓存，但部分老旧交换机可能不响应，行业共识认为，在配置文件中增加garp_master_delay和garp_master_repeat参数可以强化ARP广播频率，解决这一隐患。
防火墙拦截VRRP协议报文
Keepalived的VRRP报文使用IP协议号112,很多服务器默认防火墙规则只放行TCP/UDP，导致两个节点收不到彼此的心跳报文，进而发生脑裂，配置时需要显式放行：
iptables -I INPUT -p vrrp -j ACCEPT或者使用firewalld：
firewall-cmd --add-protocol=vrrp --permanent
firewall-cmd --reload不同场景下怎样选择集群IP配置方案
数据库双机热备场景
数据库集群对IP切换时间极其敏感,通常要求RPO（恢复点目标）接近零，此场景推荐使用共享存储+VIP漂移方案，两台服务器连接同一台盘阵或分布式存储，Keepalived负责VIP管理，数据库服务（如MySQL主从或Oracle RAC）负责数据一致性，这类方案在金融行业广泛落地，单次切换时间通常控制在
30秒以内。
Web应用负载均衡场景
如果两台服务器同时对外提供服务,而不是一台空转备用，那就不适合用Keepalived的“主备模式”，而应使用负载均衡集群方案，Nginx + upstream模块或HAProxy可以将请求分发到两台服务器，VIP配置在负载均衡器上，后端两台机器只需保留物理IP。这种架构下，两台服务器都在干活，利用率提升一倍，但要求应用层必须支持无状态部署或会话共享。
跨机房容灾场景
两台服务器不在同一机房时,VIP配置面临更大挑战，跨机房网络延迟影响心跳判断，且需要依赖DNS切换或全局负载均衡（GSLB）技术，此场景的常规做法是放弃二层网络的VIP漂移，改用DNS解析切换机房A故障时，通过修改DNS记录将域名指向机房B的服务器IP，切换时间取决于DNS TTL设置，通常是5到10分钟，据相关行业报告显示，多数企业的跨机房容灾方案采用这种折中方式。
常见问题解答
两台服务器集群后，原来的固定IP还能正常使用吗？
可以,物理IP继续保留在各自服务器上，用于管理、监控和节点间通信，对外业务统一使用VIP，客户端的连接串、应用配置中的数据库地址等需要改为VIP，这样才具备故障切换能力。
双机热备的VIP切换时间大概需要多久？
Keepalived默认的advert_int参数为1秒，即主节点每1秒发送一次心跳报文，主节点故障后，备用节点需要等待3个心跳周期才会确认主节点失联，加上VRRP协议和系统接管时间，总切换时间通常在3秒到10秒之间，通过调小advert_int并启用抢占模式，可以缩短到2秒以内，但会相应增加心跳链路的负载。
两台服务器配置集群IP需要额外购买设备吗？
不需要,VIP本质上是软件层面的逻辑IP，不依赖额外硬件，两台服务器只需保证业务网卡和心跳网卡配置正确，操作系统和集群软件（Keepalived为开源免费软件）即可完成整个集群IP方案，如果预算允许，建议增加一台千兆交换机专门承载心跳链路，但用网线直连两台服务器同样可行。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/573237.html
