当前位置：首页 > news >正文

LVS (Linux Virtual Server) 解析

news 2025/8/2 22:42:49

在这里插入图片描述

PREROUTING链
- 位置：所有流量入口
- 功能：DNAT准备（如NAT模式将VIP→RIP）
路由决策
- 关键判断：目标地址是否为本地IP（VIP）
INPUT链
- IPVS拦截点：当目标地址是VIP时
- 工作原理：ip_vs_in 钩子函数劫持流量
模式处理
- NAT：VIP→RIP + CIP→DIP
- DR：仅修改MAC地址
- TUN：双IP头封装
- FullNAT：双向地址转换
响应路径
- NAT/FullNAT：必须返回Director
- DR/TUN：直通客户端

完整数据流示例（NAT模式）

客户端发送：CIP ➔ VIP
Director处理：

在这里插入图片描述

RealServer接收：DIP ➔ RIP
RealServer响应：RIP ➔ DIP
Director转换：RIP→VIP + DIP→VIP
客户端接收：VIP ➔ CIP

重要区别：DR/TUN模式在第4步直接返回客户端（VIP→CIP），不经过Director，这是高性能的关键。

LVS (Linux Virtual Server) 解析

核心思想： LVS 是一个构建在 Linux 内核之上的、纯四层的网络负载均衡解决方案。它通过将一组物理服务器（Real Servers, RS）组成一个高性能、高可用的虚拟服务器（Virtual Server, VS），前端仅暴露一个虚拟 IP 地址（Virtual IP, VIP）。客户端的请求发往 VIP，LVS 的负载均衡器（Director Server 或简称 Director）根据预定义的算法和规则，将请求透明地转发给后端某一台 RS 进行处理，并将结果返回给客户端。整个过程对客户端透明（客户端认为只在与 VIP 通信）。

核心组件：

负载均衡器 / 调度器 (Director)：核心节点，运行 IPVS 模块和ipvsadm管理工具。
- 接收客户端发送到 VIP 的请求。
- 根据负载均衡算法（如轮询 rr、加权轮询 wrr、最少连接 lc、加权最少连接 wlc、源地址哈希 sh 等）从 RS 池中选择一个后端服务器。
- 使用 IPVS 模块实现特定转发模式（NAT, DR, TUN, FULLNAT）。
- 管理和监控 RS 的健康状态（通常结合 Keepalived 实现）。
真实服务器池 (Real Server Pool)： 一组实际提供服务的后端服务器。它们运行真正的应用服务（如 Web Server, App Server, Database Server）。每台 RS 需要配置网络以适配 LVS 的转发模式。
共享存储 (可选)： 为保证 RS 上服务的状态一致性（如 Session 或文件共享），通常需要共享存储（如 NAS, SAN）或分布式存储/数据库解决方案。
虚拟 IP 地址 (VIP)： 由 Director 持有并对外暴露的服务 IP 地址，客户端通过此 IP 访问服务。
Directors Real IP (DIP)： Director 用于与后端 RS 通信的真实 IP 地址。在 NAT/FULLNAT 模式下尤其重要。
Real Server IP (RIP)： 后端真实服务器的真实 IP 地址。

IPVS (IP Virtual Server) 详解

本质： LVS 集群实现负载均衡的核心内核模块。
作用：
- 安装在 Director 上，监听 VIP。
- 接收目标地址是 VIP 的数据包。
- 根据 ipvsadm 配置的规则（虚拟服务、RS、调度算法、转发模式），选择一个 RS，然后在内核空间高效地修改和转发数据包。这个过程基本不涉及用户态复制，效率极高。
与 Netfilter 的关系： IPVS 通过 Netfilter 框架提供的钩子函数（主要挂载在 INPUT 链和 FORWARD 链）在内核路径上拦截、修改和转发数据包。
ipvsadm： 用户空间的管理工具。用于配置、管理 IPVS 规则（定义 VIP:Port 的虚拟服务、绑定 RIP、选择调度算法、设置转发模式等）。
- 命令示例 (关键)：
  - ipvsadm -A -t VIP:Port -s scheduler (添加虚拟服务)
  - ipvsadm -a -t VIP:Port -r RIP:Port -g/-m/-i (添加 RS，并指定模式：-g=DR, -m=NAT, -i=TUN)
  - ipvsadm -ln (查看配置)

LVS 四种工作模式深度对比与补充

