负载均衡的LVS三种模式：NAT、TUN、DR场景对比与实践指南

最新推荐文章于 2025-09-06 17:47:50 发布

原创最新推荐文章于 2025-09-06 17:47:50 发布 · 699 阅读

6 ·

CC 4.0 BY-SA版权

文章标签：

#负载均衡 #lvs #dr模式 #ip隧道 #运维面经 #k8s面试 #docker面试

1. LVS的灵魂：三种模式的本质解析

LVS的核心在于将客户端请求高效分发到后端服务器（Real Server），而NAT、TUN、DR三种模式决定了分发的“玩法”。它们就像三种不同的交通工具：NAT是大巴，TUN是高铁，DR是飞机，各有优劣，关键看你的“旅程”需求。

NAT：简单粗暴的流量中转站

NAT（Network Address Translation）模式通过地址转换实现负载均衡。LVS Director（调度器）接收客户端请求，改写数据包的目标IP为后端Real Server的IP，Real Server处理后返回给Director，Director再将响应转发给客户端。简单来说，Director就是个“全职保姆”，全程介入请求和响应。

工作原理：Director收到请求后，根据调度算法（如轮询、加权最少连接）选择Real Server，改写数据包的目标IP和端口，发送到Real Server。Real Server处理后，响应数据包回传到Director，Director再改写源IP为自己的IP，回传给客户端。
关键特点：
- 双向流量：请求和响应都经过Director，Director既是入口也是出口。
- 网络要求：Real Server的网关必须指向Director，确保响应流量回流。
- 性能瓶颈：Director需要处理所有进出流量，网络带宽和CPU可能成为瓶颈。
适用场景：小型网站、内部系统，服务器数量少，流量压力不大。如果你是个初创公司，预算有限，NAT是你的入门首选。

TUN：隧道中的高效快递

TUN（IP Tunneling）模式利用IP隧道技术，Director将请求数据包封装在一个新的IP数据包中，通过隧道发送到Real Server，Real Server直接响应客户端，完全绕过了Director的响应转发。

工作原理：Director收到请求后，选择Real Server，将原始数据包封装在IP隧道中，发送到Real Server。Real Server解封装后处理请求，直接将响应发回客户端。
关键特点：
- 单向流量：Director只负责分发请求，响应直接由Real Server发回客户端，极大减轻Director负担。
- 网络要求：需要Real Server支持IP隧道（tunl0接口），且Director与Real Server之间需支持IPIP协议。
- 性能优势：响应流量不经过Director，适合高流量场景。
适用场景：跨地域分布式系统，CDN（内容分发网络），或者需要高吞吐量的场景。TUN就像为大流量场景量身定制的“高速通道”。

DR：极致性能的直达快车

DR（Direct Routing）模式是性能王者，Director只负责将请求数据包的目标MAC地址改为Real Server的MAC地址，Real Server直接响应客户端，堪称“零负担”分发。

工作原理：Director和Real Server在同一局域网内，共享一个虚拟IP（VIP）。Director收到请求后，改写数据包的目标MAC地址为Real Server的MAC地址，Real Server处理后直接响应客户端。
关键特点：
- 最高性能：Director只处理请求的分发，响应完全由Real Server直达客户端。
- 网络要求：Director和Real Server必须在同一物理网络，Real Server需要配置VIP（通常通过lo接口）。
- 配置复杂：需要调整Real Server的ARP设置，避免VIP冲突。
适用场景：高并发、高流量场景，如大型电商、视频流媒体平台。DR是追求极致性能的“超级跑车”。

三者对比：一图胜千言

特性	NAT	TUN	DR
流量路径	请求和响应都经过Director	请求经Director，响应直达客户端	请求经Director，响应直达客户端
网络要求	Real Server网关指向Director	支持IP隧道	同一局域网，配置VIP
性能	受限于Director带宽	高吞吐，适合跨地域	极致性能，局域网最佳
配置复杂度	简单	中等	复杂
适用场景	小型网站	分布式系统、CDN	高并发场景

选择建议：如果你是初学者，NAT简单易上手；如果你的业务跨地域或流量大，TUN是优选；如果追求极致性能且服务器在同一机房，DR是不二之选。

2. NAT模式的实战部署：从零到上线

