简介面向网络运维与负载均衡技术学习者的F5 BIG-IP双机冗余配置专题文档聚焦高可用架构落地中的关键问题两台设备如何通过心跳机制完成主备切换、如何规划全冗余拓扑。文档依次讲解串口心跳与网络心跳两类冗余方式的原理差异前者以电平信号监控对端、为F5推荐方案后者依托TCP 1028端口在设备距离较远时传递心跳并给出Network FailSafe的VLAN指定、Floating IP与Failover Peer IP设置、Redundancy Properties状态查看及System Fail-safe配置的完整示例。同时剖析实际常用的全冗余组网优缺点说明其借助L2交换机堆叠扩展端口、支撑大规模服务器群负载均衡的适用条件与成本代价并补充BIG-IP对FailOver关键进程的监控与异常触发动作。资源包共1个doc文件约240KB篇幅紧凑、条目清晰适合作为切换原理速查与配置对照手册。已有300人学习可用于排查主备不切换、心跳异常等故障并辅助规划冗余方案。1. 凌晨两点的切换日志F5 双机冗余到底靠什么判断对端死活某公司的对外业务只挂了一个 VIP主设备一块电源模块告警。第二天翻日志才发现设备确实切了但业务断了四十秒问题不在切换动作本身而在上游交换机的 MAC 地址表还指着老设备浮动 IP 的 ARP 广播没被及时认下来。这类故障排查到最后绕不开一个基础问题F5 负载均衡的双机冗余究竟靠什么信号判断对端是死是活。F5 BIG-IP 跟 VRRP 那一套不一样它不靠虚拟路由协议抢地址主流做法是串口心跳线上的电平信号加上网络心跳的 TCP 报文。这份资料把串口心跳、网络心跳、浮动 IP 与 Failover Peer IP、Network FailSafe、关键进程监控和全冗余拓扑拆了一遍适合正在做双机上线、或者被双主和假切换折腾过的人。2. 心跳链路怎么选串口电平与 TCP 1028 的检测逻辑双机冗余的第一层不是配置是选一条对端还活着的判断通路。这条通路选错了后面所有浮动 IP、FailSafe、进程监控都是在错误的地基上叠加。2.1 串口心跳一条只有电平、没有报文的线两台 BIG-IP 之间用自带的串口线直连线上跑的不是报文是电平。Active 侧持续在心跳线上输出一个高电平Backup 侧只做一件事监听这个高电平还在不在。高电平消失Backup 立刻把自己提升为 Active然后对外发 ARP 广播把所有的 VS 地址和浮动 IP 广播出去告诉上游交换机这些地址现在在自己这端流量随之切过来。这条链路的特点是“什么都不传”。没有握手、没有序列号、没有校验和、没有重传就是一个物理层的电平状态。好处很直接它不受 CPU 满载、tmm 进程卡顿、VLAN 被误删、广播风暴、路由抖动这些东西影响。网络心跳依赖的每一层串口心跳都不依赖。这也是厂商把它列为推荐方式的原因越简单的检测机制误判面越小。硬伤同样直接线长有限原厂那根线只有 50 英尺大约 15 米短得有点离谱。同机柜、同列的两台设备用串口没问题跨机柜、跨楼层就只能放弃。另外还有一点容易被忽略——电平只有 0 和 1没有“我活着但我不健康”这个中间态。串口线松了、串口卡坏了、线被机柜门夹了一下在 Backup 眼里跟对端整机宕机是同一个现象它会毫不犹豫地切过去。这个特性在后面避坑章节里会再遇到。串口心跳的检查不需要登录两台设备分别看从任意一台都能看出对端状态# 查看本机与对端的冗余角色、对端状态、最近一次切换原因 tmsh show cm failover # 只看关键三行本机 state、peer state、failover reason tmsh show cm failover | grep -Ei state|reason|peershow cm failover的输出里State是本机当前角色Peer State是对端角色Failover Reason记录最近一次切换的触发源。如果这一行显示的是类似“serial cable”之类的字样说明这次切换是串口电平判出来的而不是人为操作或进程故障。这个字段是排查假切换的第一现场比翻日志快。2.2 网络心跳TCP 1028 的超时窗口与 VLAN 选择两台设备物理位置拉开之后心跳信号改走网线。切换触发信号通过网络通知对端同时每台设备也通过网络连接监控对端状态。承载心跳的是一条 TCP 连接常见资料里给的端口是 TCP 1028配置页上这个端口是可以改的两侧必须一致中间任何 ACL、防火墙、安全组都要放通。切换过程和串口心跳的逻辑一致Active 产生心跳Backup 监听Backup 在一定时间内没有收到心跳就自切为 Active然后发 ARP 广播抢地址。差别全在“一定时间”这四个字上。串口是电平消失即刻判定网络心跳是一个超时窗口窗口长度直接决定了误切率和业务中断时长之间的平衡。窗口设太短网络抖一下、交换机做一次 STP 收敛、链路聚合切换一条成员链路心跳丢几个包就触发切换业务被无谓地搬一次家会话表也跟着遭殃。窗口设太长真故障时业务躺在地上的时间就变成了这个窗口的长度。我的习惯是先把业务能容忍的 RTO 量出来再倒推心跳超时而不是反过来“越小越好”。多数场景下这个值落在秒级到十几秒之间具体要看业务是长连接为主还是短请求为主。心跳 VLAN 选谁同样是个判断题。资料里给了两个选项两台 BIG-IP 之间的一个独立连接 VLAN或者 Internal VLAN。能用独立 VLAN 就别用 Internal——独立链路意味着心跳流量不和业务流量抢带宽也不会被业务侧的广播风暴、STP 收敛、突发大流量拖累。用 Internal VLAN 省了一根线和一个交换机端口代价是心跳的稳定性跟业务流量绑在一起业务一忙心跳就可能开始抖。配置之前先确认两端的基础设施对得上# 1) 确认心跳 VLAN 在两端都存在且 tag 一致 tmsh list net vlan # 2) 确认心跳用的 Self IP 在两端同网段、可互 ping ping -c 4 10.10.99.12 # 3) 确认 TCP 心跳端口没有被本机防火墙或上游 ACL 拦掉 tmsh list sys firewall第一步最容易翻车。BIG-IP 里同名 VLAN 但 tag 不一致配置看着是对的心跳就是不通tmsh list net vlan把两端的 tag 摆在一起比对一分钟能省两小时。第二步是排除三层不通——注意要指定源地址 ping否则走管理口出去测的不是心跳路径。第三步的防火墙列表在很多环境里是空的但只要有人配过全局规则回包被丢的情况并不罕见。2.3 两条心跳叠加谁先说话、谁兜底串口和网络心跳不是二选一常见做法是两条都配串口做首选判定网络心跳做兜底。这样同机柜内的设备享受物理层检测的低误判位置上拉开之后网络心跳还能顶上。某些平台还有专门的硬线故障切换接口性质比串口更“硬”原理类似这里不展开。维度串口心跳网络心跳传输介质专用串口线电平信号以太网TCP 连接判定依据高电平是否存在超时窗口内是否收到心跳距离限制约 50 英尺15 米不受物理距离限制受网络质量限制抗干扰能力强不依赖协议栈与业务网络弱受拥塞、ACL、STP 收敛影响能否区分宕机与线松不能不能只能看到超时典型场景同机柜双机跨机柜、跨机房双机这张表里最后一行“能否区分”值得单独说。两种方式都只能回答“对端还在不在”回答不了“对端为什么不在”。所以排障时不要指望心跳机制给出原因它只是个触发器真正的原因要去failover reason和/var/log/ltm里找。把这两者混为一谈是很多假切换排查卡住的根源。3. 让流量真的切过去浮动 IP、Failover Peer IP 与 Network FailSafe 的配置顺序心跳只解决“知道对端死了”不解决“流量怎么过来”。中间还差三样东西一组会漂移的地址、一个能互相通报状态的地址、一套在链路层面判定失联的规则。3.1 三类地址各管什么配双机的时候最容易乱的就是地址。BIG-IP 上跟冗余相关的地址可以分成三类职责完全不同配错一类就会出现“切了但业务不通”或者“两台都觉得自己该接管”。地址类型是否浮动归属作用Self IP本地否单台设备设备自身的通信地址走traffic-group-local-onlyFloating IP浮动是当前 Active对外提供服务的 VIP 与网关地址走traffic-group-1Failover Peer IP否单台设备网络心跳与状态同步的对端通信地址绑定在心跳 VLAN 上关键在第三类。Failover Peer IP 是给对端看的地址两台设备各自有一个互指对方。它必须是心跳 VLAN 上的地址不能配在业务 VLAN 上——配在业务 VLAN 上业务一抖动心跳就跟着抖切换就开始抽风。浮动 IP 的归属靠 traffic group 决定traffic group 跟着 Active 角色走设备一切换整组浮动 IP 一起漂过去再通过 ARP 广播宣告新位置。3.2 从 VLAN 到 Self IP 的落地配置配置顺序是有讲究的先有线再有 VLAN再有地址最后才是冗余关系和同步。反着来同步会把半成品配置推到对端然后两台设备一起错。# 1) 建心跳 VLAN两端都要建tag 必须一致 tmsh create net vlan ha-vlan interfaces add { 1.2 { tagged } } tag 4094 # 2) 给心跳 VLAN 配本地 Self IP只用于冗余通信不浮动 tmsh create net self 10.10.99.11/24 vlan /Common/ha-vlan \ traffic-group /Common/traffic-group-local-only \ allow-service default # 3) 给业务 VLAN 配浮动地址跟 traffic-group-1 绑定 tmsh create net self 192.168.10.100/24 vlan /Common/external \ traffic-group /Common/traffic-group-1 \ allow-service default # 4) 保存并确认地址归属 tmsh save sys config tmsh list net self第 2 步的traffic-group-local-only和traffic-group-1是整个配置的分水岭。前者表示这个地址永远待在本机不参与漂移后者表示它属于浮动组谁 Active 谁持有。Failover Peer IP 填的就是第 2 步那个地址——对端设备上填本机的 10.10.99.11本机上填对端的 10.10.99.12。第 1 步的 tag 值只是示例重点是两端一致且不要和现网已有 VLAN 冲突。allow-service default决定这个地址开放哪些管理服务心跳地址建议收紧只放通冗余通信需要的端口别图省事全开。配置完成后两台设备的冗余关系要先建立信任、再做同步# 5) 确认设备已在同一 trust domain 内 tmsh list cm trust-domain # 6) 手动触发一次配置同步方向是从当前 Active 到对端 tmsh run cm config-sync to-group /Common/failover-group # 7) 检查同步状态两端都应为 In Sync tmsh show cm sync-status第 6 步的方向性经常被搞反。同步永远是从 Active 推向 Standby如果在 Standby 上执行命令会报错或者干脆不生效人却以为同步成功了。第 7 步如果显示的不是In Sync就先别做切换测试——带着不一致的配置切过去等于把故障从一台设备搬到两台设备。3.3 Network FailSafe 把心跳 VLAN 绑成失联判据心跳判断的是“对端设备还在不在”FailSafe 判断的是“这条链路还在不在”。两者维度不同。配 Network FailSafe 的时候要指定一个 VLAN 来承载心跳信号通常是两台设备之间的独立连接 VLAN 或者 Internal VLAN。这个 VLAN 也是心跳 VLAN所以选择逻辑和 2.2 节一致。FailSafe 的价值在于它能捕获一类心跳抓不到的场景设备活着、心跳还在、但业务 VLAN 已经不通了。比如上行交换机端口被误关、光模块衰减、链路聚合全部成员失效。这类情况下如果不做 FailSafe两台设备都觉得自己健康谁也不切业务就这么挂着。配置入口在System → Fail-safe下不同版本的对象名和字段名会有小差异先用命令探一下当前的可用项再去界面里对# 查看当前系统的 fail-safe 相关配置项 tmsh list sys | grep -i fail # 确认心跳 VLAN 上是否已有流量与错误计数异常 tmsh show net interface | grep -Ei ha-vlan|errors|drops第一条命令是探路第二条是排障。如果心跳 VLAN 的接口上 errors 或 drops 持续增长先解决物理层问题再谈 FailSafe 阈值否则 FailSafe 会把一个本来就坏掉的链路当成常态反复触发。阈值设置的核心是“多久没流量算失联”。设太敏感业务低峰期 VLAN 上本来就没包FailSafe 直接误判把好好的设备切走设太迟钝真断链时业务躺得比心跳超时还久。常见做法是让这个时间略大于心跳超时窗口形成一个从内到外的递进判定先心跳判设备再 FailSafe 判链路。3.4 状态怎么验Redundancy Properties 与日志配置完不要直接上业务先在System → Redundancy Properties里把状态看一遍或者用命令# 冗余状态总览 tmsh show cm failover # 跟踪切换相关日志倒换过程中保持这个窗口开着 tail -f /var/log/ltm | grep -Ei failover|standby|active|peer # 查看 ARP 表确认浮动 IP 对应的 MAC 指向当前 Active tmsh show net arp | grep 192.168.10.100show cm failover之外第三条命令是验证“流量真的切过去了”的关键。浮动 IP 漂移之后如果 ARP 表里对应的 MAC 还是老设备的说明 ARP 广播没生效或者上游没刷新这时候业务是不通的但设备面板一切正常。这个现象在后面避坑章节会展开。日志窗口要在倒换之前就开着事后翻日志经常漏掉关键几秒。/var/log/ltm里跟切换相关的记录会写明触发源——是心跳超时、是人为命令、还是进程监控触发的。这三种触发源对应完全不同的排查方向先分清再动手。4. 进程级失联关键进程监控与 failover 动作的取舍设备活着、心跳正常、链路也通但服务已经废了——这是双机冗余里最难抓的一类故障。进程监控就是为这个场景准备的。4.1 监控对象与被监控的进程BIG-IP 内部有一批关键进程处于严格监控之下。监控系统一旦发现这些进程出现异常——无法响应、无法启动、异常退出——就可以按预先设置的动作处理。这些动作有四类切换到备份设备、重启故障设备、重启异常进程、不做处理。要注意这里监控的粒度和心跳完全不同。心跳看的是整机进程监控看的是单个服务的健康度。一个进程挂了整机还活着心跳不会触发FailSafe 也不会触发只有进程监控能发现。这也是为什么三类机制必须同时存在缺一个就有一类故障是盲区。监控本身有成本。进程状态的采集有频率频率高了对 CPU 有占用频率低了故障发现慢。多数实现里这个频率是可调的我一般不去动默认值除非有明确的业务要求——调高发现速度的收益往往抵不过误判带来的抖动风险。4.2 配一个进程监控与切换触发配置入口在System → Fail-safe与进程监控相关的页签下具体路径在版本之间略有差异。先用命令把当前的监控项和进程状态摸清楚# 查看当前被监控的服务与进程状态 tmsh show sys service tmsh show sys process # 查看进程级高可用相关配置 tmsh list sys | grep -i -E daemon|process|ha # 确认当前设备是否已经因为进程异常触发过切换 tmsh show cm failover | grep -i reasonshow sys service列出的是系统级服务的运行状态show sys process更细能看到具体进程的 PID 与存活情况。两者结合看才能判断某个异常是“服务没起来”还是“进程起来了但不响应”。配置触发动作时关键是分清“监控什么”和“监控到了做什么”是两件事。前者决定灵敏度后者决定影响面。一套常见的保守配置是核心转发相关进程异常 → 触发切换辅助类进程异常 → 只重启进程不切换。这样避免一个边缘进程抽风就把整个业务搬到另一台设备上。# 手动触发一次切换验证进程监控配置是否按预期生效 tmsh modify sys failover active # 切回原状态standby 用的是 run不是 modify动词不同 tmsh run sys failover standby # 切换后立刻确认两端角色 tmsh show cm failover | grep -Ei state|peer这两个命令的动词不一样active用modifystandby用run敲错会直接报语法错误。手动切换是验证动作配置最可靠的方式——比等一次真故障强得多也比拔线可控。切完之后立刻看两端角色如果两端都显示 Active别继续往下测先解决双主。4.3 四种动作的副作用对比四种动作没有优劣只有适用面。选错的代价通常不是切换失败而是切换得太频繁。动作适用场景副作用风险等级切换到备份设备核心转发进程失效、本机无法自愈会话可能中断ARP 需重新收敛中重启故障设备整机状态异常、配置层故障重启期间该设备完全不可用高重启异常进程单进程挂死、重启可恢复短暂服务中断可能反复重启低不做处理非关键进程、仅需告警故障持续存在依赖人工介入低“重启异常进程”看着最温和实际最容易出问题。如果一个进程陷入崩溃—重启—再崩溃的循环动作配置会把它一次次拉起来日志被刷满真正的根因被淹没。我的做法是给重启动作加次数约束连续失败超过阈值就升级为切换或者告警别让它无限重试。“重启故障设备”是最重的手段用之前一定要想清楚这台设备重启期间如果对端也有问题业务就彻底没了。只有在确认对端健康、且本机确实无法恢复的情况下才用。提示进程监控的阈值和动作改完必须做一次手动切换验证。配置层面“看起来对”和实际“切得过去”之间差着一次真实验证。5. 避坑排查双主、假切换与反复抖动的五个现场这一章是全篇最该反复看的部分。前面配得再漂亮下面这五个现场照样能把人按在地上摩擦。5.1 两台设备同时是 Active现象登录两台设备show cm failover都显示自己是 Active浮动 IP 在两台设备上都存在业务时通时断上游交换机的 MAC 表在两条路径之间来回跳。原因心跳通路断了但两台设备各自都还健康。Backup 收不到心跳判定对端已死把自己提升为 Active同时原来的 Active 并不知道对端已经“叛变”仍然保持 Active。这就是双主。常见触发点有三个心跳 VLAN 的 tag 两端不一致、TCP 心跳端口被 ACL 拦掉、心跳走的 Self IP 被 route domain 隔离导致单向可达。解决先断业务侧别让双主继续抢地址然后按 2.2 节的三条命令逐项验证心跳通路。重点查单向可达——A 能 ping 通 BB ping 不通 A这种半通状态最隐蔽因为从任意一端看都像是通的。修好之后不要直接恢复业务先手动同步一次配置确认两端In Sync再做一次手动切换演练。5.2 切过去了但业务还是不通现象切换动作执行成功show cm failover显示角色已经互换但业务侧的连接全部超时抓包看不到回应。原因地址漂了ARP 没跟上。浮动 IP 到了新设备新设备也发了 ARP 广播但上游交换机、或者中间的二层设备还缓存着老设备的 MAC。另一种可能是老设备的接口还处于 up 状态交换机没感知到拓扑变化继续往老端口转发。解决先在新设备上看 ARP 表确认浮动 IP 对应的 MAC 是新设备自己的再在上游交换机上看 MAC 地址表确认指向的端口已经切换。如果交换机侧没刷新手动清一次 ARP 缓存做验证。长期方案是确认 ARP 广播确实发出去了以及上游的 MAC 老化时间不要设得太长。# 新 Active 上确认浮动 IP 与 MAC 的对应关系 tmsh show net arp | grep 192.168.10.100 # 确认接口状态老设备侧不应还持有该地址 tmsh list net self | grep -A2 192.168.10.100 # 抓一次 ARP 广播确认切换时确实发了 tcpdump -i external arp -c 20第三条命令要在切换的瞬间抓事后抓不到。这也是为什么切换演练必须提前开好抓包窗口。5.3 切完几秒又切回来现象日志里出现连续的 failover 记录角色在 Active 和 Standby 之间反复横跳业务被搬来搬去比不切还惨。原因心跳链路不稳定。串口线接触不良、串口卡松动、心跳 VLAN 上有突发流量打满、或者心跳经过的交换机端口有 CRC 错误。每一次丢包都被判成对端失联切过去之后心跳恢复又被判成对端回来于是切回来循环往复。解决先看接口错误计数再决定是换线还是调超时# 看心跳接口的错误与丢包计数 tmsh show net interface | grep -Ei errors|drops|crc # 看最近若干次切换的时间间隔判断抖动频率 grep -i failover /var/log/ltm | tail -30第一条命令如果显示 errors 持续增长别调参数先修物理层——调大超时只是把抖动周期拉长问题还在。第二条命令看切换间隔如果间隔高度规律基本可以确定是周期性丢包如果间隔随机更可能是物理接触问题。5.4 FailSafe 在业务低峰期误触发现象每天凌晨固定时间发生一次切换白天完全正常日志里触发源指向 FailSafe。原因FailSafe 判的是“链路上还有没有流量”。业务低峰期某个 VLAN 上本来就没多少包FailSafe 把“没流量”当成“链路断了”直接触发切换。解决调整 FailSafe 的判定阈值让它容忍低峰期的静默或者把判定对象从业务 VLAN 换成心跳 VLAN——心跳流量是持续存在的不受业务峰谷影响。这个坑很典型配置时看着合理跑起来才发现判定依据选错了对象。5.5 进程监控把正常重启当成故障现象某个进程做例行重启进程监控立刻触发切换业务被搬走几秒后进程恢复正常又切回来。原因监控动作没有区分“计划内重启”和“异常退出”。进程监控看到的是进程不在了看不到它为什么不在。解决给动作加一个延迟判定窗口——进程消失后先等若干秒仍然没起来才触发动作。例行重启通常在这个窗口内完成不会误触发。同时把“重启进程”这个动作和“切换设备”这个动作的触发条件分开前者用于可自愈的进程后者只留给核心转发进程。注意这五类问题的共性是“监控机制看到了现象但看不到原因”。排障时不要停在现象层一定去日志里找触发源触发源比现象更有信息量。6. 全冗余的端口账与一次手动倒换验收实际部署里用得最多的是全冗余方式BIG-IP 下挂 L2 交换机交换机堆叠扩展端口后台大批服务器接在堆叠交换机上。这种结构的好处是扩展性——通过堆叠可以不断加端口为大规模服务器群做负载均衡时端口数量不再是瓶颈。如果堆叠交换机是全千兆端口还能在保证连接质量的前提下同时服务大批服务器并发连接处理能力和响应速度都跟着上去。代价也很清楚。部署成本高服务器用千兆网卡交换机就不能用低端的二三层设备凑合端口速率不匹配带来的丢包会让整条链路的效率掉下来。更关键的一点常被忽略扩展交换机增加的是后台服务器的接入数量提升的是并发连接处理能力它并不能提升网络流量的处理能力。后台服务器数量堆到一定程度扩展交换机自己就成了瓶颈。所以上联那段必须做端口捆绑。堆叠交换机通过 Trunk 方式与上级设备连接把多条物理链路并成一条逻辑链路流量处理能力才跟得上。环节扩展手段提升的是瓶颈风险服务器接入L2 交换机堆叠端口数量、并发连接数低上联链路Trunk 端口捆绑网络流量处理能力中成员链路数有限扩展交换机本身全千兆端口选型转发能力与端口速率匹配度高易成为整网瓶颈BIG-IP 设备双机冗余可用性不提升单机处理能力中需与流量模型匹配这张表要横着看每一行解决的是不同维度的问题任何一行缺失整条链路的能力就被那一行卡住。最常见的误判是以为堆叠加端口就能扛住更大的流量结果上联 Trunk 只有两条千兆流量一上来照样堵。验收环节我一般只做一件事手动倒换一次全程抓包。切之前把两端状态、ARP 表、会话数各记一份切完再记一份逐项比对。# 倒换前基线 tmsh show cm failover tmsh show net arp | grep 192.168.10.100 tmsh show ltm virtual | head -20 # 执行倒换在准备让出 Active 的那台上执行 tmsh run sys failover standby # 倒换后复核重点看浮动 IP 的 MAC 是否已指向新 Active tmsh show cm failover tmsh show net arp | grep 192.168.10.100比对的重点不是“状态变了没有”而是“变的过程中业务断了多久、断在哪一层”。ARP 表的 MAC 变化时间点基本就是业务真正恢复的时间点它往往比设备角色切换的时间晚几秒。这几秒就是前面说的那四十秒里最容易被忽略的部分。从那以后我每次双机上线前都强制走一遍手动倒换加抓包确认不再相信面板上的绿灯和show命令里那个漂亮的 Active 字样。角色对了不等于流量通了流量通了不等于通得够快。希望帮到你。本文还有配套的精品资源点击获取