特性	DR (Direct Routing) 模式	NAT (Network Address Translation) 模式	TUN (Tunneling) 模式	FULLNAT 模式
请求路径	CIP -> VIP (Director) -> MAC(RIP) -> RIP (直接响应 CIP)	CIP -> VIP -> RIP (Director 改写) -> RIP (RS 响应到 DIP) -> VIP (Director 改写) -> CIP	CIP -> VIP (Director) -> RIP (IPIP 封装) -> RIP (拆解后处理，直接响应 CIP)	CIP -> VIP (Director) -> SNAT(DIP) & DNAT(RIP) -> RIP (RS 响应到 DIP) -> SNAT(VIP) & DNAT(CIP)
核心操作	Director 改写目的 MAC 为选定 RS	Director 对请求做 DNAT (VIP -> RIP)，对响应做 SNAT (RIP -> VIP)	Director 对请求增加一层 IPIP 封装 (DIP -> RIP)	Director 对请求做SNAT (CIP->DIP) + DNAT (VIP->RIP)，对响应做 SNAT (RIP->VIP) + DNAT (DIP->CIP)
响应路径	RS 直接响应给客户端 (CIP)。不经过 Director! (高性能关键)	必须经过 Director (SNAT/DNAT 转换)	RS 直接响应给客户端 (CIP)。不经过 Director!	必须经过 Director (双向转换)
Director 瓶颈	低 (仅处理请求，不处理响应大流量)	高 (处理双向所有流量)	中 (处理请求封装，不处理响应)	高 (处理双向所有流量及更复杂的转换)
RS 配置	复杂： - ARP 抑制必需! (在 RS 上配置) - 绑定 VIP 到 `lo`(`/32`掩码)	简单： - 网关指向 DIP (必需!)	复杂： - 绑定 VIP 到 `tunl0` (必需!) - 支持 IPIP 隧道	简单： - RS 设置默认网关指向其本地路由器即可 (无需指向 DIP!)
网络要求	Director 和所有 RS 必须位于同一物理网络 (同 VLAN/广播域)	Director 和所有 RS 在同一网络，但 RS 网关需指向 DIP	Director 和 RS 可以跨网段 (IP 可达即可)	Director 和 RS 可以跨网段、跨 VLAN、多 LVS 级联扩展
IP 要求	RIP 通常是私有 IP，VIP 是公网/私有 IP。RS 需有到客户端的路由	VIP 是公网 IP，DIP 和 RIP 是私有 IP	VIP 和 RIP 必须是公网路由可达的 IP (隧道端点要求)	VIP/DIP/RIP 可为公有或私有 IP，部署极其灵活
端口映射	不支持 (RS 服务端口必须与 VIP 一致)	支持 (可映射到 RS 不同端口)	不支持 (同 DR)	支持 (同 NAT)
RS 看到的源 IP	CIP (保持客户端真实 IP)	DIP (Director 的 DIP)	CIP (保持客户端真实 IP)	DIP (Director 的 DIP)
典型应用场景	Web 高并发 (请求小，响应大场景)	中小规模负载均衡	跨 IDC 异地容灾/负载均衡	大规模云环境部署、跨 VLAN 部署、解决传统 NAT 规模瓶颈
性能	最高	较低	较高 (但封装/拆封有开销)	较 NAT 稍低 (转换次数最多)
可扩展性	受限于同广播域规模	受限于 Director 处理能力	较好 (跨网段)	最好 (突破网络拓扑限制，支持水平扩展)
运维复杂度	高 (ARP 抑制和网络配置)	中	高 (隧道配置、路由)	中 (内核需支持补丁/特定版本)

关键点补充说明：

DR 模式 ARP 抑制：
- 目的： 防止多个 RS（因绑定相同 VIP）响应客户端的 ARP 请求，导致网络混乱。必须只在 Director 上响应 VIP 的 ARP。
- 配置 (sysctl):
  - net.ipv4.conf.all.arp_ignore = 1：只响应目标IP地址为接收网卡上本地地址的ARP请求。
  - net.ipv4.conf.all.arp_announce = 2：总是使用最合适的本地地址（优先级：匹配目标网络的网卡地址 > 主网卡地址）来宣告ARP，避免宣告VIP。
