LVS如何实现负载均衡?服务器集群配置实战解析
服务器的负载均衡之LVS实现
LinuxVirtualServer(LVS)是构建高性能、高可用服务器集群的核心基础设施级解决方案,它工作于Linux内核层,通过高效的请求分发机制,将访问流量智能调度到后端多台真实服务器,实现负载均衡与容错,是大型网站、关键业务系统的基石。
LVS的核心优势与工作原理
LVS的核心价值在于其内核级转发性能,区别于工作在应用层(如Nginx、HAProxy)的负载均衡器,LVS的IP负载均衡技术在内核空间完成数据包处理,避免了用户态与内核态切换的开销,具备超高的吞吐量和极低的延迟,能轻松应对百万级并发连接,尤其适合处理海量静态内容请求或作为上游调度器。
其核心组件包括:
- 负载调度器(DirectorServer/LoadBalancer):运行LVS内核模块的服务器,对外提供虚拟IP(VIP),负责接收客户端请求并根据预设规则进行分发。
- 真实服务器池(RealServerPool):实际处理用户请求的后端服务器集群,运行真实应用(Web、应用服务器、数据库等)。
- 共享存储(可选):为保证后端服务器状态一致(如会话、文件),常使用NFS、分布式存储等。
LVS的四种关键工作模式剖析
LVS通过不同工作模式实现流量调度,各有适用场景:
-
VS/NAT(VirtualServerviaNetworkAddressTranslation)
- 原理:调度器修改请求包的目标IP为后端RealServerIP,并将源IP改为自身IP;RealServer返回的响应包需先回到调度器,调度器再将源IP改回VIP,目标IP改回客户端IP。
- 优点:RealServer只需配置私有IP,对网络环境要求低。
- 缺点:调度器成为响应出口瓶颈;RealServer需将默认网关指向调度器(或配置策略路由);不支持端口映射(请求端口必须与RealServer端口一致)。
- 场景:小型环境或测试,不推荐大规模生产。
-
VS/TUN(VirtualServerviaIPTunneling)
- 原理:调度器将原始请求包封装在IP隧道包(新IP头)中发送给RealServer;RealServer解包处理后,直接使用原始包的源IP(客户端IP)和目标IP(VIP)构建响应包返回给客户端。
- 优点:响应流量不经过调度器,性能高;RealServer可跨网段部署。
- 缺点:RealServer需支持IP隧道协议(需加载
ipip或tunnel模块);部署配置相对复杂;隧道封装增加额外开销。 - 场景:RealServer分散在不同机房或需绕过调度器直接响应客户端的场景。
-
VS/DR(VirtualServerviaDirectRouting)–生产首选
- 原理:调度器和RealServer位于同一物理网段,共享VIP,调度器仅修改请求包的目标MAC地址为选中的RealServerMAC,IP层不变,RealServer需在loopback接口配置VIP,并通过ARP抑制避免响应客户端ARP请求,RealServer处理请求后,直接使用VIP作为源IP响应客户端。
- 优点:性能最高(仅修改MAC,开销极小);响应流量不经过调度器。
- 缺点:要求调度器和RealServer在同一物理二层网络(或通过VLAN/策略路由打通);RealServer需配置ARP抑制(通过
arp_ignore和arp_announce内核参数)。 - 场景:绝对主流生产环境选择,适用于对性能要求极高的Web服务、API网关等。
-
VS/FULLNAT(阿里扩展模式,后被广泛采用)
- 原理:调度器同时修改请求包的源IP(改为调度器自身IP)和目标IP(改为RealServerIP),响应包返回调度器时,调度器再反向修改源IP(VIP)和目标IP(客户端IP),这是对标准NAT的扩展。
- 优点:彻底解除RealServer与调度器需同网段的限制(跨网段部署灵活);RealServer无需特殊配置(网关指向其本地路由器即可)。
- 缺点:调度器需处理双向流量,成为潜在瓶颈;需要额外内核模块支持(非原生LVS,需打补丁或使用阿里云内核/腾讯云TGW等)。
- 场景:大型云环境、IDC多网段部署、需要极高灵活性的场景。
智能调度算法:匹配业务需求的关键
LVS提供多种调度算法,决定如何从服务器池中选择RealServer:
-
静态算法:
rr(RoundRobin):轮询分发,绝对公平但忽略服务器负载。wrr(WeightedRoundRobin):加权轮询,按权重比例分配请求,适应性能差异。sh(SourceHashing):源地址哈希,同一客户端请求固定发往某RealServer,利于会话保持(非强一致)。dh(DestinationHashing):目标地址哈希,常用于缓存集群。
-
动态算法(基于实时负载):
lc(Least-Connection):最少连接数,将新请求发给当前活跃连接数最少的服务器。wlc(WeightedLeast-Connection):加权最少连接数(默认推荐),结合服务器权重和连接数,实现更优负载均衡。sed(ShortestExpectedDelay):最短期望延迟,考虑活动连接数,适用于长连接场景。nq(NeverQueue):配合sed,优先选择空闲服务器。lblc/lblcr:基于局部性的最少连接/带复制,用于缓存定向。
生产建议:wlc通常是最通用、效果良好的选择,对于需要会话保持的应用,sh是常用方案。
实战部署与高可用架构(VS/DR模式为例)
-
环境准备:
- 调度器(Director):2台(主备),配置VIP(e.g.,192.168.1.100)。
- 真实服务器(RealServer):N台,配置实际服务(e.g.,Nginx/Tomcat),并在loopback接口配置VIP(
ifconfiglo:0192.168.1.100netmask255.255.255.255broadcast192.168.1.100up)。 - 网络:所有服务器位于同一物理二层网络。
-
RealServer关键配置(ARP抑制):
#/etc/sysctl.confnet.ipv4.conf.all.arp_ignore=1net.ipv4.conf.all.arp_announce=2net.ipv4.conf.lo.arp_ignore=1net.ipv4.conf.lo.arp_announce=2#执行sysctl-p生效 -
调度器配置(ipvsadm):
#安装yuminstallipvsadm-y#CentOS/RHELaptinstallipvsadm-y#Ubuntu/Debian#添加VIP服务(TCP80)ipvsadm-A-t192.168.1.100:80-swlc#添加RealServer(假设2台:192.168.1.11,192.168.1.12)ipvsadm-a-t192.168.1.100:80-r192.168.1.11:80-g#-g表示DR模式ipvsadm-a-t192.168.1.100:80-r192.168.1.12:80-g#查看配置ipvsadm-Ln -
构建高可用(Keepalived):
单一调度器存在单点故障,使用Keepalived实现主备调度器自动故障转移。- 主调度器(
keepalived.conf):vrrp_instanceVI_1{stateMASTERinterfaceeth0#网卡名virtual_router_id51priority100advert_int1authentication{auth_typePASSauth_passyour_secure_pass}virtual_ipaddress{192.168.1.100/24#VIP}}virtual_server192.168.1.10080{delay_loop6lb_algowlclb_kindDRpersistence_timeout0#会话保持时间,按需设置protocolTCPreal_server192.168.1.1180{weight1TCP_CHECK{connect_timeout3retry3delay_before_retry3}}real_server192.168.1.1280{weight1TCP_CHECK{connect_timeout3retry3delay_before_retry3}}} - 备调度器:类似主配置,
state改为BACKUP,priority设为低于主的值(如90)。
- 主调度器(
高级优化与运维要点
-
连接追踪(Conntrack)优化:
LVSNAT/FullNAT模式依赖内核nf_conntrack,高并发下易满导致丢包。- 增大
net.netfilter.nf_conntrack_max和net.netfilter.nf_conntrack_buckets。 - 缩短
net.netfilter.nf_conntrack_tcp_timeout_超时时间。 - VS/DR模式无此问题!
- 增大
-
时间戳问题(VS/DR):
某些RealServerOS默认发送TCPTimestamp选项,可能导致客户端忽略调度器发来的SYN+ACK(因timestamp更旧),关闭RealServer的TCPTimestamp:sysctl-wnet.ipv4.tcp_timestamps=0 -
监控与日志:
- 使用
ipvsadm-Ln--stats--rate实时监控连接数、包速率。 - 结合Zabbix/Prometheus监控调度器及各RealServer状态、性能指标。
- Keepalived日志(
/var/log/messages或journalctl)是排查高可用切换的关键。
- 使用
-
安全加固:
- 调度器启用严格防火墙,仅开放必要端口(VIP、管理端口、KeepalivedVRRP通信端口)。
- RealServer配置防火墙,拒绝除调度器和必要管理流量外的访问。
LVS在现代架构中的定位
虽然云原生时代涌现了IngressController(如NginxIngress,Traefik)和ServiceMesh(如Istio),LVS因其无与伦比的内核转发性能和稳定性,在以下场景不可替代:
- 作为基础设施层入口,承接超大规模流量,为上层Ingress或Service提供高可用VIP。
- 高性能四层负载均衡需求(如数据库读写分离中间件、游戏服务器)。
- 对资源消耗极度敏感的环境。
LVS是构建高性能、高可用服务器集群的基石,深入理解其核心模式(特别是VS/DR)、调度算法,结合Keepalived实现高可用,并掌握关键优化点,是架构师和运维工程师的核心能力,它并非陈旧技术,而是在云原生架构中承担底层流量调度重任的关键组件。
您在实际项目中是如何选择LVS工作模式和调度算法的?在云环境下,是倾向于使用云厂商的LB还是自建LVS集群?欢迎分享您的架构经验与挑战!