Linux中的LVS集群技术
一、实验环境（RHEL 9）
1、NAT模式的实验环境
| 主机名 | IP地址 | 网关 | 网络适配器 | 功能 | 角色 |
|---|---|---|---|---|---|
| client | 172.25.254.111/24（NAT模式的接口） | 172.25.254.2 | NAT模式 | 客户机 | |
| lvs | 172.25.254.100/24（NAT模式的接口） 192.168.0.100/24（仅主机模式的接口） | 172.25.254.2 192.168.0.2 | NAT模式 仅主机模式 | 开启内核路由功能： echo net.ipv4.ip_forward = 1 > /etc/sysctl.conf | 负载均衡器 |
| RS1 | 192.168.0.10/24（仅主机模式的接口） | 192.168.0.100 | 仅主机模式 | 后端服务器1 | |
| RS2 | 192.168.0.20/24（仅主机模式的接口） | 192.168.0.100 | 仅主机模式 | 后端服务器2 |
在RS1和RS2中下载http，并且在默认发布目录文件中写入对应的内容，例如RS1写入RS1 - 192.168.0.10，RS2写入RS2 - 192.168.0.20。
[root@RS1 桌面]# dnf install httpd -y
[root@RS1 桌面]# systemctl disable --now firewalld.service
Removed "/etc/systemd/system/multi-user.target.wants/firewalld.service".
Removed "/etc/systemd/system/dbus-org.fedoraproject.FirewallD1.service".
[root@RS1 桌面]# echo RS1 - 192.168.0.10 > /var/www/html/index.html
[root@RS1 桌面]# systemctl enable --now httpd
Created symlink /etc/systemd/system/multi-user.target.wants/httpd.service → /usr/lib/systemd/system/httpd.service.
[root@RS2 桌面]# dnf install httpd -y
[root@RS2 桌面]# systemctl disable --now firewalld.service
Removed "/etc/systemd/system/multi-user.target.wants/firewalld.service".
Removed "/etc/systemd/system/dbus-org.fedoraproject.FirewallD1.service".
[root@RS2 桌面]# echo RS2 - 192.168.0.20 > /var/www/html/index.html
[root@RS2 桌面]# systemctl enable --now httpd
Created symlink /etc/systemd/system/multi-user.target.wants/httpd.service → /usr/lib/systemd/system/httpd.service.
确保lvs可以通过curl访问RS1和RS2。
2、DR模式的实验环境
| 主机名 | IP地址 | 网关 | 网络适配器 | 功能 | 角色 |
|---|---|---|---|---|---|
| client | 172.25.254.111/24（NAT模式的接口） | 172.25.254.100 | NAT模式 | 客户机 | |
| router | 172.25.254.100/24（NAT模式的接口） 192.168.0.100/24（仅主机模式的接口） | 不需要网关 | NAT模式 仅主机模式 | 开启内核路由功能： echo net.ipv4.ip_forward = 1 > /etc/sysctl.conf | 路由器 |
| DR-lvs | 192.168.0.200/24和192.168.0.220/24（仅主机模式的接口） 127.0.0.1/8和192.168.0.220/32（回环接口） | 192.168.0.100 | 仅主机模式 回环接口 | 负载均衡器 | |
| RS1 | 192.168.0.10/24（仅主机模式的接口） 127.0.0.1/8和192.168.0.220/32（回环接口） | 192.168.0.100 | 仅主机模式 回环接口 | 后端服务器1 | |
| RS2 | 192.168.0.20/24（仅主机模式的接口） 127.0.0.1/8和192.168.0.220/32（回环接口） | 192.168.0.100 | 仅主机模式 回环接口 | 后服务器2 |
配置回环接口IP地址的示例：
此回环接口IP地址的配置在DR-lvs、RS1、RS2上都要进行配置。
在DR-lvs上的额外配置：
需要在仅主机模式的这个接口上新添加一个192.168.0.220/24的IP地址
二、LVS集群的4种类型
LVS（Linux Virtual Server）是基于 Linux 内核的开源负载均衡解决方案，通过将多个服务器组成一个集群，实现高可用、高性能的服务。LVS 支持四种核心的集群类型（工作模式），它们在数据包转发方式、架构复杂度和适用场景上有显著区别：
1. NAT 模式（Virtual Server via Network Address Translation）
核心原理
LVS 负载均衡器作为流量的「双向网关」，通过修改数据包的 IP 地址实现转发，具体流程如下：
客户端请求（入站）：
客户端向 LVS 的 VIP（虚拟 IP）发送请求，数据包源 IP 为客户端 IP，目标 IP 为 VIP。
LVS 接收后，仅修改目标 IP（将 VIP 替换为后端 RS 的私有 IP），源 IP 保持不变（仍为客户端 IP），然后转发给选定的 RS。RS 响应（出站）：
RS 处理请求后，生成响应包，目标 IP 为客户端 IP（因源 IP 未被修改），源 IP 为自身私有 IP。
由于 RS 的默认网关指向 LVS，响应包会先回传给 LVS。
LVS 接收后，修改源 IP（将 RS 的私有 IP 替换为 VIP），再将数据包转发给客户端。
架构特点
流量路径：所有入站和出站流量必须经过 LVS，形成「客户端 → LVS → RS → LVS → 客户端」的闭环。
网络要求：LVS 与 RS 必须在同一子网（因依赖 LVS 作为网关），RS 的网关必须手动指向 LVS 的 IP。
VIP 配置：仅 LVS 需配置 VIP，RS 无需绑定 VIP（隐藏在私有子网中）。
优缺点
优点：
配置简单，RS 无需特殊设置（仅需指向 LVS 为网关）。
支持任意 TCP/UDP 服务（如数据库、FTP 等），兼容性强。
安全性高，RS 隐藏在私有网络，不直接暴露给客户端。
缺点：
LVS 是流量瓶颈（所有数据需经其转发），性能受限于 LVS 的带宽和处理能力。
仅适用于小规模集群（通常 RS 数量 ≤ 20 台）。
适用场景
小规模集群（如内部业务系统、低并发服务）。
对安全性要求高（需隐藏 RS 真实 IP）。
服务类型复杂（如需要双向交互的协议）。
2. DR 模式（Virtual Server via Direct Routing）
核心原理
LVS 仅处理入站请求，通过修改数据包的 MAC 地址 而非 IP 地址转发，出站流量由 RS 直接返回客户端，流程如下：
客户端请求（入站）：
客户端向 VIP 发送请求，数据包源 IP 为客户端 IP，目标 IP 为 VIP，目标 MAC 地址为 LVS 的 MAC。
LVS 接收后，不修改 IP 地址（源 IP 和目标 IP 保持不变），仅将目标 MAC 地址替换为选定 RS 的 MAC 地址，然后通过二层网络（交换机）转发给 RS。RS 响应（出站）：
RS 已预先绑定 VIP（需配置在回环接口或禁用 ARP 响应，避免冲突），因此会接收目标 IP 为 VIP 的数据包。
RS 处理后，直接以客户端 IP 为目标、VIP 为源 IP 发送响应包，通过自身网络接口直接返回给客户端，无需经过 LVS。
架构特点
流量分离：入站流量经 LVS，出站流量由 RS 直连客户端，LVS 负载极大降低。
VIP 配置：LVS 和所有 RS 必须绑定相同的 VIP（LVS 用于接收请求，RS 用于响应客户端）。
网络要求：LVS 与 RS 必须在同一物理子网（二层可达），因依赖 MAC 地址转发。
ARP 抑制：RS 需配置内核参数（如
arp_ignore=1、arp_announce=2），避免对 VIP 的 ARP 请求做出响应，防止客户端直接连接 RS。
优缺点
优点：
性能极高（LVS 仅处理入站流量，无 IP 修改开销），支持大规模集群（RS 可达数百台）。
出站流量不经过 LVS，避免瓶颈。
缺点：
网络拓扑受限（必须同一子网），跨网段部署困难。
RS 配置较复杂（需绑定 VIP 并抑制 ARP）。
适用场景
高并发 Web 服务（如 HTTP/HTTPS）。
大规模集群（如电商平台、内容分发节点）。
对响应速度要求极高的场景（如实时交互服务）。
3. TUN 模式（Virtual Server via IP Tunneling）
核心原理
通过 IP 隧道技术（如 IPIP、GRE）将客户端请求封装后转发给 RS，突破子网限制，流程如下：
客户端请求（入站）：
客户端向 VIP 发送请求，LVS 接收后，将原始数据包（源 IP：客户端 IP，目标 IP：VIP）封装在新的 IP 隧道中：外层隧道的源 IP 为 LVS 的 IP，目标 IP 为 RS 的隧道 IP（RS 预先配置的公网或跨网段 IP）。
LVS 将封装后的数据包发送给 RS。
RS 响应（出站）：
RS 解封装隧道包，获取原始请求（目标 IP 为 VIP），因自身已绑定 VIP，可直接处理请求。
响应包以客户端 IP 为目标、VIP 为源 IP，通过自身网络直接返回客户端，无需经过 LVS。
架构特点
跨网络部署：LVS 与 RS 可位于不同子网、不同机房甚至跨公网（依赖隧道协议）。
流量分离：入站流量经隧道转发，出站流量由 RS 直连客户端。
VIP 配置：LVS 和所有 RS 需绑定相同的 VIP（RS 绑定在隧道接口或回环接口）。
优缺点
优点：
扩展性极强，支持跨地域集群（如多机房部署）。
性能优于 NAT 模式（出站流量不经过 LVS）。
缺点：
隧道封装增加网络开销（约 20-40 字节 / 包），对高频小数据包影响较明显。
需配置隧道协议（如 IPIP、GRE），RS 配置较复杂。
适用场景
跨地域分布式集群（如 CDN 节点、多区域云服务）。
突破子网限制的大规模集群（如跨数据中心负载均衡）。
4. Full-NAT 模式（Virtual Server via Full Network Address Translation）
核心原理
LVS 同时修改数据包的 源 IP 和目标 IP，实现「双向地址转换」，流程如下：
客户端请求（入站）：
客户端向 VIP 发送请求，源 IP 为客户端 IP，目标 IP 为 VIP。
LVS 接收后，同时修改源 IP 和目标 IP：源 IP：客户端 IP → LVS 的私有 IP（避免 RS 直接与客户端通信）。
目标 IP：VIP → RS 的私有 IP。
然后将修改后的数据包转发给 RS。
RS 响应（出站）：
RS 处理后，生成响应包，源 IP 为自身私有 IP，目标 IP 为 LVS 的私有 IP（因入站时源 IP 已被修改）。
响应包回传给 LVS 后，LVS 将源 IP 替换为 VIP，目标 IP 替换为客户端 IP，再返回给客户端。
架构特点
网络灵活性：LVS 与 RS 无需同一子网，RS 的网关无需指向 LVS（只需能与 LVS 通信即可）。
双向流量经过 LVS：因源 IP 被修改，RS 无法直接响应客户端，必须经 LVS 转发。
状态跟踪：LVS 需维护连接状态表（记录客户端 IP 与 RS 的映射），确保响应包正确转发。
优缺点
优点：
网络部署灵活，支持复杂拓扑（如 LVS 在公网、RS 在内网不同子网）。
可隐藏客户端真实 IP（RS 仅能看到 LVS 的私有 IP），安全性高于 DR/TUN 模式。
缺点：
LVS 处理所有双向流量，性能低于 DR/TUN 模式，易成为瓶颈。
需内核支持
ip_vs_fullnat模块（部分 Linux 发行版默认不启用）。
适用场景
网络架构复杂（LVS 与 RS 跨子网、跨 VLAN）。
需隐藏客户端 IP（如防止 RS 被直接攻击）。
无法使用 DR/TUN 模式的场景（如 RS 无法绑定 VIP）。
四种模式核心差异对比表
| 维度 | NAT 模式 | DR 模式 | TUN 模式 | Full-NAT 模式 |
|---|---|---|---|---|
| IP 修改 | 入站改目标 IP，出站改源 IP | 不修改 IP，改 MAC 地址 | 不修改 IP，隧道封装 | 入站同时改源 IP 和目标 IP |
| 流量路径 | 双向经 LVS | 入站经 LVS，出站 RS 直连 | 入站经隧道，出站 RS 直连 | 双向经 LVS |
| 网络范围 | 同一子网 | 同一物理子网（二层可达） | 跨子网 / 跨地域（依赖隧道） | 任意网络（可跨子网） |
| 性能 | 低（瓶颈在 LVS） | 极高（仅入站经 LVS） | 中高（隧道有开销） | 中（双向经 LVS） |
| RS 网关配置 | 必须指向 LVS 的内网 IP | 无需指向 LVS（可独立设置网关） | 无需指向 LVS（可独立设置网关） | 无需指向 LVS（独立网关） |
| RS 配置复杂度 | 低（仅需设网关） | 中（需抑制 ARP + 绑定 VIP） | 高（需配置隧道 + 绑定 VIP） | 低（无需绑定 VIP） |
| 典型场景 | 小规模集群、数据库 | Web 服务、大规模集群 | 跨地域集群、CDN | 复杂网络架构、安全需求 |
三、LVS中的13种调度算法
LVS（Linux Virtual Server）提供了多种调度算法，用于决定如何将客户端请求分配给后端服务器（RS）。这些算法可分为静态调度（不考虑服务器负载）和动态调度（基于服务器实时负载）两类，共 13 种核心算法。以下是详细解析：
1、静态调度算法（不考虑服务器负载）
1. 轮询（Round Robin, rr）
原理：按顺序依次将请求分配给 RS，循环往复。
优点：实现简单，适用于各 RS 性能相近的场景。
缺点：忽略服务器实际负载和处理能力差异，可能导致性能不均衡。
示例：有三台RS：访问顺序为RS1 → RS2 → RS3 → RS1 → RS2 → RS3 → ...
2. 加权轮询（Weighted Round Robin, wrr）
原理：根据 RS 的性能（如 CPU、内存、带宽）分配权重，权重高的服务器接收更多请求。
公式：请求数分配比例 = 服务器权重 / 总权重。
优点：优化资源利用率，适合硬件配置差异较大的集群。
示例：根据权重，访问RS1三次后，访问RS2两次，最后再访问RS31次，然后就是重复以上访问顺序。RS1(3) → RS2(2) → RS3(1) → RS1(3) → RS2(2) → ...
3. 源地址哈希（Source Hashing, sh）
原理：根据客户端 IP 地址计算哈希值，将同一 IP 的请求始终路由到固定 RS。
公式：RS = Hash (Client_IP) % 服务器数量。
优点：实现会话粘滞（Sticky Session），适合需保持会话状态的服务（如购物车）。
缺点：可能导致负载分布不均（如大量请求来自同一 IP 段）。
4. 目标地址哈希（Destination Hashing, dh）
原理：根据请求的目标 IP（如 VIP）或端口计算哈希值，固定路由到同一 RS。
适用场景：内容分发网络（CDN）、反向代理缓存（如缓存服务器集群）。
区别：与源地址哈希的方向相反，常用于服务器间负载均衡。
5. IP 链（IP Link, ipip）
原理：基于 IP 地址的前缀匹配，将特定 IP 段的请求路由到指定 RS。
配置：需手动指定 IP 段与 RS 的映射关系。
示例：
plaintext
192.168.1.0/24 → RS1 192.168.2.0/24 → RS2
6. 通用哈希（Generic Hashing, gh）
原理：允许用户自定义哈希函数，基于任意请求参数（如 URL、HTTP 头）进行调度。
优点：灵活性高，适合特殊业务需求（如按 URL 路径分流）。
实现：需通过内核模块或自定义代码扩展。
2、动态调度算法（基于服务器负载）
7. 最小连接（Least Connections, lc）
原理：优先将请求分配给当前活跃连接数最少的 RS。
公式：选择
Active_Connections / Weight值最小的服务器。优点：自动平衡负载，适合长连接服务（如数据库、SSH）。
缺点：对短连接服务（如 HTTP）效果有限。
8. 加权最小连接（Weighted Least Connections, wlc）
原理：在最小连接基础上，考虑服务器权重（权重高的服务器可承受更多连接）。
公式：选择
Active_Connections / Weight值最小的服务器。示例：RS1 (权重 5) 当前 50 连接，RS2 (权重 1) 当前 10 连接，则优先分配给 RS2（50/5 > 10/1）。
9. 基于局部性的最小连接（Locality-Based Least Connections, lblc）
原理：结合源地址哈希和最小连接算法：
优先将同一 IP 的请求路由到上次处理的 RS（会话粘滞）。
若该 RS 过载（连接数超过阈值），则分配给连接数最少的 RS。
适用场景：缓存集群（如 Redis），减少缓存失效。
10. 带复制的基于局部性的最小连接（Locality-Based Least Connections with Replication, lblcr）
原理：在 lblc 基础上，增加 “复制” 机制：
当请求频繁访问某 RS 时，将该 RS 的内容复制到其他服务器（降低单点负载）。
适用场景：内容分发网络（CDN），通过复制热点内容提升响应速度。
11. 目标地址哈希的最小连接（Destination Hashing with Least Connections, dh-lc）
原理：结合目标地址哈希和最小连接算法：
先按目标 IP 哈希选择候选 RS 列表。
再从候选列表中选择连接数最少的 RS。
适用场景：负载均衡器后端连接多个上游服务器（如反向代理）。
12. 最短预期延迟（Shortest Expected Delay, sed）
原理：计算每个 RS 的预期处理延迟，选择延迟最小的服务器。
公式：预期延迟 = (Active_Connections + 1) / Weight。
特点：相比 wlc，更倾向于分配请求给轻载服务器（避免重载服务器持续过载）。
13. 最少队列调度（Never Queue, nq）
原理：若有服务器处于空闲状态（连接数为 0），直接分配；否则使用 sed 算法。
优点：避免请求排队，适合对响应时间敏感的服务。
3、内核 4.15 版本后的新增调度算法
1. 加权故障转移（Weighted Fail Over, FO）
原理：遍历虚拟服务关联的真实服务器（RS）链表，优先选择未过载且权重最高的 RS 进行调度。当 RS 被标记为 “过载”（通过设置IP_VS_DEST_F_OVERLOAD标志）时，调度器会自动跳过该 RS，将请求转发至其他符合条件的 RS。
优点：
支持通过 “过载标记” 主动剔除故障或负载过高的节点，提高集群稳定性。
权重机制可优先调度性能更强的 RS（权重高的节点优先处理请求），资源利用率更合理。
适合灰度发布场景：可通过调整权重或标记过载，逐步将流量切换到新节点。
缺点：
依赖人工或外部监控系统标记 “过载” 状态，若标记不及时可能导致请求分配不合理。
未考虑 RS 实时连接数等动态负载，仅通过权重和过载状态调度，可能在高负载时不够灵活。
适用场景：
灰度发布、A/B 测试（通过权重控制流量比例）。
需要手动干预节点状态的场景（如临时下线维护）。
对节点故障敏感的服务（快速剔除异常节点）。
2. 溢出连接（Overflow-connection, OVF）
原理：基于 RS 的权重值和当前活动连接数调度，优先选择权重最高的 RS，直到其活动连接数超过权重值（即 “溢出”），再依次调度下一个权重最高的 RS。判断条件为：
RS 未过载（未设置
IP_VS_DEST_F_OVERLOAD标志）。活动连接数 < 权重值（权重值不为 0）。
优点：
自动根据 RS 的承载能力（权重）分配连接，避免单一节点负载过高（活动连接数不超过权重上限）。
权重机制确保性能强的 RS（高权重）能处理更多连接，资源分配更均衡。
无需复杂的负载计算，调度逻辑简单，性能开销低。
缺点：
仅依赖活动连接数和权重，未考虑非活动连接等其他负载指标，对长连接场景的适应性有限。
若所有高权重 RS 均 “溢出”，低权重 RS 可能因突然承接大量请求而压力骤增。
适用场景：
短连接服务（如 Web 服务），活动连接数能较好反映负载状态。
对调度效率要求高、节点性能差异明显的集群。
需要限制单节点最大连接数的场景（通过权重控制上限）。
四、ipvsadm命令
ipvsadm的操作类型参数
用于指定要执行的操作（必选）：
| 参数 | 全称 | 作用 |
|---|---|---|
-A | --add-service | 添加虚拟服务（VIP + 端口）。 |
-E | --edit-service | 修改已存在的虚拟服务配置。 |
-D | --delete-service | 删除虚拟服务。 |
-a | --add-server | 为虚拟服务添加后端服务器（Real Server）。 |
-e | --edit-server | 修改后端服务器配置。 |
-d | --delete-server | 删除后端服务器。 |
-L | --list | 显示当前 IPVS 配置（需配合 -t、-u 或 -f 指定服务类型）。 |
-Z | --zero | 清空所有服务和服务器的统计信息（连接数、流量等）。 |
-S | --save | 导出当前 IPVS 配置为脚本（用于备份）。 |
-R | --restore | 从脚本恢复 IPVS 配置。 |
ipvsadm的服务类型参数
用于指定虚拟服务的协议类型（配合 -A、-D、-L 等使用）：
| 参数 | 作用 |
|---|---|
-t | TCP 服务，格式：-t IP:port（如 -t 192.168.1.1:80）。 |
-u | UDP 服务，格式：-u IP:port（如 -u 192.168.1.1:53）。 |
-f | 防火墙标记服务，用于基于 iptables 标记的负载均衡。 |
ipvsadm的负载均衡算法参数
通过 -s 指定调度算法（添加虚拟服务时使用）：
| 参数值 | 全称 | 算法说明 |
|---|---|---|
rr | Round Robin | 轮询，按顺序依次分发请求。 |
wrr | Weighted RR | 加权轮询，根据服务器性能分配权重。 |
lc | Least Connections | 最少连接，优先将请求分发到连接数最少的服务器。 |
wlc | Weighted LC | 加权最少连接，默认算法，在最少连接基础上考虑权重。 |
sh | Source Hashing | 源 IP 哈希，相同 IP 的客户端总是被分发到同一服务器（适用于会话保持）。 |
dh | Destination Hashing | 目标 IP 哈希，根据目标 IP 进行哈希（适用于缓存集群）。 |
lblc | Locality-Based LC | 基于位置的最少连接，用于缓存集群。 |
ipvsadm的工作模式参数
通过 -m、-g、-i 指定后端服务器的工作模式（添加 Real Server 时使用）：
| 参数 | 全称 | 模式说明 |
|---|---|---|
-m | --masquerading | NAT 模式，负载均衡器处理请求和响应，需与 RS 在同一网络。 |
-g | --gatewaying | DR 模式（直接路由），负载均衡器仅处理请求，响应直接由 RS 返回。 |
-i | --ipip | TUN 模式（IP 隧道），通过隧道连接负载均衡器和 RS，适合跨地域部署。 |
ipvsadm的其他常用参数
| 参数 | 作用 |
|---|---|
-n | 以数字形式显示 IP 和端口（如 192.168.1.1:80 而非域名）。 |
-c | 显示当前 IPVS 连接信息（配合 -L 使用）。 |
-p [秒数] | 设置会话保持时间（如 -p 3600 表示 1 小时内同一客户端请求到同一 RS）。 |
-w [权重] | 设置后端服务器的权重（如 -w 3 表示权重为 3，默认 1）。 |
--persistent-conn-timeout [秒数] | 持久连接超时时间（如 -p 360）。 |
--scheduler [算法] | 替代 -s 指定调度算法（如 --scheduler wrr）。 |
核心功能:
1、集群服务管理：增、删、改。 对应下面的定义虚拟服务（Virtual Service）--- 即管理集群服务。
2、集群服务的RS管理：增、删、改。 对应下面的添加 / 删除后端服务器（Real Server）--- 即管理集群服务中的Real Server服务器。
3、查看配置
1、负载均衡配置
1. 定义虚拟服务（Virtual Service）
创建对外提供服务的虚拟 IP（VIP）和端口，并指定负载均衡算法：
# 添加 TCP 虚拟服务（VIP:192.168.1.100，端口:80，轮询算法）
ipvsadm -A -t 192.168.1.100:80 -s rr# 添加 UDP 虚拟服务（如 DNS 负载均衡）
ipvsadm -A -u 192.168.1.100:53 -s wrr # 加权轮询
2. 添加 / 删除后端服务器（Real Server）
将实际提供服务的服务器加入或移出负载均衡池：
# 添加后端服务器（-m: NAT 模式；-g: DR 模式；-i: TUN 模式）
ipvsadm -a -t 192.168.1.100:80 -r 192.168.1.101:80 -m -w 1 # 权重为 1# 删除后端服务器
ipvsadm -d -t 192.168.1.100:80 -r 192.168.1.101:80
2、负载均衡算法及其适用场景
通过 -s 参数指定调度算法，支持多种策略：
| 算法 | 缩写 | 说明 |
|---|---|---|
| 轮询 | rr | 按顺序依次分发请求，适用于服务器性能相近的场景。 |
| 加权轮询 | wrr | 根据服务器性能分配权重（-w 参数），性能强者处理更多请求。 |
| 最少连接 | lc | 将请求分发到当前连接数最少的服务器，动态平衡负载。 |
| 加权最少连接 | wlc | 在最少连接基础上考虑服务器权重，默认算法。 |
| 源 IP 哈希 | sh | 相同 IP 的客户端总是被分发到同一服务器，适用于会话保持。 |
| 目标 IP 哈希 | dh | 根据目标 IP 进行哈希，适用于缓存服务器集群。 |
3、工作模式配置
通过 -m、-g、-i 参数指定工作模式：
| 模式 | 参数 | 说明 |
|---|---|---|
| NAT | -m | 网络地址转换，负载均衡器处理请求和响应，需与 RS 在同一网络。 |
| DR（直接路由） | -g | 负载均衡器仅处理请求，响应直接由 RS 返回给客户端，性能最优。 |
| TUN（IP 隧道） | -i | 通过 IP 隧道连接负载均衡器和 RS，适合跨地域部署。 |
4、查看与管理
1. 显示当前配置
ipvsadm -L -n # 查看所有虚拟服务和后端服务器（数字形式显示 IP:Port）
ipvsadm -L -n -c # 查看当前连接和统计信息
ipvsadm -L -t 192.168.1.100:80 # 查看特定虚拟服务的配置
2. 清空统计信息
ipvsadm -Z # 重置所有服务和服务器的连接计数器和流量统计
3. 持久化配置
ipvsadm-save > /etc/sysconfig/ipvsadm # 保存当前配置到文件
ipvsadm-restore < /etc/sysconfig/ipvsadm # 从文件恢复配置
5、高级功能
1. 会话保持（Persistence）
让同一客户端的请求始终被转发到同一服务器：
# 设置 3600 秒的会话保持时间
ipvsadm -A -t 192.168.1.100:80 -s rr -p 3600
2. 健康检查
结合外部监控工具（如 keepalived）自动检测服务器状态，失效时自动移除：
# 配置 keepalived 监控 RS 状态（示例片段）
real_server 192.168.1.101 80 {weight 1SSL_GET {url { path /healthcheck }url { path / }connect_timeout 3retry 3delay_before_retry 3}
}五、部署NAT模式的LVS集群示例
LVS NAT 模式
工作层级：第 3 层（网络层）
原因：
NAT 模式中，负载均衡器需要对数据包的 源 IP 和目标 IP 进行修改（网络层操作）。客户端请求到达负载均衡器时，目标 IP 被修改为后端服务器的私有 IP；
后端服务器响应时，源 IP 被修改为负载均衡器的公网 IP，再返回给客户端。
整个过程仅涉及 IP 地址的转换，不处理端口（传输层）或应用层数据，因此工作在网络层。
注意：如果有类似下图的错误，可能是防火墙没有关闭，可以使用 systemctl disable --now firewalld.service 这条命令关闭防火墙后再试。
1、在lvs调度机中开启内核路由功能
2、在lvs调度机中安装ipvsadm
ipvsadm 是 Linux 系统中用于管理 IP 虚拟服务器（IP Virtual Server，IPVS） 的工具，它是 LVS（Linux Virtual Server）项目的核心组件。IPVS 是 Linux 内核的一部分，提供高性能的负载均衡功能，常用于构建大规模、高可用的服务器集群。
3、在lvs调度机中添加调度策略
4、查看添加的调度策略
[root@lvs 桌面]# watch -n1 ipvsadm -Ln #可以使用这条命令监视调度策略的改动
| 字段 | 含义说明 |
|---|---|
RemoteAddress:Port | 后端真实服务器（Real Server）的 IP 地址和端口号。 |
Forward | LVS 采用的转发模式（调度算法的转发方式），常见值包括： - Route：DR 模式（直接路由）- Tunnel：TUN 模式（隧道）- Masq：NAT 模式（网络地址转换） |
Weight | 后端服务器的权重值（正数）。权重越高，分配到的请求越多；权重为 0 时，该服务器暂时不接收新请求。 |
ActiveConn | 当前活跃连接数（正在处理的请求数）。 |
InActConn | 当前非活跃连接数（已关闭或超时的连接数，用于统计历史连接）。 |
| 字段 | 含义 |
|---|---|
Pro | 协议类型（如 TCP、UDP）。 |
FromIP | 客户端源 IP 地址。 |
FPrt | 客户端源端口。 |
ToIP | 目标 IP 地址（即虚拟服务 VIP）。 |
TPrt | 目标端口（即虚拟服务端口）。 |
DestIP | 实际转发到的后端服务器（Real Server）IP 地址。 |
DPrt | 后端服务器端口。 |
State | 连接状态，常见值包括： - ESTABLISHED：已建立的连接- SYN_SENT：已发送 SYN 包- SYN_RECV：已接收 SYN 包- FIN_WAIT：等待 FIN 包- CLOSE_WAIT：等待关闭- TIME_WAIT：等待超时关闭 |
Expires | 连接超时剩余秒数（连接保持时间）。 |
PEName | 持久化引擎名称（如 sh 表示源 IP 哈希），用于会话保持。 |
PEData | 持久化引擎数据（如哈希值或会话 ID）。 |
5、测试：使用client主机循环访问lvs调度机六次之后，再查看调度策略中连接数的改变
6、保存调度策略
7、删除所有调度策略
8、重新加载调度策略
9、以上操作均为临时的重新加载调度策略的操作，如果想要让ipvsadm开机启动时自动加载策略
需要设置此服务开机自启动，而且需要/etc/sysconfig/ipvsadm 文件存在。
因为在大多数 Linux 发行版中，ipvsadm 服务的默认配置通常会加载 /etc/sysconfig/ipvsadm（或类似路径）中的规则。例如：
CentOS/RHEL 系统：
ipvsadm 服务脚本默认读取 /etc/sysconfig/ipvsadm 文件：
# 服务脚本片段（通常位于 /usr/lib/systemd/system/ipvsadm.service）
ExecStart=/sbin/ipvsadm-restore < /etc/sysconfig/ipvsadm
Ubuntu/Debian 系统：
可能使用不同的路径（如 /etc/ipvsadm.rules），需检查服务配置。
测试：
重启后发现调度策略仍然存在，说明设置成功
10、再次测试：修改为权重调用算法后，修改real server的权重，然后再次测试
因为我们上面的示例用的就是权重调用算法，所以可以不需要修改策略的算法，只需要修改real server的权重来进行测试。
修改权重后进行测试：
此结果说明权重调用算法和real server的权重修改成功。
六、部署DR模式的LVS集群示例
LVS DR 模式
工作层级：第 2 层（数据链路层）
原因：
DR 模式中，负载均衡器仅修改数据包的 目标 MAC 地址（数据链路层操作），不改变 IP 地址。客户端请求的目标 IP 始终是 VIP（负载均衡器和后端服务器共享的虚拟 IP）；
负载均衡器通过修改 MAC 地址，将数据包转发到选定的后端服务器；
后端服务器直接使用 VIP 作为源 IP 响应客户端，无需经过负载均衡器。
由于核心操作是 MAC 地址的替换，因此工作在数据链路层。
1、配置好网络环境，确保主机能互通（具体配置看第一大点的实验环境）
2、在router主机中的防火墙中启用 IP 伪装（Masquerading）功能，实现网络地址转换（NAT）。
3、DR模式中需要在LVS集群的各主机上均需要配置VIP，所以我们需要解决地址冲突。
在 LVS 的 DR 模式（Direct Routing）中，VIP（虚拟 IP）需要同时配置在 负载均衡器（Director） 和 所有后端服务器（Real Server） 上，但为了避免 ARP 地址冲突（多个设备响应同一个 VIP 的 ARP 请求），需要通过特殊配置确保：
只有负载均衡器响应 VIP 的 ARP 请求。
后端服务器静默处理 VIP，不响应 ARP 请求。
解决方案：ARP 抑制配置
参数作用详解
| 参数 | 值 | 作用 |
|---|---|---|
arp_ignore | 0 | 只要本地 IP 存在，无论哪个接口收到 ARP 请求，都响应。 |
| 1 | 仅当请求的 IP 严格配置在接收 ARP 请求的接口上时，才响应。 | |
arp_announce | 0 | 允许使用任意接口的 MAC 地址响应 ARP（可能导致混乱）。 |
| 2 | 仅使用严格配置了该 IP 的接口的 MAC 地址响应 ARP（最严格模式）。 |
通过调整内核参数 arp_ignore 和 arp_announce 来控制 ARP 响应行为：
1. 后端服务器配置（关键！）
在每个 后端服务器（Real Server） 上添加以下配置：
# 永久生效，直接写入文件
echo net.ipv4.conf.all.arp_ignore = 1 >> /etc/sysctl.conf
echo net.ipv4.conf.all.arp_announce = 2 >> /etc/sysctl.conf
echo net.ipv4.conf.lo.arp_ignore = 1 >> /etc/sysctl.conf
echo net.ipv4.conf.lo.arp_announce = 2 >> /etc/sysctl.conf# 应用配置
sysctl -p 为什么需要同时配置 all 和 lo？
all 的作用范围是所有网络接口。
lo 的作用范围是仅针对回环接口 lo。
在 LVS DR 模式中：
VIP 配置在后端服务器的
lo接口，但流量实际通过eth0收发。all配置：防止所有接口（包括eth0）响应 VIP 的 ARP 请求。lo配置：进一步强化对回环接口的控制，确保 VIP 的 ARP 响应只由负载均衡器发出。
这里在两个后端服务器RS1和RS2上都要进行配置
2. 负载均衡器配置
在 负载均衡器（Director） 上，通常只需将 VIP 配置在物理网卡（如 eth0）上，无需特殊 ARP 参数。但若 VIP 也配置在回环接口（lo），则需确保：
net.ipv4.conf.lo.arp_ignore = 0 # 允许回环接口响应 VIP 的 ARP
net.ipv4.conf.lo.arp_announce = 0 # 允许使用物理网卡的 MAC 响应4、在负载均衡器上进行lvs调度策略的编写
5、测试：
七、TUN模式的LVS集群（只做了解）
LVS（Linux Virtual Server）的 TUN 模式（IP Tunneling） 是一种高性能的负载均衡实现方式，通过 IP 隧道技术将负载均衡器和后端服务器连接起来。
1、核心原理：
工作机制：
负载均衡器（Director）接收客户端请求后，不修改原数据包，而是将其封装在一个新的 IP 包中（外层 IP 为 Director 和 Real Server 的 IP），通过隧道发送给后端服务器。
后端服务器（Real Server）解封装后处理请求，并直接将响应返回给客户端（无需经过 Director）。
关键特点：
网络层封装：使用 IPIP 协议（IP 协议号 4）或 GRE（Generic Routing Encapsulation）进行数据包封装。
跨地域部署：Director 和 Real Server 可以位于不同网络，只需路由可达。
高性能：请求和响应路径分离，Director 仅处理入站流量，避免成为瓶颈。
2、优缺点与适用场景
优点：
高性能：Director 仅处理请求，响应直接返回客户端，吞吐量高。
跨地域部署：支持将后端服务器分布在不同地理位置。
扩展性强：可轻松添加或移除后端服务器，不影响服务。
缺点：
配置复杂：需在所有服务器上配置隧道，维护成本高。
依赖 IPIP 协议：部分网络环境可能封禁 IPIP 协议（IP 协议号 4）。
故障排查困难：隧道封装可能导致数据包追踪复杂。
适用场景：
大规模负载均衡集群（如电商平台、CDN）。
跨数据中心部署的高可用服务。
需卸载 Director 压力的高并发场景。
八、FullNAT模式的LVS集群（只做了解）
FullNAT 是 LVS 的一种特殊负载均衡模式，由华为对 Linux 内核进行扩展实现（最早在 2.6.32 内核中引入）。它通过同时修改请求的源 IP 和目标 IP，突破了传统 DR 模式的网络限制，允许后端服务器（Real Server）部署在任意网络中。
1、核心原理：
1. 工作机制
请求路径：
客户端 → Director（修改源 IP 为 Director 的内网 IP，目标 IP 为 RS 的内网 IP）→ RS响应路径：
RS → Director（修改源 IP 为 VIP，目标 IP 为客户端 IP）→ 客户端
2. 关键特性
双向 NAT：同时修改请求和响应的源 / 目标 IP，实现跨网段负载均衡。
对称路径：请求和响应必须经过 Director，保证连接跟踪一致性。
解除网络限制：RS 可以部署在任意网络（如私有云、公有云），只需与 Director 路由可达。
2、优缺点与适用场景
优点
网络灵活性：突破 DR 模式的同网段限制，支持混合云部署。
部署简单：RS 无需配置 VIP 和复杂的 ARP 参数。
故障隔离：Director 可作为网络边界，增强安全性。
缺点
Director 负载较高：需处理双向流量，吞吐量低于 DR/TUN 模式。
内核依赖：非标准内核模块，需特殊编译或使用华为内核。
连接跟踪限制：依赖内核连接跟踪表，大规模集群需优化内存。
适用场景
混合云架构：后端服务器分布在公有云与私有云。
数据中心互联：跨地域数据中心的负载均衡。
网络架构复杂：无法满足 DR 模式同网段要求的场景。
九、添加防火墙标签解决轮询错误的问题
注：此实验的实验环境为上面DR模式的实验环境。
1、轮询规则中可能会遇到的错误
| 场景 | RR 算法行为 |
|---|---|
| 未做标记（独立 VS） | 80 和 443 独立轮询，可能因计数器同步 “巧合” 到同一 RS |
| 做了标记（合并 VS） | 80 和 443 严格按请求顺序轮询，导致同一客户端请求分散 |
以 HTTP 和 HTTPS 为例，当我们在RS中同时开放80和443端口，那么默认控制是分开轮询的，这样我们就出现了一个轮询错乱的问题。
当我第一次访问80被轮询到RS1后下次访问443仍然可能会被轮询到RS1上。
在RS1和RS2中安装mod_ssl并重启apache。
添加如下的LVS策略：
测试发现两次访问都轮询到了同一个real server。
未做标记时：两个独立虚拟服务的 RR 可能 “同步”
关键点在于：
每个虚拟服务（80 和 443）独立维护自己的 RR 计数器。
若客户端的 80 和 443 请求几乎同时到达，两个虚拟服务的 RR 计数器可能恰好处于相同状态（例如都指向 RS1）。
例如：
客户端首次访问 80 端口时，VS1 的 RR 计数器指向 RS1，请求被转发到 RS1。
紧接着客户端访问 443 端口，此时 VS2 的 RR 计数器也指向 RS1（因初始状态相同），请求也被转发到 RS1。
这种 “巧合” 会让您误以为 “同一客户端的请求总被分到同一 RS”，但实际上只是 RR 计数器同步的结果。若两个请求的时间间隔较长，或中间有其他客户端的请求插入，RR 计数器可能错开，导致同一客户端的请求被分到不同 RS。
2、使用防火墙标记来解决轮询调度问题
FWM:FireWall Mark。
MARK target 可用于给特定的报文打标记, --set-mark value。
其中:value 可为0xffff格式，表示十六进制数字借助于防火墙标记来分类报文，而后基于标记定义集群服 务:可将多个不同的应用使用同一个集群服务进行调度。
如何实现防火墙标记：
命令：iptables -t mangle -A PREROUTING -d $vip -p $proto -m multiport --dports
$portl,$port2,..-j MARK --set-mark NUMBER#它的作用是：对发往特定 VIP（虚拟 IP）和端口的流量打标记（MARK），以便后续基于标记进行路由或调度。关键参数说明
-t mangle：使用 mangle 表，该表专门用于修改数据包元数据（如 TOS、MARK）。
-A PREROUTING：将规则添加到 PREROUTING 链，该链在路由决策前处理数据包。
-d $vip：目标地址为变量 $vip（通常是 LVS 的虚拟 IP）。
-p $proto：协议类型（如 tcp 或 udp）。
-m multiport --dports $port1,$port2,...：匹配多个目标端口（如 80,443）。
-j MARK --set-mark NUMBER：给匹配的数据包打标记（NUMBER 是 0-4294967295 之间的整数）。在Director主机基于标记定义集群服务：
命令：ipvsadm -A -f NUMBER [options] 这是 LVS (Linux Virtual Server) 中用于创建基于防火墙标记 (firewall mark) 的虚拟服务器的命令。
这种方式允许您根据 iptables 标记的流量来调度请求，而不是传统的 IP 地址和端口。关键参数说明
除了 -f NUMBER，常用的选项包括：
-s scheduler # 指定调度算法 (rr|wrr|lc|wlc|lblc|lblcr|dh|sh|sed|nq)
-p [timeout] # 持久连接的超时时间 (秒)
-M netmask # 持久连接的子网掩码实验示例如下：
在LVS调度器中设定端口标签，认为80和443端口是一个整体
设定调度规则
测试结果如下：
发现可以成功轮询了，则实验成功。
做了标记后：合并虚拟服务导致 RR 按请求顺序分配
此时的行为差异：
80 和 443 端口的请求被视为同一个虚拟服务的流量，共享同一个 RR 计数器。
RR 算法会严格按请求到达顺序轮询所有后端服务器，而不区分客户端。
例如：
客户端 A 发送 80 端口请求，RR 计数器指向 RS1，请求被转发到 RS1。
客户端 A 紧接着发送 443 端口请求，此时 RR 计数器已更新为 RS2，请求被转发到 RS2。
这就导致了 “做标记后同一客户端的请求被分到不同 RS” 的现象。
十、LVS持久链接
在我们客户上网过程中有很多情况下需要和服务器进行交互，客户需要提交响应信息给服务器，如果单 纯的进行调度会导致客户填写的表单丢失，为了解决这个问题我们可以用sh算法，但是sh算法比较简单 粗暴，可能会导致调度失衡。
解决方案
在进行调度时，不管用什么算法，只要相同源过来的数据包我们就把他的访问记录在内存中，也就是把 这个源的主机调度到了那个RS上。
如果在短期（默认360S）内同源再来访问我仍然按照内存中记录的调度信息，把这个源的访问还调度到同一台RS上。
如果过了比较长的时间（默认最长时间360s）同源访问再次来访，那么就会被调度到其他的RS上。
命令：ipvsadm-A|E -t|u|f service-address[-s scheduler] [-p [timeout]]默认360秒参数分组：操作类型：-A：添加新的虚拟服务（Add）-E：编辑已存在的虚拟服务（Edit）服务类型：-t：TCP 服务（如 HTTP、HTTPS）-u：UDP 服务（如 DNS、NTP）-f：基于防火墙标记（Firewall Mark）的服务（您之前配置的就是这种）服务地址：对于 -t 和 -u：格式为 IP:Port（如 192.168.0.220:80）对于 -f：格式为标记值（如 6666）调度算法：-s scheduler：指定负载均衡算法（默认是 wlc，即加权最小连接数）常用值：rr（轮询）、wrr（加权轮询）、lc（最小连接数）、sh（源地址哈希）等持久连接：-p [timeout]：启用会话保持（默认超时时间 360 秒，即 6 分钟）若省略 timeout，则默认使用 360 秒
现象（HTTP 和 HTTPS 请求都被调度到同一台 RS）是由于 LVS 的会话保持（persistent）机制生效。当您使用 -p 3000 参数时，LVS 会在 3000 秒内将同一客户端的所有请求强制路由到同一台 RS，从而覆盖了 RR（轮询）算法的默认行为。
详细解释：
1. 会话保持（-p 参数）的工作原理
当执行
ipvsadm -E -f 6666 -s rr -p 3000时，LVS 会：忽略 RR 算法的轮询逻辑，转而使用客户端 IP 作为哈希键。
在 3000 秒内，将同一客户端 IP 的所有请求（无论端口）强制发送到首次选择的 RS。
因此，客户端先访问 HTTP（80 端口）时被分配到 RS2，后续 HTTPS（443 端口）请求也会被强制路由到 RS2，导致输出：
RS2 - 192.168.0.20 RS2 - 192.168.0.20
2. 与之前配置的差异
未使用
-p参数时：LVS 按 RR 算法独立调度 80 和 443 端口的请求，可能导致同一客户端的请求被分到不同 RS。使用
-p参数后：LVS 会确保同一客户端的所有请求在超时时间内被发送到同一 RS，避免会话丢失。
LVS工作模式的总结对比
| 维度 | NAT 模式 | DR 模式 | TUN 模式 | Full-NAT 模式 |
|---|---|---|---|---|
| IP 修改 | 入站改目标 IP，出站改源 IP | 不修改 IP，改 MAC 地址 | 不修改 IP，隧道封装 | 入站同时改源 IP 和目标 IP |
| 流量路径 | 双向经 LVS | 入站经 LVS，出站 RS 直连 | 入站经隧道，出站 RS 直连 | 双向经 LVS |
| 网络范围 | 同一子网 | 同一物理子网（二层可达） | 跨子网 / 跨地域（依赖隧道） | 任意网络（可跨子网） |
| RS 网关配置 | 必须指向 LVS 的内网 IP | 无需指向 LVS（可独立设置网关） | 无需指向 LVS（可独立设置网关） | 无需指向 LVS（独立网关） |
| 性能 | 低（瓶颈在 LVS） | 极高（仅入站经 LVS） | 中高（隧道有开销） | 中（双向经 LVS） |
| Director 负载 | 高（处理双向流量） | 低（仅处理请求） | 低（仅处理请求） | 中（处理双向流量） |
| RS 配置复杂度 | 低（仅需设网关） | 中（需抑制 ARP + 绑定 VIP） | 高（需配置隧道 + 绑定 VIP） | 低（无需绑定 VIP） |
| 典型场景 | 小规模集群、数据库 | Web 服务、大规模集群 | 跨地域集群、CDN | 复杂网络架构、安全需求 |