1. 先理清一个老误会LVS、Keepalived、HAProxy并不是同一个层面的东西1.1 一个架构评审里的经典“翻车现场”我做过不少技术评审几乎每次都会问候选人你们当前入口负载均衡用的什么方案十个人里至少有六个会脱口而出“LVS、Keepalived、HAProxy全套都上了”。我再追问一句“那它们分别负责什么”场面就开始安静了。这不是哪个人的水平问题而是网上的安装教程太容易让人产生错觉。很多教程的标题就是“LVSKeepalivedHAProxy集群搭建”实际操作也是三样一起装装完看到了一串自动生成的配置却没人告诉你这三样东西根本不在同一个分工层LVS是一个四层负载均衡器工作在内核态基于Netfilter框架负责把大量连接按算法快速转发给后面的真实服务器Keepalived是一套高可用软件核心是VRRP协议解决的是“VIP不丢”的问题附带着能做健康检查并动态调整LVS的后端RS列表HAProxy是一个用户态的四层/七层代理能做精细的路由、ACL、会话保持、健康检查、限流和可视化统计。一句话概括LVS负责“快”Keepalived负责“稳”HAProxy负责“灵活”。把三者当成同一个东西来理解选型和排障都会走弯路。1.2 各自的出身决定各自擅长什么LVS是Linux Virtual Server它诞生很早目标就是在Linux内核里直接做负载均衡尽量不引入用户态开销。它不像Nginx、HAProxy那样跑一个进程去接受连接、转发数据而是通过ip_vs模块拦截进入的包在流量路径上做转发决策。所以LVS能做到很高的并发转发能力尤其是使用DR模式时响应包直接回给客户端LVS本身不吃出口带宽。Keepalived最初的使命是配合LVS工作让LVS从单点变成高可用集群顺便通过vrrp机制检测后端RS的健康状态自动把挂掉的机器从LVS调度表里摘掉。后来大家发现它的VRRP能力可以独立使用于是也让它给Nginx、HAProxy、业务进程提供VIP漂移。HAProxy诞生的时候互联网业务已经不再只是简单的“转发”而是需要按域名、URI、Header、Cookie做不同的流向控制。HAProxy把这些能力集中在一个可配置、可观测的用户态进程里。它对HTTP协议的理解、健康检查的精细度、统计信息的丰富程度都远胜LVS。代价是每一个连接都要经过用户态处理性能和内核态的LVS相比还是要差一点。这个“出身”差异决定了日常使用的基本盘追求极致吞吐、要处理海量连接前排放LVS需要按业务路由、做精细治理中间放HAProxy或Nginx不管前面放谁都要一套VIP漂移和健康检查那就用Keepalived。1.3 一张表看明白三者的能力边界比较项LVSKeepalivedHAProxy工作层级内核态四层控制面协议用户态四层/七层核心职责数据转发VIP管理、主备切换代理转发、路由、健康检查能否独立对外服务不能独立做高可用不能做数据转发可以但要另配高可用方案健康检查能力极弱依赖外部自带LVS联动检查丰富支持HTTP/TCP等多种检查会话保持靠调度算法/持久连接不涉及Cookie、Stick Table、源地址等性能上限极高DR模式回包不完经过自身不影响数据面高但受进程和内存模型限制适合场景入口流量很大的四层转发任何需要VIP漂移的场景业务路由、多域名、精细校验所以当有人跟你说“我用LVS做负载均衡”严格讲应该是“我用LVS做内核态转发用Keepalived保证它不单点故障用HAProxy做更上层的业务路由”。这个底层逻辑通了后面的配置才不会变成抄作业。2. 把原理掰开揉碎LVS工作模式与Keepalived的VRRP机制理解之后配置才不会瞎抄2.1 LVS DR模式为什么是生产首选LVS有三种常见工作模式NAT、DR、TUN。其中DRDirect Routing直接路由是生产环境里用得最多、性能上限也最高的模式。DR模式的处理过程可以这样理解客户端把请求包发给VIPLVS收到后不修改IP头只根据调度算法选定一台后端RS然后把二层MAC帧的目标地址改成那台RS的MAC地址再把包从和RS同网段的物理网卡发出去。RS在自己的环回接口lo上绑定了VIP收到包后发现目的IP就是本机VIP于是接受并处理业务回包时直接从RS自己的网卡发回给客户端完全不经过LVS。这个“回包不走LVS”的设计非常关键。举例来说一个视频点播或者大文件下载场景请求可能只有几十个字节响应却有几十兆甚至上百兆。如果走NAT模式LVS既要承担入口流量又要承担出口流量出口带宽会先被打满。而DR模式下LVS只需要处理一次小请求包回包走RS的独立出口整体吞吐量会高出一个数量级。这也是为什么生产环境只要网络条件允许大家都会优先选DR模式。它要求LVS和所有RS在同一个二层网络里但如果你的服务都在同一个机房、同一个VPC内网这根本不是问题。DR模式配置时有几个点很容易错每台RS都要在lo接口上绑定VIP而且不能对外宣告。必须配置ARP抑制参数arp_ignore1、arp_announce2否则RS会响应VIP的ARP请求跟LVS抢IP地址流量直接乱掉。RS的默认网关不能指向LVS应该走正常出口路由不然回包路径会变得很别扭。2.2 NAT模式和TUN模式什么时候才需要放弃DRNAT模式的LVS会在内核里做目的地址转换客户端流量进来后LVS把目的IP改成选定RS的真实IPRS回包时再回到LVS由LVS做一次反向源地址转换再发回客户端。这相当于流量进出都过一遍LVS部署上最简单RS不需要配置VIP不需要抑制ARP网络拓扑也可以跨网段。它的代价我也要说清楚LVS本身会成为整条链路的吞吐瓶颈尤其是响应流量大时出口带宽会变成一个很现实的上限。所以NAT模式更适用于中小流量、对部署简易度要求高于性能峰值的场景。如果你预估入口和出口加起来可能超过单机网卡处理能力就不要用NAT。TUN模式是通过IP-IP隧道把包封装后转发给RSRS解包处理完业务后直接回包给客户端。它解决了DR模式要求二层互通的问题RS可以分布在不同网段甚至不同机房但隧道封装和解包有额外CPU开销整体配置也更复杂。一般不是强跨机房需求我不会主动推荐TUN。另外LVS的调度算法也要结合业务选rr纯轮询适合所有RS规格一样、请求处理时间差不多的场景wrr加权轮询适合RS规格不一致比如8C16G和16C32G混跑wlc加权最少连接适合长连接业务比如网关、IMsh/source hash源地址哈希可以简单实现同一来源IP固定的会话保持sed/nq这类特殊算法使用场景少了解一下即可。还要纠正一个很多人都会有的误解LVS的调度算法只作用于新建连接。一旦某个TCP连接被转发给了某台RS那这个连接后续所有包都会走同一条路径LVS不会把一个已建立连接中途切到别的机器上。2.3 Keepalived的VIP漂移到底做了什么Keepalived的核心是VRRP协议。逻辑上多台节点组成一个虚拟路由器其中只有一台是Master其余是Backup。Master会周期性地发送VRRP通告报文Backup接收后确认Master还活着。当Backup连续几个周期没有收到通告就会认定Master挂了随即把VIP配置到自己的网卡上并发送免费ARP通知交换机更新MAC表。默认配置下如果advert_int是1秒Backup大概要在3秒多的超时后才会接管VIP。这个切换时间不是秒级不可控但也不会是毫秒级业务上要有预期。这里有几条细节如果没掌握后面排查脑裂会非常痛苦同一个VRRP组里的virtual_router_id必须保持一致否则两个节点根本无法正常协商VIP就会乱最终谁能做Master取决于priority不取决于state字段。就算你把节点A配成MASTER但priority是50节点B配成BACKUP但priority是100B依然会抢占authentication的密码只用于VRRP报文的简单校验不是安全机制VRRP报文走的是组播地址224.0.0.18底层IP协议号是112容易被防火墙或交换机的组播过滤策略拦截。很多脑裂都是这个问题引起的。Keepalived真正跟LVS联动的地方在virtual_server配置段。Keepalived在启动和运行时会调用ipvsadm命令把健康检查通过的RS加入LVS调度表把失败或超时的RS摘除。如果你只是让Keepalived做VIP漂移不打算用LVS就千万不要在配置文件里加virtual_server段否则Keepalived会去操作ipvsadm而系统里可能根本没加载ip_vs模块服务自然起不来。还有一个生产环境很容易被忽略的问题Keepalived负责VIP漂移但LVS连接表不会自动从旧Master同步到新Master。主备切换后原来Master上建立的TCP长连接状态全部丢失客户端必须重连。如果业务是短连接影响不大如果是WebSocket、数据库连接池这类长连接业务就要在应用设计时允许自动重连或者去研究ipvs connection sync相关的同步机制。3. 生产架构选型先别急着全套上规模不一样用的方案差很多3.1 中小规模最务实的组合HAProxy Keepalived很多团队一上来就要复刻大厂的“LVSKeepalivedHAProxy”三层架构其实没必要。业务每天百万级访问量、峰值QPS一万左右时两台HAProxy加一台VIP完全够用。HAProxy的优势在这个量级非常明显用户态转发性能虽然不如LVS但对万级QPS来说是绰绰有余配置灵活按域名分流、按URL做ACL、Rewrite Host、会话保持都方便健康检查可以做HTTP层验证而不是只探TCP端口自带统计页面和admin socket排障时有直观数据。具体部署很简单两台服务器分别安装HAProxy和KeepalivedKeepalived提供一个VIPHAProxy监听*:80或*:443后端指向业务集群。Keepalived检测HAProxy进程和本地服务状态主节点挂了自动漂移VIP到备份节点。整体链路短出了故障用抓包或看日志都能快速定位。这里也经常有人纠结“为什么不用Nginx做负载均衡”。如果你对静态缓存、请求改写、Web服务能力有需求Nginx确实更适合。但如果核心诉求就是接流量、做转发、看统计、保持会话HAProxy的负载均衡能力比Nginx更专。没有谁能取代谁主要看团队更熟悉什么。3.2 标准互联网业务LVS Keepalived HAProxy 双层负载当业务进入需要面对较大并发、长时间保持大量连接、或者响应包很大的阶段时单层HAProxy会开始在连接数和CPU上显现压力。这时候经典的三件套架构就派上用场了。整体链路是这样最前面是一对LVS节点由Keepalived提供VIP漂移和健康检查LVS用DR模式把流量转发给下一层中间是HAProxy集群接收LVS转发过来的流量按业务域名、URI、Header做七层分发最后面是真正的业务应用集群。为什么要加中间这层因为LVS只能做到四层转发它看不懂域名也看不懂URL路径。一台Linux服务器上可能同时挂着商城、用户中心、内容管理三个业务如果只靠LVS所有流量都会被扔到同一批后端业务隔离和路由就无从谈起。HAProxy在这里的作用就是做“业务路由枢纽”把VIP接收的流量分给不同的后端组。这个架构看起来多了一层网络跳数但实际带来的收益远大于损耗入口的高可用和四层转发由LVSKeepalived承担HAProxy不需要绑定VIP也不担心ARP问题HAProxy可以独立配置多组backend故障隔离清晰后续扩容后端时只需在HAProxy侧加server不需要动LVS压测时哪个环节是瓶颈也一眼就能看出来。3.3 决策对照到底选哪种结构业务规模推荐架构理由日活几千、QPS几百HAProxy单节点域名解析简单够用一个进程搞定日活几万、QPS几千到一万两台HAProxy Keepalived保持高可用配置灵活日活几十万、QPS几万以上LVSKeepalivedHAProxy内核态转发承担入口压力跨机房、同一业务多地域部署DNS解析多活各机房自治LVS跨地域意义不大网络复杂度高云上部署云四层负载均衡HAProxy/Nginx自建LVS在云内受ARP和组播限制较多想强调一点LVS不是技术KPI没必要为了“架构好看”强行上。如果当前峰值连接数连几万都不到加一层LVS只会增加两层故障点。等流量真正涨上来了再平滑增加LVS层也不迟这个演进方向是完全可控的。4. 从零到一部署一套LVSKeepalivedHAProxy配置手记4.1 环境规划和初始化准备为了便于复现我用一套简化的实验环境做演示LVS主节点lvs01IP 10.0.0.10LVS备节点lvs02IP 10.0.0.11VIP地址10.0.0.100HAProxy节点110.0.0.20HAProxy节点210.0.0.21Web后端web01 10.0.0.30、web02 10.0.0.31。4台机器都部署在同一内网网段满足LVS DR模式二层互通的硬性要求。如果是Debian/Ubuntu用apt install keepalived ipvsadm haproxy -y安装如果是CentOS/RHEL用yum install keepalived ipvsadm haproxy -y。这些组件在主流发行版里都是成熟包直接用包管理器安装是最稳妥的没必要为了“版本新”去源码编译。安装之后确认LVS内核模块可以正常加载modprobe ip_vs modprobe ip_vs_wrr modprobe ip_vs_sh lsmod | grep ip_vs如果重启后想自动加载可以把模块名写入/etc/modules-load.d/lvs.conf。很多线上问题就是重启后ip_vs模块没有加载Keepalived配置了virtual_server却无法操作ipvsadm服务反复异常退出。4.2 LVS节点配置先用ipvsadm验证转发链路LVS本身没有独立守护进程配置全部通过ipvsadm命令实时维护。Keepalived会接管这个过程但在正式接入前我习惯先手动敲一遍命令验证网络层能通ipvsadm -A -t 10.0.0.100:80 -s wrr ipvsadm -a -t 10.0.0.100:80 -r 10.0.0.20:80 -g -w 1 ipvsadm -a -t 10.0.0.100:80 -r 10.0.0.21:80 -g -w 1 ipvsadm -ln-g表示DR模式-w表示权重。手动加完以后用ipvsadm -ln看一下如果能看到两条real server记录说明LVS的内核转发路径已经通了。顺手再确认下LVS节点开启了转发有些内核参数还是要提前设置net.ipv4.ip_forward 1虽然DR模式回包不经过LVS这个参数影响不大但统一配置无害。4.3 Keepalived配置主备节点差异只有三处LVS节点上的Keepalived配置是所有组件里最复杂的核心是把VIP漂移和LVS后端RS的增删绑定到一起。主节点配置示例global_defs { router_id lvs_master } vrrp_instance VI_LVS { state MASTER interface eth0 virtual_router_id 51 priority 100 advert_int 1 authentication { auth_type PASS auth_pass 1234 } virtual_ipaddress { 10.0.0.100/24 dev eth0 label eth0:0 } } virtual_server 10.0.0.100 80 { delay_loop 5 lb_algo wrr lb_kind DR protocol TCP real_server 10.0.0.20 80 { weight 1 HTTP_GET { url { path /healthz status_code 200 } connect_timeout 3 nb_get_retry 3 delay_before_retry 2 } } real_server 10.0.0.21 80 { weight 1 HTTP_GET { url { path /healthz status_code 200 } connect_timeout 3 nb_get_retry 3 delay_before_retry 2 } } }备节点配置只要改三处router_id lvs_backup、state BACKUP、priority 90。接口、VIP、virtual_router_id、real_server列表必须和主节点完全一致。如果两边的virtual_server段不一致主备切换后LVS的调度对象会变得不同流量分配立刻走样。这个示例里还有一个容易被忽略的点LVS后端RS指向的是两台HAProxy的真实IP而不是HAProxy的VIP。HAProxy不需要再绑定单独的业务VIP它只要监听*:80就能收到LVS转发过来的流量。这样设计的好处是LVS负责VIP高可用HAProxy层不用重复维护一套VIP减少了ARP和地址冲突问题。4.4 HAProxy配置绑定真实IP还是通配地址HAProxy的配置相对容易理解。一个最小可用的HTTP负载均衡配置如下global maxconn 100000 nbthread 4 log /dev/log local0 info stats socket /run/haproxy/admin.sock mode 660 level admin defaults log global mode http timeout connect 5s timeout client 30s timeout server 30s timeout http-keep-alive 5s frontend http_in bind *:80 default_backend web_cluster backend web_cluster balance roundrobin option httpchk GET /healthz HTTP/1.1\r\nHost:\ healthz.example.com server web01 10.0.0.30:80 check inter 2s rise 2 fall 3 maxconn 3000 server web02 10.0.0.31:80 check inter 2s rise 2 fall 3 maxconn 3000有两个细节值得展开说bind *:80直接用通配地址。如果只绑定VIP地址LVS转发过来的目的IP是HAProxy的真实IP流量反而进不来。option httpchk指定的健康检查URI要做得很轻量最好是固定的/healthz页。不要拿一个返回超大JSON的业务页面当健康检查否则每次检查都会额外消耗后端资源高峰期还可能因为健康检查超时造成RS频繁上下线。配置写完后先用haproxy -c -f /etc/haproxy/haproxy.cfg验证语法再systemctl enable --now haproxy启动。过程中如果出现权限或资源类报错大概率是systemd的LimitNOFILE没调这个在下一章避坑清单里展开。4.5 验证链路和主备切换演练部署完成后的验证我建议至少做四步在LVS主节点执行ipvsadm -ln确认两台real_server状态正常从客户端请求VIPcurl -I http://10.0.0.100/能看到正常HTTP响应重复请求几次再通过后端日志看请求是否在web01和web02之间轮询人为停掉一台HAProxy观察Keepalived在5到10秒内把对应real_server摘除ipvsadm -ln里应该少一条记录停掉LVS主节点的Keepalived服务VIP发生漂移客户端继续请求VIP只会出现短暂超时或者业务重试不能长期挂掉。这种演练一定要在业务低峰期做。不少企业配置好了Keepalived之后两年没切过一次真到故障时才发现notify脚本路径写错了、交换机没刷新ARP、防火墙拦截了VRRP包各种问题集中爆发。主备切换演练应该纳入常规运维计划每次架构变更后至少重跑一次。5. 生产避坑清单这些问题我几乎都在线上遇到过5.1 ARP抑制DR模式里最隐蔽的流量黑洞LVS DR模式最经典的坑就是RS没有做ARP抑制。表现出来是VIP能通但响应忽快忽慢或者在客户端抓包能看到同一个VIP在短时间内收到了不同MAC地址的ARP应答。原因是RS的lo接口上绑定了VIP但没有告诉内核“这个VIP不参与ARP应答”。当客户端或交换机发起ARP请求问“谁是10.0.0.100”时LVS和RS都可能应答交换机的MAC表就会在多个MAC之间反复横跳流量也跟着乱走。解决办法是在每台RS上强制配置ARP忽略和通告策略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写入/etc/sysctl.d/lvs_rs.conf后执行sysctl -p。如果上线前没配启动Keepalived后VIP一出整个交换机的ARP表就乱了排障会非常痛苦。5.2 LVS连接表溢出高并发下最冤枉的丢包LVS的连接表是一个哈希结构由ip_vs_conn_tab_bits参数控制大小这个值决定了哈希桶的数量。很多发行版默认值偏小高并发长连接场景下哈希冲突会迅速增加表现为LVS转发随机丢包、QPS上不去但CPU和内存看起来都正常。监控时如果发现ipvsadm -ln --stats里的并发连接数接近预估上限优先确认一下ip_vs_conn_tab_bits的当前值cat /sys/module/ip_vs/parameters/conn_tab_bits如果这里显示的是12或16这种偏小的数建议把LVS节点在维护窗口内重新初始化并提前配置更大的值比如echo 20 /sys/module/ip_vs/parameters/conn_tab_bits。要注意的是这个操作在模块已加载的节点上并不能随时写入最稳妥的方式是在节点上线前或重启节点时通过modprobe配置提前固定。所以在初始化LVS节点时这是一项必须做的前置动作而不是等出了故障再去改。5.3 Keepalived脑裂的隐蔽诱因脑裂指的是主备节点同时认为自己是Master同时持有VIP。一旦发生客户端访问VIP时交换机可能把流量分给两台机器业务出现随机超时且极难排查。常见诱因有这几类主备之间的网络通信断了VRRP组播报文收不到Backup超时后主动接管VIP防火墙把IP协议号112的VRRP包拦截了交换机开启IGMP snooping后对组播地址的管理策略有问题VRRP组播没被正常转发节点假死比如机器负载极高、keepalived进程还在但已经无法处理报文。防御脑裂比较有效的方式主备之间加一条独立心跳链路比如单独的物理网卡直连或者至少让VRRP通信不依赖业务主链路在vrrp_instance里写track_script用脚本检测关键服务比如HAProxy进程、本地80端口脚本失败时主动降低优先级或退出Master状态配置notify脚本状态切换立刻告警到监控系统如果实在不放心可以在notify_master脚本里检查对端是否还活着发现双主就手动释放本机VIP。脑裂无法靠Keepalived单点解决它需要的是网络层、应用层和运维规范三方面配合。5.4 HAProxy配置里的三处性能坑第一处是maxconn和文件描述符不匹配。HAProxy每个连接至少需要两个fd一个用于客户端侧一个用于后端服务器侧。如果你把maxconn设置为100000那么ulimit -n至少要200000以上否则高并发下会频繁报Too many open files。在systemd环境里还需要额外设置[Service] LimitNOFILE655350 LimitNPROC65535修改后执行systemctl daemon-reload并重启HAProxy。很多人只改了系统ulimit忘了systemd还有自己的限制结果问题依旧。第二处是健康检查频率太高或检查路径太重。把inter设成300毫秒看起来能更快发现故障但实际上后端服务一个抖动健康检查就开始连续失败RS被摘掉后又恢复恢复后又频繁加入直接带来流量雪崩。生产环境我建议至少inter 2s并配合rise 2、fall 3这样的阈值给后端留出足够的恢复窗口。第三处是超时参数设置不符合业务特征。timeout client是客户端侧空闲超时timeout server是后端侧空闲超时如果你在做WebSocket、长轮询、数据库中间件代理这些值就不能沿用默认的十几秒。需要结合业务最长处理时长去压测然后把超时调到足够宽。很多莫名其妙的连接断开最后查到都是这里。5.5 上线、扩容、切换的时间窗管理运维层面最容易出问题的不是配置本身而是操作顺序。以下几个顺序性问题我踩过不止一次上线LVS前先要把所有RS的sysctl参数和lo:0 VIP配置好再启动Keepalived。顺序反了RS一开始就会对外ARP应答LVS还没就绪VIP就已经被“污染”了。扩容后端时先在Keepalived的real_server里把weight改成0等存量连接自然消尽再真正停止服务维护。直接kill进程会让所有活跃连接瞬间断开长连接业务基本全军覆没。修改VIP或强制刷新交换机MAC表时在持有VIP的节点上执行一次免费ARP广播arping -I eth0 -c 3 -U 10.0.0.100每次变更前校验配置文件keepalived -t -f /etc/keepalived/keepalived.conf haproxy -c -f /etc/haproxy/haproxy.cfg配置文件要纳入版本管理主备节点上线前对比一下md5能杜绝一大批“只在一边改了规则另外一边不知道”的低级故障。6. 容量评估与监控峰值到来之前这些数字必须心里有数6.1 该盯的核心指标是什么LVS、Keepalived、HAProxy各自的监控重点完全不同。LVS侧最重要是连接数、转发速率和软中断占用。查询命令ipvsadm -ln --stats ipvsadm -ln --rate--stats看累计连接数、活跃连接数、转发字节数--rate看实时速率。同时用top盯一下CPU的si占用如果si很高说明网卡包量已经让内核软中断处理开始吃力了。Keepalived侧重点看VRRP状态和切换次数。最简单的方法是查看ip addr里是否存在VIP正常只有一个节点持有。再配合notify脚本记录每次Master切换监控上能看到切换频率。如果一周内多次切换背后大概率是网络抖动或配置问题。HAProxy侧主要看当前连接数、会话速率、队列、健康检查失败次数。通过admin socket可以直接查看echo show stat | socat stdio /run/haproxy/admin.sock有Prometheus环境的话可以用haproxy_exporter直接拉取指标。一个可落地的监控组合是node_exporter带ipvs collector采集LVS指标keepalived_exporter采集VRRP状态haproxy_exporter采集HAProxy指标统一进Grafana。6.2 压测时如何评估结果和瓶颈压测工作最容易被忽视的是压测机本身先成为瓶颈。默认情况下客户端的可用源端口可能只有几万个连接一多就会出现Cannot assign requested address。压测前先把net.ipv4.ip_local_port_range调大或者压测机配置多个IP否则压测数据毫无参考价值。压测时可以分三轮做第一轮HTTP短连接聚焦QPS和CPU表现。正常情况下LVS的CPU占用应该远低于HAProxy因为内核态转发效率高第二轮定长连接聚焦并发数和内存。HAProxy每个连接要维护两条socket和对应的内存缓冲区连接数上了几十万后内存增长非常明显第三轮混合压测按真实业务比例混合短连接和长连接观察后端RS的错误率和延迟分布。记录下来的关键数字建议是LVS在什么QPS下软中断开始飙高、HAProxy在什么连接数下内存吃紧、后端RS在什么延迟开始抬头。然后以这些数据为基准保留30%到50%的水位冗余设定监控阈值。6.3 关于“高可用”的最后一层认知高可用从来不是某个软件单点保证的它是转发、漂移、健康检查、监控、规范、演练共同组合出来的结果。LVS把转发做快Keepalived把VIP稳住HAProxy把流量做细监控把故障提前暴露演练把操作动作练熟。缺任何一环架构都可能在某次大流量或者故障中出问题。我在实际维护中体会最深的一件事是简单比炫技重要。流量没起来之前HAProxy加Keepalived就是最高效的方案流量起来了再平滑增加LVS层完全来得及。真没有必要为了显得架构高级一开始就堆三件套那样只会增加出故障时的排查半径。最后分享一个小技巧每次变更前把ipvsadm -ln的输出和每台RS的健康检查结果截图留档变更后马上做一次比对。如果流量分配或者RS状态和变更前不一致能第一时间判断是配置原因还是故障原因。这个习惯看起来不起眼但线上出问题的时候它真的能帮你节省几十分钟的排查时间。
LVS、Keepalived、HAProxy三件套：负载均衡与高可用架构实战解析
1. 先理清一个老误会LVS、Keepalived、HAProxy并不是同一个层面的东西1.1 一个架构评审里的经典“翻车现场”我做过不少技术评审几乎每次都会问候选人你们当前入口负载均衡用的什么方案十个人里至少有六个会脱口而出“LVS、Keepalived、HAProxy全套都上了”。我再追问一句“那它们分别负责什么”场面就开始安静了。这不是哪个人的水平问题而是网上的安装教程太容易让人产生错觉。很多教程的标题就是“LVSKeepalivedHAProxy集群搭建”实际操作也是三样一起装装完看到了一串自动生成的配置却没人告诉你这三样东西根本不在同一个分工层LVS是一个四层负载均衡器工作在内核态基于Netfilter框架负责把大量连接按算法快速转发给后面的真实服务器Keepalived是一套高可用软件核心是VRRP协议解决的是“VIP不丢”的问题附带着能做健康检查并动态调整LVS的后端RS列表HAProxy是一个用户态的四层/七层代理能做精细的路由、ACL、会话保持、健康检查、限流和可视化统计。一句话概括LVS负责“快”Keepalived负责“稳”HAProxy负责“灵活”。把三者当成同一个东西来理解选型和排障都会走弯路。1.2 各自的出身决定各自擅长什么LVS是Linux Virtual Server它诞生很早目标就是在Linux内核里直接做负载均衡尽量不引入用户态开销。它不像Nginx、HAProxy那样跑一个进程去接受连接、转发数据而是通过ip_vs模块拦截进入的包在流量路径上做转发决策。所以LVS能做到很高的并发转发能力尤其是使用DR模式时响应包直接回给客户端LVS本身不吃出口带宽。Keepalived最初的使命是配合LVS工作让LVS从单点变成高可用集群顺便通过vrrp机制检测后端RS的健康状态自动把挂掉的机器从LVS调度表里摘掉。后来大家发现它的VRRP能力可以独立使用于是也让它给Nginx、HAProxy、业务进程提供VIP漂移。HAProxy诞生的时候互联网业务已经不再只是简单的“转发”而是需要按域名、URI、Header、Cookie做不同的流向控制。HAProxy把这些能力集中在一个可配置、可观测的用户态进程里。它对HTTP协议的理解、健康检查的精细度、统计信息的丰富程度都远胜LVS。代价是每一个连接都要经过用户态处理性能和内核态的LVS相比还是要差一点。这个“出身”差异决定了日常使用的基本盘追求极致吞吐、要处理海量连接前排放LVS需要按业务路由、做精细治理中间放HAProxy或Nginx不管前面放谁都要一套VIP漂移和健康检查那就用Keepalived。1.3 一张表看明白三者的能力边界比较项LVSKeepalivedHAProxy工作层级内核态四层控制面协议用户态四层/七层核心职责数据转发VIP管理、主备切换代理转发、路由、健康检查能否独立对外服务不能独立做高可用不能做数据转发可以但要另配高可用方案健康检查能力极弱依赖外部自带LVS联动检查丰富支持HTTP/TCP等多种检查会话保持靠调度算法/持久连接不涉及Cookie、Stick Table、源地址等性能上限极高DR模式回包不完经过自身不影响数据面高但受进程和内存模型限制适合场景入口流量很大的四层转发任何需要VIP漂移的场景业务路由、多域名、精细校验所以当有人跟你说“我用LVS做负载均衡”严格讲应该是“我用LVS做内核态转发用Keepalived保证它不单点故障用HAProxy做更上层的业务路由”。这个底层逻辑通了后面的配置才不会变成抄作业。2. 把原理掰开揉碎LVS工作模式与Keepalived的VRRP机制理解之后配置才不会瞎抄2.1 LVS DR模式为什么是生产首选LVS有三种常见工作模式NAT、DR、TUN。其中DRDirect Routing直接路由是生产环境里用得最多、性能上限也最高的模式。DR模式的处理过程可以这样理解客户端把请求包发给VIPLVS收到后不修改IP头只根据调度算法选定一台后端RS然后把二层MAC帧的目标地址改成那台RS的MAC地址再把包从和RS同网段的物理网卡发出去。RS在自己的环回接口lo上绑定了VIP收到包后发现目的IP就是本机VIP于是接受并处理业务回包时直接从RS自己的网卡发回给客户端完全不经过LVS。这个“回包不走LVS”的设计非常关键。举例来说一个视频点播或者大文件下载场景请求可能只有几十个字节响应却有几十兆甚至上百兆。如果走NAT模式LVS既要承担入口流量又要承担出口流量出口带宽会先被打满。而DR模式下LVS只需要处理一次小请求包回包走RS的独立出口整体吞吐量会高出一个数量级。这也是为什么生产环境只要网络条件允许大家都会优先选DR模式。它要求LVS和所有RS在同一个二层网络里但如果你的服务都在同一个机房、同一个VPC内网这根本不是问题。DR模式配置时有几个点很容易错每台RS都要在lo接口上绑定VIP而且不能对外宣告。必须配置ARP抑制参数arp_ignore1、arp_announce2否则RS会响应VIP的ARP请求跟LVS抢IP地址流量直接乱掉。RS的默认网关不能指向LVS应该走正常出口路由不然回包路径会变得很别扭。2.2 NAT模式和TUN模式什么时候才需要放弃DRNAT模式的LVS会在内核里做目的地址转换客户端流量进来后LVS把目的IP改成选定RS的真实IPRS回包时再回到LVS由LVS做一次反向源地址转换再发回客户端。这相当于流量进出都过一遍LVS部署上最简单RS不需要配置VIP不需要抑制ARP网络拓扑也可以跨网段。它的代价我也要说清楚LVS本身会成为整条链路的吞吐瓶颈尤其是响应流量大时出口带宽会变成一个很现实的上限。所以NAT模式更适用于中小流量、对部署简易度要求高于性能峰值的场景。如果你预估入口和出口加起来可能超过单机网卡处理能力就不要用NAT。TUN模式是通过IP-IP隧道把包封装后转发给RSRS解包处理完业务后直接回包给客户端。它解决了DR模式要求二层互通的问题RS可以分布在不同网段甚至不同机房但隧道封装和解包有额外CPU开销整体配置也更复杂。一般不是强跨机房需求我不会主动推荐TUN。另外LVS的调度算法也要结合业务选rr纯轮询适合所有RS规格一样、请求处理时间差不多的场景wrr加权轮询适合RS规格不一致比如8C16G和16C32G混跑wlc加权最少连接适合长连接业务比如网关、IMsh/source hash源地址哈希可以简单实现同一来源IP固定的会话保持sed/nq这类特殊算法使用场景少了解一下即可。还要纠正一个很多人都会有的误解LVS的调度算法只作用于新建连接。一旦某个TCP连接被转发给了某台RS那这个连接后续所有包都会走同一条路径LVS不会把一个已建立连接中途切到别的机器上。2.3 Keepalived的VIP漂移到底做了什么Keepalived的核心是VRRP协议。逻辑上多台节点组成一个虚拟路由器其中只有一台是Master其余是Backup。Master会周期性地发送VRRP通告报文Backup接收后确认Master还活着。当Backup连续几个周期没有收到通告就会认定Master挂了随即把VIP配置到自己的网卡上并发送免费ARP通知交换机更新MAC表。默认配置下如果advert_int是1秒Backup大概要在3秒多的超时后才会接管VIP。这个切换时间不是秒级不可控但也不会是毫秒级业务上要有预期。这里有几条细节如果没掌握后面排查脑裂会非常痛苦同一个VRRP组里的virtual_router_id必须保持一致否则两个节点根本无法正常协商VIP就会乱最终谁能做Master取决于priority不取决于state字段。就算你把节点A配成MASTER但priority是50节点B配成BACKUP但priority是100B依然会抢占authentication的密码只用于VRRP报文的简单校验不是安全机制VRRP报文走的是组播地址224.0.0.18底层IP协议号是112容易被防火墙或交换机的组播过滤策略拦截。很多脑裂都是这个问题引起的。Keepalived真正跟LVS联动的地方在virtual_server配置段。Keepalived在启动和运行时会调用ipvsadm命令把健康检查通过的RS加入LVS调度表把失败或超时的RS摘除。如果你只是让Keepalived做VIP漂移不打算用LVS就千万不要在配置文件里加virtual_server段否则Keepalived会去操作ipvsadm而系统里可能根本没加载ip_vs模块服务自然起不来。还有一个生产环境很容易被忽略的问题Keepalived负责VIP漂移但LVS连接表不会自动从旧Master同步到新Master。主备切换后原来Master上建立的TCP长连接状态全部丢失客户端必须重连。如果业务是短连接影响不大如果是WebSocket、数据库连接池这类长连接业务就要在应用设计时允许自动重连或者去研究ipvs connection sync相关的同步机制。3. 生产架构选型先别急着全套上规模不一样用的方案差很多3.1 中小规模最务实的组合HAProxy Keepalived很多团队一上来就要复刻大厂的“LVSKeepalivedHAProxy”三层架构其实没必要。业务每天百万级访问量、峰值QPS一万左右时两台HAProxy加一台VIP完全够用。HAProxy的优势在这个量级非常明显用户态转发性能虽然不如LVS但对万级QPS来说是绰绰有余配置灵活按域名分流、按URL做ACL、Rewrite Host、会话保持都方便健康检查可以做HTTP层验证而不是只探TCP端口自带统计页面和admin socket排障时有直观数据。具体部署很简单两台服务器分别安装HAProxy和KeepalivedKeepalived提供一个VIPHAProxy监听*:80或*:443后端指向业务集群。Keepalived检测HAProxy进程和本地服务状态主节点挂了自动漂移VIP到备份节点。整体链路短出了故障用抓包或看日志都能快速定位。这里也经常有人纠结“为什么不用Nginx做负载均衡”。如果你对静态缓存、请求改写、Web服务能力有需求Nginx确实更适合。但如果核心诉求就是接流量、做转发、看统计、保持会话HAProxy的负载均衡能力比Nginx更专。没有谁能取代谁主要看团队更熟悉什么。3.2 标准互联网业务LVS Keepalived HAProxy 双层负载当业务进入需要面对较大并发、长时间保持大量连接、或者响应包很大的阶段时单层HAProxy会开始在连接数和CPU上显现压力。这时候经典的三件套架构就派上用场了。整体链路是这样最前面是一对LVS节点由Keepalived提供VIP漂移和健康检查LVS用DR模式把流量转发给下一层中间是HAProxy集群接收LVS转发过来的流量按业务域名、URI、Header做七层分发最后面是真正的业务应用集群。为什么要加中间这层因为LVS只能做到四层转发它看不懂域名也看不懂URL路径。一台Linux服务器上可能同时挂着商城、用户中心、内容管理三个业务如果只靠LVS所有流量都会被扔到同一批后端业务隔离和路由就无从谈起。HAProxy在这里的作用就是做“业务路由枢纽”把VIP接收的流量分给不同的后端组。这个架构看起来多了一层网络跳数但实际带来的收益远大于损耗入口的高可用和四层转发由LVSKeepalived承担HAProxy不需要绑定VIP也不担心ARP问题HAProxy可以独立配置多组backend故障隔离清晰后续扩容后端时只需在HAProxy侧加server不需要动LVS压测时哪个环节是瓶颈也一眼就能看出来。3.3 决策对照到底选哪种结构业务规模推荐架构理由日活几千、QPS几百HAProxy单节点域名解析简单够用一个进程搞定日活几万、QPS几千到一万两台HAProxy Keepalived保持高可用配置灵活日活几十万、QPS几万以上LVSKeepalivedHAProxy内核态转发承担入口压力跨机房、同一业务多地域部署DNS解析多活各机房自治LVS跨地域意义不大网络复杂度高云上部署云四层负载均衡HAProxy/Nginx自建LVS在云内受ARP和组播限制较多想强调一点LVS不是技术KPI没必要为了“架构好看”强行上。如果当前峰值连接数连几万都不到加一层LVS只会增加两层故障点。等流量真正涨上来了再平滑增加LVS层也不迟这个演进方向是完全可控的。4. 从零到一部署一套LVSKeepalivedHAProxy配置手记4.1 环境规划和初始化准备为了便于复现我用一套简化的实验环境做演示LVS主节点lvs01IP 10.0.0.10LVS备节点lvs02IP 10.0.0.11VIP地址10.0.0.100HAProxy节点110.0.0.20HAProxy节点210.0.0.21Web后端web01 10.0.0.30、web02 10.0.0.31。4台机器都部署在同一内网网段满足LVS DR模式二层互通的硬性要求。如果是Debian/Ubuntu用apt install keepalived ipvsadm haproxy -y安装如果是CentOS/RHEL用yum install keepalived ipvsadm haproxy -y。这些组件在主流发行版里都是成熟包直接用包管理器安装是最稳妥的没必要为了“版本新”去源码编译。安装之后确认LVS内核模块可以正常加载modprobe ip_vs modprobe ip_vs_wrr modprobe ip_vs_sh lsmod | grep ip_vs如果重启后想自动加载可以把模块名写入/etc/modules-load.d/lvs.conf。很多线上问题就是重启后ip_vs模块没有加载Keepalived配置了virtual_server却无法操作ipvsadm服务反复异常退出。4.2 LVS节点配置先用ipvsadm验证转发链路LVS本身没有独立守护进程配置全部通过ipvsadm命令实时维护。Keepalived会接管这个过程但在正式接入前我习惯先手动敲一遍命令验证网络层能通ipvsadm -A -t 10.0.0.100:80 -s wrr ipvsadm -a -t 10.0.0.100:80 -r 10.0.0.20:80 -g -w 1 ipvsadm -a -t 10.0.0.100:80 -r 10.0.0.21:80 -g -w 1 ipvsadm -ln-g表示DR模式-w表示权重。手动加完以后用ipvsadm -ln看一下如果能看到两条real server记录说明LVS的内核转发路径已经通了。顺手再确认下LVS节点开启了转发有些内核参数还是要提前设置net.ipv4.ip_forward 1虽然DR模式回包不经过LVS这个参数影响不大但统一配置无害。4.3 Keepalived配置主备节点差异只有三处LVS节点上的Keepalived配置是所有组件里最复杂的核心是把VIP漂移和LVS后端RS的增删绑定到一起。主节点配置示例global_defs { router_id lvs_master } vrrp_instance VI_LVS { state MASTER interface eth0 virtual_router_id 51 priority 100 advert_int 1 authentication { auth_type PASS auth_pass 1234 } virtual_ipaddress { 10.0.0.100/24 dev eth0 label eth0:0 } } virtual_server 10.0.0.100 80 { delay_loop 5 lb_algo wrr lb_kind DR protocol TCP real_server 10.0.0.20 80 { weight 1 HTTP_GET { url { path /healthz status_code 200 } connect_timeout 3 nb_get_retry 3 delay_before_retry 2 } } real_server 10.0.0.21 80 { weight 1 HTTP_GET { url { path /healthz status_code 200 } connect_timeout 3 nb_get_retry 3 delay_before_retry 2 } } }备节点配置只要改三处router_id lvs_backup、state BACKUP、priority 90。接口、VIP、virtual_router_id、real_server列表必须和主节点完全一致。如果两边的virtual_server段不一致主备切换后LVS的调度对象会变得不同流量分配立刻走样。这个示例里还有一个容易被忽略的点LVS后端RS指向的是两台HAProxy的真实IP而不是HAProxy的VIP。HAProxy不需要再绑定单独的业务VIP它只要监听*:80就能收到LVS转发过来的流量。这样设计的好处是LVS负责VIP高可用HAProxy层不用重复维护一套VIP减少了ARP和地址冲突问题。4.4 HAProxy配置绑定真实IP还是通配地址HAProxy的配置相对容易理解。一个最小可用的HTTP负载均衡配置如下global maxconn 100000 nbthread 4 log /dev/log local0 info stats socket /run/haproxy/admin.sock mode 660 level admin defaults log global mode http timeout connect 5s timeout client 30s timeout server 30s timeout http-keep-alive 5s frontend http_in bind *:80 default_backend web_cluster backend web_cluster balance roundrobin option httpchk GET /healthz HTTP/1.1\r\nHost:\ healthz.example.com server web01 10.0.0.30:80 check inter 2s rise 2 fall 3 maxconn 3000 server web02 10.0.0.31:80 check inter 2s rise 2 fall 3 maxconn 3000有两个细节值得展开说bind *:80直接用通配地址。如果只绑定VIP地址LVS转发过来的目的IP是HAProxy的真实IP流量反而进不来。option httpchk指定的健康检查URI要做得很轻量最好是固定的/healthz页。不要拿一个返回超大JSON的业务页面当健康检查否则每次检查都会额外消耗后端资源高峰期还可能因为健康检查超时造成RS频繁上下线。配置写完后先用haproxy -c -f /etc/haproxy/haproxy.cfg验证语法再systemctl enable --now haproxy启动。过程中如果出现权限或资源类报错大概率是systemd的LimitNOFILE没调这个在下一章避坑清单里展开。4.5 验证链路和主备切换演练部署完成后的验证我建议至少做四步在LVS主节点执行ipvsadm -ln确认两台real_server状态正常从客户端请求VIPcurl -I http://10.0.0.100/能看到正常HTTP响应重复请求几次再通过后端日志看请求是否在web01和web02之间轮询人为停掉一台HAProxy观察Keepalived在5到10秒内把对应real_server摘除ipvsadm -ln里应该少一条记录停掉LVS主节点的Keepalived服务VIP发生漂移客户端继续请求VIP只会出现短暂超时或者业务重试不能长期挂掉。这种演练一定要在业务低峰期做。不少企业配置好了Keepalived之后两年没切过一次真到故障时才发现notify脚本路径写错了、交换机没刷新ARP、防火墙拦截了VRRP包各种问题集中爆发。主备切换演练应该纳入常规运维计划每次架构变更后至少重跑一次。5. 生产避坑清单这些问题我几乎都在线上遇到过5.1 ARP抑制DR模式里最隐蔽的流量黑洞LVS DR模式最经典的坑就是RS没有做ARP抑制。表现出来是VIP能通但响应忽快忽慢或者在客户端抓包能看到同一个VIP在短时间内收到了不同MAC地址的ARP应答。原因是RS的lo接口上绑定了VIP但没有告诉内核“这个VIP不参与ARP应答”。当客户端或交换机发起ARP请求问“谁是10.0.0.100”时LVS和RS都可能应答交换机的MAC表就会在多个MAC之间反复横跳流量也跟着乱走。解决办法是在每台RS上强制配置ARP忽略和通告策略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写入/etc/sysctl.d/lvs_rs.conf后执行sysctl -p。如果上线前没配启动Keepalived后VIP一出整个交换机的ARP表就乱了排障会非常痛苦。5.2 LVS连接表溢出高并发下最冤枉的丢包LVS的连接表是一个哈希结构由ip_vs_conn_tab_bits参数控制大小这个值决定了哈希桶的数量。很多发行版默认值偏小高并发长连接场景下哈希冲突会迅速增加表现为LVS转发随机丢包、QPS上不去但CPU和内存看起来都正常。监控时如果发现ipvsadm -ln --stats里的并发连接数接近预估上限优先确认一下ip_vs_conn_tab_bits的当前值cat /sys/module/ip_vs/parameters/conn_tab_bits如果这里显示的是12或16这种偏小的数建议把LVS节点在维护窗口内重新初始化并提前配置更大的值比如echo 20 /sys/module/ip_vs/parameters/conn_tab_bits。要注意的是这个操作在模块已加载的节点上并不能随时写入最稳妥的方式是在节点上线前或重启节点时通过modprobe配置提前固定。所以在初始化LVS节点时这是一项必须做的前置动作而不是等出了故障再去改。5.3 Keepalived脑裂的隐蔽诱因脑裂指的是主备节点同时认为自己是Master同时持有VIP。一旦发生客户端访问VIP时交换机可能把流量分给两台机器业务出现随机超时且极难排查。常见诱因有这几类主备之间的网络通信断了VRRP组播报文收不到Backup超时后主动接管VIP防火墙把IP协议号112的VRRP包拦截了交换机开启IGMP snooping后对组播地址的管理策略有问题VRRP组播没被正常转发节点假死比如机器负载极高、keepalived进程还在但已经无法处理报文。防御脑裂比较有效的方式主备之间加一条独立心跳链路比如单独的物理网卡直连或者至少让VRRP通信不依赖业务主链路在vrrp_instance里写track_script用脚本检测关键服务比如HAProxy进程、本地80端口脚本失败时主动降低优先级或退出Master状态配置notify脚本状态切换立刻告警到监控系统如果实在不放心可以在notify_master脚本里检查对端是否还活着发现双主就手动释放本机VIP。脑裂无法靠Keepalived单点解决它需要的是网络层、应用层和运维规范三方面配合。5.4 HAProxy配置里的三处性能坑第一处是maxconn和文件描述符不匹配。HAProxy每个连接至少需要两个fd一个用于客户端侧一个用于后端服务器侧。如果你把maxconn设置为100000那么ulimit -n至少要200000以上否则高并发下会频繁报Too many open files。在systemd环境里还需要额外设置[Service] LimitNOFILE655350 LimitNPROC65535修改后执行systemctl daemon-reload并重启HAProxy。很多人只改了系统ulimit忘了systemd还有自己的限制结果问题依旧。第二处是健康检查频率太高或检查路径太重。把inter设成300毫秒看起来能更快发现故障但实际上后端服务一个抖动健康检查就开始连续失败RS被摘掉后又恢复恢复后又频繁加入直接带来流量雪崩。生产环境我建议至少inter 2s并配合rise 2、fall 3这样的阈值给后端留出足够的恢复窗口。第三处是超时参数设置不符合业务特征。timeout client是客户端侧空闲超时timeout server是后端侧空闲超时如果你在做WebSocket、长轮询、数据库中间件代理这些值就不能沿用默认的十几秒。需要结合业务最长处理时长去压测然后把超时调到足够宽。很多莫名其妙的连接断开最后查到都是这里。5.5 上线、扩容、切换的时间窗管理运维层面最容易出问题的不是配置本身而是操作顺序。以下几个顺序性问题我踩过不止一次上线LVS前先要把所有RS的sysctl参数和lo:0 VIP配置好再启动Keepalived。顺序反了RS一开始就会对外ARP应答LVS还没就绪VIP就已经被“污染”了。扩容后端时先在Keepalived的real_server里把weight改成0等存量连接自然消尽再真正停止服务维护。直接kill进程会让所有活跃连接瞬间断开长连接业务基本全军覆没。修改VIP或强制刷新交换机MAC表时在持有VIP的节点上执行一次免费ARP广播arping -I eth0 -c 3 -U 10.0.0.100每次变更前校验配置文件keepalived -t -f /etc/keepalived/keepalived.conf haproxy -c -f /etc/haproxy/haproxy.cfg配置文件要纳入版本管理主备节点上线前对比一下md5能杜绝一大批“只在一边改了规则另外一边不知道”的低级故障。6. 容量评估与监控峰值到来之前这些数字必须心里有数6.1 该盯的核心指标是什么LVS、Keepalived、HAProxy各自的监控重点完全不同。LVS侧最重要是连接数、转发速率和软中断占用。查询命令ipvsadm -ln --stats ipvsadm -ln --rate--stats看累计连接数、活跃连接数、转发字节数--rate看实时速率。同时用top盯一下CPU的si占用如果si很高说明网卡包量已经让内核软中断处理开始吃力了。Keepalived侧重点看VRRP状态和切换次数。最简单的方法是查看ip addr里是否存在VIP正常只有一个节点持有。再配合notify脚本记录每次Master切换监控上能看到切换频率。如果一周内多次切换背后大概率是网络抖动或配置问题。HAProxy侧主要看当前连接数、会话速率、队列、健康检查失败次数。通过admin socket可以直接查看echo show stat | socat stdio /run/haproxy/admin.sock有Prometheus环境的话可以用haproxy_exporter直接拉取指标。一个可落地的监控组合是node_exporter带ipvs collector采集LVS指标keepalived_exporter采集VRRP状态haproxy_exporter采集HAProxy指标统一进Grafana。6.2 压测时如何评估结果和瓶颈压测工作最容易被忽视的是压测机本身先成为瓶颈。默认情况下客户端的可用源端口可能只有几万个连接一多就会出现Cannot assign requested address。压测前先把net.ipv4.ip_local_port_range调大或者压测机配置多个IP否则压测数据毫无参考价值。压测时可以分三轮做第一轮HTTP短连接聚焦QPS和CPU表现。正常情况下LVS的CPU占用应该远低于HAProxy因为内核态转发效率高第二轮定长连接聚焦并发数和内存。HAProxy每个连接要维护两条socket和对应的内存缓冲区连接数上了几十万后内存增长非常明显第三轮混合压测按真实业务比例混合短连接和长连接观察后端RS的错误率和延迟分布。记录下来的关键数字建议是LVS在什么QPS下软中断开始飙高、HAProxy在什么连接数下内存吃紧、后端RS在什么延迟开始抬头。然后以这些数据为基准保留30%到50%的水位冗余设定监控阈值。6.3 关于“高可用”的最后一层认知高可用从来不是某个软件单点保证的它是转发、漂移、健康检查、监控、规范、演练共同组合出来的结果。LVS把转发做快Keepalived把VIP稳住HAProxy把流量做细监控把故障提前暴露演练把操作动作练熟。缺任何一环架构都可能在某次大流量或者故障中出问题。我在实际维护中体会最深的一件事是简单比炫技重要。流量没起来之前HAProxy加Keepalived就是最高效的方案流量起来了再平滑增加LVS层完全来得及。真没有必要为了显得架构高级一开始就堆三件套那样只会增加出故障时的排查半径。最后分享一个小技巧每次变更前把ipvsadm -ln的输出和每台RS的健康检查结果截图留档变更后马上做一次比对。如果流量分配或者RS状态和变更前不一致能第一时间判断是配置原因还是故障原因。这个习惯看起来不起眼但线上出问题的时候它真的能帮你节省几十分钟的排查时间。