1. 为什么还要聊LVS和NAT模式干了这么多年运维每次带新人或者跟同行交流只要话题一碰到四层负载均衡LVS就绕不开。很多人第一次接触LVS看到那一堆术语——DS、RS、VIP、DIP、RIP再加上三种模式NAT、DR、TUN直接就被劝退了。但说实话如果你只是想快速搭一套能用的四层负载均衡NAT模式是最容易上手、对网络环境要求最低的一种。它不需要改后端服务器的默认网关不需要在RS上做复杂的ARP抑制甚至不需要后端服务器和负载均衡器在同一个二层网络里。你只要有一台能通外网、能通内网的Linux机器就能把整套东西跑起来。这篇文章就是围绕LVS的NAT模式来展开的。我会从整体设计思路讲起把为什么选NAT、NAT模式的数据包流转逻辑、ipvsadm的核心参数、后端Real Server的配置要点一直到完整的实操步骤和排错经验全部拆开揉碎讲一遍。适合那些刚接触四层负载均衡、想快速搭一套实验环境验证效果的运维新手也适合那些以前只用过Nginx七层代理、想往四层下沉一步的开发者。看完之后你至少能做到自己规划IP、自己配LVS、自己加后端、自己验证效果出了问题知道从哪几个方向去查。2. LVS NAT模式整体设计与思路拆解2.1 为什么选NAT模式而不是DR或TUNLVS的三种模式里DR模式性能最好因为响应包直接由RS返回给客户端不经过Director。但DR模式有个硬性要求Director和RS必须在同一个物理二层网络里而且RS上要配置VIP到lo接口并做ARP抑制。TUN模式更麻烦需要RS支持IP隧道网络环境要允许协议号4的IPIP包通过。相比之下NAT模式虽然性能不如前两者但它的网络要求最低——Director只要能和RS通信就行RS的网关指向Director即可。对于实验环境、内部测试环境、或者后端服务器数量不多的小型生产环境NAT模式完全够用。我个人的经验是如果你第一次搭LVS直接上DR模式很容易在ARP抑制那一步卡住因为不同发行版、不同内核版本对arp_ignore和arp_announce的处理有细微差异。NAT模式就没这些坑你只要把网络层配通剩下的就是ipvsadm几条命令的事。2.2 NAT模式的数据包流转逻辑NAT模式的核心就一句话客户端请求到DirectorDirector做DNAT把目标地址改成某台RS的地址RS处理完把响应包回给DirectorDirector再做SNAT把源地址改成VIP最后返回给客户端。整个过程客户端只知道VIP不知道后面有多少台RS。这里有个关键点RS的默认网关必须指向Director的内网IPDIP。因为RS收到的请求包源地址是客户端地址如果RS的默认网关不是Director它就会尝试直接把响应包发给客户端但客户端根本不认识RS的地址这个包就丢了。所以NAT模式下Director实际上是RS的网关所有回包都必须经过Director。2.3 整体架构规划我一般做实验会用三台虚拟机规划如下角色主机名IP地址说明负载均衡器lvs-directorVIP: 192.168.100.100 / DIP: 10.0.0.1双网卡VIP对外DIP对内后端服务器1rs-web-0110.0.0.11网关指向10.0.0.1后端服务器2rs-web-0210.0.0.12网关指向10.0.0.1VIP和DIP在不同网段这样NAT的DNAT和SNAT逻辑更清晰。如果你只有一个网段也可以做但实验效果没那么直观。3. 核心细节解析与实操要点3.1 ipvsadm核心参数拆解ipvsadm是LVS的管理工具命令不多但每个参数的含义要搞清楚。最常用的几条-A添加一个虚拟服务后面跟VIP和端口-s指定调度算法-a添加一台Real Server-r指定RS地址-m表示NAT模式-l列出当前规则-n不解析域名直接显示IP-C清空所有规则-Z清零计数器调度算法我一般用wrr加权轮询或者rr轮询。如果后端机器配置不一样用wrr给高配机器更大权重。lc最少连接在长连接场景下更合适但实验环境用rr就够了。3.2 后端Real Server的配置要点NAT模式下RS的配置极其简单但有两个地方必须注意第一RS的默认网关必须指向DIP。这是NAT模式的硬性要求不配的话回包出不去。第二RS上不需要安装任何LVS相关的软件它就是一个普通的Web服务器跑个Nginx或者Apache就行。提示如果你在RS上看到请求的源IP是客户端真实IP那是正常的因为Director做的是DNAT没有改源地址。但响应包回Director的时候Director会做SNAT所以客户端看到的响应源IP是VIP。3.3 内核参数转发设置Director上必须开启IP转发否则内核不会把包从一个网卡转到另一个网卡。命令是echo 1 /proc/sys/net/ipv4/ip_forward永久生效的话写到/etc/sysctl.conf里net.ipv4.ip_forward 1然后sysctl -p加载。这个参数不开启LVS规则配了也没用包根本不会转发。4. 完整实操过程与核心环节实现4.1 环境准备与网络配置先在三台机器上把网络配好。Director有两块网卡ens33对应VIP网段ens34对应DIP网段。RS各一块网卡网关指向DIP。Director网络配置示例# ens33 配置VIP nmcli con mod ens33 ipv4.addresses 192.168.100.100/24 nmcli con mod ens33 ipv4.method manual nmcli con up ens33 # ens34 配置DIP nmcli con mod ens34 ipv4.addresses 10.0.0.1/24 nmcli con mod ens34 ipv4.method manual nmcli con up ens34RS网络配置示例以rs-web-01为例nmcli con mod ens33 ipv4.addresses 10.0.0.11/24 nmcli con mod ens33 ipv4.gateway 10.0.0.1 nmcli con mod ens33 ipv4.method manual nmcli con up ens33配完之后互相ping一下确保Director能ping通RSRS能ping通DIP。4.2 Director上安装和配置LVS安装ipvsadmyum install -y ipvsadm # 或者 Ubuntu/Debian apt install -y ipvsadm开启IP转发echo 1 /proc/sys/net/ipv4/ip_forward添加虚拟服务和Real Server# 添加虚拟服务VIP 192.168.100.100:80调度算法轮询 ipvsadm -A -t 192.168.100.100:80 -s rr # 添加两台RSNAT模式 ipvsadm -a -t 192.168.100.100:80 -r 10.0.0.11:80 -m ipvsadm -a -t 192.168.100.100:80 -r 10.0.0.12:80 -m # 查看规则 ipvsadm -ln正常输出应该是这样的IP Virtual Server version 1.2.1 (size4096) Prot LocalAddress:Port Scheduler Flags - RemoteAddress:Port Forward Weight ActiveConn InActConn TCP 192.168.100.100:80 rr - 10.0.0.11:80 Masq 1 0 0 - 10.0.0.12:80 Masq 1 0 0Masq就是NAT模式的标记看到这个说明规则加对了。4.3 后端RS部署Web服务两台RS上各装一个Nginx写一个简单的测试页面yum install -y nginx echo This is RS1 - 10.0.0.11 /usr/share/nginx/html/index.html systemctl start nginx systemctl enable nginxRS2同理页面内容改成RS2的标识。这样访问的时候能直观看到请求被分发到了哪台机器。4.4 验证负载均衡效果在客户端机器上或者直接在Director上用curl访问VIPcurl http://192.168.100.100多执行几次应该能看到RS1和RS2的页面交替出现。如果只出现一台检查另一台RS的Nginx是否正常、网关是否指向DIP。查看连接分发情况ipvsadm -ln --stats这个命令会显示每台RS的活跃连接数和总连接数能直观看到分发是否均匀。5. 常见问题与排查技巧实录5.1 访问VIP不通或超时这是最常见的问题排查顺序如下排查项检查命令可能原因IP转发是否开启cat /proc/sys/net/ipv4/ip_forward返回0说明没开LVS规则是否存在ipvsadm -ln规则为空或端口写错RS的Web服务是否正常curl http://10.0.0.11Nginx没启动或防火墙拦截RS网关是否指向DIPip route show default网关不对回包出不去防火墙是否放行iptables -L -nDirector或RS上防火墙拦截了80端口我踩过最坑的一次是RS上开了firewalld80端口没放行Director转发过去的包直接被RS的防火墙丢了。后来养成习惯实验环境先把防火墙关了或者放行相关端口。5.2 只有一台RS能响应如果发现所有请求都打到同一台RS上先检查另一台RS的Nginx是否正常。如果Nginx正常再看ipvsadm -ln里那台RS的Weight是不是0。有时候手误把权重设成0了流量就不会往那台机器分。还有一种情况是调度算法用了wrr但两台机器权重不一样流量分配不均。实验环境建议先用rr确认分发正常后再调权重。5.3 客户端看到的源IP不对NAT模式下RS看到的源IP是客户端真实IP但客户端看到的响应源IP是VIP。如果你在RS的访问日志里看到的是客户端IP那是正常的。如果你希望RS看到的是Director的DIP那需要做Full NAT但LVS原生不支持Full NAT需要额外打补丁或者用其他方案。5.4 持久连接问题有些应用需要同一个客户端的请求始终打到同一台RS上比如带Session的Web应用。LVS支持持久连接用-p参数ipvsadm -A -t 192.168.100.100:80 -s rr -p 300-p 300表示300秒内同一个客户端IP的请求都打到同一台RS。这个在实验环境里很好验证加完之后再curl会发现一段时间内始终返回同一台RS的页面。注意持久连接会影响负载均衡效果如果客户端IP集中比如都在一个NAT后面会导致流量倾斜。生产环境要结合实际情况决定是否开启。6. 实操心得与进阶建议6.1 实验环境搭建的几个小技巧我一般会用Vagrant或者Docker来快速起实验环境。如果用虚拟机建议Director至少给2G内存RS给1G就够了。网络模式用Host-Only或者自定义NAT网络避免和宿主机网段冲突。另外实验前先把所有机器的防火墙和SELinux关掉能省掉至少一半的排错时间。命令systemctl stop firewalld setenforce 0生产环境当然不能这么干但实验环境先跑通再说。6.2 从NAT模式往DR模式迁移的思路如果你NAT模式跑通了想试试DR模式核心改动就三点Director和RS要在同一网段RS上要把VIP配到lo接口RS要做ARP抑制。ipvsadm的命令从-m改成-g。其他逻辑基本一样。所以NAT模式是很好的入门跳板先把LVS的基本概念和命令熟悉了再往高性能模式迁移就顺理成章。6.3 监控和日常维护生产环境用LVS至少要监控两个东西Director上的连接分发是否均匀以及RS的健康状态。LVS本身不带健康检查需要配合keepalived或者自己写脚本。实验环境可以手动ipvsadm -ln --stats看看生产环境一定要上自动健康检查否则一台RS挂了流量还会往上面打客户端就会遇到间歇性502。我个人在实际操作中的体会是LVS NAT模式虽然简单但它是理解四层负载均衡最好的切入点。你把NAT模式的数据包流转搞清楚了再去理解DR和TUN就非常容易。而且NAT模式在很多内部系统里仍然在用并不是说它性能差就完全被淘汰了。关键还是看场景适合的才是最好的。
