1. 为什么还在用LVS先搞清楚它到底解决什么问题做后端服务的人对负载均衡这个词肯定不陌生。一提到负载均衡脑子里马上会跳出Nginx、HAProxy、云厂商的SLB以及有时候会听到的LVS。LVS的全称是Linux Virtual Server中文常叫Linux虚拟服务器它在Linux内核里以ip_vs模块的形式运行由章文嵩博士在九十年代末发起是国内开源圈里分量极重的一个项目。先说清楚定位LVS工作在网络四层传输层直接处理TCP和UDP报文转发能力远超用户态的Nginx和HAProxy。生产环境里一种非常典型的组合是LVS做入口流量分发Nginx做七层反向代理后端挂一批应用服务。LVS把海量连接快速铺到后面的机器上Nginx负责按URL、Header这些应用层信息做更精细的路由。那LVS到底适合谁来用又能解决什么问题我用一句话概括如果你的业务量已经到单台Nginx扛不住或者你希望流量入口的转发性能尽可能高、额外开销尽可能小LVS几乎是绕不开的选项。它不像HAProxy那样功能丰富也不像Nginx那样有灵活的配置语法它更像一扇坚固的闸门把流量按规则快速送走不做太多花哨的事情。这篇文章不是把LVS的man手册抄一遍而是按照实际部署一个LVS负载均衡集群的流程来讲从模式选型、调度算法、安装配置到线上问题排查把我踩过的坑和觉得好用的经验都放进来。无论是刚接触LVS想做技术选型的同学还是已经上了LVS但遇到性能或RS异常问题的运维朋友这篇文章应该都能给你一些参考。我会用一个典型的DR模式案例贯穿全文因为它最常用也最容易出问题。在开始之前先给一个整体框架后面的内容基本按这个顺序展开。第一部分讲LVS的整体架构和三种工作模式的取舍第二部分讲调度算法怎么选以及连接保持这些细节第三部分给出一个完整可落地的配置案例并逐行解释第四部分把线上最容易遇到的高可用和性能问题一起说清楚。这样从原理到实操到排障一条线走下来你回头在公司搭一套LVS时能少走不少弯路。2. LVS的架构和三种工作模式DR模式为什么是首选2.1 LVS由哪几部分组成LVS从结构上看是一个标准的集群方案它由三个角色组成负载调度器就是运行LVS的机器我们叫它Director后端真正处理请求的服务器叫RealServer简称RS还有一个共享存储层负责让后端服务器看到一致的数据实践中可以挂NFS、分布式存储或者干脆让RS无状态化这一层根据业务形态弹性处理。关键点在于LVS的转发决策不是靠某个用户态进程逐包处理的而是Linux内核里的ip_vs模块直接完成的。用户通过ipvsadm这个命令行工具把虚拟服务、转发规则、调度算法这些配置下发给内核内核里的IPVS框架在数据包到达时按规则做匹配和转发。换句话说即使你把用户态的管理程序停掉已经下发到内核的规则依然会继续转发数据包。意识到这个特性的意义在于排查问题时不要一看到ipvsadm进程不存在就以为LVS挂了真正需要的判断依据是内核里的规则还在不在以及网卡上有没有流量进来这两点才是LVS工作的核心。LVS之所以能做到极高的转发性能核心原因是它绕过了用户态和内核态之间频繁的上下文切换数据包从网卡驱动进入内核协议栈后在IP层就完成了匹配和转发动作连socket层都不会碰。对比Nginx和HAProxy它们作为用户态进程每个数据包要经过内核收包、拷贝到用户态、处理完再发回内核的过程开销完全不在一个量级。2.2 三种工作模式DR、NAT、TunnelLVS支持三种工作模式虽然文档上都会写到但真正在选型时很多人会被绕晕。我先把三种模式的核心差异用表格列出来然后逐一讲清楚。模式是否修改报文响应路径依赖协议对RS要求适用场景DRDirect Routing只改MAC直接回客户端不经过Director无特殊要求RS必须配置VIP并抑制ARP响应绝大多数业务性能最高NATNetwork Address Translation改IP和端口必须回Director再转发需依赖iptables/路由规则RS无需配置VIP网关指向DirectorRS与Director跨网段、端口映射场景TunnelIP-IP封装封装原始报文直接回客户端内核支持IPIP隧道RS需启用tunl0并配置VIP跨机房、跨地域的大规模集群DR模式是最常见的选择原理上Director只修改数据帧的目标MAC地址把请求帧直接转发给选中的RSRS处理完以后直接把响应报文还给客户端。因为请求和响应走了不同的路径响应流量完全不经过DirectorDirector的负载被降到最低。这也是为什么DR模式能够支撑非常大的吞吐量本质上Director只像一个交通警察指了一下方向剩下的车辆自己走。NAT模式正好相反Director会改写数据包的目标IP和端口后端RS处理完后响应报文还必须回到Director再由Director改写源IP后发回客户端。这样一来所有响应流量都会压到Director上Director很容易成为瓶颈。所以NAT模式适合规模不大、或者Director和RS跨了VLAN必须做地址转换的场合毕竟DR模式要求Director和RS在同一个二层网络。Tunnel模式是把原始IP报文用IPIP隧道再封装一层后端RS收到后解封装看到原始目的IP是VIP然后自己直接回复客户端。它解决了DR模式只能在二层局域网内用的痛点适合跨机房部署的场景。但隧道封装本身会带来额外的CPU开销RS侧也要做额外配置除非有跨地域需求否则日常业务用不上。2.3 DR模式下最重要的两个细节DR模式虽然性能最好但有一个必须处理的副作用因为目标IP地址是VIPRS收到请求后发现目标IP不是自己网卡上的地址默认会认为这个包不是发给自己从而丢弃。解决办法是给RS的loopback接口配置VIP并且必须关闭对VIP的ARP响应。这里要理解ARP协议为什么是DR模式能不能跑通的关键。当客户端请求VIP时会先通过ARP得到VIP对应的MAC地址。如果不做任何抑制处理Director和所有RS都会响应这个ARP请求客户端可能就把请求发到了某个RS上流量就不经过Director负载均衡直接失效。所以RS的loopback上配了VIP之后必须让RS对这个VIP的ARP请求保持沉默只由Director用自己的MAC地址应答VIP的ARP。具体到Linux内核参数就是要在RS上设置arp_ignore和arp_announce这两个参数。通常建议在sysctl.conf里加上这些配置并让它们永久生效net.ipv4.conf.lo.arp_ignore 1 net.ipv4.conf.lo.arp_announce 2 net.ipv4.conf.all.arp_ignore 1 net.ipv4.conf.all.arp_announce 2arp_ignore设置为1表示只回答目标IP地址是本机网卡真实IP的ARP请求不回答VIP的ARP请求。arp_announce设置为2表示发送ARP通告时不使用VIP作为源IP尽可能使用网卡上的真实IP。这两条配置缺一不可很多初次部署DR模式的人忘记配置导致RS在ARP层面和Director抢VIP的MAC地址流量直接打到某台RS上症状时好时坏是典型的隐蔽问题。另外还要注意一个细节在配置RS的loopback时不要设置netmask为32如果掩码设置过大RS可能会因为这个VIP形成一个直连路由而主动通告路由信息在复杂的网络环境里引起不必要的麻烦。我习惯在RS上用ifconfig lo:0 10.0.0.10 netmask 255.255.255.255 up的方式配置只绑定VIP这一条主机路由不产生额外的路由扩散。3. 调度算法与连接保持选错算法流量会跪3.1 静态调度算法LVS支持十种左右的调度算法大致可以分为静态和动态两类。静态算法不关注后端RS当前的负载情况只按固定规则选择RS。常用的静态算法有三个轮询rr、加权轮询wrr、目的地址哈希dh、源地址哈希sh。轮询rr是最基础的请求按顺序挨个分给每一台RS适合后端机器配置相近、请求处理耗时基本一致的场景。加权轮询wrr在rr的基础上给不同RS配置权重权重高的RS会分到更多请求适合后端机器性能不均衡的情况比如新老服务器混布的时候。源地址哈希sh的做法是针对同一个源IP的请求始终调度到同一台RS。这个算法比较适合需要会话保持的场景比如某些老业务系统没有做分布式session用户登录状态存在本机内存里一旦切换到另一台RS就掉线了用sh可以保证同一用户的请求总落在同一台机器上。但它的缺点是如果某台RS挂了哈希到它上面的用户会集中受影响体验会有明显波动。目的地址哈希dh和sh类似但针对的是目标地址通常用在多级缓存或代理场景里。3.2 动态调度算法动态算法会根据RS当前的连接数、负载情况做实时判断用起来更聪明但也要理解它的依据是什么。最少连接lc算法会把新请求分给当前活动连接数最少的RS适合请求处理时间波动大的场景。加权最少连接wlc是它的加权版本LVS默认算法就是wlc兼顾了后端差异和当前负载。还有几个带约束的变种算法比如sed基于最小期望延迟nq从不排队以及带有局部性的lblc和lblcr。lblc的优化思路是一个IP的请求尽量让同一台RS处理但如果那台RS当前不是最少连接的就可能切换lblcr则通过缓存记录目标地址与RS的映射关系更适合Cache集群。在实践里要特别注意wlc和lc这类动态算法依赖RS上的连接数数据。如果RS上有非常多的长连接比如数据库连接池这类应用连接数本身就很高LC类算法反而会把新请求压到本来就繁忙的机器上因为连接数最多不代表CPU忙。这种情况下我建议直接评估业务的连接特征短请求多就选wlc长连接多且希望会话保持就优先sh。算法的选择要尊重业务形态不能一味相信默认值就是最优解。3.3 连接超时与保持的细节问题LVS内核里维护了一张连接跟踪表记录每个TCP/UDP会话的状态。当一个连接空闲超过一定时间LVS会把它从表中清除后续如果同一个四元组的报文再次出现LVS就会把它当作一个新连接重新触发调度。这个特性在高并发场景下非常关键。假如你的业务是WebSocket长连接客户端可能十几分钟不发数据如果LVS连接超时设置得太短连接被内核清掉服务端的连接其实还在客户端一旦再发消息LVS会把它当成新连接重新调度结果可能调度到另一台RS造成服务端会话信息错乱。所以根据业务调整超时参数是必须做的。常用的时间参数包括TCP空闲超时tcptimeout、TCP FIN等待超时tcpfin timeout以及UDP超时udptimeout。就我个人的经验线上如果跑的是WebSocket或IM类长连接TCP超时至少要配置到900秒以上有的业务甚至直接配成3600秒。调整方法是在ipvsadm里设置超时值ipvsadm --set 900 120 300这条命令把TCP空闲超时设为900秒TCP FIN等待设为120秒UDP超时设为300秒。你可以在部署完LVS之后用ipvsadm -L --timeout查看当前生效的超时配置。还有一个经常被忽略的点LVS的调度器和RS之间的Keepalive也就是常说的tcp_keepalive_time也会影响长连接的稳定性。如果RS上的应用程序自己不维护心跳内核默认的keepalive探测间隔是7200秒这通常太长了可能出现客户端已经断网但服务端还傻等的情况。建议在RS上缩短tcp_keepalive_time、tcp_keepalive_intvl和tcp_keepalive_probes把探测周期调到十分钟左右让异常连接能更快被清理掉。4. 动手配置一套DR模式LVS从ipvsadm到Keepalived4.1 安装与基本命令在这个案例里我们假设有三台机器一台DirectorIP是192.168.1.10承担负载均衡两台RSIP分别是192.168.1.20和192.168.1.30。VIP统一规划为192.168.1.100业务端口是80端口后端跑Nginx。Director和两台RS都在同一网段用的是DR模式。在Director上安装ipvsadm不同发行版命令有差异CentOS和Ubuntu都试过最省事的还是走系统包管理器# CentOS / RHEL yum install -y ipvsadm keepalived # Ubuntu / Debian apt install -y ipvsadm keepalived装完之后先确认内核是否已经加载了ip_vs模块modprobe ip_vs lsmod | grep ip_vs如果没有任何输出说明模块可能没加载你可以手动加载一下。现代内核几乎都编译了IPVS相关模块只是有的发行版默认不自动加载。加载之后就可以开始配置虚拟服务了先把VIP绑定到Director的物理网卡上ifconfig ens192:0 192.168.1.100 netmask 255.255.255.255 up然后用ipvsadm配置虚拟服务和后端RS。基础的命令是这样的ipvsadm -A -t 192.168.1.100:80 -s wlc ipvsadm -a -t 192.168.1.100:80 -r 192.168.1.20:80 -g -w 1 ipvsadm -a -t 192.168.1.100:80 -r 192.168.1.30:80 -g -w 1第一行添加一个TCP虚拟服务VIP是192.168.1.100端口80调度算法用wlc。第二行和第三行分别加入两台RS-g参数表示DR模式-w是权重两台机器配置相同的情况下权重都设为1。如果要用NAT模式就把-g换成-mTunnel模式换成-i但这里我们主推DR模式所以全部走-g。配置完成之后用ipvsadm -L -n查看规则列表确认Virtual Service和RS都正常。如果以后想调整RS权重用-E和-e参数修改不用删掉重新加。4.2 通过Keepalived实现VIP漂移和健康检查直接敲ipvsadm命令的方式适合临时测试生产环境必须配合守护进程自动管理规则和VIP。Keepalived是LVS最经典的搭档它同时干两件事用VRRP协议在多个Director之间做主备切换以及周期性探测后端RS的健康状态一旦发现RS异常自动把它从内核转发链路上摘掉。先看Keepalived的配置文件一般位于/etc/keepalived/keepalived.conf。下面是一个DR模式主节点的配置我逐段解释global_defs { router_id LVS_DEVEL } vrrp_instance VI_1 { state MASTER interface ens192 virtual_router_id 51 priority 100 advert_int 1 authentication { auth_type PASS auth_pass 1111 } virtual_ipaddress { 192.168.1.100/32 dev ens192 } } virtual_server 192.168.1.100 80 { delay_loop 6 lb_algo wlc lb_kind DR protocol TCP real_server 192.168.1.20 80 { weight 1 TCP_CHECK { connect_timeout 3 nb_get_retry 3 delay_before_retry 3 connect_port 80 } } real_server 192.168.1.30 80 { weight 1 TCP_CHECK { connect_timeout 3 nb_get_retry 3 delay_before_retry 3 connect_port 80 } } }vrrp_instance这块是Director之间的高可用配置。state MASTER表示这台机器是主节点备节点要写成BACKUP。priority是竞选优先级主节点必须大于备节点。virtual_ipaddress里填的就是VIPKeepalived启动后会自动把VIP绑定到ens192这块网卡上主节点故障时备节点会自动抢占实现VIP漂移。virtual_server这一段定义了LVS的完整转发规则。delay_loop是健康检查的周期单位秒一般设5到10秒。TCP_CHECK表示通过TCP端口探测来检查RS健康这里探测80端口。如果后端服务连续多次连接失败Keepalived会从ipvs规则里临时摘掉这台RS恢复健康后再自动加回来。这个机制可以做到后端一台机器宕机时流量自动转移到其他RS上。备节点的配置和主节点几乎一样只是state改成BACKUPpriority调低比如改成90。router_id和virtual_router_id必须保持一致否则VRRP协议无法正常协商。配置好之后重启keepalived服务然后分别查看VIP是否绑在了正确的网卡上用ipvsadm -L -n确认规则是否自动生成。4.3 Keepalived主备切换的验证配置做完不能只看服务起来就完事必须做一次主备切换演练。我在第一次部署时吃过亏当时只验证了Keepalived进程活着没有真正测试VIP漂移结果某天主节点硬件故障整个入口完全不可用流量全断了。演练方法很简单在主节点上执行systemctl stop keepalived然后立即去备节点查看VIP是否出现。正常情况下几秒钟之内VIP就会漂移到备节点用ip addr命令能看到VIP出现在备机网卡上。同时用ipvsadm -L -n确认转发规则也完整同步到备节点了。再把主节点恢复注意停掉VIP的优先权会回到主节点这是正常的抢占行为。如果你的环境不希望发生抢占可以在vrrp_instance里加nopreempt参数。另外还要测试后端RS故障时的摘除逻辑。在某一台RS上停掉Nginx然后观察Director上的ipvs规则几分钟后那台RS会被自动移除。恢复Nginx后规则里又会重新出现这台RS的条目。这个测试能确认Keepalived的健康检查和内核规则的动态管理都正常工作否则回源流量可能打到已宕机的机器上直接影响业务可用性。4.4 其他值得修改的内核参数LVS所在的主机在正式承接流量前还需要调整一批内核参数。首先是启用IP转发Director作为三层转发节点需要开启这个能力。其次是关闭rp_filter反向路径过滤否则LVS在收到目标MAC是自己、但源和目标IP某种情况下不符合反向路径校验规则的报文时可能会直接丢弃导致转发异常。下面这组参数是我上线前必改的net.ipv4.ip_forward 1 net.ipv4.conf.all.rp_filter 0 net.ipv4.conf.ens192.rp_filter 0 net.ipv4.conf.default.rp_filter 0这里想多说一句不要盲目抄网上的配置需要理解每一个参数在做什么。rp_filter的这个设置在大多数单网卡直连的部署场景下是必要的但在接入层交换机上做了严格对称路由限制的环境里关闭它反而可能带来风险。建议改完参数后做一轮完整的功能回归测试确认业务请求可以通过VIP正常访问。还有一个和性能紧密相关的参数是网卡的队列长度和RSS队列。LVS在流量特别大的时候由于所有数据包都得由CPU来处理你可能会观察到某个CPU核的软中断特别高其他核却很闲也就是常说的软中断不均衡。可以通过设置网卡的RSS队列数结合smp_affinity把不同的队列中断绑定到不同CPU核上把处理压力分散开。这在高并发场景下能让LVS的转发性能上升一个台阶我后面会专门说。5. 线上常见问题与性能排查用数据说话5.1 症状排查VIP通但业务偶发失败这是DR模式环境下最高频的故障具体表现是VIP可以ping通但请求时而成功时而失败或者特定客户端访问总是不对。绝大多数情况都和ARP问题有关。排查顺序建议这样来先在Director上执行ipvsadm -L -n --stats看当前连接统计数据是否正常每秒转发包量是否合理。如果Director上连接数一直在涨但某些RS上却接不到新连接说明调度器没有按照预期把连接均匀分发。接下来就去RS上检查route -n和ip addr重点看loopback上的VIP是否还在、ARP抑制参数是否被意外重置。有些系统在重启后会把sysctl.conf的配置重置所以规则里应该同时写进/etc/rc.local或者使用systemd服务来确保开机自动配置。如果检查完这些发现都没有问题那就看看ARP表arp -n。正常情况下VIP的MAC地址应该对应Director的网卡MAC。如果发现VIP对应的MAC变成了某台RS的MAC就说明那台RS的ARP抑制没生效它用VIP响应了ARP请求。这个情况处理起来也直接回到那台RS重新配置arp_ignore和arp_announce然后清理ARP缓存arp -d 192.168.1.100让客户端重新发ARP解析。还有一个可能被忽略的原因交换机本身开启了端口安全、动态ARP检测之类功能会记住VIP的MAC和端口绑定关系切换时不会立刻更新导致流量的二层转发目的地还是旧端口。如果遇到这个情况需要在交换机上配置VIP的静态ARP条目或者关闭对应端口的ARP检测策略让二层转发表跟随VRRP状态变化。5.2 长连接场景下的连接不释放与soft connect问题结合近期热词lvs soft connect来看很多人反馈LVS在某些场景下出现连接建立异常缓慢或者连接不释放。这个问题的本质要从LVS和客户端之间的连接状态说起。LVS作为四层负载均衡负责维护客户端到VIP之间的连接状态它需要判断一条连接什么时候结束。对于TCP协议来说正常情况下通过FIN握手就能感知但遇到异常断网、客户端断电这类非正常断开LVS上的连接状态会一直留在ESTABLISHED直到超时被清理。连接长时间不释放加上新连接持续进来内核里的连接跟踪表就会越撑越大最终可能把整个会话表填满新来的SYN包没有空间记录连接状态表现就是客户端连接不上或者连接建立要卡好几秒。这时候你去Director上运行dmesg会看到nf_conntrack相关的报错磁盘和CPU可能同时飙升。解决思路有三个方向。一是合理设置连接超时时间把空闲超时缩短尽快清理无效连接。二是调大nf_conntrack的最大限制给连接表扩容命令是sysctl -w net.netfilter.nf_conntrack_max2000000。三是当业务形态允许时直接减少连接跟踪的压力比如把LVS的转发模式从NAT调整为DR因为DR模式下并发连接记录不占满整个连接跟踪表。soft connect这个词还有一个可能的含义在连接数特别高的场景负载均衡节点本身CPU软中断处理不过来新连接无法按预期建立表现就像连接变软了一样很慢很粘。这个问题在LVS上比在Nginx上更突出因为LVS是纯内核态处理一旦某个CPU核的软中断占满整个机器的收包能力就会卡住。优化方式是调整网卡多队列和中断绑定让每个队列均匀落在不同的CPU上。通过mpstat -I CPU查看软中断分布可以直观发现哪些核过载。然后把网卡队列的IRQ绑定到空闲核上性能可以得到明显改善。5.3 回源流量异常RS直接响应但客户端收不到还有一种比较隐蔽的问题RS已经直接回了响应报文但客户端就是收不到。DR模式下RS回包的目标地址是客户端的IP源地址是VIP所以它直接发出即可无需经过Director。但如果在RS上配置了额外的防火墙规则、或者RS有多个网卡导致回包走了错误的网关就会造成响应报文丢失。排查这个问题在RS上用tcpdump抓包最直接。先抓回包方向确认RS确实发出了响应报文。如果确认发出但客户端收不到再看RS的路由表回包的路由是否指向默认网关源IP是否确实是VIP。这里有个细节需要注意如果RS的默认路由走了和客户端不同的出接口回包可能被交换机或路由器丢弃。解决办法是在RS上为VIP添加一条明确的主机路由确保VIP的响应报文从正确的接口发出去ip route add 192.168.1.0/24 dev eth0 src 192.168.1.20类似的路由问题常常在RS同时跑着多块网卡、或者服务器上了VLAN的复杂网络里遇到。我见过一个真实案例RS本身有管理网卡和业务网卡默认路由指向管理网络结果请求从业务网卡进来回包却从管理网卡出去防火墙直接丢弃了不对称流量。排查这类问题时打开RP_FILTER日志也很有帮助可以看到具体是哪个包被判定为非法而丢弃。5.4 性能指标参考和监控配置运维LVS时哪些指标需要长期盯着我归纳成四个层级。第一个是网络层指标包括Director的入口吞吐、出口吞吐、每秒包数这是判断转发压力的第一道信号。第二个是连接层指标通过ipvsadm -L -n --stats查看当前活动连接数、累计连接数、每秒转发连接数这些数据能告诉你调度器本身是否繁忙。第三个是系统层指标包括CPU软中断占比、内存占用、连接跟踪表使用量重点怀疑表和软中断瓶颈。第四个是后端RS的指标包括每台RS的活跃连接数和请求成功率这是判断Keepalived健康检查是否有效的基础。用Prometheus实现监控也是个不错的选择node_exporter会暴露netstat相关的连接指标配合自定义脚本定时抓取ipvsadm的输出可以把LVS的关键数据都展现到Grafana面板上。实际上我建议就算不上Prometheus也要至少保留一条简单的采集脚本每天凌晨把ipvsadm -L -n --stats的结果归档一次方便事后排查容量问题。按经验给一个性能参考一台2路CPU、10G网卡的服务器纯DR模式转发TCP流量整机转发能力做到上百万并发连接是可行的前提是网卡队列和中断绑定的调优做到位。很多团队说LVS性能不如商业LB原因往往不是LVS本身不行而是系统参数没有针对高并发场景做调整软中断不均衡把CPU打满了。6. 回到实践我的建议和几个容易踩的坑如果你正在规划一套新的负载均衡我的建议是优先评估LVSKeepalived这个组合尤其当流量规模已经达到单台Nginx扛不住的级别。它架构简单、性能利落、业界验证充分不像商业LB那样有依赖关系也不像自研网关那样需要维护成本。它适合用在一线流量入口和早期的四层转发层后面再接Nginx做七层路由可以说是最经典的组合。在部署过程中有几个容易踩的坑值得反复强调。第一RS上忘记配置ARP抑制导致VIP被多台机器争抢。第二Keepalived配置里主备节点的virtual_router_id不一致导致VIP无法正常选举。第三没有测试主备切换只在节点存活时验证了服务在线结果真出故障时才发现备节点规则没同步。第四连接超时参数没有根据业务调整长连接业务跑几天就出现连接中断。另一个容易被低估的点是文档建设。LVS是内核态的转发机制配置复杂度和排障门槛都不低团队里如果只有一个人懂其他人遇到问题容易抓瞎。我强烈建议在交付时写一份简短的排障手册包含VIP地址、主备节点、RS列表、常用命令、健康检查策略以及每次故障的处理记录。这份文档在关键时刻能救命不值得省。我个人的体会是LVS虽然已经是一个有近二十年历史的项目但它在今天的互联网架构里依然有自己的位置。很多看起来新潮的方案底层兜底的仍然是它。学会了LVS不仅多了一项硬技能也更能理解数据包在内核里的流转逻辑。以后接触到其他网络组件思路会通很多。