DR模式 LVS负载均衡群集

在现代互联网服务架构中，面对不断增长的用户访问量和数据吞吐需求，单台服务器往往难以满足高性能、高可用的要求。负载均衡技术应运而生，它通过在多台服务器之间合理分配网络请求，显著提升了系统的处理能力、可靠性和可扩展性。Linux Virtual Server (LVS) 作为一种高效、稳定的开源四层（传输层）负载均衡解决方案，在众多场景中发挥着核心作用。

在 LVS 实现的多种负载均衡模式中，DR（Direct Routing）模式以其卓越的性能和简洁的架构脱颖而出。在 DR 模式下，负载均衡器（Director）仅负责处理请求的调度分发，而响应数据则由真实服务器（Real Server）直接返回给客户端，有效避免了负载均衡器可能成为网络瓶颈的问题。这种“请求-响应路径分离”的特性使得 DR 模式特别适用于高并发、大流量的应用场景，能够充分利用后端服务器的处理能力。

然而，实现一个高效、稳定的 DR 模式 LVS 群集，需要精心设计网络架构，特别是解决 ARP（Address Resolution Protocol）相关问题以及确保负载均衡器与真实服务器之间网络层的协同工作。本方案旨在阐述 DR 模式 LVS 群集的部署原理、关键配置要点以及其带来的优势，为构建高性能、高可用的服务集群提供参考。

一、LVS集群

1.集群定义

LVS（Linux Virtual Server）集群是一种基于Linux的开源负载均衡解决方案，通过将流量分发到多个后端服务器（Real Server）实现高可用性和横向扩展。

2.核心使用场景

LVS（Linux Virtual Server）的核心使用场景主要包括：

负载均衡集群
- 主要目标： 分发网络流量或计算请求到多个节点上，避免单个节点过载，提高系统的整体吞吐量和响应速度。
- 核心思想： 通常有一个入口节点（负载均衡器）接收用户请求，然后根据预设的策略（如轮询、最少连接数、基于权重等）将请求转发给后端的一组服务器节点处理。这些节点处理请求并将结果返回给负载均衡器，再由负载均衡器返回给用户。
- 典型应用场景： Web 服务器集群、应用服务器集群。
高可用集群
- 主要目标： 最大限度地减少系统停机时间，提供不间断的服务。当集群中的某个节点发生故障（硬件、软件或网络故障）时，服务能够自动、快速地切换到其他健康的节点上继续运行，用户感知到的中断时间非常短甚至为零。
- 核心思想： 通过冗余（多个节点运行相同的服务）和故障转移机制来实现。集群软件监控节点状态，一旦检测到故障，会触发故障转移过程，将故障节点上的服务（包括 IP、存储访问等）接管到备用节点上。
- 典型应用场景： 数据库服务器集群、关键业务应用服务器、文件服务器集群。
高性能计算集群
- 主要目标： 将大规模的计算任务分解成许多可以并行处理的子任务，然后将这些子任务分配给集群中的多个计算节点同时执行，最后汇总结果，以显著缩短完成复杂计算所需的时间。
- 核心思想： 利用并行计算技术。集群中的节点通常通过高速网络（如 InfiniBand）互联，并运行专门的并行计算软件框架来协调任务分发、通信和结果收集。
- 典型应用场景： 科学计算（如气象预报、分子模拟）、工程分析（如流体动力学仿真、有限元分析）、大数据分析、人工智能模型训练。

这三种集群类型在实际应用中并非完全互斥，一个大型系统可能会结合多种集群技术来实现更全面的目标。例如，一个高可用的 Web 服务集群内部可能同时运用了负载均衡技术来分发流量。

3.LVS三种工作模式

3.1 NAT 模式 (Network Address Translation - 网络地址转换)

