1. LVS-DR模式核心原理与ARP问题解析第一次接触LVS-DR模式时我被它的三角传输特性惊艳到了——客户端请求经过负载均衡器但响应却直接从真实服务器返回客户端。这种设计巧妙避开了性能瓶颈但随之而来的ARP问题却让我踩了不少坑。数据包流向全景图可以这样理解当客户端访问VIP时Director Server调度器只修改MAC地址就将请求转发给Real Server。这里有个关键细节Real Server需要在lo接口配置VIP但必须避免响应VIP的ARP请求。我曾在测试环境忘记配置arp_ignore参数结果导致整个局域网ARP表紊乱所有请求在调度器和真实服务器之间乱跳。ARP问题的本质在于IP地址冲突。在DR模式中调度器和所有真实服务器都有相同的VIP这违反了网络通信的基本原则。解决方案是通过两个内核参数arp_ignore1只响应目标IP是本机接口IP的ARP请求arp_announce2始终使用接口网络的最佳本地地址作为ARP源地址# Real Server上的关键配置 echo 1 /proc/sys/net/ipv4/conf/all/arp_ignore echo 2 /proc/sys/net/ipv4/conf/all/arp_announce2. 生产环境LVS-DR集群部署实战去年为某电商大促部署LVS-DR集群时我们采用了以下架构调度器Dell R740xd双万兆网卡真实服务器20台华为2288H V5VIP192.168.10.100会话保持使用wrr加权轮询算法关键配置步骤调度器配置# 添加VIP ip addr add 192.168.10.100/32 dev eth0 # 禁用ICMP重定向 echo 0 /proc/sys/net/ipv4/conf/all/send_redirects # 配置IPVS规则 ipvsadm -A -t 192.168.10.100:80 -s wrr ipvsadm -a -t 192.168.10.100:80 -r 192.168.10.21 -g -w 3 ipvsadm -a -t 192.168.10.100:80 -r 192.168.10.22 -g -w 2真实服务器配置# 在lo接口添加VIP ip addr add 192.168.10.100/32 dev lo # 设置ARP参数 sysctl -w net.ipv4.conf.all.arp_ignore1 sysctl -w net.ipv4.conf.all.arp_announce2 # 添加本地路由 route add -host 192.168.10.100 dev lo常见踩坑点忘记在真实服务器上禁用VIP的ARP响应导致IP冲突真实服务器的网关错误指向了调度器应该指向实际网关没有配置本地路由导致响应包被丢弃3. Keepalived高可用架构深度优化单点故障是负载均衡系统的大忌。我们通过Keepalived实现主备切换但实际部署中发现默认配置有几个隐患问题1脑裂问题 当主备节点间心跳检测异常时可能出现双主情况。我们的解决方案vrrp_script chk_ipvs { script /usr/bin/killall -0 ipvsadm interval 2 weight 50 } vrrp_instance VI_1 { state MASTER interface eth0 virtual_router_id 51 priority 100 advert_int 1 authentication { auth_type PASS auth_pass 1111 } virtual_ipaddress { 192.168.10.100/32 dev eth0 } track_script { chk_ipvs } notify_master /etc/keepalived/notify.sh master notify_backup /etc/keepalived/notify.sh backup }问题2真实服务器健康检查 默认TCP检查不够精准我们改用HTTP检查virtual_server 192.168.10.100 80 { delay_loop 6 lb_algo wrr lb_kind DR protocol TCP real_server 192.168.10.21 80 { weight 3 HTTP_GET { url { path /health status_code 200 } connect_timeout 3 nb_get_retry 3 delay_before_retry 3 } } }4. 性能调优与故障排查指南在百万级QPS的场景下我们总结出以下优化经验内核参数调优# 调度器参数 net.ipv4.tcp_tw_reuse 1 net.ipv4.tcp_fin_timeout 30 net.core.somaxconn 32768 # 真实服务器参数 net.ipv4.tcp_syncookies 1 net.ipv4.tcp_max_syn_backlog 8192IPVS调优技巧使用-b模式处理SYN洪水攻击对于长连接服务调整ipvsadm --set tcp tcpfin udp超时参数使用-p参数实现会话保持典型故障案例现象客户端偶发连接重置排查ipvsadm -lcn发现部分真实服务器SYN_RECV状态堆积原因真实服务器backlog队列满解决调整net.core.somaxconn和net.ipv4.tcp_max_syn_backlog最后分享一个真实监控案例某次大促期间LVS集群突然出现大量TCP重传。通过tcpdump -i eth0 tcp[tcpflags] (tcp-syn|tcp-ack) tcp-syn抓包发现是某个真实服务器的网卡带宽跑满及时下线该节点后系统恢复稳定。