
前言:为什么需要LVS?——从企业成本与性能角度出发
在互联网业务快速发展的今天,企业面临着日益增长的用户访问量和数据处理需求。传统的解决方案是购买高性能的专用服务器(如小型机、大型机)来支撑业务,但这类服务器价格昂贵,动辄数十万甚至上百万,且扩展能力有限,一旦业务量再次上升,又需要再次投入巨资进行硬件升级,形成“成本螺旋”。
与此同时,单台服务器无论性能多强,都存在单点故障的风险——一旦这台服务器宕机,整个业务就会中断,造成巨大的经济损失和用户体验下降。
LVS(Linux Virtual Server)正是为了解决这些痛点而生。 它的核心思想是:用多台普通的、廉价的PC服务器,通过软件方式组合成一个高性能、高可用的虚拟服务器,对外提供与昂贵专用服务器相当甚至更强的服务能力。
从企业角度来看,LVS的意义体现在以下几个方面:
-
大幅降低成本:用多台普通x86服务器替代昂贵的小型机,硬件采购成本可降低数倍甚至数十倍。同时,Linux操作系统和LVS软件本身是开源的,无需支付昂贵的许可证费用。
-
高可用性保障:通过集群冗余机制,当某台后端服务器故障时,LVS会自动将流量切换到其他健康服务器,业务不中断,可用性从单点的99.9%提升到99.99%以上。
-
弹性扩展能力:业务增长时,只需向集群中添加新的普通服务器,无需替换原有设备,实现“按需扩容”,避免了过度投资。
-
资源利用率最大化:LVS能够将海量请求均衡地分发到各台服务器上,避免部分服务器空闲而部分过载,充分发挥每一台服务器的处理能力。
可以说,LVS的出现,让中小型企业也能用得起高并发架构,让大型企业能够灵活应对流量洪峰,是现代互联网架构中不可或缺的基石技术之一。
1 LVS-集群和分布式
1.1 集群
LVS(Linux Virtual Server)集群,即Linux虚拟服务器集群,是一个在Unix/Linux平台下实现负载均衡集群功能的系统。它由国人章文嵩博士在1998年开发,是中国国内最早出现的自由软件项目之一,现在LVS已经是Linux内核标准的一部分。LVS集群通过将多台服务器组织起来,共同对外提供服务,以提高系统的整体性能、可扩展性和高可用性。
1.1.1 集群的基本概念
-
集群(Cluster):为解决某个特定问题将多台计算机组合起来形成的单个系统。这些计算机在对外提供服务时,只表现为一个整体,只提供一个访问入口(如域名或IP地址)。
-
LVS集群:特指使用LVS技术构建的服务器集群,它通过负载均衡调度器将客户端请求分发到后端的多台服务器上,从而实现请求的均衡处理和高可用性。
1.1.2 集群的组成
LVS集群主要由以下几个部分组成:
-
调度器(Director/Dispatcher/Load Balancer):也称为代理服务器或前端服务器,负责接收客户端的请求,并根据预设的负载均衡算法将请求转发给后端服务器。调度器是集群对外提供服务的唯一入口。
-
后端服务器(Real Server/Backend Server):负责处理调度器转发过来的请求,并将处理结果返回给客户端。后端服务器可以是一台或多台,根据集群的规模和需求进行配置。
-
共享存储(可选):为后端服务器提供稳定、一致的文件存取服务,确保整个集群的统一性。共享存储可以使用NAS设备或提供NFS共享服务的专用服务器。
1.1.3 集群的工作模式
LVS集群支持多种工作模式,每种模式都有其特点和适用场景:
-
NAT(Network Address Translation)模式:
-
修改请求报文的目标IP地址和端口,将请求转发给后端服务器。
-
后端服务器的响应报文通过调度器返回给客户端,因此调度器容易成为瓶颈。
-
支持端口映射,可以修改请求报文的目标端口。
-
-
DR(Direct Routing)模式:
-
通过重新封装MAC地址来转发请求报文,不修改IP地址和端口。
-
响应报文由后端服务器直接返回给客户端,不经过调度器,减轻了调度器的压力。
-
需要确保前端路由器将目标IP为VIP的请求报文发往调度器。
-
-
TUN(Tunneling)模式:
-
在请求报文之外再封装一个新的IP报文首部,将报文通过隧道转发给后端服务器。
-
支持跨网络部署集群节点,但响应报文仍然由后端服务器直接返回给客户端。
-
需要后端服务器支持隧道功能。
-
1.1.4 集群常见的三种类型
LVS(Linux Virtual Server)集群常见的三种类型主要包括负载均衡集群(Load Balancing Cluster,简称LB)、高可用集群(High Availability Cluster,简称HA)和高性能运算集群(High Performance Computing Cluster,简称HPC)。
-
负载均衡集群(LB)
-
目标:以提高应用系统的响应能力,尽可能处理更多的访问请求,减少延迟为目标,获得高并发、高负载的整体性能。
-
特点:负载分配依赖于主节点的分流算法,将来自客户机的访问请求分担给多个服务器节点,从而缓解整个系统的负载压力。常见的负载均衡技术包括“DNS轮询”、“应用层交换”、“反向代理”等。在LVS中,负载均衡集群通过LVS调度器将访问请求分发给后端的真实服务器(Real Server),实现请求的分散处理和响应的收集。
-
-
高可用集群(HA)
-
目标:以提高应用系统的可靠性,尽可能地减少中断时间为目标,确保服务的连续性,达到高可用(HA)的容错效果。
-
特点:高可用集群通过冗余部署和资源监控,确保在单点故障发生时能够迅速切换到备用节点,保持服务不中断。常见的高可用技术包括“故障切换”、“双机热备”、“多机热备”等。在LVS中,高可用集群可以通过配置主备调度器实现热备份,确保在主调度器故障时能够自动切换到备调度器,保持负载均衡服务的连续性。
-
-
高性能运算集群(HPC)
-
目标:以提高应用系统的CPU运算速度,扩展硬件资源和分析能力为目标,获得相当于大型、超级计算机的高性能运算能力。
-
特点:高性能运算集群通过整合多个服务器的CPU、内存等计算资源,实现超大规模的计算任务处理。常见的高性能运算技术包括“云计算”、“网格计算”等。在LVS中,虽然LVS本身主要关注负载均衡和高可用,但高性能运算集群的概念可以启发我们在构建大规模计算环境时,考虑将LVS作为其中的一部分,通过负载均衡优化计算任务的分配和执行。
-
1.1.5 集群的优势
-
高性能:LVS工作在网络层,由操作系统内核直接处理流量,具有高效的数据处理能力。
-
高可用性:通过负载均衡和容错机制,确保集群在部分服务器故障时仍能对外提供服务。
-
可扩展性:支持动态添加或删除后端服务器,以适应业务规模的变化。
-
低成本:将多台低性能的服务器组合成一个高性能的服务器集群,降低了硬件成本。
为什么需要LVS?——从企业成本与性能角度出发
在互联网业务快速发展的今天,企业面临着日益增长的用户访问量和数据处理需求。传统的解决方案是购买高性能的专用服务器(如小型机、大型机)来支撑业务,但这类服务器价格昂贵,动辄数十万甚至上百万,且扩展能力有限,一旦业务量再次上升,又需要再次投入巨资进行硬件升级,形成“成本螺旋”。
与此同时,单台服务器无论性能多强,都存在单点故障的风险——一旦这台服务器宕机,整个业务就会中断,造成巨大的经济损失和用户体验下降。
LVS(Linux Virtual Server)正是为了解决这些痛点而生。 它的核心思想是:用多台普通的、廉价的PC服务器,通过软件方式组合成一个高性能、高可用的虚拟服务器,对外提供与昂贵专用服务器相当甚至更强的服务能力。
从企业角度来看,LVS的意义体现在以下几个方面:
-
大幅降低成本:用多台普通x86服务器替代昂贵的小型机,硬件采购成本可降低数倍甚至数十倍。同时,Linux操作系统和LVS软件本身是开源的,无需支付昂贵的许可证费用。
-
高可用性保障:通过集群冗余机制,当某台后端服务器故障时,LVS会自动将流量切换到其他健康服务器,业务不中断,可用性从单点的99.9%提升到99.99%以上。
-
弹性扩展能力:业务增长时,只需向集群中添加新的普通服务器,无需替换原有设备,实现“按需扩容”,避免了过度投资。
-
资源利用率最大化:LVS能够将海量请求均衡地分发到各台服务器上,避免部分服务器空闲而部分过载,充分发挥每一台服务器的处理能力。
可以说,LVS的出现,让中小型企业也能用得起高并发架构,让大型企业能够灵活应对流量洪峰,是现代互联网架构中不可或缺的基石技术之一。
1.2 分布式
1.2.1 LVS分布式架构
在分布式架构中,LVS通常作为负载均衡层(Load Balancer)部署在前端,负责接收客户端的请求并根据一定的调度算法将请求分发给后端的服务器集群。LVS分布式架构主要由以下几个部分组成:
-
负载均衡层(Load Balancer):
-
一台或多台LVS服务器构成负载调度器,也称为Director Server。
-
负责接收客户端的请求,并根据调度算法将请求分发给后端的Real Server。
-
监控Real Server的健康状况,动态地从LVS路由表中添加或剔除不健康的服务器。
-
-
服务器群组层(Server Array):
-
由一台或多台实际运行的应用服务器构成,也称为Real Server。
-
负责处理LVS分发过来的请求,并将处理结果返回给客户端。
-
Real Server之间可以通过有效网络互连,实现数据的共享和通信。
-
-
共享存储层(Shared Storage)(可选):
-
提供共享存储空间和内容一致性的存储区域,如数据库、OSS存储、FS文件服务器等。
-
在需要共享数据或资源的分布式系统中,共享存储层是不可或缺的。
-
2 LVS-NAT模式原理及部署方法
2.1 LVS-NAT模式原理
LVS-NAT(Linux Virtual Server Network Address Translation)模式是LVS(Linux Virtual Server)的一种工作模式,其原理基于网络地址转换(NAT)技术。在这种模式下,LVS服务器充当了网络中的网关角色,它接收来自客户端的请求,并根据配置的负载均衡算法选择一个合适的后端真实服务器(Real Server)来处理这些请求。然后,LVS服务器将请求报文中的目标IP地址和端口号修改为选中的Real Server的IP地址和端口号,并将修改后的请求报文转发给Real Server。Real Server处理完请求后,将响应报文发送给LVS服务器,LVS服务器再将响应报文中的源IP地址和端口号修改为虚拟IP地址(VIP)和客户端的IP地址,最后将响应报文发送给客户端。
具体来说,LVS-NAT模式的工作流程如下:
-
请求接收:LVS服务器监听虚拟IP地址上的特定端口,接收来自客户端的请求。
-
负载均衡:根据配置的负载均衡算法(如轮询、加权轮询等),LVS服务器选择一个合适的Real Server来处理请求。
-
地址转换:LVS服务器将请求报文中的目标IP地址和端口号修改为选中的Real Server的IP地址和端口号。
-
请求转发:将修改后的请求报文转发给选中的Real Server。
-
请求处理:Real Server处理请求,并将响应报文发送给LVS服务器。
-
响应转发:LVS服务器将响应报文中的源IP地址和端口号修改为VIP和客户端的IP地址,然后将响应报文发送给客户端。
2.2 LVS-NAT模式部署方法
2.2.1 配置LVS调度器
准备一台LVS服务器,配置两块网卡(eth0为NAT模式连接外网,eth1为仅主机模式连接后端服务器)。
[root@lvs ~]# ifconfig eth0 192.168.1.100 netmask 255.255.255.0 up
[root@lvs ~]# ifconfig eth1 192.168.2.1 netmask 255.255.255.0 up
[root@lvs ~]# route add default gw 192.168.1.1
[root@lvs ~]# echo 1 > /proc/sys/net/ipv4/ip_forward
[root@lvs ~]# cat /proc/sys/net/ipv4/ip_forward
1
永久开启IP转发:
[root@lvs ~]# echo "net.ipv4.ip_forward = 1" >> /etc/sysctl.conf
[root@lvs ~]# sysctl -p
net.ipv4.ip_forward = 1
若本地网卡并非此命名格式 可以先提前吧网卡更换格式 并且启用netconfig=0再作配置
验证网络配置:
[root@lvs ~]# ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether 00:0c:29:3a:12:34 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.100/24 brd 192.168.1.255 scope global eth0
valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether 00:0c:29:3a:12:3e brd ff:ff:ff:ff:ff:ff
inet 192.168.2.1/24 brd 192.168.2.255 scope global eth1
valid_lft forever preferred_lft forever
2.2.2 配置后端Web服务器
Web Server 1 (192.168.2.10):
[root@web1 ~]# ifconfig eth0 192.168.2.10 netmask 255.255.255.0 up
[root@web1 ~]# route add default gw 192.168.2.1
[root@web1 ~]# yum install -y httpd
Loaded plugins: fastestmirror
...
Complete!
[root@web1 ~]# echo "Web1" > /var/www/html/index.html
[root@web1 ~]# systemctl start httpd
[root@web1 ~]# systemctl enable httpd
Created symlink from /etc/systemd/system/multi-user.target.wants/httpd.service to /usr/lib/systemd/system/httpd.service.
[root@web1 ~]# curl http://localhost
Web1
Web Server 2 (192.168.2.11):
[root@web2 ~]# ifconfig eth0 192.168.2.11 netmask 255.255.255.0 up
[root@web2 ~]# route add default gw 192.168.2.1
[root@web2 ~]# yum install -y httpd
Loaded plugins: fastestmirror
...
Complete!
[root@web2 ~]# echo "Web2" > /var/www/html/index.html
[root@web2 ~]# systemctl start httpd
[root@web2 ~]# systemctl enable httpd
Created symlink from /etc/systemd/system/multi-user.target.wants/httpd.service to /usr/lib/systemd/system/httpd.service.
[root@web2 ~]# curl http://localhost
Web2
2.2.3 测试LVS到Web服务器的连通性
在LVS上执行:
[root@lvs ~]# ping -c 2 192.168.2.10
PING 192.168.2.10 (192.168.2.10) 56(84) bytes of data.
64 bytes from 192.168.2.10: icmp_seq=1 ttl=64 time=0.8 ms
64 bytes from 192.168.2.10: icmp_seq=2 ttl=64 time=0.9 ms
--- 192.168.2.10 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 0.8/0.85/0.9/0.05 ms
[root@lvs ~]# ping -c 2 192.168.2.11
PING 192.168.2.11 (192.168.2.11) 56(84) bytes of data.
64 bytes from 192.168.2.11: icmp_seq=1 ttl=64 time=0.7 ms
64 bytes from 192.168.2.11: icmp_seq=2 ttl=64 time=0.8 ms
--- 192.168.2.11 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1000ms
rtt min/avg/max/mdev = 0.7/0.75/0.8/0.05 ms
2.2.4 安装LVS管理工具
[root@lvs ~]# yum install -y ipvsadm
Loaded plugins: fastestmirror
...
Installed:
ipvsadm.x86_64 0:1.27-7.el7
Complete!
2.2.5 配置ipvsadm负载均衡策略
[root@lvs ~]# ipvsadm -A -t 192.168.1.100:80 -s rr
[root@lvs ~]# ipvsadm -a -t 192.168.1.100:80 -r 192.168.2.10:80 -m -w 1
[root@lvs ~]# ipvsadm -a -t 192.168.1.100:80 -r 192.168.2.11:80 -m -w 1
[root@lvs ~]# ipvsadm -Ln
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP 192.168.1.100:80 rr
-> 192.168.2.10:80 Masq 1 0 0
-> 192.168.2.11:80 Masq 1 0 0
2.2.6 测试负载均衡
在客户端(与LVS外网同网段,例如192.168.1.0/24)访问VIP:
[root@client ~]# curl http://192.168.1.100
Web1
[root@client ~]# curl http://192.168.1.100
Web2
[root@client ~]# curl http://192.168.1.100
Web1
[root@client ~]# curl http://192.168.1.100
Web2
在LVS上查看连接统计:
[root@lvs ~]# ipvsadm -Ln --stats
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Conns InPkts OutPkts InBytes OutBytes
-> RemoteAddress:Port
TCP 192.168.1.100:80 4 12 0 972 0
-> 192.168.2.10:80 2 6 0 486 0
-> 192.168.2.11:80 2 6 0 486 0
3 LVS-ipvsadm的常用参数
3.1 虚拟服务器管理
在Router上开启转发:
5.3 调度算法选择建议
面对不同的业务场景,选择合适的调度算法至关重要:
5.2 动态调度算法
动态调度算法实时监控后端服务器的连接数、负载情况,动态调整分配策略,能够更均衡地利用集群资源,适应突发流量。
5.3 调度算法选择建议
面对不同的业务场景,选择合适的调度算法至关重要:
LVS的技术生态仍在持续演进。随着eBPF、XDP等新一代内核技术的兴起,负载均衡领域出现了更多创新方案,但LVS作为经过二十年生产环境考验的成熟组件,在稳定性、易用性与生态兼容性方面仍具有不可替代的地位。深入理解LVS的技术原理与联动模式,是构建现代化高并发架构的重要基础。
-
添加虚拟服务器:
[root@lvs ~]# ipvsadm -A -t 192.168.1.100:80 -s rr编辑虚拟服务器:
[root@lvs ~]# ipvsadm -A -t 192.168.1.100:80 -s rr删除虚拟服务器:
[root@lvs ~]# ipvsadm -D -t 192.168.1.100:80清除所有虚拟服务器:
[root@lvs ~]# ipvsadm -C恢复虚拟服务器规则:
[root@lvs ~]# ipvsadm -R < /etc/sysconfig/ipvsadm.rules保存虚拟服务器规则
[root@lvs ~]# ipvsadm -S > /etc/sysconfig/ipvsadm.rules [root@lvs ~]# cat /etc/sysconfig/ipvsadm.rules -A -t 192.168.1.100:80 -s rr -a -t 192.168.1.100:80 -r 192.168.2.10:80 -m -w 1 -a -t 192.168.1.100:80 -r 192.168.2.11:80 -m -w 13.2 真实服务器管理
-
添加真实服务器:
[root@lvs ~]# ipvsadm -a -t 192.168.1.100:80 -r 192.168.2.10:80 -m -w 1编辑真实服务器:
[root@lvs ~]# ipvsadm -e -t 192.168.1.100:80 -r 192.168.2.10:80 -m -w 2删除真实服务器:
[root@lvs ~]# ipvsadm -d -t 192.168.1.100:80 -r 192.168.2.10:803.3 显示和设置
-
显示虚拟服务器表
[root@lvs ~]# ipvsadm -Ln IP Virtual Server version 1.2.1 (size=4096) Prot LocalAddress:Port Scheduler Flags -> RemoteAddress:Port Forward Weight ActiveConn InActConn TCP 192.168.1.100:80 rr -> 192.168.2.10:80 Masq 1 0 0 -> 192.168.2.11:80 Masq 1 0 0计数器清零:
[root@lvs ~]# ipvsadm -Z设置连接超时值:
[root@lvs ~]# ipvsadm --set 120 10 60启动同步守护进程:
[root@lvs ~]# ipvsadm --start-daemon master --mcast-interface eth0 [root@lvs ~]# ipvsadm --start-daemon backup --mcast-interface eth0停止同步守护进程:
[root@lvs ~]# ipvsadm --stop-daemon master [root@lvs ~]# ipvsadm --stop-daemon backup显示帮助:
[root@lvs ~]# ipvsadm -h3.4 其他选项(后置参数)
-
服务类型:
-
TCP:
-t -
UDP:
-u -
防火墙标记:
-f
-
-
调度算法:
-s rr|wrr|lc|wlc|lblc|lblcr|dh|sh|sed|nq -
工作模式:
-
直接路由(DR):
-g -
隧道(TUN):
-i -
NAT:
-m
-
-
权值:
bash
-w 2
- 持久服务:
[root@lvs ~]# ipvsadm -A -t 192.168.1.100:80 -s rr -p 6004 LVS实战项目-DR模式的实现(实战内容)
4.1 配置环境
-
准备五台机器(Client、Router、LVS、Web1、Web2),网络规划如下:
-
Client:eth0 192.168.10.10/24,网关指向192.168.10.1
-
Router:eth0 192.168.10.1/24,eth1 192.168.20.1/24
-
LVS:eth0 192.168.10.100/24,网关指向192.168.10.1
-
Web1:eth0 192.168.20.10/24,网关指向192.168.20.1
-
Web2:eth0 192.168.20.11/24,网关指向192.168.20.1
-
在Router上开启转发:
[root@router ~]# echo 1 > /proc/sys/net/ipv4/ip_forward [root@router ~]# cat /proc/sys/net/ipv4/ip_forward 1 [root@router ~]# echo "net.ipv4.ip_forward = 1" >> /etc/sysctl.conf [root@router ~]# sysctl -p net.ipv4.ip_forward = 1 -
配置Router的IP地址:
[root@router ~]# ifconfig eth0 192.168.10.1 netmask 255.255.255.0 up [root@router ~]# ifconfig eth1 192.168.20.1 netmask 255.255.255.0 up [root@router ~]# ip addr show ... 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 inet 192.168.10.1/24 brd 192.168.10.255 scope global eth0 3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 inet 192.168.20.1/24 brd 192.168.20.255 scope global eth14.2 在Web服务器上配置ARP抑制与VIP
在两台Web服务器上执行相同操作(以Web1为例):
[root@web1 ~]# ifconfig lo:0 192.168.10.100 netmask 255.255.255.255 broadcast 192.168.10.100 up [root@web1 ~]# route add -host 192.168.10.100 dev lo:0 [root@web1 ~]# 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 [root@web1 ~]# sysctl -p 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验证VIP和ARP配置:
[root@web1 ~]# ip addr show lo 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet 192.168.10.100/32 brd 192.168.10.100 scope global lo:0 valid_lft forever preferred_lft foreverWeb2同样配置:
[root@web2 ~]# ifconfig lo:0 192.168.10.100 netmask 255.255.255.255 broadcast 192.168.10.100 up [root@web2 ~]# route add -host 192.168.10.100 dev lo:0 [root@web2 ~]# echo "net.ipv4.conf.all.arp_ignore = 1" >> /etc/sysctl.conf [root@web2 ~]# echo "net.ipv4.conf.all.arp_announce = 2" >> /etc/sysctl.conf [root@web2 ~]# echo "net.ipv4.conf.lo.arp_ignore = 1" >> /etc/sysctl.conf [root@web2 ~]# echo "net.ipv4.conf.lo.arp_announce = 2" >> /etc/sysctl.conf [root@web2 ~]# sysctl -p ...4.3 在LVS上配置VIP和负载策略
[root@lvs ~]# ifconfig eth0:0 192.168.10.100 netmask 255.255.255.0 up [root@lvs ~]# echo 1 > /proc/sys/net/ipv4/ip_forward [root@lvs ~]# ipvsadm -A -t 192.168.10.100:80 -s rr [root@lvs ~]# ipvsadm -a -t 192.168.10.100:80 -r 192.168.20.10:80 -g -w 1 [root@lvs ~]# ipvsadm -a -t 192.168.10.100:80 -r 192.168.20.11:80 -g -w 1 [root@lvs ~]# ipvsadm -Ln IP Virtual Server version 1.2.1 (size=4096) Prot LocalAddress:Port Scheduler Flags -> RemoteAddress:Port Forward Weight ActiveConn InActConn TCP 192.168.10.100:80 rr -> 192.168.20.10:80 Route 1 0 0 -> 192.168.20.11:80 Route 1 0 04.4 测试连通性
在Client上测试到各节点的连通性:
[root@client ~]# ping -c 2 192.168.10.1 PING 192.168.10.1 (192.168.10.1) 56(84) bytes of data. 64 bytes from 192.168.10.1: icmp_seq=1 ttl=64 time=1.2 ms 64 bytes from 192.168.10.1: icmp_seq=2 ttl=64 time=1.1 ms --- 192.168.10.1 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1003ms rtt min/avg/max/mdev = 1.1/1.15/1.2/0.05 ms [root@client ~]# ping -c 2 192.168.10.100 PING 192.168.10.100 (192.168.10.100) 56(84) bytes of data. 64 bytes from 192.168.10.100: icmp_seq=1 ttl=64 time=0.9 ms 64 bytes from 192.168.10.100: icmp_seq=2 ttl=64 time=1.0 ms --- 192.168.10.100 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1002ms rtt min/avg/max/mdev = 0.9/0.95/1.0/0.05 ms [root@client ~]# ping -c 2 192.168.20.10 PING 192.168.20.10 (192.168.20.10) 56(84) bytes of data. 64 bytes from 192.168.20.10: icmp_seq=1 ttl=63 time=1.5 ms 64 bytes from 192.168.20.10: icmp_seq=2 ttl=63 time=1.4 ms --- 192.168.20.10 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1002ms rtt min/avg/max/mdev = 1.4/1.45/1.5/0.05 ms4.5 测试负载均衡
在Web服务器上启动httpd(如果之前未安装):
[root@web1 ~]# yum install -y httpd [root@web1 ~]# echo "Web1 DR" > /var/www/html/index.html [root@web1 ~]# systemctl start httpd [root@web2 ~]# yum install -y httpd [root@web2 ~]# echo "Web2 DR" > /var/www/html/index.html [root@web2 ~]# systemctl start httpd在Client上反复访问VIP:
[root@client ~]# curl http://192.168.10.100 Web1 DR [root@client ~]# curl http://192.168.10.100 Web2 DR [root@client ~]# curl http://192.168.10.100 Web1 DR [root@client ~]# curl http://192.168.10.100 Web2 DR在LVS上查看连接统计:
[root@lvs ~]# ipvsadm -Ln --stats IP Virtual Server version 1.2.1 (size=4096) Prot LocalAddress:Port Conns InPkts OutPkts InBytes OutBytes -> RemoteAddress:Port TCP 192.168.10.100:80 4 12 0 972 0 -> 192.168.20.10:80 2 6 0 486 0 -> 192.168.20.11:80 2 6 0 486 05 LVS调度算法详解与选型指南
LVS的核心价值在于将客户请求智能地分发到后端服务器集群。这一智能分发功能由调度算法实现。调度算法决定了请求如何分配给Real Server,直接影响集群的整体性能、资源利用率和用户体验。LVS支持丰富的调度算法,可分为静态算法和动态算法两大类。正确理解和选择合适的调度算法,是构建高并发、高可用架构的关键。
5.1 静态调度算法
静态调度算法在决策时不考虑后端服务器的当前负载状态,仅依据预先设定的规则进行分配。这类算法实现简单,开销小,适用于服务器性能均匀、请求处理时间相对固定的场景。
-
轮询(Round Robin, RR)
将请求按顺序依次分配给各个Real Server,循环往复。
适用场景:集群中所有服务器硬件配置相同,且每个请求处理耗时相近的场景,如静态文件服务器集群。 -
加权轮询(Weighted Round Robin, WRR)
在轮询的基础上引入权重概念,权重高的Real Server被分配更多请求。管理员根据服务器处理能力(如CPU核心数、内存大小)设置权重。
适用场景:服务器性能不均衡的集群,希望性能强的服务器承担更多负载。 -
目标地址散列(Destination Hashing, DH)
根据请求的目标IP地址(通常是VIP)计算哈希值,将请求映射到固定的Real Server。同一目标IP的请求始终发往同一台服务器。
适用场景:多VIP场景,或需要将特定服务的请求固定到某台服务器(如缓存服务器)。 -
源地址散列(Source Hashing, SH)
根据请求的源IP地址计算哈希值,将来自同一客户端的请求始终调度到同一台Real Server。
适用场景:需要会话保持的应用(如购物车、登录状态),确保用户在整个会话期间与同一后端交互。 -
最少连接(Least-Connection, LC)
将新请求分配给当前活动连接数最少的Real Server。
适用场景:请求处理时间差异较大的场景,如动态应用服务器(PHP、Java),能有效避免连接堆积。 -
加权最少连接(Weighted Least-Connection, WLC)
在最少连接的基础上加入权重,公式为(活动连接数 * 256 + 非活动连接数) / 权重,选择计算结果最小的服务器。
特点:LVS默认算法,兼顾服务器性能和当前负载,是最常用的动态算法。
适用场景:绝大多数通用业务,特别是服务器性能异构且负载波动较大的环境。 -
最短期望延迟(Shortest Expected Delay, SED)
基于WLC,但计算公式改为(活动连接数 + 1) * 256 / 权重,旨在选择期望延迟最短的服务器。
适用场景:对响应延迟敏感的服务,希望尽可能将请求分配给处理能力强的服务器。 -
永不排队(Never Queue, NQ)
改进自SED,当有服务器连接数为0时,直接将请求分配给该空闲服务器,无需排队等待。
适用场景:需要快速响应的实时服务,避免请求在队列中等待。 -
静态文件、CDN边缘节点场景,请求处理时间短且均匀,推荐使用RR或WRR算法,实现简单高效。
-
电商、论坛等动态网站,请求处理时间差异大,推荐使用WLC算法,它是LVS默认算法,成熟稳定,兼顾负载与性能。
-
需要会话保持的应用(如购物车、登录状态),推荐使用SH算法,源地址哈希保证同一用户始终访问同一服务器。
-
服务器性能差异明显的集群,推荐使用WRR或WLC算法,通过权重机制充分利用高性能服务器。
-
长连接服务(如WebSocket),推荐使用LC或WLC算法,关注连接数,避免单台服务器连接过多。
-
对响应延迟要求极高的服务,推荐使用SED或NQ算法,优先选择最快响应的服务器。
-
最少连接(Least-Connection, LC)
将新请求分配给当前活动连接数最少的Real Server。
适用场景:请求处理时间差异较大的场景,如动态应用服务器(PHP、Java),能有效避免连接堆积。 -
加权最少连接(Weighted Least-Connection, WLC)
在最少连接的基础上加入权重,公式为(活动连接数 * 256 + 非活动连接数) / 权重,选择计算结果最小的服务器。
特点:LVS默认算法,兼顾服务器性能和当前负载,是最常用的动态算法。
适用场景:绝大多数通用业务,特别是服务器性能异构且负载波动较大的环境。 -
最短期望延迟(Shortest Expected Delay, SED)
基于WLC,但计算公式改为(活动连接数 + 1) * 256 / 权重,旨在选择期望延迟最短的服务器。
适用场景:对响应延迟敏感的服务,希望尽可能将请求分配给处理能力强的服务器。 -
静态文件、CDN边缘节点场景,请求处理时间短且均匀,推荐使用RR或WRR算法,实现简单高效。
-
电商、论坛等动态网站,请求处理时间差异大,推荐使用WLC算法,它是LVS默认算法,成熟稳定,兼顾负载与性能。
-
需要会话保持的应用(如购物车、登录状态),推荐使用SH算法,源地址哈希保证同一用户始终访问同一服务器。
-
服务器性能差异明显的集群,推荐使用WRR或WLC算法,通过权重机制充分利用高性能服务器。
-
长连接服务(如WebSocket),推荐使用LC或WLC算法,关注连接数,避免单台服务器连接过多。
-
对响应延迟要求极高的服务,推荐使用SED或NQ算法,优先选择最快响应的服务器。
-
永不排队(Never Queue, NQ)
改进自SED,当有服务器连接数为0时,直接将请求分配给该空闲服务器,无需排队等待。
适用场景:需要快速响应的实时服务,避免请求在队列中等待。结语
在深入LVS的技术细节之前,有必要先了解与其协同工作的几项关键基础设施组件:Keepalived 用于实现LVS调度器的高可用与后端健康检查;Nginx/HAProxy 作为七层负载均衡器,与LVS组成四层+七层架构;Kubernetes 在云原生环境中通过kube-proxy的IPVS模式提供Service负载均衡;BGP/ECMP 则用于构建多台L调度器集群,实现流量分担与冗余。
从技术实现层面审视,LVS(Linux Virtual Server)作为一款内核态的四层负载均衡器,其核心价值源于对Linux操作系统底层的深度整合。它基于Netfilter框架,在内核空间维护IPVS(IP Virtual Server)模块,通过Hook函数拦截和处理网络数据包,实现了请求的快速转发与调度。这种内核态的实现方式,使其完全避免了用户态与内核态之间的上下文切换开销,在标准x86服务器上即可轻松支撑百万级并发连接,成为高并发场景下的技术基石。
在具体的转发模式设计中,LVS展现了技术方案的多样性。NAT模式利用网络地址转换机制,将请求的目标IP和端口改写为后端服务器地址,适用于后端操作系统不受限的小规模集群;DR模式则通过改写数据链路层的MAC地址实现直接路由,响应流量绕过调度器直达客户端,将调度器的性能压力降至最低;TUN模式基于IP隧道技术,在原始报文外封装新的IP头部,使集群能够跨越地域限制,为异地多活架构提供了基础能力。这三种模式各自应对不同的网络拓扑与业务需求,体现了LVS在架构设计上的全面考量。
更为重要的是,LVS并非孤立存在的技术组件,它与现代基础设施生态深度融合,衍生出丰富的联动方案:
-
与Keepalived的高可用集成:Keepalived通过VRRP协议为LVS调度器提供主备冗余机制,当主节点故障时备用节点自动接管VIP,实现负载均衡服务的无损切换。同时,Keepalived内置的健康检查机制可动态探测后端Real Server的状态,自动隔离异常节点,保障集群的持续可用性。
-
与Nginx/HAProxy的多层负载均衡架构:LVS作为四层入口处理海量TCP/UDP流量,将请求初步分发至后端的Nginx或HAProxy集群;七层负载均衡器进一步解析HTTP协议,根据URL、Header等应用层信息实现精细化路由。这种“四层+七层”的架构,既发挥了LVS的极致性能,又融合了七层负载均衡的灵活性与功能丰富性。
-
-
与云原生生态的结合:在Kubernetes环境中,kube-proxy的IPVS模式将LVS技术抽象为Service的负载均衡实现,为容器化应用提供高性能的南北向流量入口。此外,部分云厂商的负载均衡产品底层亦借鉴LVS设计思想,体现了其在云计算时代的延续性与适应性。
-
与BGP/ECMP的协同工作:在大型数据中心场景中,多台LVS调度器可通过BGP协议与上游交换机建立动态路由,利用ECMP(等价多路径)技术实现流量的均衡分发与冗余备份。这一方案突破了单机瓶颈,构建了可水平扩展的负载均衡集群。

2195

被折叠的 条评论
为什么被折叠?



