Linux LVS四种工作模式及其最佳实践
Linux LVS(Linux Virtual Server,Linux 虚拟服务器)是由章文嵩博士开发的内核级负载均衡技术,基于 IP 层(L3/L4)实现请求分发,具有高性能、高稳定性的特点,广泛用于大规模服务集群(如 Web、数据库、API 服务)的流量调度。LVS 支持四种核心工作模式,每种模式的原理、数据流向和适用场景差异显著,需结合业务需求选择。
一、LVS 核心概念铺垫
在讲解模式前,先明确 LVS 的核心组件,避免理解混淆:
- Director(调度器):接收客户端请求,根据调度算法将请求分发到后端 Real Server,是 LVS 集群的 “入口”。
- Real Server(RS,真实服务器):实际处理业务请求的服务器(如 Web 服务器、应用服务器)。
- VIP(Virtual IP):对外暴露的虚拟服务 IP,客户端通过 VIP 访问集群。
- DIP(Director IP):调度器用于与后端 RS 通信的内网 IP。
- RIP(Real Server IP):后端 RS 的内网 IP。
- 调度算法:LVS 通过算法分配请求,如轮询(RR)、加权轮询(WRR)、最小连接(LC)等。
二、LVS 四种工作模式详解
1. 模式一:DR(Direct Routing,直接路由模式)
DR 模式是 LVS 最常用的模式,核心特点是调度器仅处理 “请求包”,后端 RS 直接将 “响应包” 发给客户端,避免调度器成为流量瓶颈。
1.1 工作原理
- 客户端发送请求到 VIP(Director 的外网 IP),Director 接收后不修改 IP 地址,仅修改数据帧的MAC 地址(将目的 MAC 改为目标 RS 的 MAC),然后转发给 RS。
- RS 接收请求后,发现目的 IP 是自身配置的 VIP(需在 RS 的回环口配置 VIP),直接处理请求,处理完成后将响应包通过自身网卡直接发给客户端(无需经过 Director)。
1.2 关键数据流向
客户端 → Director(修改MAC) → RS(请求) → 客户端(响应,直连)
1.3 优缺点
优点 | 缺点 |
---|---|
性能极高:Director 仅转发请求包,响应包绕开 Director,无流量瓶颈 | 网络限制:Director 与 RS 必须在同一物理网段(二层网络,依赖 MAC 转发),无法跨路由 |
资源开销低:仅修改 MAC,无 IP 封装 / 转换开销 | 配置稍复杂:RS 需抑制 ARP 响应,避免 VIP 地址冲突 |
1.4 适用场景
- 高并发、高带宽业务(如 Web 服务、静态资源服务、直播推流)。
- 后端 RS 性能一致且集中部署在同一机房(同一交换机下)。
1.5 模式特定最佳实践
- RS 的 VIP 配置:在 RS 的回环口(lo)配置 VIP,避免与 Director 的 VIP 冲突,命令示例:
# RS上配置VIP(回环口) ifconfig lo:0 192.168.1.100 netmask 255.255.255.255 up # 192.168.1.100为VIP echo "1" > /proc/sys/net/ipv4/conf/lo/arp_ignore # 仅响应目的IP为本地物理IP的ARP请求 echo "2" > /proc/sys/net/ipv4/conf/lo/arp_announce # 仅向网卡所在网段发送ARP通告
- 网络拓扑:Director 与 RS 接入同一台二层交换机,避免跨路由导致 MAC 转发失效。
- 调度算法:优先选择RR(轮询) 或 WRR(加权轮询)(适合 RS 性能均匀或可通过权重调整负载的场景)。
2. 模式二:NAT(Network Address Translation,网络地址转换模式)
NAT 模式是最易部署的模式,核心特点是Director 作为客户端与 RS 的 “网关”,所有请求和响应都经过 Director,通过 IP 地址转换实现流量调度。
2.1 工作原理
- 客户端请求到 VIP(Director 的外网 IP),Director 接收后将目的 IP(VIP)转换为目标 RS 的 RIP,同时记录连接跟踪(conntrack),然后转发给 RS。
- RS 处理请求后,将响应包发给网关(必须指向 Director 的 DIP),Director 接收后将源 IP(RIP)转换为 VIP,再转发给客户端。
2.2 关键数据流向
客户端 → Director(目的IP:VIP→RIP) → RS(请求) → Director(源IP:RIP→VIP) → 客户端(响应)
2.3 优缺点
优点 | 缺点 |
---|---|
部署简单:RS 无需配置 VIP,仅需将网关指向 Director 的 DIP | 性能瓶颈:所有流量(请求 + 响应)经过 Director,高并发场景下 Director 易成为瓶颈 |
网络灵活:RS 与 Director 可不在同一网段(支持跨路由) | 扩展性差:单 Director 仅支持约 100-200 台 RS(受限于网络带宽和 CPU) |
2.4 适用场景
- 小规模服务集群(如内部 OA 系统、测试环境服务)。
- 流量较低(如峰值带宽 < 1Gbps)、RS 数量较少(<50 台)的场景。
2.5 模式特定最佳实践
- Director 双网卡配置:需两张网卡(外网卡 + 内网卡),外网卡配置 VIP(对外提供服务),内网卡配置 DIP(与 RS 通信),示例:
# Director外网卡(eth0) ifconfig eth0 10.0.0.100 netmask 255.255.255.0 up # 10.0.0.100为VIP(外网) # Director内网卡(eth1) ifconfig eth1 192.168.1.1 netmask 255.255.255.0 up # 192.168.1.1为DIP(内网)
- RS 网关配置:所有 RS 的默认网关必须指向 Director 的 DIP(如 192.168.1.1),确保响应包能回传给 Director。
- 调度算法:优先选择LC(最小连接) 或 WLC(加权最小连接)(适合连接数波动大的场景,可动态分配负载)。
- 内核优化:开启 IP 转发,调整连接跟踪超时(避免连接过早释放):
echo "1" > /proc/sys/net/ipv4/ip_forward # 开启IP转发 echo "300" > /proc/sys/net/netfilter/nf_conntrack_tcp_timeout_established # TCP连接超时设为300秒
3. 模式三:TUN(IP Tunneling,IP 隧道模式)
TUN 模式是为跨地域 / 跨网段部署 RS设计的模式,核心特点是通过IP 隧道封装将请求包转发给 RS,响应包直接发给客户端。
3.1 工作原理
- 客户端请求到 VIP(Director 的外网 IP),Director 接收后将原始请求包(客户端 IP→VIP)封装在一个新的 IP 包内(源 IP:DIP,目的 IP:RS 的 RIP),通过 IP 隧道(如 IPIP 隧道)发送给 RS。
- RS 接收后解封装隧道包,处理请求(RS 需配置 VIP,识别目的 IP 为 VIP),然后直接将响应包发给客户端(无需经过 Director)。
3.2 关键数据流向
客户端 → Director(封装IP隧道:DIP→RIP) → RS(解封装+处理) → 客户端(响应,直连)
3.3 优缺点
优点 | 缺点 |
---|---|
跨网段灵活:Director 与 RS 可跨机房、跨路由(依赖 IP 隧道) | 隧道开销:IP 封装增加约 20 字节 / 包,性能比 DR 模式低 10%-20% |
性能较高:响应包绕开 Director,无流量瓶颈 | 兼容性限制:RS 需支持 IP 隧道(如 Linux 内核加载ipip 模块),不支持 Windows RS |
3.4 适用场景
- 分布式集群(如跨地域 CDN 节点、多机房灾备服务)。
- RS 分散部署但需统一 VIP 对外服务的场景。
3.5 模式特定最佳实践
- 加载 IP 隧道模块:Director 和所有 RS 需加载
ipip
模块(Linux 内核默认支持):modprobe ipip # 加载IPIP隧道模块 lsmod | grep ipip # 验证模块加载
- RS 的 VIP 配置:与 DR 模式一致,在 RS 的回环口配置 VIP 并抑制 ARP 响应(避免冲突)。
- 隧道网络优化:确保 Director 与 RS 之间的隧道链路(如专线、VPN)带宽充足,避免隧道丢包(可通过
ping
测试隧道连通性)。 - 调度算法:优先选择RR(轮询) 或 WRR(加权轮询)(跨地域 RS 性能通常较均匀,轮询更易维护)。
4. 模式四:FULL-NAT(Full Network Address Translation,全地址转换模式)
FULL-NAT 是 NAT 模式的改进版,核心特点是同时转换 “源 IP” 和 “目的 IP”,解决了 NAT 模式下 RS 必须指向 Director 为网关的限制。
4.1 工作原理
- 客户端请求到 VIP(Director 的外网 IP),Director 接收后做两步转换:
- 目的 IP:VIP → 目标 RS 的 RIP;
- 源 IP:客户端 IP → Director 的 DIP(内网 IP);
然后转发给 RS。
- RS 处理请求后,将响应包发给 Director 的 DIP(源 IP 为 RIP,目的 IP 为 DIP),Director 接收后再做两步转换:
- 源 IP:RIP → VIP;
- 目的 IP:DIP → 客户端 IP;
然后转发给客户端。
4.2 关键数据流向
客户端 → Director(源IP:客户端→DIP;目的IP:VIP→RIP) → RS(请求) → Director(源IP:RIP→VIP;目的IP:DIP→客户端) → 客户端(响应)
4.3 优缺点
优点 | 缺点 |
---|---|
部署灵活:RS 无需指向 Director 为网关,支持多子网 RS(如 RS 在不同 VPC) | 性能瓶颈:所有流量经过 Director,且需两次 IP 转换,开销比 NAT 模式高 5%-10% |
兼容性强:RS 可属于任意网段,无需特殊配置(如 VIP、ARP 抑制) | 连接跟踪压力:Director 需维护大量连接跟踪表,高并发下 CPU 开销大 |
4.4 适用场景
- RS 无法配置网关指向 Director 的场景(如多 VPC 部署、运维权限限制)。
- 小规模、多子网的服务集群(如混合云环境中的服务)。
4.5 模式特定最佳实践
- 内核支持:确保 Linux 内核版本≥2.6.28(FULL-NAT 需内核支持
ipvs full-nat
模块),部分发行版(如 CentOS 7+)需手动启用。 - ipvsadm 配置:使用
-f
参数指定 FULL-NAT 模式,示例:# 添加虚拟服务(VIP:80),调度算法为WLC ipvsadm -A -t 10.0.0.100:80 -s wlc # 添加RS(192.168.2.10),模式为FULL-NAT ipvsadm -a -t 10.0.0.100:80 -r 192.168.2.10 -f
- RS 配置:无需特殊配置,仅需确保 RS 能与 Director 的 DIP 通信(如路由可达)。
- 内核优化:增加连接跟踪表大小(避免连接丢失):
echo "1048576" > /proc/sys/net/netfilter/nf_conntrack_max # 最大连接跟踪数设为100万
三、LVS 通用最佳实践
无论选择哪种模式,以下通用实践能大幅提升 LVS 集群的稳定性和性能:
1. 解决 Director 单点故障:高可用部署
Director 是 LVS 集群的 “入口”,单点故障会导致整个集群不可用。需通过VRRP(虚拟路由冗余协议) 实现双 Director 主备架构,常用工具为
keepalived
。配置示例(keepalived 主备)
- 主 Director 配置(
/etc/keepalived/keepalived.conf
):vrrp_instance VI_1 { state MASTER # 主节点 interface eth0 # 外网网卡 virtual_router_id 51 # 虚拟路由ID(主备需一致) priority 100 # 优先级(主>备,如备设为90) advert_int 1 # 心跳间隔(1秒) authentication { auth_type PASS # 认证方式 auth_pass 1111 # 认证密码(主备需一致) } virtual_ipaddress { 10.0.0.100/24 # VIP(对外服务IP) } } # 配置LVS虚拟服务(DR模式示例) virtual_server 10.0.0.100 80 { delay_loop 6 # 健康检查间隔(6秒) lb_algo wrr # 调度算法(加权轮询) lb_kind DR # 工作模式(DR) persistence_timeout 50# 会话保持时间(50秒,可选) protocol TCP # 协议(TCP) real_server 192.168.1.20 80 { # RS1 weight 1 # 权重 TCP_CHECK { # TCP健康检查 connect_port 80 connect_timeout 3 } } real_server 192.168.1.21 80 { # RS2 weight 2 # 权重(比RS1高,分配更多请求) TCP_CHECK { connect_port 80 connect_timeout 3 } } }
- 备 Director 配置:仅需将
state
改为BACKUP
,priority
改为90
,其余与主节点一致。
2. 配置健康检查:剔除故障 RS
LVS 默认不做健康检查,需通过
keepalived
或ldirectord
实现 RS 健康探测,自动剔除故障节点(如 RS 宕机、服务不可用),避免请求分发到无效 RS。- 常用健康检查方式:
- TCP_CHECK:检测 RS 的端口是否存活(如 Web 服务检测 80 端口)。
- HTTP_GET:发送 HTTP 请求(如
/health
),检查响应码是否为 200(适合应用层健康检查)。 - SSL_GET:针对 HTTPS 服务的健康检查。
3. 选择合适的调度算法
LVS 支持 10 + 种调度算法,需根据业务场景选择:
算法 | 核心逻辑 | 适用场景 |
---|---|---|
RR(轮询) | 按顺序轮流分配请求到 RS | RS 性能均匀、无会话依赖的服务(如静态资源) |
WRR(加权轮询) | 按权重分配请求,权重高的 RS 优先 | RS 性能不均(如部分 RS 配置更高) |
LC(最小连接) | 分配请求到当前连接数最少的 RS | 连接数波动大的服务(如 API 服务) |
WLC(加权最小连接) | 按 “连接数 / 权重” 比值分配,比值最小优先 | RS 性能不均且连接数波动大 |
SED(最短预期延迟) | 优化 WLC,优先分配给 “(连接数 + 1)* 权重” 最小的 RS | 高并发、RS 性能差异大的场景 |
NQ(Never Queue) | 优先分配请求到空闲 RS(连接数为 0),无空闲时用 SED | 避免请求排队,适合低延迟需求(如数据库) |
4. 网络与内核优化
- 关闭 ICMP 重定向:防止 RS 将流量绕开 Director(所有节点需配置):
echo "0" > /proc/sys/net/ipv4/conf/all/send_redirects echo "0" > /proc/sys/net/ipv4/conf/default/send_redirects
- 调整 TCP 参数:优化连接建立和关闭效率(Director 和 RS 均需配置):
echo "1" > /proc/sys/net/ipv4/tcp_tw_reuse # 复用TIME_WAIT连接 echo "5" > /proc/sys/net/ipv4/tcp_fin_timeout # FIN_WAIT2超时设为5秒
增大 TCP 队列:避免高并发下 SYN 队列溢出(Director 需配置):
echo "65535" > /proc/sys/net/core/somaxconn # 最大监听队列数 echo "1048576" > /proc/sys/net/ipv4/tcp_max_syn_backlog # SYN队列大小
5. 监控与告警
需实时监控 LVS 集群状态,及时发现异常:
- 监控指标:
- Director:CPU、内存、网络带宽(进出流量)、连接跟踪数。
- RS:连接数、服务端口存活状态、响应延迟。
- LVS:虚拟服务状态、RS 健康状态、调度次数。
- 常用工具:
- 基础监控:
ipvsadm -L -n
(查看 LVS 调度状态)、netstat -tuln
(端口监控)。 - 可视化监控:Prometheus+Grafana(需部署
ipvs-exporter
采集 LVS 指标)、Zabbix(自定义模板监控 RS 健康)。
- 基础监控:
四、四种模式对比与选择建议
对比维度 | DR 模式 | NAT 模式 | TUN 模式 | FULL-NAT 模式 |
---|---|---|---|---|
数据流向 | 请求过 Director,响应直连 | 所有流量过 Director | 请求过 Director,响应直连 | 所有流量过 Director |
跨网段支持 | 不支持(同二层) | 支持 | 支持(跨地域) | 支持(多子网) |
性能 | 极高(无流量瓶颈) | 低(Director 瓶颈) | 高(隧道开销) | 较低(两次 IP 转换) |
RS 配置复杂度 | 中(需 VIP+ARP 抑制) | 低(仅需网关) | 中(需 VIP + 隧道) | 低(无特殊配置) |
适用场景 | 高并发本地集群 | 小规模内部服务 | 跨地域分布式集群 | 多子网灵活部署 |
选择建议
- 优先选 DR 模式:若 RS 集中部署在同一机房,且需高并发、高带宽(如生产环境 Web 服务)。
- 次选 TUN 模式:若 RS 跨地域 / 跨路由部署(如 CDN、多机房灾备)。
- 备选 NAT 模式:若集群规模小、流量低(如测试环境、内部 OA)。
- 最后选 FULL-NAT 模式:仅当 RS 无法配置网关指向 Director 时(如多 VPC 混合云)。
总结
LVS 的四种模式各有侧重,核心是通过 “减少 Director 流量负担”(DR/TUN)或 “降低部署复杂度”(NAT/FULL-NAT)平衡性能与灵活性。实际部署中,需结合业务流量规模、网络拓扑、运维成本选择模式,并通过 “高可用(keepalived)+ 健康检查 + 内核优化” 确保集群稳定运行。
阅读剩余
版权声明:
作者:SE-YangYao
链接:https://www.cnesa.cn/7599.html
文章版权归作者所有,未经允许请勿转载。
THE END
相关推荐