- lo: VIP 必须配置 /32 掩码：避免在 RS 上产生到 VIP 的本地子网路由（该路由优先级高，可能导致 RS 尝试响应 VIP 的非本地 ARP 请求）。
TUN 模式要点：
- IPIP 封装： Director 将原始 CIP->VIP 的 IP 报文作为有效载荷，封装在一个新的 IP 包中（源 IP=DIP，目的 IP=RIP）。RS 内核需要支持 IPIP 隧道并拆包。
- MTU 问题： IPIP 封装增加了额外包头（20字节），可能导致分片，需要适当调大 MTU 或开启 Path MTU Discovery (PMTUD)。
- 真实部署： 生产环境独立部署较少，多见于公有云内部跨可用区的负载均衡方案。RS 需要公网可达 IP 增加了成本和复杂度。
FULLNAT 模式要点：
- 双向 SNAT/DNAT： 解决传统 NAT 要求 RS 网关指向 Director 的限制（导致同 VLAN、Director 单点瓶颈）。
- RS 源 IP 问题： RS 收到的源 IP 是 DIP，不再是真实的 CIP。需通过 TOA (TCP Option Address) 内核模块或 HTTP Header (X-Forwarded-For) 传递真实客户 IP。TOA 效率更高。
- 内核支持： 原生 Linux 内核直到较高版本才部分吸收 FULLNAT 理念。早期及许多生产环境依赖定制化内核（如阿里云内核/LVS 补丁）。
- 性能损耗： 四次地址转换（两次 SNAT+两次 DNAT）有一定 CPU 开销，比 NAT 模式大约低 10%，但换取了网络部署的极大灵活性。

NAT模式

在这里插入图片描述

特点：
- 请求/响应均经过LVS（性能瓶颈）
- Real Server网关必须指向LVS
- 支持端口映射（VIP端口≠RIP端口）
限制：集群规模≤20节点

DR模式

在这里插入图片描述

核心机制：
LVS改写目标MAC地址，Real Server通过lo:VIP直接响应
关键配置：
- Real Server绑定VIP到lo接口（掩码32位）
- 开启ARP抑制：arp_ignore=1, arp_announce=2
优势：响应流量不经过LVS（支持高并发）
限制：所有节点需在同一局域网

TUN模式

在这里插入图片描述

核心机制：
LVS添加新IP头（外层：DIP→RIP，内层：CIP→VIP）
特点：
- Real Server需支持IP隧道协议
- 可跨网段部署（RIP可为公网IP）
- Real Server直接响应客户端
缺点：运维复杂，需绑定VIP且支持隧道协议

LVS FullNAT模式

在这里插入图片描述

解决痛点：
- LVS与Real Server跨VLAN通信
- 突破单LVS性能瓶颈
特性：双重地址转换（请求/响应路径均修改IP）

Keepalived 深度解析

Keepalived与LVS

核心功能：
1. LVS节点监控：自动剔除故障Real Server
2. Director高可用：通过VRRP协议实现主备切换
VRRP协议：虚拟路由器冗余协议，解决单点故障
核心角色： LVS 高可用性的守护神，同时自身也具备基本的负载均衡能力（通过健康检查和设置权重）。
起源与发展： 最初确实是作为 LVS Director 的健康检查和主备故障切换 (Failover) 工具诞生的。后来融入了 VRRP (Virtual Router Redundancy Protocol) 的功能，成为一个通用的高可用解决方案。
核心功能：
1. VRRP 协议实现 (主备切换)：
  - 原理： 多个物理节点运行 Keepalived，组成一个 VRRP 组。
  - 虚拟路由器： 该组对外表现为一个虚拟路由器 (VRRP Router)。
  - VIP 持有权： VRRP 组通过选举产生一个 Master 节点（虚拟路由器活动实例）。Master 持有并宣告 VIP 和配置的 MAC 地址。其他节点为 Backup。
  - 心跳 & 选举： Master 定期向组播地址发送 VRRP Advertisement (心跳) 消息通告状态。如果 Backup 在超时时间 (advert_int) 内未收到 Master 的心跳，则认为 Master 故障。Backups 触发选举，选出新的 Master 接管 VIP 和服务。
2. 服务健康检查 (Health Checking)：
  - 目的： 检测后端 RS 是否健康可用。如果 RS 故障，Keepalived 通知 IPVS (ipvsadm) 将其从可用 RS 池中移除。
  - 检查类型：
    - TCP_CHECK: 尝试与 RS 的指定端口建立 TCP 连接。成功即健康。
    - HTTP_GET / SSL_GET: 向 RS 的指定 URL 发送 HTTP(S) GET 请求，检查响应状态码或内容。
    - MISC_CHECK: 执行自定义外部脚本检测，脚本返回 0 表示成功（健康）。
    - SMTP_CHECK, DNS_CHECK 等。
  - 配置参数： delay_loop（检查间隔），timeout（超时时间），fall（失败多少次标记为 DOWN），rise（成功多少次标记为 UP）。
