两台服务器装LVS，最省事的做法是让一台当调度器（Director）、另一台当真实服务器（RealServer），用DR模式先跑通流量；如果业务不能断，再在这两台机器上各装一个Keepalived做双机热备，两台互为备份。软件层面不花钱，ipvsadm 加 keepalived 两个包就够，真正的门槛在网卡参数和VIP处理上。
两台服务器LVS安装前先想清楚分工
很多人一上手就敲 yum install，结果装完发现两台机器谁都不肯接流量，问题不在软件，在架构，LVS本质是四层转发器，它自己不处理业务，所以两台服务器的角色必须先定死。
三种常见分工方式
- 一台Director + 一台RS：最典型的两台起步方案，调度器只转发，业务全部压在后端，适合先验证连通性，但后端只有一台，没有负载可言。
- 两台都做RS，其中一台兼任Director：LVS支持把VIP和业务绑在同一台机器上，小流量场景能省一台设备，代价是调度器一挂业务也跟着挂。
- 两台都做Director，互为主备，RS放在别处：这是生产环境的常规形态，如果你手上真的只有两台，可以先把业务跑在备用机上，等第三台到位再横向扩。
业内专家指出,两台服务器部署LVS更多是验证和过渡，真正承载生产流量时，通常建议调度层至少2台、后端至少2台，形成最小可用集群。
系统与内核要确认的三件事
- 内核是否带IPVS模块，主流的 CentOS 7/8、Rocky、Ubuntu 20.04 以上内核都已内置，用
lsmod | grep ip_vs看一眼，没加载就modprobe ip_vs。 - 两台机器是否同网段，DR模式要求调度器和真实服务器在同一广播域，跨网段只能走NAT或TUN。
- VIP选哪个地址，VIP不能和任何一台机器的物理IP重复，否则ARP会打架。
两台服务器LVS-DR模式怎么配置
DR模式是两台服务器场景下最推荐的,因为它只改写目的MAC、不改IP包内容，真实服务器直接把响应回给客户端，调度器压力小。
第一步：装软件包
CentOS/Rocky 系：
yum install -y ipvsadm keepalived systemctl enable --now keepalived
Ubuntu/Debian 系：
apt update && apt install -y ipvsadm keepalived
ipvsadm 是规则管理工具，keepalived 负责健康检查和VIP漂移，只装 ipvsadm 也能跑，但规则重启即丢，没人帮你做故障切换。
第二步：真实服务器上的ARP抑制
这一步是整个DR模式最容易翻车的地方,真实服务器必须“闭嘴”，不能对外宣称自己拥有VIP，否则客户端的请求会被它直接抢走。
cat >> /etc/sysctl.conf <<EOF net.ipv4.conf.all.arp_ignore = 1 net.ipv4.conf.all.arp_announce = 2 net.ipv4.conf.lo.arp_ignore = 1 net.ipv4.conf.lo.arp_announce = 2 EOF sysctl -p
接着把VIP绑到回环口,子网掩码必须写 255.255.255：
ip addr add 192.168.10.100/32 dev lo
顺便确认业务端口在监听：ss -lntp | grep 80。
第三步：调度器上加转发规则
ipvsadm -A -t 192.168.10.100:80 -s wrr ipvsadm -a -t 192.168.10.100:80 -r 192.168.10.12:80 -g ipvsadm -Ln
-g 表示DR模式，-s wrr 是加权轮询，两台机器调试阶段后端只有一台，先用 rr 也能验证通不通。
第四步：调度器上把VIP加上
ip addr add 192.168.10.100/24 dev eth0
然后从客户端 curl http://192.168.10.100，能返回后端页面就说明转发链路成立，如果超时，八成是真实服务器上的ARP参数没生效，或者VIP掩码写成了24位。
LVS和Nginx做负载均衡哪个适合两台服务器
这是搜索量很高的对比问题,两者不冲突，甚至经常一起用，但定位完全不同。
| 对比项 | LVS | Nginx |
|---|---|---|
| 工作层次 | 四层（TCP/UDP） | 七层（HTTP/HTTPS） |
| 吞吐能力 | 强，内核态转发 | 中，用户态处理 |
| 规则灵活度 | 按IP端口转发，看不懂URL | 可按域名、路径、Header分流 |
| 证书卸载 | 不支持 | 支持 |
| 配置难度 | 偏底层，要懂网络 | 配置文件直观 |
| 适合场景 | 大流量入口、数据库代理 | 网站入口、API网关 |
行业共识认为,两台服务器规模不大时，直接上Nginx做反向代理更省心；只有当单机连接数成为瓶颈、或者需要代理非HTTP协议时，LVS的价值才明显，实际部署中常见组合是：LVS在最前面做四层入口，后面挂两台Nginx做七层分发。
让LVS不宕机：Keepalived双机热备
两台服务器都装LVS时,Keepalived负责两件事：一是定时探测后端端口，挂了就摘掉；二是主备之间靠VRRP协议抢VIP。
keepalived.conf 的核心骨架
主调度器 /etc/keepalived/keepalived.conf：
vrrp_instance VI_1 {
state MASTER
interface eth0
virtual_router_id 51
priority 100
advert_int 1
authentication {
auth_type PASS
auth_pass lvs2026
}
virtual_ipaddress {
192.168.10.100/24
}
}
virtual_server 192.168.10.100 80 {
delay_loop 6
lb_algo wrr
lb_kind DR
persistence_timeout 50
protocol TCP
real_server 192.168.10.12 80 {
weight 1
TCP_CHECK {
connect_timeout 3
nb_get_retry 3
delay_before_retry 3
}
}
}
备用机把 state 改成 BACKUP、priority 调成 90，其余保持一致，防火墙记得放行VRRP协议，firewall-cmd --add-protocol=vrrp --permanent 或直接开 ip protocol 112。
验证漂移是否真的生效
在主调度器上执行 systemctl stop keepalived，然后在备用机 ip addr | grep 192.168.10.100，能看到VIP出现即为成功，再把主节点拉起，它会按优先级把VIP抢回来，这一步必须做，不做等于没配。
简米云两台ECS装LVS要额外买负载均衡吗
这是云上用户问得最多的问题,答案是：技术上不需要，LVS装在ECS里就能跑，软件零成本；但你要接受几个现实约束。
云上部署的三个额外注意点
- VIP不属于你的VPC，云平台不认你随便填的私网IP，必须用辅助私网IP功能申请一个弹性网卡地址，再绑到实例上。
- 后端回包路径，DR模式要求真实服务器和客户端路由可达，云上安全组如果不放行，回包会被丢，TCP_CHECK 探活通过但业务不通，多半卡在这里。
- 成本对比，自建LVS只花ECS和带宽的钱，一台入门规格月付几十到上百元不等；托管负载均衡按实例规格和流量计费，通常需要额外支出，但免去运维和故障排查，近年来的普遍做法是：日活不高、团队有运维能力就自建，业务波动大、不想半夜接告警就买托管。
上线前必须过的验证清单
ipvsadm -Ln能看到virtual server和real server，状态不是InAct- 后端机器
ss -lntp端口在听，本机curl 127.0.0.1:80正常 - 调度器
ipvsadm -Lnc能看到ESTABLISHED连接 - 停掉后端一次,看连接是否按预期被剔除、恢复后是否自动加回
- 主备切换演练至少做一轮,记录切换耗时
关于两台服务器安装LVS的常见问答
两台服务器装LVS，必须用DR模式吗？
不是必须,但最推荐，NAT模式要调度器做地址转换，回包全部经过它，两台机器时调度器很容易成为瓶颈；TUN模式需要后端支持IP隧道，配置更重，同网段的两台机器用DR，配置少、性能好。
装完LVS后客户端访问VIP超时，先查什么？
按顺序查三处：真实服务器上的 arp_ignore/arp_announce 是否真写进了内核参数并 sysctl -p 生效；VIP是否绑在 lo 上且掩码为 /32；调度器上的转发规则是否带了 -g 参数，三类原因能覆盖绝大多数超时案例。
两台服务器能不能都当调度器又都跑业务？
可以,LVS允许VIP和真实服务共存于同一台机器，两台互为主备时也能各自承载业务，但这样一旦某台宕机，调度和业务会同时丢失一半容量，所以只适合内部系统或测试环境，不适合对外生产。
两台服务器装LVS的核心不是命令多难,而是角色划分、ARP抑制和VIP归属这三件事想清楚；把DR模式跑通、Keepalived切换验证完，剩下的就是按业务量逐步扩后端。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/lvs%e5%9c%a8%e4%b8%a4%e5%8f%b0%e6%9c%8d%e5%8a%a1%e5%99%a8%e4%b8%8a%e6%80%8e%e4%b9%88%e5%ae%89%e8%a3%85%ef%bc%8c%e8%b4%9f%e8%bd%bd%e5%9d%87%e8%a1%a1%e6%80%8e%e4%b9%88%e9%85%8d%e7%bd%ae/
