目录
一、核心组件与作用
1. LVS（Linux Virtual Server）
2. Keepalived
二、DR 模式下的 LVS + Keepalived 工作原理
1. 整体架构
2. 数据包流向（DR 模式）
三、部署步骤（DR 模式）
3.1 环境规划
3.2 主 / 备 LVS 节点配置（以主节点为例）
（1）基础环境准备
（2）配置 VIP（主 / 备节点均需配置）
（3）配置 Keepalived（主节点）
（4）优化内核参数（主 / 备节点均需配置）
（5）启动服务
3.3 后端 RS 配置（RS1 和 RS2 均需配置）
（1）绑定 VIP 到 lo 接口
（2）优化 ARP 策略（避免 MAC 冲突）
（3）部署 Web 服务
四、测试与验证
五、核心优势与注意事项
优势
注意事项
六、与其他方案对比（LVS+Keepalived vs Nginx/HAProxy）
三种模式的选择依据
一、核心组件与作用
1. LVS（Linux Virtual Server）
- 定位：内核级四层负载均衡器，通过虚拟 IP（VIP）将客户端请求分发到后端真实服务器（Real Server，RS）。
- 核心功能：
- 基于不同模式（DR/NAT/TUN）实现流量转发，其中 DR 模式因高性能成为主流选择。
- 支持多种调度算法（如轮询 rr、加权轮询 wrr 等），实现请求的均衡分发。
- 优势：工作在内核态，转发效率极高，适合高并发场景（百万级并发支撑）。
2. Keepalived
- 定位：基于 VRRP 协议的高可用工具，为 LVS 提供故障转移和健康检查能力。
- 核心功能：
- VIP 漂移：监控 LVS 主节点状态，故障时自动将 VIP 切换到备用节点，避免单点故障。
- 健康检查：检测后端 RS 状态，自动剔除故障节点，确保请求仅分发到正常服务。
- 集群管理：直接集成 LVS 配置，统一管理负载均衡规则。
二、DR 模式下的 LVS + Keepalived 工作原理
1. 整体架构
- 角色分工：
- 主 LVS 节点（MASTER）：承载 VIP，处理并分发客户端请求，发送 VRRP 心跳给备节点。
- 备 LVS 节点（BACKUP）：监听主节点心跳，主节点故障时接管 VIP，继续提供负载均衡。
- 后端 RS：部署 Web 等服务，通过 lo 接口绑定 VIP，直接响应客户端（不经过 LVS）。
- VIP 流转：正常时 VIP 在主 LVS 节点，主节点故障后 VIP 自动漂移到备节点。
2. 数据包流向（DR 模式）
- 客户端 → 主 LVS 节点：客户端请求发送到 VIP，数据包到达主 LVS 内核空间。
- LVS → 后端 RS：LVS 仅修改数据包的目标 MAC 地址（改为目标 RS 的 MAC），IP 地址不变（源 CIP，目标 VIP），通过二层网络发送到 RS。
- RS → 客户端：RS 通过 lo 接口的 VIP 处理请求，响应数据包直接发送给客户端（源 VIP，目标 CIP），不经过 LVS。
三、部署步骤（DR 模式）
3.1 环境规划
| 角色 | IP 地址 | 核心配置 |
|---|---|---|
| 主 LVS（MASTER） | 192.168.10.80 | 绑定 VIP 192.168.10.180 |
| 备 LVS（BACKUP） | 192.168.10.23 | 备用节点，主节点故障时接管 VIP |
| 后端 RS1 | 192.168.10.16 | 部署 Web 服务，lo 接口绑定 VIP |
| 后端 RS2 | 192.168.10.17 | 部署 Web 服务，lo 接口绑定 VIP |
| 客户端 | 192.168.10.100 | 访问 VIP 192.168.10.180 |
3.2 主 / 备 LVS 节点配置（以主节点为例）
（1）基础环境准备
# 关闭防火墙和 SELinux
systemctl stop firewalld && systemctl disable firewalld
setenforce 0 && sed -i 's/SELINUX=enforcing/SELINUX=disabled/' /etc/selinux/config# 安装工具
yum -y install ipvsadm keepalived
modprobe ip_vs # 加载 LVS 内核模块
（2）配置 VIP（主 / 备节点均需配置）
# 创建虚拟网卡配置文件
cd /etc/sysconfig/network-scripts/
cp ifcfg-ens33 ifcfg-ens33:0# 编辑配置（子网掩码必须为 255.255.255.255）
vim ifcfg-ens33:0
DEVICE=ens33:0
ONBOOT=yes
IPADDR=192.168.10.180
NETMASK=255.255.255.255
IPV6INIT=no# 启动虚拟网卡
ifup ens33:0
（3）配置 Keepalived（主节点）
vim /etc/keepalived/keepalived.conf
global_defs {router_id LVS_01 # 主节点标识，备节点改为 LVS_02
}# VRRP 实例（控制 VIP 漂移）
vrrp_instance VI_1 {state MASTER # 备节点改为 BACKUPinterface ens33 # 绑定 VIP 的物理网卡virtual_router_id 10 # 主备节点需一致priority 100 # 主节点优先级高于备节点（备节点设为 90）advert_int 1 # 心跳间隔 1 秒authentication {auth_type PASSauth_pass abc123 # 主备节点认证密码需一致}virtual_ipaddress {192.168.10.180 # VIP 地址}
}# LVS 负载均衡配置
virtual_server 192.168.10.180 80 {delay_loop 6 # 健康检查间隔 6 秒lb_algo rr # 调度算法：轮询lb_kind DR # 模式：DRpersistence_timeout 50 # 会话保持超时 50 秒（同一客户端 50 秒内固定访问同一 RS）protocol TCP# 后端 RS1 配置real_server 192.168.10.16 80 {weight 1 # 权重（越高分配越多请求）TCP_CHECK { # TCP 健康检查connect_port 80connect_timeout 3nb_get_retry 3delay_before_retry 3}}# 后端 RS2 配置real_server 192.168.10.17 80 {weight 1TCP_CHECK {connect_port 80connect_timeout 3nb_get_retry 3delay_before_retry 3}}
}
（4）优化内核参数（主 / 备节点均需配置）
send_redirects：控制当前服务器是否发送 ICMP 重定向报文。
- 取值
1（默认）：允许发送 ICMP 重定向报文。 - 取值
0：禁止发送 ICMP 重定向报文。
关闭 ICMP 重定向的核心目的是 避免客户端绕开负载均衡器直接访问后端服务器，具体原因如下：
-
DR 模式的特殊网络路径：
- 负载均衡器（Director）通过修改 MAC 地址将请求转发给后端服务器。
- 后端服务器处理后，直接通过自己的物理网卡向客户端发送响应（源 IP 是 VIP）。
此时，服务器（后端或 Director）可能会认为 “客户端到 VIP 的最优路径是直接访问后端服务器”，从而发送 ICMP 重定向报文给客户端，导致客户端后续请求直接发给后端服务器（绕过 Director），破坏负载均衡策略。
-
防止路由混乱：
LVS 集群中，VIP 同时存在于 Director 和后端服务器（DR 模式），网络拓扑相对特殊。ICMP 重定向可能会让客户端或中间设备（如交换机）学习到错误的路由规则，导致请求分发异常。
vim /etc/sysctl.conf
net.ipv4.conf.all.send_redirects = 0 控制 ICMP 重定向
net.ipv4.conf.default.send_redirects = 0
net.ipv4.conf.ens33.send_redirects = 0
sysctl -p # 生效配置
（5）启动服务
ip_vs 是 Linux 内核中实现 LVS（Linux Virtual Server，Linux 虚拟服务器）的核心模块，全称为 IP Virtual Server。它是由章文嵩博士主导开发的内核级负载均衡组件，通过在 Linux 内核中直接处理网络数据包，实现了高性能、高可用的 Layer 4（传输层）负载均衡。
ip_vs 的核心作用
ip_vs 运行在 Linux 内核的网络协议栈中，主要负责：
- 接收客户端请求：监听虚拟 IP（VIP）上的服务端口（如 80、443）。
- 负载均衡调度：根据配置的算法（如轮询、权重、IP 哈希等），从后端真实服务器（Real Server）池中选择合适的节点。
- 转发数据包：根据 LVS 的工作模式（NAT/DR/TUN），对数据包进行地址转换、MAC 地址修改或隧道封装，将请求转发到选定的后端服务器。
- 维护连接状态：跟踪客户端与后端服务器的连接，确保同一客户端的请求能被正确转发（如 IP 哈希算法）。
ip_vs 的工作原理
- 内核态处理：
ip_vs直接在内核态工作，避免了用户态与内核态之间的数据拷贝，因此性能远高于基于用户态的负载均衡工具（如 Nginx 作为四层负载均衡时）。 - 依赖 IPVS 管理工具：
ip_vs本身是内核模块，需要通过用户态工具（如ipvsadm或keepalived）进行配置（如定义 VIP、后端服务器、负载策略等）。 - 支持多种转发模式：如前文提到的 NAT、DR、TUN 三种模式，通过不同的数据包处理方式适配不同的网络场景。
ip_vs 与 LVS 的关系
- LVS 是整体架构：包含内核中的
ip_vs模块（负责实际转发）和用户态管理工具（如ipvsadm，负责配置规则）。 - ip_vs 是 LVS 的核心：没有
ip_vs模块，LVS 就无法实现负载均衡功能；用户态工具仅用于配置和管理ip_vs的规则。
使用场景
ip_vs 适用于需要高性能四层负载均衡的场景，例如：
- 大规模 Web 服务集群的入口流量分发。
- 数据库读写分离的连接转发。
- 高并发 TCP/UDP 服务的负载均衡（如游戏服务器、视频流服务）。
systemctl start keepalived
systemctl enable keepalivedipvsadm -ln # 验证 LVS 规则（显示 RR 算法和 DR 模式）
#清除规则
ipvsadm -C
#添加虚拟服务器（VIP），使用轮询算法（rr）
ipvsadm -A -t 192.168.10.180:80 -s rr
#添加后端真实服务器（DR 模式）
ipvsadm -a -t 192.168.10.180:80 -r 192.168.10.16:80 -g
ipvsadm -a -t 192.168.10.180:80 -r 192.168.10.17:80 -g
#保存规则到配置文件
ipvsadm-save > /etc/sysconfig/ipvsadm
systemctl start ipvsadm3.3 后端 RS 配置（RS1 和 RS2 均需配置）
（1）绑定 VIP 到 lo 接口
cd /etc/sysconfig/network-scripts/
cp ifcfg-lo ifcfg-lo:0vim ifcfg-lo:0
DEVICE=lo:0
ONBOOT=yes
IPADDR=192.168.10.180 # 与 LVS 的 VIP 一致
NETMASK=255.255.255.255
IPV6INIT=no# 启动接口并添加路由
ifup lo:0
route add -host 192.168.10.180 dev lo:0 # 确保 VIP 路由指向 lo 接口
（2）优化 ARP 策略（避免 MAC 冲突）
各参数含义
1. arp_ignore：控制是否响应 ARP 请求
- 作用：决定当服务器收到一个 ARP 请求（询问某个 IP 对应的 MAC 地址）时，是否返回自己的 MAC 地址。
- 取值含义：
0（默认）：只要本地配置了该 IP，就响应 ARP 请求（返回自己的 MAC）。1：仅当 ARP 请求的目标 IP 配置在接收请求的网络接口上时，才响应；如果 IP 配置在非接收接口（如 lo 回环接口），则不响应。
2. arp_announce：控制发送 ARP 通告时的源 IP 选择
- 作用：当服务器主动发送 ARP 通告（告知网络中其他设备 “我拥有某个 IP”）时，决定使用哪个 IP 作为源 IP。
- 取值含义：
0（默认）：允许使用任意网络接口上的 IP 作为源 IP 发送 ARP 通告。1：尽量使用与目标 IP 同网段的本地 IP 作为源 IP。2：强制使用发送接口上的 IP 作为源 IP，不允许使用其他接口（如 lo）上的 IP。
vim /etc/sysctl.conf
# 禁止 RS 响应非本地物理 IP 的 ARP 请求
net.ipv4.conf.lo.arp_ignore = 1
net.ipv4.conf.lo.arp_announce = 2
net.ipv4.conf.all.arp_ignore = 1
net.ipv4.conf.all.arp_announce = 2
sysctl -p
（3）部署 Web 服务
yum -y install httpd
systemctl start httpd && systemctl enable httpd# RS1 页面内容
echo 'this is kgc web!' > /var/www/html/index.html
# RS2 页面内容
echo 'this is benet web!' > /var/www/html/index.html
四、测试与验证
- 负载均衡测试：客户端访问
http://192.168.10.180，刷新页面（间隔超过 50 秒），应轮询显示 RS1 和 RS2 的页面。 - 高可用测试：
- 停止主 LVS 节点的 Keepalived：
systemctl stop keepalived。 - 在备节点执行
ip addr，确认 VIP 已漂移到备节点。 - 客户端继续访问 VIP，服务正常（由备节点分发请求）。
- 重启主节点 Keepalived，VIP 自动回归（默认抢占模式）。
- 停止主 LVS 节点的 Keepalived：
五、核心优势与注意事项
优势
- 高性能：DR 模式下 LVS 仅修改 MAC 地址，转发效率极高，适合高并发。
- 高可用：Keepalived 实现 VIP 漂移，避免 LVS 节点单点故障。
- 灵活性：支持多种调度算法，可根据 RS 性能调整权重。
注意事项
- 网络要求：LVS 节点与 RS 必须在同一物理网段（DR 模式限制）。
- ARP 策略：RS 必须配置
arp_ignore和arp_announce，否则会导致 VIP 冲突。 - 会话保持：
persistence_timeout需根据业务场景调整（如静态页面可设为 0）。 - 脑裂防护：通过双心跳线、仲裁 IP（如网关）避免主备节点同时争抢 VIP。
六、与其他方案对比（LVS+Keepalived vs Nginx/HAProxy）
| 特性 | LVS + Keepalived | Nginx | HAProxy |
|---|---|---|---|
| 工作层级 | 四层（内核态） | 四层 + 七层（应用态） | 四层 + 七层（应用态） |
| 性能 | 最高（百万级并发） | 高（十万级并发） | 高（接近 Nginx） |
| 健康检查 | 依赖 Keepalived 脚本 / TCP 检查 | 简单 HTTP/TCP 检查 | 强大（支持多种协议） |
| 适用场景 | 超大规模集群、高并发 | 中小型集群、需七层转发（如 URL 路由） | 高可用集群、复杂健康检查需求 |
三种模式的选择依据
| 模式 | 核心适用场景 | 与 Keepalived 结合的优势 | 典型业务场景 |
|---|---|---|---|
| DR | 同网段、高并发、高性能要求 | 性能最优，适合大规模集群，Keepalived 保障 VIP 高可用 | 电商、门户等高流量网站 |
| NAT | 跨网段、小规模集群、需隐藏后端 IP | 部署灵活，适合简单网络，Keepalived 简化故障转移 | 小型应用、内部服务 |
| TUN | 跨地域、分布式部署，需避免 NAT 瓶颈 | 支持广域网负载均衡，Keepalived 确保隧道节点高可用 | 跨数据中心集群、分布式服务 |
通过 LVS + Keepalived 的组合，可构建兼具高性能和高可用性的负载均衡架构，是企业级核心服务的理想选择。
` 、`max()`、 `clamp()`)
问题详解)
![[Windows] PDF 专业压缩工具 v3.0](http://pic.xiahunao.cn/[Windows] PDF 专业压缩工具 v3.0)