工作原理：
- 客户端发送请求到LVS调度器的公网虚拟IP地址（VIP）。
- 调度器接收到请求后，根据负载均衡算法（如轮询、加权轮询、最少连接等）选择一个后端真实服务器（Real Server, RS）。
- 调度器修改请求报文的目标IP地址和目标端口，将其改为选中的真实服务器的IP地址（通常是内网RIP）和端口，然后转发请求给该服务器。
- 真实服务器处理请求后，将响应报文发送回调度器（因为请求报文的目标IP是调度器改写的真实服务器IP，所以响应默认会发给调度器）。
- 调度器修改响应报文的源IP地址和源端口，将其改回为虚拟IP（VIP）和相应的端口，然后发送回客户端。
特点：
- 请求和响应报文都需要经过调度器转发，调度器成为性能瓶颈。
- 真实服务器只需要处理请求，其返回的响应流量也必须经过调度器进行地址转换。
- 真实服务器可以使用私有IP地址，只要能与调度器通信即可。
- 支持端口映射（Port Mapping）。
优点：
- 配置相对简单。
- 真实服务器无需特殊配置（如设置VIP、ARP抑制等），只需要配置网关指向调度器（或配置路由确保响应报文能回到调度器）。
缺点：
- 性能较低（调度器需要处理双向流量和进行NAT转换）。
- 调度器容易成为瓶颈，限制了集群的扩展能力。
- 通常要求真实服务器和调度器在同一个二层网络或通过路由可达，且真实服务器的默认网关需要指向调度器（或配置特定路由）。

3.2 DR 模式 (Direct Routing - 直接路由)

工作原理：
- 客户端发送请求到LVS调度器的公网虚拟IP地址（VIP）。
- 调度器接收到请求后，根据负载均衡算法选择一个后端真实服务器。
- 调度器不修改请求报文的目标IP地址（仍然是VIP），而是修改目标MAC地址为选中的真实服务器的MAC地址（通过ARP协议学习或静态配置），然后将报文转发出去。
- 由于目标IP是VIP，而真实服务器在本地回环接口（lo）或其他接口上也配置了相同的VIP地址（但对外不可见，通过ARP抑制技术避免冲突），因此真实服务器能够接收并处理该请求报文。
- 真实服务器处理完请求后，直接将响应报文发送给客户端。响应报文的源IP地址是VIP（由真实服务器上的VIP配置产生），目标IP是客户端的IP。
特点：
- 请求报文经过调度器转发（修改MAC地址）。
- 响应报文由真实服务器直接发送给客户端，不经过调度器。
- 调度器只处理入站（请求）流量，性能远高于NAT模式。
- 真实服务器需要配置VIP地址（通常在lo接口上）并做特殊配置（如抑制ARP响应），以防止VIP冲突。
- 真实服务器必须和调度器在同一个物理二层网络（同一个VLAN或交换机下），因为调度器需要直接修改MAC地址进行转发。
优点：
- 性能非常高（调度器只处理请求，响应直接返回）。
- 解决了NAT模式中调度器的瓶颈问题。
缺点：
- 配置相对复杂（真实服务器需要配置VIP和ARP抑制）。
- 要求真实服务器和调度器在同一个二层网络，限制了部署灵活性（无法跨子网部署）。

3.3 TUN 模式 (IP Tunneling - IP隧道)

工作原理：
- 客户端发送请求到LVS调度器的公网虚拟IP地址（VIP）。
- 调度器接收到请求后，根据负载均衡算法选择一个后端真实服务器。
- 调度器将原始请求报文封装在一个新的IP数据包中。新的IP数据包的源IP是调度器自身的IP（通常是DIP，一个用于隧道通信的IP），目标IP是选中的真实服务器的IP（RIP）。这个封装过程就是建立了一个IP隧道（如IPIP隧道）。
- 封装后的报文被发送给真实服务器。
- 真实服务器接收到封装后的报文，进行解封装，得到原始的请求报文（目标IP仍然是VIP）。
- 真实服务器在本地接口（如tunl0）上也配置了VIP地址（同样需要ARP抑制），因此能够处理解封后的原始请求。
- 真实服务器处理完请求后，直接将响应报文发送给客户端。响应报文的源IP地址是VIP，目标IP是客户端的IP。
特点：
- 请求报文经过调度器封装转发（隧道传输）。
- 响应报文由真实服务器直接发送给客户端，不经过调度器。
- 调度器只处理入站（请求）流量。
- 真实服务器需要支持IP隧道协议（如IPIP），并配置隧道接口和VIP地址（同样需要ARP抑制）。
- 真实服务器可以位于不同的网络、甚至不同的地理位置，只要它们与调度器之间IP可达即可。
优点：
- 性能较高（调度器只处理请求）。
- 真实服务器可以部署在任意网络位置（跨子网、跨机房、跨地域），具有极高的部署灵活性。
缺点：
- 配置最复杂（调度器和真实服务器都需要配置隧道）。
- 封装和解封装报文增加了额外的开销，性能略低于DR模式（但仍优于NAT）。
- 需要真实服务器操作系统支持IP隧道功能。

