【Day 60】Linux-LVS负载均衡
一、 LVS 介绍
1、基础内容
LVS(Linux Virtual Server)即 Linux 虚拟服务器 ,是一个由中国章文嵩博士在 1998 年发起的开源项目,现已被集成到 Linux 内核中,从 2.4 版本内核开始就支持 LVS 功能。
它是一种基于 IP 层的负载均衡技术,在操作系统核心层将来自 IP 层的 TCP/UDP 请求均衡地转移到不同的服务器,把一组服务器构成一个高性能、高可用的虚拟服务器。
LVS 的核心组件包括 IPVS(IP Virtual Server)和 ipvsadm 。
IPVS 是 Linux 内核模块,位于内核空间,是 LVS 最核心的部分,它实现了 TCP/UDP 请求的分发,支持多种调度算法,如轮询(RR)、加权轮询(WRR)、最少连接(LC)等。 IPVS 通过 netfilter 框架拦截、重写和转发数据包,根据配置的调度算法,将客户端的请求转发到后端的真实服务器(Real Server)上,真正执行数据转发的逻辑,以实现负载均衡的功能。
ipvsadm 则是用户态工具,是用于配置 IPVS 转发规则的命令行工具,系统管理员可以使用 ipvsadm 进行添加、删除真实服务器(RS),设置调度算法,查看连接状态等操作。
LVS 的工作原理基于其在 Linux 内核中的 IPVS 模块,工作在 OSI 模型的第四层(传输层),基于 TCP/IP 协议进行路由和转发。
- 当客户端发送请求到 LVS 负载均衡器时,IPVS 模块首先根据目标 IP 和端口匹配转发表(IPVS 表项)。
- 然后依据配置的调度算法,如轮询、加权轮询、最少连接等,从后端的真实服务器池中选择一台合适的 Real Server 来处理该请求 。
- 接着,LVS 执行数据包重写或转发操作,将请求转发到选定的 Real Server 上。
- Real Server 处理完请求后,将响应返回给客户端。
- 在不同的工作模式下,LVS 的转发方式有所不同,
- NAT 模式下,LVS 修改目标 IP 为 RS 的 IP,源地址为 LVS 的 IP;
- DR 模式中,LVS 修改目标 MAC 地址,而不改变 IP 地址;
- TUN 模式下,LVS 将请求封装为 IPIP 隧道包进行转发 。
由于 LVS 直接在内核层进行转发,无需像应用层负载均衡器那样进行用户态和内核态的频繁切换,减少了上下文切换的开销,因此拥有更高的性能和吞吐能力,在处理海量并发连接时表现出色,尤其适用于大规模的 Web 服务、数据库集群等应用场景,
2、 负载均衡策略 / 算法
LVS 提供了多种负载均衡策略 / 算法,每种算法都有其独特的原理和适用场景,用户可以根据实际的业务需求和服务器环境来选择合适的算法,以实现高效的负载均衡。
轮询(Round Robin,RR)算法是一种最为简单直观的负载均衡算法。它的工作原理是按顺序将请求依次分配给后端服务器,循环往复。例如,假设有 3 台后端服务器 A、B、C,当有请求到来时,第一个请求会被分配到服务器 A,第二个请求分配到服务器 B,第三个请求分配到服务器 C,第四个请求又重新分配到服务器 A,依此类推。这种算法的优点是实现简单,无需额外的计算和复杂的逻辑判断,并且能够公平地分配请求,在服务器性能相近的场景下,能使各服务器的负载相对均衡。但它的缺点也很明显,由于它不考虑服务器的实际负载情况,无法感知服务器之间的性能差异,可能会导致性能较差的服务器因承受过多请求而过载,同时它也不支持动态调整权重,灵活性较差。因此,轮询算法适用于服务器配置相同且负载波动较小的场景,如一些提供静态资源服务的服务器集群,这些服务器处理请求的能力基本一致,使用轮询算法可以简单有效地实现负载均衡。
加权轮询(Weighted Round Robin,WRR)算法是在轮询算法的基础上发展而来的,它为每台服务器分配一个权重,权重的大小反映了服务器的处理能力。权重高的服务器将获得更多的请求,例如,服务器 A 的权重为 1,服务器 B 的权重为 2,那么在分配请求时,调度器调度到服务器 B 的请求数量大约会是服务器 A 的两倍。这种算法的优点在于可以根据服务器的性能差异灵活地分配流量,适用于服务器硬件配置不同的异构服务器环境,管理员可以根据服务器的 CPU、内存、带宽等资源情况手动配置权重,使性能更强的服务器承担更多的负载,从而提高整个集群的处理能力。然而,加权轮询算法的权重需要预先静态配置,无法根据服务器实时的负载变化进行动态调整,而且在长时间运行过程中,可能会导致低权重服务器闲置,资源利用率不高。所以,在实际应用中,当服务器性能差异明显且负载相对稳定时,加权轮询算法是一个不错的选择。
最少连接(Least Connections,LC)算法会将新的请求分配给当前连接数最少的服务器。它的核心思想是动态地感知服务器的负载情况,认为当前连接数最少的服务器处理能力相对较强,将请求分配给它可以使负载更加均衡。例如,当有新的请求到达时,负载均衡器会检查后端每台服务器的当前连接数,然后将请求转发给连接数最少的那台服务器。这种算法适用于处理长连接或请求处理时间差异较大的场景,比如数据库查询服务,因为在这些场景中,不同请求的处理时间可能相差很大,如果使用轮询算法,可能会导致某些服务器因为处理长请求而积压大量连接,而其他服务器却处于空闲状态,而最少连接算法可以根据服务器的实际连接情况进行动态分配,有效避免这种情况的发生。但该算法需要实时监控服务器的连接数,会增加系统的开销,并且对于短连接或请求处理时间均匀的场景,其优势并不明显。
加权最少连接(Weighted Least Connections,WLC)算法结合了权重和连接数这两个因素。它在选择服务器时,不仅考虑服务器当前的连接数,还会结合服务器的权重来综合判断。具体来说,它会计算每个服务器的加权连接数,即当前连接数除以权重,然后将请求分配给加权连接数最小的服务器。这样,既考虑了服务器的性能差异(通过权重体现),又能根据服务器的实时负载情况(通过连接数体现)进行动态调整,使得负载分配更加合理。例如,服务器 A 的权重为 2,当前连接数为 4;服务器 B 的权重为 1,当前连接数为 2,那么服务器 A 的加权连接数为 4÷2 = 2,服务器 B 的加权连接数为 2÷1 = 2,此时如果有新请求,负载均衡器会在这两台服务器中随机选择一台(当加权连接数相等时)。加权最少连接算法是 LVS 的默认算法,它综合了加权轮询和最少连接算法的优点,适用于各种复杂的服务器环境,能够在不同性能的服务器之间实现高效的负载均衡。
源地址哈希(Source Hashing,SH)算法根据客户端的 IP 地址进行哈希计算,然后将请求分配给对应的服务器。其原理是通过哈希函数将客户端的 IP 地址映射到一个固定的范围内,再根据这个范围与后端服务器列表的对应关系,确定将请求转发到哪台服务器。这样可以确保同一个客户端的请求始终被分配到同一个服务器上,有利于实现会话保持。例如,对于一个电商网站,用户在浏览商品、添加购物车、下单等一系列操作过程中,使用源地址哈希算法可以保证这些操作都在同一台服务器上处理,避免因为请求被分配到不同服务器而导致的会话不一致问题,提高用户体验。但这种算法也存在一定的局限性,当后端服务器列表发生变化时,可能会导致哈希值的重新计算,从而使同一个客户端的请求被分配到不同的服务器上,影响会话的连续性。因此,源地址哈希算法适用于对会话保持要求较高的场景,并且在服务器列表相对稳定的情况下效果更佳。
3、 LVS 设计模式
LVS 支持三种主要的设计模式,分别是 NAT 模式、DR 直接路由模式和 TUN 隧道模式,每种模式都有其独特的工作原理和适用场景,用户可以根据具体的业务需求和网络环境来选择合适的模式。
(1)NAT 模式
NAT(Network Address Translation)模式,即网络地址转换模式。在这种模式下,LVS 负载均衡器充当着网络地址转换的角色,其工作原理如下:
1、客户端(CIP)访问业务服务(如 www.xxx.com)
- 通过 DNS 解析到 LVS 的 VIP(对外服务的虚拟 IP)。
- 客户端发送请求数据包,数据包的 源地址 = CIP,目标地址 = VIP,然后通过网络传输到 LVS 负载均衡器。
2、LVS 调度与 DNAT:VIP → DIP → RIP
- LVS 接收到数据包后,根据预设的调度算法(如轮询、加权轮询、最少连接等),从后端 Real Server 池中选中一台节点(RIP)。
- LVS 执行 DNAT(目的地址转换):将数据包的 目标地址从 VIP 改为选中的 RIP,同时为了后续能接收响应,LVS 会在本地维护一张 “连接跟踪表”(记录 CIP、VIP、RIP 的映射关系)。
- 之后,LVS 将修改后的数据包转发给 Real Server:此时数据包的 源地址 = CIP,目标地址 = RIP,转发的网络路径是 LVS 的 DIP(私网网卡)到 Real Server 的 RIP(同一私网)。
3、Real Server 处理并返回响应:RIP → DIP
- Real Server(RIP)接收到数据包后,识别出目标地址是自己,于是处理业务请求(如查询数据库、生成网页内容)。
- 处理完成后,Real Server 生成响应数据包,此时数据包的 源地址 = RIP,目标地址 = CIP(因为 Real Server 只知道请求来自 CIP)。
- 由于 Real Server 与 CIP 不在同一网段(CIP 可能是公网,RIP 是私网),且 Real Server 的默认网关通常配置为 LVS 的 DIP(关键配置!),因此响应数据包会直接发送到 LVS 的 DIP(私网网卡)。
4、LVS 执行 SNAT 并返回客户端:DIP → VIP → CIP
- LVS 接收到 Real Server 的响应数据包后,通过本地的 “连接跟踪表”,找到之前记录的 CIP-VIP-RIP 映射关系,确认这是某客户端请求的响应。
- LVS 执行 SNAT(源地址转换):将响应数据包的 源地址从 RIP 改为 VIP(目的是让客户端认为响应来自 “自己最初访问的 VIP”,而非陌生的 RIP—— 客户端不知道后端有 Real Server)。
- 最后,LVS 将修改后的响应数据包发送给客户端:此时数据包的 源地址 = VIP,目标地址 = CIP,通过公网传输回客户端,完成一次完整的请求 - 响应流程。
整个过程中,请求和响应的数据包都需要经过 LVS 进行地址转换和转发。例如,一个电商网站使用 LVS 的 NAT 模式进行负载均衡,当用户访问网站时,请求先到达 LVS 的 VIP,LVS 根据调度算法选择一台后端的 Web 服务器,将请求数据包的目标 IP 改为该 Web 服务器的 IP,Web 服务器处理完请求后将响应返回给 LVS,LVS 再将响应数据包的源 IP 改为 VIP,发送回用户的浏览器。
在使用 NAT 模式时,有一些重要的注意事项。
- VIP 和 DIP必须属于两个不同的网络,这样才能实现网络地址转换的功能。
- 负载均衡器需要开启路由转发功能,通过修改系统参数 “net.ipv4.ip_forward = 1” 来实现,这是确保数据包能够在不同网络之间正确转发的关键。
- 所有 Real Server 的网关必须指向 DIP,这样 Real Server 在处理完请求后,才能将响应数据包正确地发送回 LVS。
- 优点是配置相对简单,并且支持端口映射,适用于后端服务器位于私有网络,需要统一出口,以及中小规模负载均衡的场景。
- 缺点:由于请求和响应都要经过 LVS,当后端服务器数量较多或并发请求量较大时,LVS 可能会成为性能瓶颈,影响整个系统的处理能力。
3台虚拟机-lvs-100-node01-node02
1、初始配置
2、两个服务器的网卡:
3、lvm的两个网卡:
- [root@lvm-100 ~]nmcli connection modify ens36 ipv4.gateway 192.168.180.1
4、开启路由转发
5、负载均衡配置
[root@lvm-100 ~]ipvsadm -a -t 192.168.180.100:80 -r 192.168.26.11:80 -m
[root@lvm-100 ~]ipvsadm -a -t 192.168.180.100:80 -r 192.168.26.12:80 -m
[root@lvm-100 ~]ipvsadm -L -n
[root@lvm-100 ~]curl http://192.168.26.12
6、配置集群
创建集群(虚拟服务)
查看负载均衡表(虚拟服务):-n :IP端口都是数字
// 虚拟服务没端口
7、添加后端 real server
测试
(2) DR 直接路由模式
DR(Direct Routing)直接路由模式是 LVS 常用的一种工作模式,它的工作原理与 NAT 模式有所不同。在 DR 模式下,当客户端发送请求到 LVS 的 VIP 时,LVS 同样根据调度算法选择一台后端的 Real Server。但与 NAT 模式不同的是,LVS 并不修改数据包的 IP 地址,而是修改数据包的目标 MAC 地址,将其改为选中的 Real Server 的 MAC 地址。然后,LVS 通过二层交换将数据包转发给 Real Server。Real Server 接收到数据包后,发现目标 IP 是自己配置的 VIP(Real Server 需要配置与 LVS 相同的 VIP),于是处理该请求。处理完成后,Real Server 直接将响应数据包发送给客户端,而不需要经过 LVS。例如,一个大型的新闻网站采用 LVS 的 DR 模式进行负载均衡,用户访问网站时,请求到达 LVS 的 VIP,LVS 根据算法选择一台后端的 Web 服务器,修改数据包的目标 MAC 地址后将其转发给 Web 服务器,Web 服务器处理完请求后,直接将响应发送回用户的浏览器。
在配置和使用 DR 模式时,有几个关键要点。所有的 Real Server 必须配置 VIP,这是为了使 Real Server 能够正常接收目标 IP 为 VIP 的请求。通常在 Real Server 的回环接口(lo)上配置 VIP,并且使用 32 位掩码,即 “ip addr add dev lo 192.168.140.100/32”,这样可以确保 VIP 在网络中唯一且独立。所有的 Real Server 需要修改两个重要的 arp 系统参数。将 “arp_ignore” 设置为 1,其作用是使系统只响应目的 IP 为本地物理网卡 IP 的 ARP 请求,避免 VIP 产生冲突,因为在一个网络中,如果多台服务器都配置了相同的 VIP,ARP 请求可能会导致混乱,通过设置该参数可以确保只有目标 MAC 地址匹配的服务器才会响应 ARP 请求;将 “arp_announce” 设置为 2,这会使系统不使用 IP 数据包的源地址来设置 ARP 请求的源地址,而选择发送接口(物理网卡)的 IP 地址,避免客户端直接访问后端的 Real Server,失去负载均衡的效果,防止网关设备的 ARP 缓存表紊乱。DR 模式的优点是响应不经过 LVS,大大减轻了 LVS 的负载压力,性能更高,适用于高并发场景,追求极致性能的应用。但它也有一定的局限性,要求 LVS 和 Real Server 必须在同一个物理网络(同一网段),这在一定程度上限制了其网络部署的灵活性。
1、准备:两个web、一个lvsadm
修改all.arp
(3) TUN 隧道模式
TUN(IP Tunneling)隧道模式是 LVS 的另一种工作模式,它利用 IP 隧道技术实现负载均衡。其工作原理是:当客户端发送请求到 LVS 的 VIP 时,LVS 根据调度算法选择一台后端的 Real Server,然后 LVS 将请求数据包进行封装,在原有的 IP 包头外面再添加一个新的 IP 头,新 IP 头的源地址是 LVS 的 IP(DIP),目标地址是选中的 Real Server 的 IP(RIP),通过 IP 隧道将封装后的数据包发送给 Real Server。Real Server 接收到封装的数据包后,解开外层的 IP 头,得到原始的请求数据包,然后进行处理。处理完成后,Real Server 直接将响应数据包发送给客户端,响应数据包的源 IP 为 VIP。例如,一个跨国公司的分布式应用系统,使用 LVS 的 TUN 模式进行负载均衡,位于不同地区的用户访问应用时,请求到达 LVS 的 VIP,LVS 将请求封装后通过 IP 隧道发送到位于不同地理位置的后端服务器,后端服务器处理完请求后直接将响应返回给用户。
TUN 模式适用于分布式集群场景,尤其是当 LVS 和 Real Server 分布在不同的网段,甚至不同的地域时,TUN 模式可以实现跨网络的负载均衡。但这种模式也存在一些缺点,它需要在 Real Server 上启用隧道支持,通常需要加载相应的内核模块,如 “modprobe ipip”,配置相对复杂,并且对服务器的性能也有一定的要求。由于 IP 隧道的封装和解封装过程会带来一定的开销,所以 TUN 模式的性能略低于 DR 模式。在实际应用中,如果需要实现跨地域的负载均衡,并且对服务器的配置和性能有足够的把控能力,可以选择 TUN 模式。
二、实例
lftp 10.11.0.254:/software> cd jenkins/
lftp 10.11.0.254:/software/jenkins> mget dian.sql
10401 bytes transferred
lftp 10.11.0.254:/software/jenkins> exit
[root@lvm__100 ~]# mysql -uroot -pSu@548165
mysql: [Warning] Using a password on the command line interface can be insecure.
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 11
Server version: 8.0.43 MySQL Community Server - GPLCopyright (c) 2000, 2025, Oracle and/or its affiliates.Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.mysql> source /root/dian.sql
mysql> show databases;
+--------------------+
| Database |
+--------------------+
| dian |
| information_schema |
| mysql |
| performance_schema |
| sys |
| test |
| test_lvs |
+--------------------+
7 rows in set (0.03 sec)mysql> select * from sys.user;
ERROR 1146 (42S02): Table 'sys.user' doesn't exist
mysql> select * from sys_user;
+---------+----------+------------+--------------+---------------------+
| user_id | username | password | role | created_time |
+---------+----------+------------+--------------+---------------------+
| 11 | admin | 123456 | ADMIN | 2025-07-21 20:05:14 |
| 13 | demon | WWW.1.com! | METER_READER | 2025-07-21 20:16:02 |
| 14 | tome | WWW.1.com! | CUSTOMER | 2025-07-21 20:38:17 |
+---------+----------+------------+--------------+---------------------+
3 rows in set (0.01 sec)mysql> select user from user;
+------------------+
| user |
+------------------+
| repl |
| mysql.infoschema |
| mysql.session |
| mysql.sys |
| root |
+------------------+
5 rows in set (0.00 sec)mysql> create user 'dian'@'%' identified by 'Dian@548165';
Query OK, 0 rows affected (0.05 sec)mysql> grant all on dian.* to 'dian'@'%' ;
Query OK, 0 rows affected (0.00 sec)mysql> flush privileges;
Query OK, 0 rows affected (0.02 sec)
集群配置
DR模式
配置文件
1、global_defs{}
2、vrrp_instance{} 一个组组名组id密码必须一样。state MASTER 这个机子是主,interface 指网卡名,在真实的网卡上生成vip,virtual_router_id (组的id)advert_int 心跳,authenticcation密码吗,virtual_ipaddress生成的虚拟ip
3、virtual_server ip port {},下边是样例,可以删掉
这是对https的健康状态检查,换成针对tcp健康状态检查的
其他不变
keepalived没端口,验证
(1)虚拟服务
(2)vip(虽然都有虚拟服务,但是vip只有主有)如果两个都有则是错误的。
验证:
如果主调度关掉,vip自动到备调度上,不影响客户端访问。