NAT模式因其配置简单，常用于中小型项目。让我们通过一个实际案例，部署一个简单的Web负载均衡集群，假设你有一台Director和两台Real Server，目标是分发HTTP请求。

环境准备

硬件：
- Director：CentOS 7，IP为192.168.1.100（外网网卡eth0），192.168.2.100（内网网卡eth1）。
- Real Server 1：CentOS 7，IP为192.168.2.101。
- Real Server 2：CentOS 7，IP为192.168.2.102。
软件：安装ipvsadm（LVS管理工具），Real Server上运行Nginx。
网络拓扑：客户端 -> Director（eth0） -> Real Server（eth1）。

步骤1：安装与配置LVS

安装ipvsadm：
```
yum install ipvsadm -y
```
开启IP转发（Director需要转发数据包）：编辑/etc/sysctl.conf，添加：
```
net.ipv4.ip_forward = 1
```
应用配置：
```
sysctl -p
```

配置LVS NAT规则：

ipvsadm -A -t 192.168.1.100:80 -s rr  # 添加虚拟服务，rr为轮询算法
ipvsadm -a -t 192.168.1.100:80 -r 192.168.2.101:80 -m  # 添加Real Server 1，-m表示NAT模式
ipvsadm -a -t 192.168.1.100:80 -r 192.168.2.102:80 -m  # 添加Real Server 2

步骤2：配置Real Server

安装Nginx：

yum install nginx -y
systemctl start nginx
systemctl enable nginx

设置网关：确保Real Server的默认网关指向Director的内网IP（192.168.2.100）：
```
route add default gw 192.168.2.100
```
验证Nginx服务：在每台Real Server上创建测试页面（如/usr/share/nginx/html/index.html），内容分别为“Server 1”和“Server 2”。

步骤3：测试与验证

用浏览器访问http://192.168.1.100，观察是否轮询访问到Server 1和Server 2的页面。

查看LVS状态：

ipvsadm -Ln

输出示例：

IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
  -> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP  192.168.1.100:80 rr
  -> 192.168.2.101:80 Masq    1      0          0
  -> 192.168.2.102:80 Masq    1      0          0

注意事项

防火墙：确保Director的eth0和eth1端口80开放，Real Server的80端口可访问。
性能瓶颈：NAT模式下，Director的带宽和CPU可能成为限制，建议监控其负载。
扩展性：添加更多Real Server只需重复ipvsadm -a命令，灵活性高。

NAT模式的魅力在于简单，就像搭积木，配置几条命令就能跑起来。但它的短板也很明显：Director的压力大，流量大了容易“喘不过气”。接下来，我们看看TUN模式如何“解放”Director！

3. TUN模式的进阶实践：跨地域负载均衡

TUN模式通过IP隧道实现请求分发，特别适合跨地域的分布式系统。假设你运营一个视频网站，后端服务器分布在不同数据中心，TUN模式能让你的Director只管“派单”，响应交给Real Server直接搞定。

环境准备

硬件：
- Director：CentOS 7，IP为10.0.0.1。
- Real Server 1：CentOS 7，IP为172.16.0.101（数据中心A）。
- Real Server 2：CentOS 7，IP为192.168.0.102（数据中心B）。
软件：ipvsadm，Real Server上运行Apache。
网络要求：Director和Real Server需支持IPIP隧道协议。

步骤1：配置IP隧道

Director端：
- 加载IPIP模块：
```
modprobe ipip
```
- 确认模块加载：
```
lsmod | grep ipip
```
Real Server端：
- 加载IPIP模块并创建tunl0接口：
```
modprobe ipip
ip link set tunl0 up
```
- 配置VIP（假设VIP为10.0.0.100）：
```
ip addr add 10.0.0.100/32 dev tunl0
```

步骤2：配置LVS TUN规则

在Director上：

ipvsadm -A -t 10.0.0.100:80 -s wlc  # wlc为加权最少连接算法
ipvsadm -a -t 10.0.0.100:80 -r 172.16.0.101:80 -i  # -i表示TUN模式
ipvsadm -a -t 10.0.0.100:80 -r 192.168.0.102:80 -i

步骤3：Real Server配置Apache

安装Apache：

yum install httpd -y
systemctl start httpd
systemctl enable httpd

创建测试页面：在/var/www/html/index.html写入不同内容，如“Data Center A”和“Data Center B”。

