服务器的负载均衡之LVS实现
Linux Virtual Server (LVS) 是构建高性能、高可用服务器集群的核心基础设施级解决方案，它工作于Linux内核层，通过高效的请求分发机制，将访问流量智能调度到后端多台真实服务器，实现负载均衡与容错，是大型网站、关键业务系统的基石。
LVS的核心优势与工作原理
LVS的核心价值在于其内核级转发性能，区别于工作在应用层（如Nginx、HAProxy）的负载均衡器，LVS的IP负载均衡技术在内核空间完成数据包处理，避免了用户态与内核态切换的开销，具备超高的吞吐量和极低的延迟，能轻松应对百万级并发连接,尤其适合处理海量静态内容请求或作为上游调度器。
其核心组件包括：
- 负载调度器 (Director Server / Load Balancer)：运行LVS内核模块的服务器，对外提供虚拟IP (VIP),负责接收客户端请求并根据预设规则进行分发。
- 真实服务器池 (Real Server Pool)：实际处理用户请求的后端服务器集群，运行真实应用（Web、应用服务器、数据库等）。
- 共享存储 (可选)：为保证后端服务器状态一致（如会话、文件），常使用NFS、分布式存储等。
LVS的四种关键工作模式剖析
LVS通过不同工作模式实现流量调度,各有适用场景：
-
VS/NAT (Virtual Server via Network Address Translation)
- 原理：调度器修改请求包的目标IP为后端Real Server IP，并将源IP改为自身IP；Real Server返回的响应包需先回到调度器，调度器再将源IP改回VIP,目标IP改回客户端IP。
- 优点：Real Server只需配置私有IP,对网络环境要求低。
- 缺点：调度器成为响应出口瓶颈；Real Server需将默认网关指向调度器（或配置策略路由）；不支持端口映射（请求端口必须与Real Server端口一致）。
- 场景：小型环境或测试,不推荐大规模生产。
-
VS/TUN (Virtual Server via IP Tunneling)
- 原理：调度器将原始请求包封装在IP隧道包（新IP头）中发送给Real Server；Real Server解包处理后，直接使用原始包的源IP（客户端IP）和目标IP（VIP）构建响应包返回给客户端。
- 优点：响应流量不经过调度器，性能高；Real Server可跨网段部署。
- 缺点：Real Server需支持IP隧道协议（需加载
ipip或tunnel模块）；部署配置相对复杂；隧道封装增加额外开销。 - 场景：Real Server分散在不同机房或需绕过调度器直接响应客户端的场景。
-
VS/DR (Virtual Server via Direct Routing) – 生产首选
- 原理：调度器和Real Server位于同一物理网段，共享VIP，调度器仅修改请求包的目标MAC地址为选中的Real Server MAC，IP层不变，Real Server需在loopback接口配置VIP，并通过ARP抑制避免响应客户端ARP请求，Real Server处理请求后,直接使用VIP作为源IP响应客户端。
- 优点：性能最高（仅修改MAC，开销极小）；响应流量不经过调度器。
- 缺点：要求调度器和Real Server在同一物理二层网络（或通过VLAN/策略路由打通）；Real Server需配置ARP抑制（通过
arp_ignore和arp_announce内核参数）。 - 场景：绝对主流生产环境选择，适用于对性能要求极高的Web服务、API网关等。
-
VS/FULLNAT (阿里扩展模式，后被广泛采用)
智能调度算法：匹配业务需求的关键
LVS提供多种调度算法，决定如何从服务器池中选择Real Server：
-
静态算法：
rr(Round Robin)：轮询分发,绝对公平但忽略服务器负载。wrr(Weighted Round Robin)：加权轮询，按权重比例分配请求,适应性能差异。sh(Source Hashing)：源地址哈希，同一客户端请求固定发往某Real Server，利于会话保持（非强一致）。dh(Destination Hashing)：目标地址哈希,常用于缓存集群。
-
动态算法（基于实时负载）：
lc(Least-Connection)：最少连接数,将新请求发给当前活跃连接数最少的服务器。wlc(Weighted Least-Connection)：加权最少连接数（默认推荐），结合服务器权重和连接数,实现更优负载均衡。sed(Shortest Expected Delay)：最短期望延迟，考虑活动连接数,适用于长连接场景。nq(Never Queue)：配合sed,优先选择空闲服务器。lblc/lblcr：基于局部性的最少连接/带复制,用于缓存定向。
生产建议： wlc 通常是最通用、效果良好的选择，对于需要会话保持的应用，sh 是常用方案。
实战部署与高可用架构 (VS/DR模式为例)
-
环境准备：
- 调度器 (Director)： 2台（主备），配置VIP (e.g., 192.168.1.100)。
- 真实服务器 (Real Server)： N台，配置实际服务 (e.g., Nginx/Tomcat)，并在loopback接口配置VIP (
ifconfig lo:0 192.168.1.100 netmask 255.255.255.255 broadcast 192.168.1.100 up)。 - 网络： 所有服务器位于同一物理二层网络。
-
Real Server关键配置 (ARP抑制)：
# /etc/sysctl.conf 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 # 执行 sysctl -p 生效
-
调度器配置 (ipvsadm)：
# 安装 yum install ipvsadm -y # CentOS/RHEL apt install ipvsadm -y # Ubuntu/Debian # 添加VIP服务 (TCP 80) ipvsadm -A -t 192.168.1.100:80 -s wlc # 添加Real Server (假设2台：192.168.1.11, 192.168.1.12) ipvsadm -a -t 192.168.1.100:80 -r 192.168.1.11:80 -g # -g 表示 DR模式 ipvsadm -a -t 192.168.1.100:80 -r 192.168.1.12:80 -g # 查看配置 ipvsadm -Ln
-
构建高可用 (Keepalived)：
单一调度器存在单点故障,使用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 your_secure_pass } virtual_ipaddress { 192.168.1.100/24 # VIP } } virtual_server 192.168.1.100 80 { delay_loop 6 lb_algo wlc lb_kind DR persistence_timeout 0 # 会话保持时间，按需设置 protocol TCP real_server 192.168.1.11 80 { weight 1 TCP_CHECK { connect_timeout 3 retry 3 delay_before_retry 3 } } real_server 192.168.1.12 80 { weight 1 TCP_CHECK { connect_timeout 3 retry 3 delay_before_retry 3 } } } - 备调度器： 类似主配置，
state改为BACKUP，priority设为低于主的值（如90）。
- 主调度器 (
高级优化与运维要点
-
连接追踪 (Conntrack) 优化：
LVS NAT/FullNAT模式依赖内核nf_conntrack,高并发下易满导致丢包。- 增大
net.netfilter.nf_conntrack_max和net.netfilter.nf_conntrack_buckets。 - 缩短
net.netfilter.nf_conntrack_tcp_timeout_超时时间。 - VS/DR模式无此问题！
- 增大
-
时间戳问题 (VS/DR)：
某些Real Server OS默认发送TCP Timestamp选项，可能导致客户端忽略调度器发来的SYN+ACK（因timestamp更旧），关闭Real Server的TCP Timestamp：sysctl -w net.ipv4.tcp_timestamps=0
-
监控与日志：
- 使用
ipvsadm -Ln --stats --rate实时监控连接数、包速率。 - 结合Zabbix/Prometheus监控调度器及各Real Server状态、性能指标。
- Keepalived日志 (
/var/log/messages或journalctl) 是排查高可用切换的关键。
- 使用
-
安全加固：
- 调度器启用严格防火墙，仅开放必要端口（VIP、管理端口、Keepalived VRRP通信端口）。
- Real Server配置防火墙,拒绝除调度器和必要管理流量外的访问。
LVS在现代架构中的定位
虽然云原生时代涌现了Ingress Controller (如Nginx Ingress, Traefik) 和Service Mesh (如Istio)，LVS因其无与伦比的内核转发性能和稳定性,在以下场景不可替代：
- 作为基础设施层入口，承接超大规模流量,为上层Ingress或Service提供高可用VIP。
- 高性能四层负载均衡需求（如数据库读写分离中间件、游戏服务器）。
- 对资源消耗极度敏感的环境。
LVS是构建高性能、高可用服务器集群的基石，深入理解其核心模式（特别是VS/DR）、调度算法，结合Keepalived实现高可用，并掌握关键优化点，是架构师和运维工程师的核心能力，它并非陈旧技术,而是在云原生架构中承担底层流量调度重任的关键组件。
您在实际项目中是如何选择LVS工作模式和调度算法的？在云环境下，是倾向于使用云厂商的LB还是自建LVS集群？欢迎分享您的架构经验与挑战！
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/lvs%e5%a6%82%e4%bd%95%e5%ae%9e%e7%8e%b0%e8%b4%9f%e8%bd%bd%e5%9d%87%e8%a1%a1%ef%bc%9f%e6%9c%8d%e5%8a%a1%e5%99%a8%e9%9b%86%e7%be%a4%e9%85%8d%e7%bd%ae%e5%ae%9e%e6%88%98%e8%a7%a3%e6%9e%90/
