一、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 # 注意：子网掩码为 322.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 -p2.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 --system2.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 httpd2.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 备节点需要设置为 BACKUP
interface ens160 # Keepalived 监听 VRRP 通告和绑定 VIP 的网络接口
virtual_router_id 100 # VRRP 组的唯一标识符，同一组内的实例此 ID 需相同
priority 100 # 当前实例的优先级，数值越高越优先成为主节点
# 注意：备节点，优先级需要设置为 80
advert_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 地址需要设置为本机 IP
unicast_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 组之间可以相互备份，实现主主模式。这样可以充分利用各个节点的资源，提高整个系统的性能和可用性。