3.4三种模式对比总结

特性	NAT 模式	DR 模式	TUN 模式
请求报文路径	调度器 -> RS	调度器 -> RS	调度器 (封装) -> RS (解封装)
响应报文路径	RS -> 调度器 -> 客户端	RS -> 客户端	RS -> 客户端
调度器瓶颈	是 (处理双向流量+NAT)	否 (仅处理请求)	否 (仅处理请求和封装)
性能	最低	最高	较高
配置复杂度	简单	中等 (RS需配VIP+ARP抑制)	复杂 (需隧道配置)
RS网络要求	同网段或路由可达	必须同二层网络	IP可达即可 (可跨网段、地域)
RS网关要求	指向调度器	可指向正常网关	可指向正常网关
RS端口映射	支持	不支持	不支持
典型应用场景	小规模、简单环境、需端口映射	大规模、高性能集群、同机房	地理分散的服务器、跨机房集群

选择建议

追求极致性能且服务器在同一个机房/二层网络： 首选 DR模式。
服务器分布在不同地域或网络： 选择 TUN模式。
对性能要求不高、配置简单、或需要端口映射： 考虑 NAT模式，但要注意其扩展性和瓶颈问题。
大规模生产环境： DR模式是最常见的选择；跨地域部署则考虑TUN模式；NAT模式通常用于特定场景或小规模环境。

4.负载均衡核心组件与工作流程

4.1 核心组件

组件	功能描述
负载均衡器(LoadBalancer)	接收客户端请求，按算法选择后端服务器，转发请求
后端服务器池(Server Pool)	实际处理请求的服务器集群，提供业务能力
健康检查组件	定期检测服务器状态，标记健康 / 不健康，确保请求只转发给可用节点
会话保持机制	确保同一客户端的连续请求被路由到同一服务器，维持会话状态

4.2 负载均衡核心组件与工作流程

核心组件

组件	功能描述
负载均衡器(LoadBalancer)	接收客户端请求，按算法选择后端服务器，转发请求
后端服务器池(Server Pool)	实际处理请求的服务器集群，提供业务能力
健康检查组件	定期检测服务器状态，标记健康 / 不健康，确保请求只转发给可用节点
会话保持机制	确保同一客户端的连续请求被路由到同一服务器，维持会话状态

工作流程 (典型三层架构)

Step 1：客户端发送请求至负载均衡器 (通过 VIP / 域名)

Step 2：负载均衡器执行健康检查，筛选出可用服务器

Step 3：根据负载均衡算法从可用服务器中选择一台

Step 4：将请求转发至选定服务器

Step 5：服务器处理请求并返回响应

Step 6：负载均衡器将响应返回客户端

5.负载均衡算法

调度器选择服务器所依据的策略。常见算法包括：

轮询 (Round Robin): 依次将请求分配给列表中的每个服务器。简单公平，但忽略服务器实际负载。
加权轮询 (Weighted Round Robin): 给不同性能的服务器分配不同权重，性能高的获得更多请求。
最少连接 (Least Connections): 将新请求分配给当前连接数最少的服务器。动态适应负载变化。
加权最少连接 (Weighted Least Connections): 结合权重和当前连接数。
源 IP 哈希 (Source IP Hash): 基于客户端 IP 地址的哈希值分配请求，保证同一用户的请求总是落到同一服务器（会话保持）。
目标地址哈希 (Destination Hash): 用于缓存集群等场景。
响应时间 (Response Time): 将请求分配给响应最快的服务器（需要额外监控）。

6.配置负载调度器配置节点服务器测试 LVS 群集

(1) 系统配置

首先，准备系统环境：

