一台机器的CPU和带宽顶不住的时候很多人第一反应是在前面挂一层 Nginx 做反向代理。真挂上去之后发现Nginx 那一层自己先变成了瓶颈连接数上不去、worker 进程调度开销大、TLS 握手吃掉一半 CPU后端加机器解决不了入口转发这一层的问题。这种场景下就该把视线往协议栈下面挪一层回到四层转发而 LVSLinux Virtual Server就是这个位置上最经典的一套方案——它跑在内核里只做数据包的地址改写不理解 HTTP也不需要在用户态复制数据一台普通配置的机器就能顶住几十万并发连接。这篇内容写给两类人一类是刚接触负载均衡、想搞清楚 LVS 到底在内核里做了什么动手又怕搞坏环境的同学另一类是已经在用 Nginx 或 HAProxy、想补上四层这块短板的从业者。我以 LVS 集群的基本原理打底重点把 NAT 模式的部署链路一条一条走通包括网络规划、ipvsadm 命令的逐条解释、验证手段以及我实际部署中踩过的几个坑。所有配置都是可以在虚拟机里复现的跟着做一遍就能跑起来。1. LVS 在整条请求链路上究竟改动了什么1.1 从一个数据包出发理解四层转发很多人学 LVS 卡住不是命令记不住而是脑子里没有数据包的走向图。四层负载均衡的本质其实非常简单一个请求从客户端发出来目标地址写的是对外的那个 IP习惯上叫 VIPLVS 所在的这台机器Director收到包之后把 IP 头里的目的地址悄悄改成某台后端真实服务器Real Server下面简称 RS的地址再把包转出去后端处理完响应沿着原路回去或者按另一种方式直接回给客户端。整个过程里客户端始终认为自己是在和 VIP 通信后端也知道自己接到的请求是给 VIP 的中间那台机器对两端都是透明的。这个偷偷改地址的动作就是 NAT在网络层就是 DNAT 和 SNAT 的组合。之所以叫四层是因为 LVS 只看 IP 头里的源地址、目的地址、协议号、源端口、目的端口这五元组它不拆 TCP 报文里的应用层内容不知道请求的是/api/login还是/static/logo.png也不会解析 Host 头。这个限制让它在功能上不如 Nginx 灵活但同时换来了极高的转发效率——它做的事情越少单位时间内能处理的包就越多。这个取舍后面会反复提到先把链路走通更重要。1.2 内核里的 ip_vs 模块才是真正的干活主体跑ipvsadm命令的时候容易产生一个误解以为ipvsadm是个守护进程像 Nginx 那样常驻在后台处理请求。其实不是。ipvsadm只是一个控制面工具它的作用相当于往内核里写配置真正的转发逻辑全部由内核模块ip_vs完成。这一点理解清楚之后很多疑惑会自动消失比如为什么ipvsadm命令执行完就退出了、为什么系统重启之后规则没了、为什么用ps看不到 LVS 进程、为什么卸载ipvsadm软件包原先的转发规则还在生效。可以用lsmod | grep ip_vs确认模块是否加载。一般来说主流发行版的内核都编译了ip_vs执行modprobe ip_vs就能拉起来。一些依赖模块比如ip_vs_rr轮询调度、ip_vs_wrr加权轮询、ip_vs_wlc加权最少连接是按需加载的你用了哪种算法对应的模块才会出现。如果某次配置完之后发现调度的行为和预期不符先看看对应的算法模块有没有加载成功这是一个很省时间的检查点。内核里的连接状态记录用一张哈希表来存每条转发连接在表里占一个条目。这个表的容量决定了能同时维持多少活跃连接可以通过ip_vs_conn_tab_bits这个模块参数调整。大部分中小规模场景默认值够用但如果做的业务长连接特别多比如推送服务、数据库代理或者并发连接已经到十万量级就值得关注一下这个参数。修改方法是在/etc/modprobe.d/下建一个配置文件写入options ip_vs conn_tab_bits20然后重启模块或者重启机器生效。注意这个是 2 的指数20 意味着约 100 万个桶位。1.3 LVS、Nginx、HAProxy 不是替代关系而是分工关系经常看到有人争论负载均衡到底该用哪个这个问题本身问得不对。它们工作在协议栈的不同层次解决的是不同问题。LVS 工作在第四层只看 IP 和端口速度最快但不能根据 URL 分流、不能做 TLS 卸载、不能改请求头Nginx 和 HAProxy 工作在第七层能看到完整的 HTTP 语义可以做基于路径的路由、灰度、限流、鉴权但转发成本明显更高。实际生产里常见的是分层组合最外层用 LVS 把流量摊到几台 Nginx 上Nginx 再根据业务路径分发到各组后端。这样 LVS 承担的是抗量、抗并发、做入口高可用Nginx 承担的是业务路由。我见过一些团队直接省掉 LVS、只用 Nginx 做入口在流量规模不大的时候完全没问题但量级上去之后要么需要给 Nginx 换更高配的机器要么堆更多层反而不划算。维度LVSNginxHAProxy工作层次四层TCP/UDP七层为主也支持四层七层为主也支持四层转发路径内核态完成用户态代理用户态代理单机并发能力极高数十万级万级到数万级数万级按 URL/Host 路由不支持支持支持端口映射支持NAT 模式支持支持TLS 卸载不支持支持支持健康检查粒度较粗端口/连接级细可自定义细可自定义这张表不是要分高下而是帮你判断当前场景该把哪一层放在前面。如果需求里出现了按域名分流按路径灰度做 HTTPS 卸载那入口一定要有七层组件如果需求是一个端口扛住巨大流量、后端只是无差别的同构服务那四层在前面会更省资源。2. 三种工作模式的取舍逻辑与 NAT 的适用边界2.1 NAT 模式的完整数据包走向LVS 有三种经典的工作模式NAT、DR直接路由和 TUNIP 隧道。三种模式的差别全部体现在请求包怎么进去、响应包怎么出来这两件事上。NAT 模式是最容易理解、对网络环境要求最低的一种也是新手入门首选。完整走一遍客户端假设地址 10.0.0.5向 VIP假设 10.0.0.100:80发起 TCP 连接。请求包到达 DirectorDirector 根据调度算法挑一台 RS比如 192.168.10.11把目的 IP 从 10.0.0.100 改成 192.168.10.11目的端口保持 80然后从内网网卡发给 RS。RS 收到包源地址还是 10.0.0.5目的地址是自己于是正常处理并返回响应响应包的目的地址是 10.0.0.5源地址是 192.168.10.11。这个包要回到客户端就必须经过 RS 的默认网关而 RS 的网关被配置成了 Director 的内网地址 192.168.10.1于是响应包回到 Director。Director 收到后把源地址从 192.168.10.11 改回 10.0.0.100再发给客户端。这条链路的关键在于请求和响应都要穿过 Director所以 Director 必须同时能到达客户端所在网段和后端网段这是双网卡这个前提的由来同时 RS 的默认网关必须指向 Director否则响应包会走别的路径直接出去客户端收到一个源地址是内网地址的包TCP 三次握手就断了。这两条是 NAT 模式成立的硬性条件缺一不可后面部署环节所有的配置都是围绕这两条展开的。2.2 DR 与 TUN 到底差在哪一句话DR 模式的核心思路是只改 MAC不改 IP。请求包进来后Director 把目的 MAC 改成某台 RS 的 MAC 转发出去IP 头里的目的地址仍然是 VIP。RS 为了能接收这个包需要在自己的回环接口上额外配一个 VIP同时抑制它对外发送 ARP 响应否则整个网络里就会有多个设备声称自己拥有 VIP形成地址冲突相关的两个内核参数是arp_ignore和arp_announce。响应包由 RS 直接发给客户端不再经过 Director源地址天然就是 VIP客户端不会有任何察觉。因为响应不走 DirectorDR 模式能支撑的吞吐量远高于 NAT但要求 Director 和所有 RS 处在同一个二层网络里。TUN 模式在 IP 层做封装把原始请求包整个塞进一个新的 IP 包里发给 RSRS 拆封后处理响应直接回客户端。它和 DR 一样响应不经过 Director但可以跨网段部署代价是需要内核支持 IPIP 隧道且 RS 上同样要配 VIP 和抑制 ARP配置复杂度更高。对比项NATDRTUN请求路径经 Director 改目的地址经 Director 改目的 MAC经 Director 封装后转发响应路径必须经 Director直接回客户端直接回客户端Director 是否成为带宽瓶颈是否否网络位置要求无特殊要求可跨网段必须同一二层网络可跨网段RS 是否需要配 VIP否是是是否支持端口映射支持不支持不支持部署复杂度低中高2.3 NAT 模式的真实短板与它仍然值得部署的理由看到表格里Director 成为带宽瓶颈这一条不少人会直接放弃 NAT。但实际情况要分场景看。NAT 模式的瓶颈主要在两个地方一是进出流量都要过 Director网卡带宽被双向占用二是连接跟踪和地址改写本身消耗 CPU。对多数内部系统、中小型对外服务、以及镜像站、包仓库这类读多写少但单请求数据量不大的场景一台普通服务器的网卡完全撑得住用 NAT 换来的部署简单性远比那点带宽损失划算。更关键的一点是端口映射。NAT 模式允许 VIP 的端口和 RS 的端口不一样比如对外暴露 80后端实际监听 8080只要在添加规则时写清楚就行。DR 和 TUN 做不到这一点因为它们不改端口RS 必须监听和 VIP 完全一致的端口。对于容器化环境或者历史遗留系统端口不统一的情况这个能力非常实用也是我在不少迁移项目里优先选 NAT 的原因。还有一个容易被忽略的点NAT 模式下 RS 完全不用感知自己处在负载均衡后面不需要配 VIP、不需要动内核参数、不需要处理 ARP 抑制就当作一台监听端口的普通服务器用。这意味着你可以随时把它从 LVS 后面摘下来直连调试排查问题时少了一层干扰。对于刚开始搭建集群、还在反复试错的阶段这个特性省心程度很高。3. 部署前的拓扑设计与网络规划3.1 双网卡 Director 的地址规划先把拓扑在纸上画清楚比直接上手敲命令效率高得多。以虚拟机实验环境为例规划如下Director 两块网卡外网侧eth0配 10.0.0.100/24这就是 VIP同时也是客户端能访问到的地址内网侧eth1配 192.168.10.1/24两台 RS 分别配 192.168.10.11 和 192.168.10.12掩码 24网关全部指向 192.168.10.1客户端机器配 10.0.0.5/24网关指向 10.0.0.1实验环境里可以就是物理路由也可以让 Director 兼任。这里有一个细节容易被忽略Director 上不需要单独再配一个管理 IPVIP 直接绑在网卡上就行。有些资料会建议用ifconfig eth0:0或ip addr add加一个别名地址来承载 VIP这种做法在需要做 VIP 漂移配合 keepalived的场景下是必要的但单纯跑 NAT 模式时没必要多此一举直接让网卡主地址就是 VIP 更清爽。等到后面要引入高可用时再拆开也不迟。另外要确认路由表是正确的。在 Director 上执行ip route应该看到默认路由指向外网网关192.168.10.0/24 这条直连路由指向eth1。如果两条网卡的默认路由冲突比如eth1也被配了默认网关就会出现回包方向错误表现为能连上但很快断开这种诡异现象。部署前花两分钟检查路由能省掉后面半小时的排查。3.2 真实服务器的网关指向是硬约束RS 的网关必须指向 Director 内网地址这条前面强调过这里说清楚为什么以及怎么验证。TCP 连接是双向的客户端发出去的 SYN 到达 RS 后RS 回的 SYN-ACK 包源地址是 192.168.10.11。如果这个包走了别的出口客户端会收到一个源地址与自己请求的目的地址10.0.0.100不一致的包绝大多数操作系统都会直接丢弃连接建立失败。只有在 Director 上把源地址改写回 VIP客户端才会认。验证方法很直接在 RS 上执行ip route get 10.0.0.5输出里应该显示via 192.168.10.1。如果显示的是别的地址或者直接 unreachable说明网关配错了。另一种常见的配置事故是RS 上为了让内网通信正常手工加了一条明细路由走别的网关结果这条路由的优先级高于默认路由导致回包跑偏。遇到部分客户端能连、部分不能这种不规律现象时一定要在 RS 上把路由表完整看一遍而不是只盯着 LVS 配置。还有一点值得提醒如果实验环境里 Director 和 RS 都在同一台宿主机上的虚拟机里注意虚拟网络编辑器的网关设置是否和你在系统内配的网关冲突这类环境问题会伪装成 LVS 配置错误排查时容易被带偏。3.3 转发开关与必要内核参数的最小集合Director 本质上是在做路由转发所以必须打开 IP 转发。这是最容易漏的一步漏了之后的症状是ipvsadm -Ln显示规则一切正常连接表里也有条目但客户端就是连不上后端也收不到包。开启方法有两种临时生效用sysctl -w net.ipv4.ip_forward1持久化写进/etc/sysctl.d/下的配置文件里然后sysctl -p加载。除了转发开关还有几个参数和 NAT 模式的稳定性相关。net.ipv4.vs.conntrack控制是否让 ip_vs 的连接跟踪与 netfilter 的 conntrack 联动这个参数在有些内核版本上默认是 0如果同时用了 iptables 做端口过滤可能需要打开它才能正常工作但打开之后性能开销会上升纯粹做 LVS 转发时没必要开。net.ipv4.vs.conn_reuse_mode涉及端口复用行为在某些高并发短连接场景下会影响新建连接的成功率遇到大量 TIME_WAIT 或连接被拒时值得关注一下。还有一组参数是net.ipv4.conf.all.rp_filter和对应网卡的rp_filter。这是反向路径过滤用来防源地址欺骗但在双网卡的不对称路由场景下可能把合法的回包丢掉。如果部署后发现偶发丢包、抓包能看到包进来了但系统不处理可以尝试把相关网卡的rp_filter设为 0 或 2 验证一下。注意这是排查手段不是无脑关掉就好确认原因之后再决定长期配置。4. ipvsadm 命令逐条拆解与配置落地4.1 建立虚拟服务规则安装ipvsadm之后第一条命令是创建虚拟服务。格式如下ipvsadm -A -t 10.0.0.100:80 -s wlc这条命令的意思是新增-A一个 TCP 服务-t如果是 UDP 就用-u监听 10.0.0.100 的 80 端口调度算法用加权最少连接-s wlc。执行完之后用ipvsadm -Ln应该能看到这条规则只是下面还没有 RS状态是空的。这里要解释一个新手常见的困惑-t后面跟的地址必须是本机上的地址。如果写了一个不属于本机任何网卡的 IPipvsadm可能会报错或者规则建了但不生效。因为在 NAT 模式下Director 需要在自己的地址上接住这个请求才能进一步转发。所以 VIP 一定得真实绑定在网卡上这一点和 DR 模式不一样DR 模式下 VIP 也可以在别处。调度算法这里选wlc是默认值适合后端机器性能不均的情况。如果后端配置完全一致、请求处理时间也比较均匀rr轮询其实更简单直观如果请求处理时间差异极大比如有的请求几十毫秒、有的要几秒wlc的表现会更好因为它会优先把新连接分配给当前活跃连接数少的机器。4.2 调度算法的选择依据调度算法不是随便挑一个就行的选错了会出现某台机器压力明显偏高或者长连接把一台打满的情况。常用的几种可以对照下面这张表理解。算法简写适用场景不适用场景轮询rr后端配置一致、请求耗时均匀后端性能差异大加权轮询wrr后端配置有差异可按比例分配请求耗时差异极大最少连接lc请求处理时间差异较大后端性能不一致加权最少连接wlc综合以上默认首选无源地址哈希sh需要同一客户端固定落到同一后端客户端 IP 分布不均或经过 NAT目标地址哈希dh缓存类场景同一资源命中同一后端请求无资源维度特征sh这个算法需要单独提醒一句。它按源 IP 做哈希计算能保证同一个客户端始终落到同一台 RS适合有会话状态但又不方便做集中式会话存储的场景。但它的前提是客户端的源 IP 能被正确识别。如果客户端和 LVS 之间还有一层 NAT 设备那么所有客户端在 LVS 看来都是同一个源 IP哈希结果全部一样流量会全部压到一台机器上。这种事故我见过不止一次现场表现就是另外几台后端 CPU 一直是 0排查方向很容易跑偏到算法模块没加载上去。4.3 挂载后端节点与权重设置规则建好之后把后端挂上去ipvsadm -a -t 10.0.0.100:80 -r 192.168.10.11:80 -m -w 3 ipvsadm -a -t 10.0.0.100:80 -r 192.168.10.12:80 -m -w 1-a表示新增后端-r指定后端地址和端口-m表示使用 NATmasquerading模式-w是权重。这两条命令把 11 这台机器的权重设成 3、12 设成 1在wlc或wrr算法下大致就是 3:1 的流量分配比例。-m这个参数是整个 NAT 模式的核心开关如果写成了-gDR 模式或者-iTUN 模式那么前面所有的网络规划都要跟着变。初次部署时最容易犯的错误就是照着某个教程抄了-g然后配的是 NAT 的拓扑结果就是规则显示正常但流量完全不通。检查方法很简单ipvsadm -Ln输出里每台 RS 后面会带一个字母标识NAT 模式会显示Masq看到这个字样就说明模式对了。权重的含义要说清楚它不是流量百分比而是一个相对值。权重 3 和 1 在加权轮询里就是每 4 个新连接里 3 个给前者。调整权重用ipvsadm -e命令修改即可不需要先删除再加回来改动是立即生效的正在进行的连接不受影响。这个特性在做灰度发布或者临时摘掉某台机器时非常有用——把权重设为 0 就等于不再分配新连接但已有连接还能自然结束比直接删除后端温和得多。4.4 持久连接与配置保存持久连接用-p参数开启单位是秒ipvsadm -A -t 10.0.0.100:80 -s wlc -p 300开启之后同一个客户端在 300 秒内的请求会被强制分配到同一台 RS。这个功能在需要会话保持、又不想用源地址哈希的时候很有价值。不过它有个副作用需要知道持久连接会压缩调度算法的效果如果某个客户端的请求量特别大它会在 300 秒内把压力集中在一台机器上。所以超时时间不宜设得太长按业务实际会话时长来定比较合理。配置保存是另一件必须做的事。ipvsadm的规则存在内核里重启就没了。不同发行版的持久化方式不一样一类是通过ipvsadm-save把规则导出到文件再配合ipvsadm-restore或者对应的 systemd 服务开机加载另一类是把命令直接写进开机脚本或 systemd unit 里。我倾向的做法是写一个简单的启动脚本把ip_forward的开启和ipvsadm的规则添加都放在里面这样配置的完整逻辑一目了然换机器时直接复制脚本就行比分散在好几个配置文件里更好维护。#!/bin/bash sysctl -w net.ipv4.ip_forward1 ipvsadm -C ipvsadm -A -t 10.0.0.100:80 -s wlc -p 300 ipvsadm -a -t 10.0.0.100:80 -r 192.168.10.11:80 -m -w 3 ipvsadm -a -t 10.0.0.100:80 -r 192.168.10.12:80 -m -w 1脚本开头的ipvsadm -C是清空所有规则保证每次执行的结果是幂等的不会因为重复执行而叠加出错误的规则。这一点在调试阶段尤其重要改配置之前先清空再加能避免很多规则看起来对不对不上的困惑。5. 怎么确认链路真的通了从连接表到抓包5.1 ipvsadm -Lcn 的连接表怎么读ipvsadm -Ln看的是规则ipvsadm -Lcn看的是实时连接这是两个完全不同的视图。排查问题时后者往往更有用因为它能告诉你请求到底有没有进来、被分配到了哪台后端、当前处于什么状态。输出大致是这样几列Pro协议、Expire剩余超时、State状态、Source客户端地址、VirtualVIP 和端口、Destination选中的后端。状态列里ESTABLISHED表示连接已建立且还在活跃SYN_RECV表示只收到了请求方向的 SYN、还没看到后端响应TIME_WAIT是正常关闭后的残留。这个状态信息非常关键。如果客户端报连接超时而连接表里看到大量卡在SYN_RECV的条目基本可以断定是请求能到后端但响应回不来——大概率就是 RS 的网关配错了或者后端服务压根没在监听。如果连接表里根本没有条目说明请求根本没到 Director问题在更前面可能是 VIP 没绑好、防火墙拦了、或者客户端路由不对。这两种情况排查方向完全不同先看一眼连接表能省下大量时间。5.2 抓包确认地址改写的落点配置文件看不出来的问题抓包基本都能看出来。在 Director 的内网网卡上抓tcpdump -i eth1 -nn host 192.168.10.11 and port 80正常情况应该看到源地址是客户端、目的地址是 192.168.10.11 的包说明 DNAT 生效了。同时可以在外网网卡上抓tcpdump -i eth0 -nn host 10.0.0.5 and port 80这里应该看到目的地址是 10.0.0.100 的请求包以及源地址是 10.0.0.100 的响应包。如果响应包的源地址显示的是 192.168.10.11 而不是 VIP说明 SNAT 没生效客户端那边一定会丢弃。这个对比是最直接的验证方式比翻日志快得多。在 RS 上抓包同样有价值。正常应该看到目的地址是自己的包源地址是客户端地址而不是 Director 的地址因为 NAT 模式只改了目的地址请求方向的源地址保持不变。如果看到的源地址是 192.168.10.1说明配置的可能是别的模式或者有额外的 SNAT 规则干扰值得回头核对一下。5.3 用压测验证权重是否真的生效规则配完、单次访问通了还不算完。至少要验证两件事权重分配是否符合预期以及后端有一台挂掉时的表现。用ab或wrk这类工具跑一轮并发请求然后看两台 RS 的访问日志条数比例权重 3:1 的情况下应该接近这个比例。如果比例明显不对先确认调度算法是不是wlc有时候会误用lc它不识别权重再看是不是开了持久连接把分配固定住了。后端故障的表现更值得关注。直接在某台 RS 上停掉服务然后继续压测观察请求是否会持续失败。默认情况下 LVS 不做主动健康检查它只根据连接建立的成功与否来更新后端状态所以在服务刚停的头几秒仍然可能有请求被分配过去然后失败。如果业务对这块敏感要么在 LVS 前面配合 keepalived 做健康检查要么接受短暂失败由客户端重试兜底。这一点必须提前和业务方对齐预期不然线上出现偶发 502 会很难解释。6. NAT 模式部署里最容易翻车的几个地方6.1 RS 网关漏配导致的半通现象前面反复提过网关这件事这里完整还原一次排查链路因为这个坑太典型了。现象是用浏览器访问 VIP页面一直转圈最后超时ping VIP是通的在 Director 上curl后端的内网地址也是通的看起来一切正常。第一步在 Director 上执行ipvsadm -Lcn发现有大量SYN_RECV状态的条目说明请求已经进来了、也分配出去了但没等到后端的响应。第二步在 RS 上抓包能看到请求包正常到达也能看到 RS 发出的响应包但响应包的目的地址是客户端且从内网网卡直接发出去没有经过 Director。第三步在 RS 上执行ip route get 客户端IP果然显示via 192.168.1.254也就是配了一个错误的网关。根因就是 RS 的默认网关没指向 Director。修复很简单改网关重启网络即可。但这里有个经验改完之后如果还是不通检查一下 ARP 缓存或者让 Director 那边的连接表自然超时后再试因为旧的连接条目还在可能继续命中错误的转发路径。执行ipvsadm -C清一次再试能排除这种残留干扰。6.2 端口不通和连接被拒的几种可能同一类表象背后可能是完全不同的原因需要按链路顺序排除。客户端报 Connection refused说明包到了某处并收到了 RST。可能性包括VIP 没绑在网卡上ip addr确认、LVS 规则没建或者被清空了ipvsadm -Ln确认、后端端口没监听在 RS 上ss -lntp确认、以及后端所在机器的防火墙拦了请求。如果报 Connection timed out那就是包丢了方向性更强要么请求没到 Director要么请求到了但响应回不来。前者查客户端的路由和中间的网络策略后者查 RS 的网关、Director 的转发开关和rp_filter设置。还有一种比较隐蔽的情况是时通时不通。这通常和rp_filter、多网卡路由选择、或者后端机器的负载过高有关。排查时可以连续发几百个请求统计失败率然后在失败的那一刻同步抓包定位是丢在哪个环节。这种方式比反复改配置盲猜有效得多。6.3 带宽瓶颈的位置判断与规避思路NAT 模式下所有流量双向经过 Director所以当业务流量涨起来之后最先出问题的往往不是 CPU 而是网卡带宽。判断方法是在 Director 上持续观察网卡流量如果接近链路带宽上限那再优化调度算法也没意义了得换方案。规避思路有几种。一种是把 NAT 换成 DR 模式让响应绕开 Director这要求网络拓扑支持同二层。另一种是在 NAT 前面再加一层用多台 Director 分担不同业务端口本质上是把瓶颈拆散。还有一种更彻底的做法是在架构设计阶段就区分开——把大文件下载、视频流这类带宽消耗型流量从 LVS 后端池里剥离出去走独立的出口让 LVS 专注处理小而多的 API 请求。这个思路在实际项目里效果最好因为 NAT 对短小请求的处理效率确实很高而大流量场景本来就不太适合让它扛。6.4 arp_ignore 和 arp_announce 什么时候才需要动这两个参数在 DR 模式的教程里几乎是必配项导致很多人学 NAT 的时候也顺手抄了过来。实际上 NAT 模式完全不需要动这两个参数因为 RS 上没有绑定 VIP不存在 VIP 地址冲突的问题。乱改这两个参数反而可能影响正常的网络行为尤其是arp_announce设成 2 的时候会限制本机对外通告的地址范围在有多个网卡或额外地址的机器上可能引发意外。判断标准很简单如果你在 RS 的回环接口或者别的网卡上配了和 VIP 相同的地址那就必须处理 ARP 抑制如果没配就不用管。我在实际部署中养成的习惯是配置之前先问一句这个参数是为哪个模式服务的把参数和模式的对应关系理清楚比盲目照抄教程稳得多。最后分享一个我个人觉得挺有用的小技巧整套配置在虚拟机里跑通之后不要急着把命令一条条记到文档里而是把整个流程写成一个可以重复执行的脚本脚本里包含清空规则、设置转发、建规则、挂后端、打印结果这几步。每次换环境或者调整参数重新跑一遍脚本就行出错概率会低很多。同时脚本本身就是一份不会过时的配置文档比写一堆说明文字实用。另外一个体会是关于学习路径的。LVS 这个东西命令不多难点全在“包是怎么走的”这个认知上。我建议的做法是先在单机或者两台虚拟机里把 NAT 模式跑通然后用抓包工具在三个位置客户端侧、Director 内外网卡、RS各抓一次把同一个连接的完整旅程看一遍。这个过程走下来之后DR 模式和 TUN 模式基本上一看就懂因为它们只是在这条路径上改了一两个环节而已。跳过这一步直接上 DR往往会被 ARP 抑制和 VIP 配置搞得一头雾水反而更慢。