3. LVS Director 集成：
  - Keepalived 通过配置文件 /etc/keepalived/keepalived.conf 定义 virtual_server 块。
  - 在该块中配置 VIP、Port、调度算法（lvs_sched）、持久化（persistence_timeout）、转发模式（lvs_method）。
  - 在 real_server 块内配置 RS 的 RIP、Port 以及该 RS 的健康检查方式和参数。
  - 故障切换流程：
    1. 主 Director (Keepalived Master) 运行 LVS。
    2. 主 Director 的 Keepalived 持续检查后端 RS。
    3. 如果主 Director 本身故障（硬件、网络、进程崩溃），VRRP 选举 Backup 为新的 Master。新 Master 接管 VIP。
    4. 新 Master 上的 Keepalived 根据配置重新初始化 LVS（VIP, RS列表，规则）。
    5. 客户端流量自动切换到新 Master 的 VIP 上。
    6. 在此过程中，Keepalived 持续监控后端 RS。如果某个 RS 故障，Master 上的 Keepalived 会调用 ipvsadm 动态地从 LVS 池中移除该故障 RS。当 RS 恢复健康时，再自动添加回来。
超越 LVS： 尽管源自 LVS，Keepalived 的 VRRP 功能可应用于任何需要高可用的 IP 资源。你可以将 Keepalived 配置在：
- Nginx / Haproxy 前端： 作为反向代理或七层负载均衡器的高可用，故障时切换 VIP 到备用节点。
- MySQL 主库： 实现 VIP 的切换（通常结合 MHA、MGR 等做数据一致性保证）。
- 其他需要 VIP 漂移保证高可用的服务。

重要配置文件结构 (keepalived.conf)：

global_defs { ... }        # 全局参数 (路由ID, 通知邮件等)
vrrp_instance VI_1 {      # VRRP组定义state MASTER/BACKUP    # 初始状态interface eth0         # 绑定网络接口virtual_router_id 51   # 虚拟路由ID (同一网段内必须唯一)priority 100           # 优先级 (越高越易成为 Master)advert_int 1           # 心跳间隔 (秒)authentication { ... } # VRRP认证 (可选)virtual_ipaddress {    # 定义的 VIP 地址VIP}track_script {         # 跟踪自定义脚本状态chk_my_service}
}
virtual_server VIP Port {  # LVS 虚拟服务定义delay_loop 6           # 服务轮询间隔 (秒)lb_algo wrr            # 调度算法lb_kind DR             # 转发模式persistence_timeout 50 # 持久连接超时 (秒)protocol TCP           # 服务协议real_server RIP Port { # 定义真实服务器weight 1           # 权重TCP_CHECK {        # TCP健康检查connect_timeout 3retry 3delay_before_retry 3}# 或 HTTP_GET 等}
}
vrrp_script chk_my_service { # 自定义健康检查脚本script "/path/to/check.sh"interval 2weight 2                  # 脚本返回成功时本节点增加权重 (正数利于成Master) 或减少 (负数利于触发 Failover)
}

脑裂 (Split-Brain)： 当 Keepalived 节点之间网络中断，但两个节点本身都健康时，它们都可能认为自己应该成为 Master 并尝试宣告 VIP，导致网络中 VIP 冲突。解决方案：
- 增强心跳监控： 使用 VRRP单播 (vrrp_unicast_peer) 替代默认组播，明确指定对端IP，避免因组播不通导致的误判。
- 多播路由/防火墙： 确保 VRRP 组播报文 (224.0.0.18) 在所有节点间畅通无阻。
- 辅助心跳： 在配置 vrrp_script 监控除网络外的服务状态或网关连通性，如果检测失败则降低优先级或停止 Keepalived，避免非网络故障时出现脑裂。
- 优先级调整： 确保主备初始优先级有足够差距 (如 100 vs 90)。

总结：

LVS/IPVS: 提供强大、高效的四层负载均衡能力。选择合适的模式（DR、NAT、TUN、FULLNAT）是成功部署的关键，需权衡性能、扩展性、网络限制和运维复杂性。
Keepalived: 为 LVS Director 和广义上的 IP 服务提供了不可或缺的高可用性保障，通过 VRRP 实现 VIP 接管，通过全面的健康检查确保后端服务的可用性。
组合运用： LVS(IPVS) + Keepalived 构成了一个非常经典、稳定、高性能的网络负载均衡与高可用解决方案，尤其适合处理大规模、高性能要求的四层流量负载均衡场景。

查看全文

http://www.dtcms.com/a/305524.html