步骤4：测试与验证

访问http://10.0.0.100，确认是否能轮询到不同数据中心的页面。
检查LVS状态：
```
ipvsadm -Ln
```

注意事项

隧道性能：TUN模式对网络延迟敏感，确保Director和Real Server间的网络稳定。
安全：IP隧道可能被攻击，建议配置IPSec加密隧道。
跨地域挑战：不同数据中心的网络环境可能导致隧道不稳定，需测试连通性。

TUN模式的精髓在于“轻量分发”，Director只管把请求丢进隧道，响应完全交给Real Server，性能提升显著。接下来，我们进入DR模式的“高性能赛道”！

4. DR模式的实战部署：打造高性能负载均衡

DR模式（Direct Routing）是LVS的性能王者，Director只负责将请求的MAC地址改写为Real Server的MAC地址，响应直接由Real Server发回客户端，完全绕过Director的响应处理。这种模式特别适合大型网站、视频流媒体或电商平台等高并发场景。让我们通过一个实际案例，部署一个DR模式的负载均衡集群。

环境准备

硬件：
- Director：CentOS 7，IP为192.168.1.100（网卡eth0）。
- Real Server 1：CentOS 7，IP为192.168.1.101。
- Real Server 2：CentOS 7，IP为192.168.1.102。
- 虚拟IP（VIP）：192.168.1.200，共享在Director和Real Server上。
软件：ipvsadm，Real Server上运行Nginx。
网络要求：Director和Real Server必须在同一局域网（同一二层网络），以确保MAC地址改写有效。

步骤1：配置Director

安装ipvsadm：
```
yum install ipvsadm -y
```
配置VIP：在Director的eth0上绑定VIP：
```
ip addr add 192.168.1.200/32 dev eth0
```

配置LVS DR规则：

ipvsadm -A -t 192.168.1.200:80 -s wrr  # wrr为加权轮询算法
ipvsadm -a -t 192.168.1.200:80 -r 192.168.1.101:80 -g -w 1  # -g表示DR模式，权重为1
ipvsadm -a -t 192.168.1.200:80 -r 192.168.1.102:80 -g -w 1

步骤2：配置Real Server

DR模式需要在Real Server上配置VIP，并抑制ARP广播以避免IP冲突。这部分配置有点“玄学”，但搞定后性能飞起！

安装Nginx：

yum install nginx -y
systemctl start nginx
systemctl enable nginx

配置VIP（在lo接口上，避免影响真实网络）：
```
ip addr add 192.168.1.200/32 dev lo
```

抑制ARP广播（防止Real Server响应VIP的ARP请求）：编辑/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

创建测试页面：在/usr/share/nginx/html/index.html写入不同内容，如“Real Server 1”和“Real Server 2”。

步骤3：测试与验证

用浏览器访问http://192.168.1.200，轮询访问Real Server 1和2的页面。

检查LVS状态：

ipvsadm -Ln

输出示例：

IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
  -> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP  192.168.1.200:80 wrr
  -> 192.168.1.101:80 Route   1      0          0
  -> 192.168.1.102:80 Route   1      0          0

注意事项

同一网段：Director和Real Server必须在同一二层网络，否则MAC地址改写无效。
ARP抑制：如果ARP配置错误，可能导致VIP冲突，客户端无法访问。
防火墙：确保Director和Real Server的80端口开放，禁用SELinux或配置相应规则。
扩展性：添加新Real Server只需重复步骤2，DR模式扩展性极强。

DR模式的魅力在于极致性能，Director几乎“甩手掌柜”，只管改MAC地址，响应全由Real Server搞定。但配置稍复杂，尤其是ARP抑制，容易踩坑。搞定这些细节，你就是LVS的“驯兽师”！

5. 三种模式的性能测试与对比

理论讲了一堆，实际性能到底如何？我们来做个简单测试，比较NAT、TUN、DR在高并发场景下的表现。这部分就像给三种模式做个体检，数据说话！

测试环境

硬件：Director和两台Real Server均使用4核8G云服务器，同一局域网。
工具：使用ab（Apache Benchmark）模拟高并发请求。
测试场景：每种模式下，访问静态HTML页面，模拟1000并发用户，请求10万次。
LVS配置：轮询算法（rr），两台Real Server权重相等。

