LVS如何实现负载均衡？服务器集群配置实战解析

服务器的负载均衡之LVS实现

Linux Virtual Server (LVS) 是构建高性能、高可用服务器集群的核心基础设施级解决方案，它工作于Linux内核层，通过高效的请求分发机制，将访问流量智能调度到后端多台真实服务器，实现负载均衡与容错，是大型网站、关键业务系统的基石。

加载中

负载均衡是什么？LVS的三种模式有什么区别？

架

架构师阿Q

1.1万--

原视频地址

LVS的核心优势与工作原理

LVS的核心价值在于其内核级转发性能，区别于工作在应用层（如Nginx、HAProxy）的负载均衡器，LVS的IP负载均衡技术在内核空间完成数据包处理，避免了用户态与内核态切换的开销，具备超高的吞吐量和极低的延迟，能轻松应对百万级并发连接,尤其适合处理海量静态内容请求或作为上游调度器。

其核心组件包括：

1. 负载调度器 (Director Server / Load Balancer)：运行LVS内核模块的服务器，对外提供虚拟IP (VIP),负责接收客户端请求并根据预设规则进行分发。
2. 真实服务器池 (Real Server Pool)：实际处理用户请求的后端服务器集群，运行真实应用（Web、应用服务器、数据库等）。
3. 共享存储 (可选)：为保证后端服务器状态一致（如会话、文件），常使用NFS、分布式存储等。

LVS的四种关键工作模式剖析

LVS通过不同工作模式实现流量调度,各有适用场景：

1. 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端口一致）。
   • 场景：小型环境或测试,不推荐大规模生产。

2. 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分散在不同机房或需绕过调度器直接响应客户端的场景。

3. 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网关等。

4. VS/FULLNAT (阿里扩展模式，后被广泛采用)

   • 原理：调度器同时修改请求包的源IP（改为调度器自身IP）和目标IP（改为Real Server IP），响应包返回调度器时，调度器再反向修改源IP（VIP）和目标IP（客户端IP）,这是对标准NAT的扩展。
   • 优点：彻底解除Real Server与调度器需同网段的限制（跨网段部署灵活）；Real Server无需特殊配置（网关指向其本地路由器即可）。
   • 缺点：调度器需处理双向流量，成为潜在瓶颈；需要额外内核模块支持（非原生LVS，需打补丁或使用阿里云内核/腾讯云TGW等）。
   • 场景：大型云环境、IDC多网段部署、需要极高灵活性的场景。

智能调度算法：匹配业务需求的关键

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模式为例)

1. 环境准备：

   • 调度器 (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)。
   • 网络： 所有服务器位于同一物理二层网络。

2. 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 生效

3. 调度器配置 (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

4. 构建高可用 (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）。

高级优化与运维要点

1. 连接追踪 (Conntrack) 优化：
   LVS NAT/FullNAT模式依赖内核nf_conntrack,高并发下易满导致丢包。

   • 增大net.netfilter.nf_conntrack_max和net.netfilter.nf_conntrack_buckets。
   • 缩短net.netfilter.nf_conntrack_tcp_timeout_超时时间。
   • VS/DR模式无此问题！

2. 时间戳问题 (VS/DR)：
   某些Real Server OS默认发送TCP Timestamp选项，可能导致客户端忽略调度器发来的SYN+ACK（因timestamp更旧），关闭Real Server的TCP Timestamp：

   sysctl -w net.ipv4.tcp_timestamps=0

3. 监控与日志：

   • 使用ipvsadm -Ln --stats --rate实时监控连接数、包速率。
   • 结合Zabbix/Prometheus监控调度器及各Real Server状态、性能指标。
   • Keepalived日志 (/var/log/messages或journalctl) 是排查高可用切换的关键。

4. 安全加固：

   • 调度器启用严格防火墙，仅开放必要端口（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集群？欢迎分享您的架构经验与挑战！