停止防火墙并禁用SELinux（确保临时生效，生产环境需考虑永久设置）：
```
systemctl stop firewalld.service
setenforce 0
 
```
加载ip_vs内核模块（用于LVS）：
```
modprobe ip_vs
 
```
安装ipvsadm工具（管理LVS规则）：
```
yum -y install ipvsadm
 
```
(2) 配置虚拟IP

为调度器配置VIP，使其能接收客户端请求：

创建虚拟接口配置文件（例如ens33:0）：

cd /etc/sysconfig/network-scripts/
cp ifcfg-ens33 ifcfg-ens33:0
vim ifcfg-ens33:0

在文件中添加以下内容（确保DEVICE名称匹配您的网卡）：

DEVICE=ens33:0
ONBOOT=yes
IPADDR=192.168.10.180
NETMASK=255.255.255.255

激活接口并检查：

ifup ens33:0
ifconfig ens33:0  # 应显示VIP 192.168.10.180

(3) 调整内核参数

设置内核参数以避免IP冲突并优化性能：

编辑sysctl.conf文件：

vim /etc/sysctl.conf

添加或修改以下参数（重点在禁用转发和重定向）：

net.ipv4.ip_forward = 0
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.default.send_redirects = 0
net.ipv4.conf.ens33.send_redirects = 0  # 替换ens33为您的网卡名

应用更改：

sysctl -p

(4) 配置 LVS 服务及调度

设置LVS规则，使用轮询（rr）调度算法：

清除现有规则（可选）：

ipvsadm -C

添加VIP服务（监听80端口）：

ipvsadm -A -t 192.168.10.180:80 -s rr

添加后端节点服务器（使用-g选项表示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 -ln  # 输出中应显示Route标志，确认DR模式生效

配置节点服务器（Real Server）

(1) 配置 VIP 到 lo 接口

为每个节点服务器配置VIP，避免直接响应客户端ARP请求：

创建loopback接口配置文件：

cd /etc/sysconfig/network-scripts/
cp ifcfg-lo ifcfg-lo:0
vim ifcfg-lo:0

添加内容：

DEVICE=lo:0
ONBOOT=yes
IPADDR=192.168.10.180
NETMASK=255.255.255.255

激活接口并添加路由：

ifup lo:0
ifconfig lo:0  # 检查VIP配置
route add -host 192.168.10.180 dev lo:0

确保路由持久化（重启后生效）：可将路由命令添加到/etc/rc.local。
编辑sysctl.conf：
(2) ARP 参数调整

避免MAC地址冲突，抑制节点服务器响应VIP的ARP请求：
编辑sysctl.conf：
```
vim /etc/sysctl.conf
 
```

添加参数（针对所有接口和特定接口）：

net.ipv4.conf.all.arp_ignore = 1
net.ipv4.conf.all.arp_announce = 2
net.ipv4.conf.lo.arp_ignore = 1
net.ipv4.conf.lo.arp_announce = 2

应用更改：
```
sysctl -p
 
```
(3) 安装 Web 服务

在每个节点服务器上安装Web服务（如Apache），用于测试：

安装Apache：

yum -y install httpd
systemctl start httpd
systemctl enable httpd

创建测试页面（区分不同节点）：

在192.168.10.16上：

echo "Server 192.168.10.16" > /var/www/html/index.html

在192.168.10.17上：

echo "Server 192.168.10.17" > /var/www/html/index.html

测试 LVS 群集

验证负载均衡是否工作正常：

在客户端浏览器访问：http://192.168.10.180/
预期行为：首次访问显示一个节点页面（如192.168.10.16的内容），刷新页面应轮询显示另一个节点（如192.168.10.17的内容），表明调度器在分发请求。
注意事项：您提到的“下次刷新时延迟50秒”可能源于浏览器缓存或网络设置。在标准LVS-DR配置中，刷新应即时轮询，无需延迟。如果遇到延迟，请检查：
- 客户端浏览器缓存（尝试强制刷新或使用不同浏览器）。
- 节点服务器响应时间（确保Web服务正常运行）。
- 网络连通性（ping VIP和节点IP）。
调试工具：使用curl http://192.168.10.180/多次运行，观察输出是否变化。