测试步骤

NAT模式：
- 配置如第2章，VIP为192.168.1.100。
- 测试命令：
```
ab -n 100000 -c 1000 http://192.168.1.100/
```
- 结果：QPS约5000，Director CPU占用80%，网络带宽接近饱和。
TUN模式：
- 配置如第3章，VIP为10.0.0.100。
- 测试命令：
```
ab -n 100000 -c 1000 http://10.0.0.100/
```
- 结果：QPS约8000，Director CPU占用30%，网络带宽压力较小。
DR模式：
- 配置如第4章，VIP为192.168.1.200。
- 测试命令：
```
ab -n 100000 -c 1000 http://192.168.1.200/
```
- 结果：QPS约12000，Director CPU占用仅10%，网络带宽几乎无压力。

测试结论

NAT：Director成为瓶颈，适合低流量场景。
TUN：性能提升明显，适合跨地域或高流量场景，但隧道开销略影响QPS。
DR：性能最佳，Director负载极低，适合高并发场景。

建议：小流量选NAT，跨地域选TUN，高并发选DR。但别忘了，性能好坏还得看你的硬件、网络和调优水平！

6. LVS调优：让性能再飞一会儿

三种模式部署好了，性能还想再榨一点？LVS的调优就像给赛车换上涡轮增压，细节决定成败。以下是一些实战中常用的优化技巧，涵盖网络、调度算法和监控。

优化1：选择合适的调度算法

LVS支持多种调度算法，不同场景选对算法能显著提升性能：

rr（轮询）：简单公平，适合Real Server性能均衡。
wrr（加权轮询）：根据权重分配请求，适合服务器性能差异大。
lc（最少连接）：动态选择连接数最少的Real Server，适合长连接场景。
wlc（加权最少连接）：结合权重和连接数，适合复杂场景。

配置示例：

ipvsadm -A -t 192.168.1.200:80 -s wlc
ipvsadm -a -t 192.168.1.200:80 -r 192.168.1.101:80 -g -w 2  # 权重2
ipvsadm -a -t 192.168.1.200:80 -r 192.168.1.102:80 -g -w 1  # 权重1

优化2：网络参数调优

增大连接跟踪表：LVS依赖内核的连接跟踪，增大表大小避免连接丢失：

echo "net.nf_conntrack_max = 655360" >> /etc/sysctl.conf
echo "net.netfilter.nf_conntrack_tcp_timeout_established = 300" >> /etc/sysctl.conf
sysctl -p

优化TCP参数：

echo "net.ipv4.tcp_tw_reuse = 1" >> /etc/sysctl.conf
echo "net.ipv4.tcp_fin_timeout = 15" >> /etc/sysctl.conf
sysctl -p

优化3：健康检查

LVS默认不检查Real Server状态，需结合工具如keepalived实现：

安装keepalived：
```
yum install keepalived -y
```

配置健康检查（/etc/keepalived/keepalived.conf）：

vrrp_instance VI_1 {
    state MASTER
    interface eth0
    virtual_router_id 51
    priority 100
    advert_int 1
    virtual_ipaddress {
        192.168.1.200
    }
}
virtual_server 192.168.1.200 80 {
    delay_loop 6
    lb_algo wrr
    lb_kind DR
    protocol TCP
    real_server 192.168.1.101 80 {
        weight 1
        TCP_CHECK {
            connect_timeout 3
            nb_get_retry 3
            delay_before_retry 3
        }
    }
    real_server 192.168.1.102 80 {
        weight 1
        TCP_CHECK {
            connect_timeout 3
            nb_get_retry 3
            delay_before_retry 3
        }
    }
}

启动keepalived：

systemctl start keepalived
systemctl enable keepalived

优化4：监控与日志

监控LVS状态：
```
watch -n 1 'ipvsadm -Ln'
```
收集性能数据：使用sar或nload监控Director的CPU和网络负载。

日志分析：启用LVS日志（需内核支持）：

echo "net.ipv4.vs.debug_level = 1" >> /etc/sysctl.conf
sysctl -p

调优的核心是平衡：算法选对、参数调好、健康检查到位，你的LVS就能跑得又快又稳！

7. 高可用LVS：用Keepalived打造不宕机的集群

