一、LVS+Keepalived 原理
1.1.LVS 负载均衡原理
LVS(Linux Virtual Server)是一种基于 Linux 内核的负载均衡技术,它通过 IPVS(IP Virtual Server)模块来实现。LVS 可以将客户端的请求分发到多个后端服务器上,从而实现负载均衡。它主要支持三种工作模式:
-
DR 模式(直接路由):客户端的请求首先到达 LVS 负载均衡器,负载均衡器将请求的目标 MAC 地址修改为后端真实服务器的 MAC 地址,而 IP 地址保持不变,然后将请求转发给后端服务器。后端服务器处理完请求后,直接将响应返回给客户端,无需再经过 LVS 负载均衡器。这种模式的优点是性能高,因为响应数据包不需要经过负载均衡器,减少了负载均衡器的处理压力。
-
NAT 模式(网络地址转换):客户端的请求和后端服务器的响应都需要经过 LVS 负载均衡器。负载均衡器在转发请求时,会修改请求的目标 IP 地址为后端服务器的 IP 地址,同时修改源 IP 地址为自己的 IP 地址。在转发响应时,会将响应的目标 IP 地址修改为客户端的 IP 地址。这种模式的优点是配置简单,但缺点是负载均衡器的处理压力较大,而且后端服务器必须和负载均衡器在同一个子网内。
-
TUN 模式(IP 隧道):LVS 负载均衡器将客户端的请求封装在一个新的 IP 报文中,通过隧道发送给后端服务器。后端服务器接收到报文后,解封装得到原始请求,处理完请求后直接将响应返回给客户端。这种模式的优点是支持跨子网的负载均衡,但缺点是配置相对复杂,而且需要额外的隧道开销。
1.2.Keepalived 高可用原理
Keepalived 是一个基于 VRRP(Virtual Router Redundancy Protocol,虚拟路由冗余协议)的高可用解决方案。VRRP 协议的目的是为了解决静态路由环境下的单点故障问题。在一个 VRRP 组中,有一个主路由器(Master)和多个备份路由器(Backup),它们共享一个虚拟 IP 地址(VIP)。主路由器负责处理客户端的请求,备份路由器则监听主路由器的状态。
-
VRRP 虚拟路由冗余:主路由器会定期发送 VRRP 通告消息给备份路由器,告知自己的状态。如果备份路由器在一定时间内没有收到主路由器的通告消息,就认为主路由器出现故障,此时备份路由器中的一个会通过竞选机制成为新的主路由器,并接管虚拟 IP 地址,继续处理客户端的请求。
-
健康检查:Keepalived 可以通过脚本或协议(如 HTTP、HTTPS 等)对后端服务器和 LVS 节点的状态进行监控。如果发现某个后端服务器或 LVS 节点出现故障,Keepalived 会将其从负载均衡池中移除,从而保证只有正常的服务器能够处理客户端的请求。
-
VIP 漂移:当主节点出现故障时,备节点会抢占虚拟 IP 地址,实现 VIP 的漂移。客户端的请求会自动切换到备节点上,从而实现服务的高可用性,切换过程通常可以在秒级完成。
二、配置思路与步骤
2.1.环境准备
四台主机(rocky 8):
节点角色 | IP 地址 | 组件 |
---|---|---|
LVS 主节点 | 192.168.67.110 | Keepalived + IPVS |
LVS 备节点 | 192.168.67.120 | Keepalived + IPVS |
后端 RS1 | 192.168.67.10 | HTTPD + VIP 配置 |
后端 RS2 | 192.168.67.20 | HTTPD + VIP 配置 |
客户端 | 任意 IP | 浏览器或测试工具 |
注意:整个环境所有主机都关闭了 firewalld 和 SElinux 。
2.2.RS 主机配置
2.2.1.配置 VIP
DR 模式
绑定 VIP 的作用:在后端 RS 主机上绑定 VIP 是为了让后端服务器能够正确处理目标 IP 为 VIP 的请求。在 LVS 的 DR 模式下,LVS 负载均衡器将客户端的请求转发给后端服务器时,请求的目标 IP 地址是 VIP。如果后端服务器没有绑定 VIP,它会认为这个请求不是发给自己的,从而丢弃该请求。例如,在一个电商网站的架构中,客户端通过访问 VIP 来浏览商品信息,LVS 将请求转发给后端的 RS 服务器。如果 RS 服务器没有绑定 VIP,就无法处理这些请求,用户将无法正常访问网站。
# 后端两个 RS 主机都需添加 VIP
ip address add 192.168.67.100/32 dev lo # 注意:子网掩码为 32
2.2.2.配置 ARP 抑制
配置 ARP 抑制的作用:配置 ARP 抑制的主要作用是避免后端 RS 服务器与 LVS 负载均衡器之间的 ARP 冲突。在网络中,ARP 协议用于将 IP 地址解析为 MAC 地址。当客户端发送 ARP 请求询问 VIP 的 MAC 地址时,如果后端 RS 服务器不进行 ARP 抑制,可能会响应这个请求,导致客户端将请求直接发送给后端 RS 服务器,而不是通过 LVS 负载均衡器进行转发,从而破坏了负载均衡的架构。例如,在一个企业的内部网络中,如果出现 ARP 冲突,可能会导致部分用户无法正常访问企业的网站或应用程序。
-
两个 RS 主机都需配置,选以下方法终其中一种方法即可。
2.2.2.1.法一
临时设置 ARP 规则。
echo "1" > /proc/sys/net/ipv4/conf/all/arp_ignore
echo "1" > /proc/sys/net/ipv4/conf/lo/arp_ignore
echo "2" > /proc/sys/net/ipv4/conf/all/arp_announce
echo "2" > /proc/sys/net/ipv4/conf/lo/arp_announce
2.2.2.2.法二
永久设置 ARP 规则(主配置文件),在主配置文件最后添加以下四条规则。
sysctl -p:使规则生效。
vim /etc/sysctl.conf
net.ipv4.conf.all.arp_ignore=1
net.ipv4.conf.lo.arp_ignore=1
net.ipv4.conf.all.arp_announce=2
net.ipv4.conf.lo.arp_announce=2
sysctl -p
2.2.2.3.法三
永久设置 ARP 规则(子配置文件),在子配置文件目录里创建 .conf 结尾的文件。
sysctl --system:读取系统中多个指定的配置文件,并将这些文件里定义的内核参数设置加载到当前运行的内核中,以此实现对内核参数的批量设置。
vim /etc/sysctl.d/arp.conf
net.ipv4.conf.all.arp_ignore=1
net.ipv4.conf.lo.arp_ignore=1
net.ipv4.conf.all.arp_announce=2
net.ipv4.conf.lo.arp_announce=2
sysctl --system
2.2.2.4.验证
查看是否设置成功:
2.2.3.配置 Web 服务
作用:安装 Web 服务是为了让后端 RS 服务器能够处理客户端的 HTTP 请求。在实际应用中,后端 RS 服务器通常是提供 Web 服务的服务器,如电商网站的商品展示页面、新闻网站的新闻内容页面等。通过安装 Web 服务,如 Apache 或 Nginx,后端 RS 服务器可以接收并处理客户端的请求,返回相应的网页内容。
两个 RS 主机都需配置。
yum install httpd -y
echo `hostname -I` > /var/www/html/index.html
systemctl enable --now httpd
2.3.Keepalived 主机配置
2.3.1.配置 Keepalived 策略
安装 Keepalived 软件,编辑配置文件,配置 LVS DR 模式。
yum install keepalived -y
注意:两台 keepalived 主机都需修改配置文件,内容如下
vim /etc/keepalived/keepalived.conf ! Configuration File for keepalived
global_defs {notification_email {2373179473@qq.com # 接收 Keepalived 状态变化通知邮件的邮箱地址}notification_email_from keepalived@timinglee.org # 发送通知邮件的邮箱地址smtp_server 127.0.0.1 # 用于发送通知邮件的 SMTP 服务器地址smtp_connect_timeout 30 # 与 SMTP 服务器建立连接的超时时间,单位为秒router_id ka1.timinglee.org # 此 Keepalived 实例的唯一标识,用于在 VRRP 组中区分不同实例vrrp_skip_check_adv_addr # 跳过对 VRRP 通告地址的合法性检查vrrp_garp_interval 0 # 免费 ARP(Gratuitous ARP)消息的发送间隔,设为 0 表示不发送vrrp_gna_interval 0 # 免费邻居通告(Gratuitous Neighbor Advertisement)消息的发送间隔,设为 0 表示不发送vrrp_mcast_group4 224.0.0.18 # VRRP 组播通信使用的 IP 地址
}
vrrp_instance VI_1 {state MASTER # 当前 Keepalived 实例的初始状态,MASTER 表示主节点# 注意:state 备节点需要设置为 BACKUPinterface ens160 # Keepalived 监听 VRRP 通告和绑定 VIP 的网络接口virtual_router_id 100 # VRRP 组的唯一标识符,同一组内的实例此 ID 需相同priority 100 # 当前实例的优先级,数值越高越优先成为主节点# 注意:备节点,优先级需要设置为 80advert_int 1 # 发送 VRRP 通告消息的时间间隔,单位为秒authentication {auth_type PASS # 认证类型,PASS 表示使用密码认证auth_pass 1111 # 认证密码,同一 VRRP 组内的实例需一致}virtual_ipaddress {192.168.67.100/24 dev ens160 label ens160:1 # 虚拟 IP 地址及其子网掩码,绑定到 ens160 接口,别名是 ens160:1}unicast_src_ip 192.168.67.110 # 单播通信时使用的源 IP 地址# 注意:备节点源 IP 地址需要设置为本机 IPunicast_peer {192.168.67.120 # 单播通信的对端 Keepalived 实例的 IP 地址# 注意:备节点需要设置为主节点 IP}
}
virtual_server 192.168.67.100 80 {delay_loop 6 # 健康检查的时间间隔,单位为秒lb_algo wrr # 负载均衡算法,wrr 表示加权轮询lb_kind DR # 负载均衡模式,DR 代表直接路由模式protocol TCP # 负载均衡使用的协议,这里是 TCP 协议
real_server 192.168.67.10 80 {weight 1 # 该真实服务器的权重,影响分配到的请求数量HTTP_GET {url {path / # 健康检查请求的 URL 路径status_code 200 # 期望的 HTTP 响应状态码}connect_timeout 3 # 建立连接的超时时间,单位为秒nb_get_retry 2 # 连接失败后的重试次数delay_before_retry 2 # 每次重试前的延迟时间,单位为秒}}real_server 192.168.67.20 80 {weight 1 # 该真实服务器的权重HTTP_GET {url {path / # 健康检查请求的 URL 路径status_code 200 # 期望的 HTTP 响应状态码}connect_timeout 3 # 建立连接的超时时间nb_get_retry 2 # 连接失败后的重试次数delay_before_retry 2 # 每次重试前的延迟时间}}
}
重启服务。
systemctl restart keepalived.service
安装 ipvsadm 命令,用于观察 ipvs 规则。
yum install ipvsadm -y
ipvsadm -Ln
三、测试
3.1.基础功能验证
目前 VIP 在 192.168.67.110 主机上。
客户端访问虚拟 IP:192.168.67.100,实现请求通过 LVS 负载均衡器转发到后端真实服务器(192.168.67.10 和 192.168.67.20),页面正常轮询显示,表明 LVS 负载均衡器能够正确地将客户端的请求分发到后端的 RS 服务器上。。
while true; do curl 192.168.67.100; sleep 1; done
3.2.主备切换测试
关闭主节点:192.168.67.110
关闭主节点 192.168.67.110 的 Keepalived 服务。
systemctl stop keepalived.service # 关闭 192.168.67.110 的 Keepalived 服务
VIP 自动漂移到备节点上。
客户端访问 192.168.67.100 时,请求自动切换到备节点 192.168.67.120,实现服务无中断。
while true; do curl 192.168.67.100; sleep 1; done
重启主节点:192.168.67.110
重启主节点,Keepalived 服务恢复后:
-
VIP 自动切回主节点,实现高可用。
-
请求按权重(weight=1)均匀分配到 192.168.67.10 和 192.168.67.20,实现流量均衡。
-
服务无中断。
while true; do curl 192.168.67.100; sleep 1; done
3.3.健康检查验证
-
手动停止后端服务器 192.168.67.10 的 HTTP 服务,Keepalived 通过健康检查(/ 路径返回 200)发现异常,将其从 LVS 集群中移除。
-
客户端访问 192.168.67.100 时,所有请求自动转发到正常服务器 192.168.67.20,实现故障隔离。
-
恢复 192.168.67.10 的 HTTP 服务后,Keepalived 重新将其加入集群,请求恢复正常分配
四、总结
4.1.收获和问题
核心收获
-
高性能转发:LVS 的 DR 模式实现零拷贝转发,吞吐量远超 Nginx/HAProxy。例如,在一个大型电商网站的促销活动期间,大量用户同时访问网站,LVS 的 DR 模式能够快速地将请求转发到后端服务器,确保用户能够快速地浏览商品信息和下单。
-
高可用保障:Keepalived 通过 VRRP 和健康检查机制,确保服务 99.99% 可用性。以在线游戏为例,如果游戏服务器的主节点出现故障,Keepalived 能够迅速将 VIP 漂移到备节点,保证玩家不会因为服务器故障而中断游戏。
-
流量调度策略:加权轮询算法有效分配流量,提升资源利用率。在一个视频网站中,不同的服务器性能可能不同,通过设置不同的权重,可以将更多的请求分配到性能较高的服务器上,从而提高整个系统的性能。
问题解决
-
ARP 冲突:通过内核参数抑制后端 RS 的 ARP 响应,避免 VIP 地址冲突。在一个企业的局域网中,如果没有配置 ARP 抑制,可能会出现多个服务器响应同一个 VIP 的 ARP 请求,导致网络通信混乱。通过配置 ARP 抑制,解决了这个问题,保证了网络的正常运行。
-
单点故障:主备架构消除 LVS 节点宕机风险,实现无缝切换。在一个金融交易系统中,如果 LVS 节点出现单点故障,可能会导致交易中断,给企业带来巨大的损失。通过 LVS+Keepalived 的主备架构,当主节点出现故障时,备节点能够迅速接管服务,实现无缝切换,避免了交易中断的风险。
4.2.适用场景
-
高并发 Web 服务:适用于电商、社交平台等高流量场景。例如,淘宝、京东等电商平台在双 11、618 等促销活动期间,会面临巨大的流量压力。LVS+Keepalived 可以将大量的用户请求分发到多个后端服务器上,保证网站的高可用性和高性能。
-
数据库集群:在 MySQL、Redis 等数据库集群中,LVS+Keepalived 可以实现读写分离和负载均衡。例如,在一个新闻网站中,用户的读请求可以通过 LVS 分发到多个从数据库服务器上,写请求则可以发送到主数据库服务器上,提高数据库的读写性能。
-
跨地域负载均衡:结合 TUN 模式支持异地容灾。例如,一家跨国企业在不同的国家和地区都有数据中心,通过 LVS 的 TUN 模式和 Keepalived 的高可用机制,可以将用户的请求分发到距离最近的数据中心,提高用户的访问速度,同时实现异地容灾,保证数据的安全性和可用性。
4.3.对比其他方案
方案 | 优势 | 劣势 |
---|---|---|
HAProxy | 七层功能丰富(HTTP 路由),支持多种负载均衡算法,配置相对简单。例如,在一个需要根据 HTTP 请求的 URL 进行路由的应用场景中,HAProxy 可以很方便地实现。 | 性能低于 LVS,资源消耗较高。在处理大量的并发请求时,HAProxy 的处理能力可能不如 LVS。 |
Nginx | 配置灵活,支持反向代理,同时还可以作为 Web 服务器使用。例如,在一个小型的网站中,Nginx 可以同时作为 Web 服务器和负载均衡器使用。 | 单节点性能有限,需额外高可用方案。如果 Nginx 节点出现故障,需要额外的机制来实现高可用性。 |
F5 硬件 | 全功能支持,性能高,可靠性强。例如,在一些对性能和可靠性要求极高的金融、电信等行业,F5 硬件负载均衡器是一个不错的选择。 | 成本高,闭源难以定制。F5 硬件负载均衡器的价格昂贵,而且由于是闭源产品,难以根据具体需求进行定制。 |
4.4.优化建议
-
性能调优:开启内核参数 net.ipv4.tcp_tw_reuse 减少 TIME_WAIT。在高并发的场景下,大量的 TIME_WAIT 状态会占用系统资源,影响系统的性能。通过开启这个参数,可以复用处于 TIME_WAIT 状态的连接,提高系统的性能。
-
监控告警:集成 Prometheus+Grafana 实时监控集群状态。Prometheus 可以收集集群中各个节点的性能指标,如 CPU 使用率、内存使用率、网络流量等,Grafana 可以将这些指标以直观的图表形式展示出来,并设置告警规则,当指标超过阈值时及时通知管理员。
-
多活架构:部署多个 VRRP 组实现主主模式,提升资源利用率。在一个大型的分布式系统中,可以部署多个 VRRP 组,每个 VRRP 组都有自己的主节点和备节点,不同的 VRRP 组之间可以相互备份,实现主主模式。这样可以充分利用各个节点的资源,提高整个系统的性能和可用性。