一、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 组之间可以相互备份，实现主主模式。这样可以充分利用各个节点的资源，提高整个系统的性能和可用性。