LVS的Director是整个负载均衡的“心脏”，一旦挂掉，服务就全线瘫痪。在生产环境里，单点故障是大忌！ 这时候，Keepalived就派上用场了，它通过VRRP协议实现Director的主备切换，确保服务不中断。让我们以DR模式为例，配置一个高可用的LVS集群。

环境准备

硬件：
- 主Director：CentOS 7，IP为192.168.1.100。
- 备Director：CentOS 7，IP为192.168.1.110。
- Real Server 1：IP为192.168.1.101。
- Real Server 2：IP为192.168.1.102。
- 虚拟IP（VIP）：192.168.1.200。
软件：ipvsadm、keepalived，Real Server运行Nginx。
网络：所有机器在同一局域网，VIP共享。

步骤1：配置主Director

安装ipvsadm和keepalived：
```
yum install ipvsadm keepalived -y
```

配置LVS DR规则（同第4章）：

ipvsadm -A -t 192.168.1.200:80 -s wrr
ipvsadm -a -t 192.168.1.200:80 -r 192.168.1.101:80 -g -w 1
ipvsadm -a -t 192.168.1.200:80 -r 192.168.1.102:80 -g -w 1

配置Keepalived（/etc/keepalived/keepalived.conf）：

vrrp_instance VI_1 {
    state MASTER
    interface eth0
    virtual_router_id 51
    priority 100  # 主Director优先级高
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 123456
    }
    virtual_ipaddress {
        192.168.1.200/32 dev eth0
    }
}
virtual_server 192.168.1.200 80 {
    delay_loop 6
    lb_algo wrr
    lb_kind DR
    protocol TCP
    real_server 192.168.1.101 80 {
        weight 1
        TCP_CHECK {
            connect_timeout 3
            nb_get_retry 3
            delay_before_retry 3
        }
    }
    real_server 192.168.1.102 80 {
        weight 1
        TCP_CHECK {
            connect_timeout 3
            nb_get_retry 3
            delay_before_retry 3
        }
    }
}

启动服务：

systemctl start keepalived
systemctl enable keepalived

步骤2：配置备Director

安装ipvsadm和keepalived：
```
yum install ipvsadm keepalived -y
```

配置Keepalived（/etc/keepalived/keepalived.conf）：

vrrp_instance VI_1 {
    state BACKUP
    interface eth0
    virtual_router_id 51
    priority 90  # 优先级低于主Director
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 123456
    }
    virtual_ipaddress {
        192.168.1.200/32 dev eth0
    }
}
virtual_server 192.168.1.200 80 {
    delay_loop 6
    lb_algo wrr
    lb_kind DR
    protocol TCP
    real_server 192.168.1.101 80 {
        weight 1
        TCP_CHECK {
            connect_timeout 3
            nb_get_retry 3
            delay_before_retry 3
        }
    }
    real_server 192.168.1.102 80 {
        weight 1
        TCP_CHECK {
            connect_timeout 3
            nb_get_retry 3
            delay_before_retry 3
        }
    }
}

启动服务：

systemctl start keepalived
systemctl enable keepalived

步骤3：Real Server配置

参考第4章，配置VIP和ARP抑制，确保Real Server响应请求。

步骤4：测试高可用

正常状态：访问http://192.168.1.200，确认轮询到Real Server。
模拟主Director故障：停止主Director的keepalived服务：
```
systemctl stop keepalived
```
观察备Director是否接管VIP（通过ip addr查看192.168.1.200是否出现在eth0）。
恢复主Director：重启keepalived，确认VIP切换回主Director。

注意事项

VRRP广播：确保网络允许VRRP多播（组播地址224.0.0.18）。
健康检查：TCP_CHECK仅检查端口连通性，若需更复杂的检查，可用HTTP_GET或脚本。
日志监控：检查keepalived日志（/var/log/messages）以排查切换问题。

Keepalived让LVS如虎添翼，主备切换快如闪电，服务几乎零中断。但生产环境里，故障排查才是真考验，接下来我们聊聊怎么“捉虫”！

8. 故障排查：让LVS的“坑”无处遁形

LVS配置看似简单，但生产环境里总会冒出各种“妖魔鬼怪”。别慌，带上这套排查套路，问题一个都跑不掉！ 以下是常见问题及解决办法，涵盖NAT、TUN、DR三种模式。

问题1：客户端无法访问VIP

可能原因：
- Director的VIP未正确绑定。
- 防火墙阻挡了VIP或端口。
- Real Server未正确配置网关（NAT模式）或VIP（DR/TUN模式）。
排查步骤：
1. 确认VIP状态：
```
ip addr show eth0
```
  确保VIP（如192.168.1.200）出现在网卡上。
2. 检查防火墙：
```
iptables -L -n
firewall-cmd --list-all
```
  确保80端口开放。
3. NAT模式检查Real Server网关：
```
ip route
```
  确认默认网关指向Director。
4. DR模式检查ARP抑制：
```
sysctl -a | grep arp
```
  确保arp_ignore=1，arp_announce=2。
解决示例：若VIP未绑定，重新执行ip addr add 192.168.1.200/32 dev eth0。

问题2：部分Real Server无法响应

可能原因：
- Real Server服务（如Nginx）未运行。
- Keepalived健康检查剔除了Real Server。
- 网络不通（TUN模式隧道问题，DR模式MAC地址转发失败）。
排查步骤：
1. 检查Real Server服务状态：
```
systemctl status nginx
```
2. 查看LVS状态：
```
ipvsadm -Ln
```
  若Real Server的ActiveConn为0，可能被剔除。
3. TUN模式检查隧道：
```
ping 172.16.0.101  # 从Director到Real Server
```
4. DR模式检查MAC转发：
```
arp -n
```
  确认VIP对应的MAC地址正确。
解决示例：若Nginx未运行，重启服务；若健康检查剔除，调整keepalived的检查参数。

问题3：性能瓶颈

可能原因：
- NAT模式Director带宽或CPU不足。
- 调度算法不合理（如rr在性能差异大的Real Server上表现不佳）。
- 连接跟踪表溢出。
排查步骤：
1. 监控Director负载：
```
top
nload eth0
```
2. 检查连接跟踪表：
```
cat /proc/sys/net/nf_conntrack_max
cat /proc/net/nf_conntrack | wc -l
```
3. 优化算法（参考第6章）。
解决示例：若连接跟踪表溢出，增大nf_conntrack_max：
```
echo "net.nf_conntrack_max = 655360" >> /etc/sysctl.conf
sysctl -p
```

问题4：Keepalived切换失败

可能原因：
- VRRP广播被网络设备阻挡。
- 主备Director配置不一致（如virtual_router_id不同）。
- 优先级设置错误。
排查步骤：
1. 检查日志：
```
tail -f /var/log/messages
```
2. 抓取VRRP包：
```
tcpdump -i eth0 vrrp
```
3. 确认配置一致性，检查priority和virtual_router_id。
解决示例：若VRRP包被阻挡，与网络管理员确认组播设置。

故障排查的关键是细心，从VIP到Real Server，从网络到服务，逐层排查，总能找到“罪魁祸首”。日志、抓包、状态检查是你的三大法宝！

9. LVS的场景化实践：从电商到视频流

三种模式各有千秋，但如何根据业务场景选择？让我们通过两个真实案例，看看LVS如何在不同行业发光发热！

案例1：电商平台（DR模式）

场景：某电商平台双11促销，预计QPS达2万，需高性能负载均衡。

架构：1台Director，4台Real Server（运行Tomcat），VIP为192.168.1.200。
配置要点：
- 使用DR模式，配置如第4章。
- 调度算法选择wlc，权重根据Tomcat性能调整（如8核服务器权重2，4核权重1）。
- 部署keepalived实现高可用（参考第7章）。
- 优化TCP参数，增大连接跟踪表（参考第6章）。
效果：QPS稳定在2.2万，Director CPU占用仅15%，主备切换时间小于1秒。

案例2：视频流平台（TUN模式）

场景：某视频网站，服务器分布在三个数据中心，需跨地域负载均衡。

架构：1台Director，3台Real Server（不同数据中心，运行Nginx），VIP为10.0.0.100。
配置要点：
- 使用TUN模式，配置如第3章。
- 配置IPSec加密隧道，保障数据安全。
- 使用wrr算法，权重根据数据中心带宽调整。
- 部署keepalived，增加HTTP_GET健康检查。
效果：跨地域延迟平均150ms，QPS达1.5万，Director负载低。