简介这份文档面向负责 F5 BIG-IP 高可用部署与运维的网络工程师、系统管理员及备考相关认证的学习者围绕双机冗余与全冗余解析梳理关键知识点帮助理解串口心跳、网络心跳及故障切换的落地配置。压缩包内共 1 个 doc 文件约 240KB内容以专题文档形式组织便于集中查阅和离线留存。已有约 300 人学习具备一定参考热度。正文覆盖串口心跳通过电平监控对端、Backup 切换后发送 ARP 广播的流程网络心跳借助 TCP 1028 端口传递信号并给出 Network FailSafe、Floating IP、Failover Peer IP 与 System Fail-safe 的配置示例同时说明实际常用的全冗余组网及其扩展性和成本取舍以及 BIG-IP 对关键进程的监控与触发动作。读者可据此对照理解双机切换原理、配置要点和排错方向适合作为 F5 高可用方案设计的参考材料。1. F5 双机冗余的第一道选择题为什么不是 VRRP很多人接手 F5 做负载均衡的双机冗余配置时第一反应是照着交换机的思路配一套 VRRP 主备翻遍菜单却发现没有虚拟路由优先级这一项切换也不按这条路走。分歧点在于F5 的双机冗余走的是串口心跳和网络心跳两条链路主备判定、地址漂移、进程监控是一整套独立机制跟 VRRP 那套虚拟路由逻辑并不通用。这套方案要解决的问题很具体心跳链路怎么选、双机怎么配、浮动地址怎么跟、接入层怎么组网、最后怎么验收。适合正在做网络方向毕设或课程设计、需要交一份能跑起来也能讲明白的双机高可用方案的人也适合刚接手一套双机现网、要核对配置是否完整的运维。2. 总体架构设计两种心跳链路、三类切换对象与一层接入堆叠先把骨架摆出来后面所有配置才有落点。这套双机冗余在结构上分三层看最上面是心跳层决定两台设备之间用什么方式互相判断对方还活着中间是状态层决定谁当 Active、谁当 Standby以及什么时候切换最下面才是业务层也就是浮动地址、虚拟服务和后端服务器群跟着谁走。三层里任何一层没设计清楚表现出来的症状都是“切换不生效”但根因完全不同这也是后面排查章节要分条讲的原因。心跳层有两种可选链路串口和网络它们不是替代关系很多现网是两种都上。状态层的核心是 failover 触发条件可能是心跳丢失也可能是关键进程异常还可能是某个 VLAN 断链。业务层则是切换动作的最终体现新的 Active 设备对外发 ARP 广播把虚拟服务和浮动地址宣告到自己这一侧上游交换机刷新 MAC 表流量随之改道。2.1 串口心跳与网络心跳的适用边界串口心跳用设备自带的串口线把两台 BIG-IP 直连链路里跑的不是数据报文而是电平信号。Active 设备在心跳线上维持一个高电平Backup 设备持续监听这个电平一旦监听不到就认为对端已经失效把自己提升为 Active。这条链路里没有任何协议交互也就没有协商、没有超时重传、没有版本兼容问题判定逻辑简单到几乎不会出错所以它通常是厂商推荐的首选方式。它的限制也很直接原装串口线比较短一般规格在 50 英尺这个量级两台设备必须摆得很近。机房做过改造、两台设备被分到不同机柜甚至不同楼层的情况串口线就不够用了这时候才轮到网络心跳上场。网络心跳通过两台设备之间的一条网络链路传递心跳信号走 TCP 的 1028 端口每台设备既发送自己的心跳也监听对端的心跳一定时间内收不到对端心跳就触发切换。这种方式对物理距离没有约束代价是多了一段需要规划的网络路径和地址。对比项串口心跳网络心跳传输介质原装串口线直连网络链路独立 VLAN 或 Internal VLAN判定依据电平信号有无固定时间内是否收到对端心跳距离限制受线缆长度限制约 50 英尺不受物理距离限制协议开销无数据信号无协议交互TCP 1028 端口承载心跳常见问题线缆延长、非原装线导致电平判不准VLAN 选错、端口被 ACL 拦、单向可达适用场景同机柜部署、追求判定稳定异地机房、跨机柜、跨楼层部署选型上的经验是两台设备在同一机柜内优先串口心跳判定最干净距离拉开用网络心跳同时把心跳 VLAN 做成独立物理链路不要和业务流量挤同一条 trunk。有条件的话两种都配串口当第一判据网络当补充任何一条断掉都还有另一条兜底避免单条心跳链路自己成了新的单点。2.2 双机状态机与三类切换对象双机的状态只有两个有意义的值Active 和 Standby。所有配置动作本质上都是在回答三个问题——什么时候切、切过去之后哪些东西跟着走、切完怎么让网络知道。第一类是地址对象。浮动 IPFloating IP和虚拟服务地址VS不绑定在某一台物理设备上而是挂在 traffic-group 里跟着当前 Active 走。这里有个容易被忽略的点地址漂移本身是设备内部的事上游网络并不会自动感知必须靠新 Active 发出 ARP 广播把 VS 和浮动 IP 重新宣告一遍网关和交换机的 MAC 表才会更新。第二类是连接状态。切换发生时已经在跑的会话不一定能完整保留尤其是没做连接镜像的部署。所以设计阶段就要明确这套业务能不能接受切换瞬间的会话中断能接受多长。这个结论直接决定验收标准怎么写也决定要不要在双机上开连接镜像。第三类是进程与触发动作。BIG-IP 会对一批关键进程做监控进程无响应或者起不来的时候可以预设动作切换到备机、重启故障设备、只重启异常进程、或者不做处理只告警。这四种动作的激进程度完全不同选错了就会出现“进程抖一下就整体切走”或者“进程已经挂了但设备还觉得自己健康”这两种极端。提示进程监控动作建议按业务分级配置。核心转发相关进程用切换辅助类进程用重启进程采集类进程只告警避免非关键进程把整台设备拖下水。2.3 全冗余组网接入层堆叠怎么撑起后端服务器群实际项目里更常见的是全冗余方式两台 BIG-IP 往下接一组二层交换机交换机做堆叠后端服务器群全部挂在这组交换机上。这样组网的好处是端口数量不再受限于 BIG-IP 自身的物理端口数堆叠可以一层层扩几百台服务器也能接得下负载均衡的后端规模可以随业务增长往上堆。代价有两个。一是成本服务器普遍是千兆网卡接入交换机就必须配千兆端口用低端百兆或者混速的二三层交换机会出现端口速率与网卡不匹配表现出来就是丢包、重传、吞吐上不去这种问题在压力测试阶段特别隐蔽因为小流量下完全正常。二是瓶颈位置发生了转移堆叠交换机扩的是端口数量不是总的流量处理能力后端服务器数量一多交换机上行链路反而成了瓶颈。通常的做法是接入交换机用全千兆端口把多条上行链路做端口捆绑以 trunk 方式连到 BIG-IP靠链路聚合把上行带宽拉起来。这套结构里还要注意一点堆叠交换机自身也是单点。堆叠 cable 断一根通常还有冗余路径但如果是单台交换机承载全部上行那就等于把双机冗余的意义削掉了一半。设计时至少保证上行链路分属不同堆叠成员两台 BIG-IP 的下联也分别落在不同成员上。3. 串口心跳落地电平链路与切换时序怎么做串口心跳的配置量在所有方案里是最少的因为它几乎没有参数可调真正需要想清楚的是物理连接和切换时序。物理层没接对后面所有软件配置都是空谈时序没理顺切换是发生了但业务恢复时间会远超预期。3.1 物理连接与高电平监听的判定逻辑连接方式是把原装串口线两端分别插到两台设备的串口上中间不经过任何转换器、延长器、配线架。这一点必须写进实施规范因为现场施工时最容易出现的动作就是“线不够长加个延长线”而延长之后电平信号衰减Backup 侧可能读到一个介于高低之间的电平判定就开始飘——有时候误切有时候该切不切。这类问题没有任何日志能直接告诉你原因只能靠排除法。连接完成后两台设备之间形成的是一条只传电平、不传数据的链路。Active 侧持续输出高电平Standby 侧持续监听。监听逻辑是二值的有高电平就认为对端健康没有高电平就认为对端失效。中间不存在“半健康”的中间态也没有超时重传这类机制所以它的判定延迟非常短短到几乎等于电平消失的那一刻。正因为判定这么快串口心跳对链路质量的要求反而更高。线缆松动、接头氧化、串口模块故障都会瞬间被识别为对端失效并触发切换。听上去像是误判但从高可用角度看这是合理的保守策略——宁可多切一次也不能在对端已经死掉的情况下还傻等。3.2 一条心跳断掉之后的完整切换时序把切换过程按时间顺序拆开排障时才知道卡在哪一步。完整时序通常是这样Active 设备因故障、断电或人为操作停止在心跳线上输出高电平。Standby 设备监听到电平消失启动切换判定。Standby 把自己提升为 Active接管 traffic-group。新 Active 对外发送 ARP 广播把全部 VS 地址和浮动 IP 宣告到自己这侧。上游网关和交换机的 ARP 缓存与 MAC 表更新流量指向新设备。第 4 步是整个时序里最容易被低估的一环。ARP 广播发出去了不代表上游立刻认网关的 ARP 缓存有老化时间交换机 MAC 表有老化时间中间如果还隔着防火墙或者三代设备收敛时间会更长。所以业务侧感受到的中断时长往往不是切换动作本身耗时而是 ARP 收敛耗时。在设备上核对状态我一般用这几条命令# 查看本机在双机中的角色、对端设备名与当前 failover 状态 tmsh show cm device # 查看最近一次主备切换的时间点和触发原因排障第一入口 tmsh show sys failover # 手工把本机强制降为 standby用于在维护窗口内主动验证切换链路 # 注意这条会真实触发业务切换只能在停机窗口执行 tmsh run sys failover standbytmsh show cm device的输出里重点看两列本机当前是 active 还是 standby以及对端设备是否处于可达状态。如果本机显示 active但对端也显示 active那就是典型的双主问题一定出在心跳链路上而不是切换配置上。tmsh show sys failover给出的是切换原因常见的有心跳丢失、进程异常、手工切换三类看清楚原因再往下查比盲目翻配置快得多。tmsh run sys failover standby是主动触发的验证手段效果等同于把当前 Active 打下去。执行之后立刻去看备机是否接管、ARP 是否广播出去、业务是否在预期时间内恢复。这条命令我建议在割接前的演练阶段就跑一遍别等到真出事的时候才第一次验证。4. 网络心跳配置1028 端口、心跳 VLAN 与 Failover Peer 地址网络心跳比串口心跳多了一层规划工作要有一条独立的网络路径、一个专用的 VLAN、一对互相指向的地址。配置项本身不多但每一项都关系到切换能不能触发配错一个就会出现“心跳看起来通、切换就是不发生”的情况。4.1 心跳 VLAN 的地址规划与选路心跳 VLAN 的选法有两种一是两台设备之间单独拉一根网线划一个独立 VLAN二是复用 Internal VLAN。第一种更干净心跳流量和业务流量在物理上就隔开了任何一侧的广播风暴、大流量冲击都不会影响心跳判定。第二种省事但风险在于 Internal VLAN 上如果还跑着其他东西某天流量打满心跳报文被挤掉就会误触发切换。地址规划上两台设备各给自己的心跳接口配一个同网段地址例如 A 机用 10.10.10.1/24B 机用 10.10.10.2/24。这两个地址只用于心跳和对端识别不对外宣告也不要配成浮动地址。判断心跳 VLAN 规划是否合理有一个简单标准这条链路上除了心跳报文不应该有任何其他流量。还要确认 1028 端口在路径上是通的。心跳链路如果中间经过了防火墙、安全组或者 ACL一定要显式放通双向的 TCP 1028。单向可达是这类配置里最常见的问题——A 能到 BB 回不到 A设备上看着心跳有一半但切换判定永远不满足。4.2 从浮动地址到 Failover Peer 的配置序列配置顺序有讲究先配心跳对端再配 traffic-group 的主备顺序最后挂浮动地址。顺序反了不会报错但会出现地址挂上去了却不知道该跟谁走的情况。下面是一组典型的配置序列# 1. 指定故障切换对端地址取心跳 VLAN 内 B 机的地址 # 这一步建立了 A 到 B 的心跳指向B 机上要做对称配置指向 A tmsh modify cm device bigip-a failover unicast-peer 10.10.10.2 # 2. 声明 traffic-group 的主备顺序排在第一位的最先抢 Active # 设备名必须与 cm device 里的设备名完全一致大小写敏感 tmsh modify cm traffic-group traffic-group-1 ha-order bigip-a bigip-b # 3. 把浮动地址挂到 traffic-group 上让它跟着 Active 走 # 这里以 192.0.2.100/24 为例实际地址按业务网段替换 tmsh create net self 192.0.2.100/24 vlan external traffic-group traffic-group-1 # 4. 把心跳所在的 VLAN 标记为 fail-safe # 该 VLAN 断链时即触发切换判定属性名以设备上的 tmsh 补全为准 tmsh modify net vlan internal failsafe enabled第 1 步的failover unicast-peer是把对端地址告诉本机方向是单向的两台设备都要配而且必须互相指向对方的地址。只配一台的话那台设备知道对端在哪对端却不知道它在哪心跳就成了单通。第 2 步的ha-order决定优先级不是决定谁永远当主——正常情况下排在前面的先抢 Active但它挂掉之后后面的会接管等前面的恢复回来是否抢回还要看抢占设置。第 3 步挂浮动地址时traffic-group参数是关键不写这个参数地址就绑死在当前设备上切换时不会漂移。第 4 步的failsafe是网络心跳特有的保护把承载心跳的 VLAN 纳入监控这个 VLAN 一断设备就认为链路出了问题按预设策略处理。配置完成后用tmsh show cm traffic-group核对 traffic-group 的当前承载设备用tmsh list net self确认浮动地址确实带了 traffic-group 属性。这两条命令的输出是验收材料里最直接的一手证据。4.3 Fail-safe 的进程监控与触发动作选择网络心跳解决的是链路层面的健康判断进程监控解决的是设备自身的健康判断。有些故障不影响心跳设备照样收发心跳报文但转发进程已经卡死——这种情况下如果不做进程监控双机就形同虚设因为备机永远收不到切换信号。BIG-IP 对一批关键进程做了内置监控进程无响应或者起不来时按预设动作处理。可选项通常包括切换到备机、重启本机、重启异常进程、不做处理。选择逻辑取决于这个进程在转发链路里的位置进程类型建议动作理由核心转发相关切换到备机转发面已不可用留着也是黑洞配置同步相关重启异常进程不影响转发重启即可恢复监控采集相关只告警不做处理切走反而扩大影响面会话管理相关切换到备机会话表异常会导致大面积断流配置进程监控之前先把每个进程的作用搞清楚别照抄别人的动作模板。我见过把采集类进程配成“切换”的案例结果监控脚本抖动一次两台设备来回切了三轮业务中断时间比进程本身故障还长。进程监控的粒度应该比心跳更保守因为进程状态本来就有抖动不是所有抖动都值得付出一次全量切换的代价。5. 避坑与排查五类最容易在切换时翻车的问题双机冗余的配置界面看起来简单真正出问题的地方大多不在界面上而在链路、时序和边界条件里。下面这五类是我在实际项目里反复见到的按现象、原因、解决三段写遇到问题可以对着一条条排。5.1 心跳与状态类问题现象两台设备都显示 Active业务时通时断。原因是心跳链路实际不通两台设备各自听不到对方都认为自己该当主。常见触发点有三个心跳 VLAN 配在了不同 VLAN 上、1028 端口被中间设备拦了单向、串口线接触不良。解决步骤是先在两台设备上互相 ping 心跳地址确认双向可达再用抓包确认 1028 端口上有来有回最后检查串口线是否原装、是否被延长过。串口和网络两种心跳同时配的部署还要确认两条链路不是同时断的。现象心跳一切正常主设备断电后业务不切换。原因是切换判定没有绑定到实际链路。有的部署把心跳 VLAN 选成了 Internal VLAN而 Internal VLAN 又和业务流量混在一起链路断的是业务侧、心跳侧毫发无损设备自然认为一切正常。解决方式是把心跳 VLAN 独立出来同时在 fail-safe 里把业务侧的关键 VLAN 也纳入监控让“业务链路断了”这件事也能触发切换。现象切换发生了但恢复时间比预期长很多业务侧报了几十秒中断。根因通常不在切换动作而在 ARP 收敛。新 Active 发出 ARP 广播后上游网关的 ARP 缓存还没过期仍然把流量往老设备的 MAC 地址上发。解决思路有两条一是缩短上游网关的 ARP 老化时间二是确认新 Active 发出的 ARP 广播确实到了网关必要时在切换后主动触发一次地址宣告。验收阶段一定要实测这段收敛时间把它写进验收指标里。5.2 组网与容量类问题现象全冗余组网下压力测试跑到一定并发就开始丢包但设备 CPU 和内存都不高。原因多半在接入交换机服务器是千兆网卡交换机端口是百兆或者混速端口速率不匹配导致缓冲区打满。另一个可能是上行链路没有做端口捆绑所有流量挤在一条链路上。解决方式是接入层统一用全千兆端口上行做 trunk 聚合连到 BIG-IP同时用流量监控确认瓶颈到底在接入、在上行还是在设备本身。现象后端服务器加到一定数量后整体吞吐反而下降了。这是堆叠交换机成为瓶颈的典型表现。堆叠扩的是端口数不是交换容量服务器群一大堆叠内部互访和上行流量就把交换矩阵压满了。解决方式不是继续加堆叠成员而是把上行链路做捆绑提升带宽或者按业务把服务器群拆成多组、每组走不同的上行路径。设计阶段就要把“端口数够了但带宽不够”这种情况算进去。现象进程监控触发切换后备机接管了但故障进程在备机上同样起不来两台来回切。原因是这个进程的故障原因不在单机而在共享依赖上比如后端存储、认证服务或者配置源。这种情况下切换解决不了问题只会把故障放大成双机振荡。解决方式是给切换动作加次数限制和冷却时间同时把共享依赖也纳入监控出现依赖故障时选择告警而不是切换。6. 验收与答辩用三次切换实验证明这套双机真的能用配置完不算完能通过验收的判据是“敢不敢在业务低峰期真的切一次”。答辩或者交付时光讲拓扑和配置项说服力有限把三次实验的过程和结果摆出来比讲十分钟原理都管用。第一次实验验证串口心跳。在维护窗口内拔掉主设备串口线观察备机是否在预期时间内接管、浮动地址是否漂移、ARP 是否宣告出去。记录三个时间点拔线时刻、状态翻转时刻、业务恢复时刻。这三个数字之间的差值就是这套方案的真实切换指标。第二次实验验证网络心跳。断开心跳 VLAN 的链路或者用 ACL 屏蔽 1028 端口观察切换是否按 fail-safe 的预设策略触发。这一步重点看方向性——单向屏蔽和双向屏蔽的结果不一样单向屏蔽往往不触发切换正好用来验证前面的双向放通检查是否做到位。第三次实验验证进程监控。这个实验风险最高建议在测试环境做用受控方式让目标进程退出观察是切换、重启进程还是只告警与配置表逐条比对。验收项操作预期结果留存证据串口心跳切换断开串口线备机接管VS 与浮动 IP 漂移切换前后tmsh show cm device输出网络心跳切换屏蔽心跳 VLAN 的 1028 端口按 fail-safe 策略触发切换切换原因与时间戳截图进程监控动作受控退出目标进程动作与配置表一致无双机振荡进程状态与切换日志ARP 收敛切换后立即从上游网关测试业务在约定时间内恢复连续 ping 的丢包区间双主防护同时断开两条心跳不出现双主或按预设策略降级两台设备状态对比答辩时最容易被问到的两个问题是“切换需要多久”和“切过去之后业务怎么找回来”。第一个问题用实验记录的时间点回答第二个问题用 ARP 广播和 traffic-group 的机制回答两个答案都能指到具体的实验记录上就不会被认为是背下来的。从那以后我每做完一套双机配置都强制自己走一遍“断线—观察—记录”的流程哪怕客户说不用测、哪怕窗口只有十分钟。因为没实测过的切换只是配置界面上的一个绿色图标真出事的时候没人敢信它。希望这套结构和验收方法能帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/11/3 2:57:52 · 阅读 1.2k F5双机冗余高可用：串口/网络心跳与切换验收
简介这份文档面向负责 F5 BIG-IP 高可用部署与运维的网络工程师、系统管理员及备考相关认证的学习者围绕双机冗余与全冗余解析梳理关键知识点帮助理解串口心跳、网络心跳及故障切换的落地配置。压缩包内共 1 个 doc 文件约 240KB内容以专题文档形式组织便于集中查阅和离线留存。已有约 300 人学习具备一定参考热度。正文覆盖串口心跳通过电平监控对端、Backup 切换后发送 ARP 广播的流程网络心跳借助 TCP 1028 端口传递信号并给出 Network FailSafe、Floating IP、Failover Peer IP 与 System Fail-safe 的配置示例同时说明实际常用的全冗余组网及其扩展性和成本取舍以及 BIG-IP 对关键进程的监控与触发动作。读者可据此对照理解双机切换原理、配置要点和排错方向适合作为 F5 高可用方案设计的参考材料。1. F5 双机冗余的第一道选择题为什么不是 VRRP很多人接手 F5 做负载均衡的双机冗余配置时第一反应是照着交换机的思路配一套 VRRP 主备翻遍菜单却发现没有虚拟路由优先级这一项切换也不按这条路走。分歧点在于F5 的双机冗余走的是串口心跳和网络心跳两条链路主备判定、地址漂移、进程监控是一整套独立机制跟 VRRP 那套虚拟路由逻辑并不通用。这套方案要解决的问题很具体心跳链路怎么选、双机怎么配、浮动地址怎么跟、接入层怎么组网、最后怎么验收。适合正在做网络方向毕设或课程设计、需要交一份能跑起来也能讲明白的双机高可用方案的人也适合刚接手一套双机现网、要核对配置是否完整的运维。2. 总体架构设计两种心跳链路、三类切换对象与一层接入堆叠先把骨架摆出来后面所有配置才有落点。这套双机冗余在结构上分三层看最上面是心跳层决定两台设备之间用什么方式互相判断对方还活着中间是状态层决定谁当 Active、谁当 Standby以及什么时候切换最下面才是业务层也就是浮动地址、虚拟服务和后端服务器群跟着谁走。三层里任何一层没设计清楚表现出来的症状都是“切换不生效”但根因完全不同这也是后面排查章节要分条讲的原因。心跳层有两种可选链路串口和网络它们不是替代关系很多现网是两种都上。状态层的核心是 failover 触发条件可能是心跳丢失也可能是关键进程异常还可能是某个 VLAN 断链。业务层则是切换动作的最终体现新的 Active 设备对外发 ARP 广播把虚拟服务和浮动地址宣告到自己这一侧上游交换机刷新 MAC 表流量随之改道。2.1 串口心跳与网络心跳的适用边界串口心跳用设备自带的串口线把两台 BIG-IP 直连链路里跑的不是数据报文而是电平信号。Active 设备在心跳线上维持一个高电平Backup 设备持续监听这个电平一旦监听不到就认为对端已经失效把自己提升为 Active。这条链路里没有任何协议交互也就没有协商、没有超时重传、没有版本兼容问题判定逻辑简单到几乎不会出错所以它通常是厂商推荐的首选方式。它的限制也很直接原装串口线比较短一般规格在 50 英尺这个量级两台设备必须摆得很近。机房做过改造、两台设备被分到不同机柜甚至不同楼层的情况串口线就不够用了这时候才轮到网络心跳上场。网络心跳通过两台设备之间的一条网络链路传递心跳信号走 TCP 的 1028 端口每台设备既发送自己的心跳也监听对端的心跳一定时间内收不到对端心跳就触发切换。这种方式对物理距离没有约束代价是多了一段需要规划的网络路径和地址。对比项串口心跳网络心跳传输介质原装串口线直连网络链路独立 VLAN 或 Internal VLAN判定依据电平信号有无固定时间内是否收到对端心跳距离限制受线缆长度限制约 50 英尺不受物理距离限制协议开销无数据信号无协议交互TCP 1028 端口承载心跳常见问题线缆延长、非原装线导致电平判不准VLAN 选错、端口被 ACL 拦、单向可达适用场景同机柜部署、追求判定稳定异地机房、跨机柜、跨楼层部署选型上的经验是两台设备在同一机柜内优先串口心跳判定最干净距离拉开用网络心跳同时把心跳 VLAN 做成独立物理链路不要和业务流量挤同一条 trunk。有条件的话两种都配串口当第一判据网络当补充任何一条断掉都还有另一条兜底避免单条心跳链路自己成了新的单点。2.2 双机状态机与三类切换对象双机的状态只有两个有意义的值Active 和 Standby。所有配置动作本质上都是在回答三个问题——什么时候切、切过去之后哪些东西跟着走、切完怎么让网络知道。第一类是地址对象。浮动 IPFloating IP和虚拟服务地址VS不绑定在某一台物理设备上而是挂在 traffic-group 里跟着当前 Active 走。这里有个容易被忽略的点地址漂移本身是设备内部的事上游网络并不会自动感知必须靠新 Active 发出 ARP 广播把 VS 和浮动 IP 重新宣告一遍网关和交换机的 MAC 表才会更新。第二类是连接状态。切换发生时已经在跑的会话不一定能完整保留尤其是没做连接镜像的部署。所以设计阶段就要明确这套业务能不能接受切换瞬间的会话中断能接受多长。这个结论直接决定验收标准怎么写也决定要不要在双机上开连接镜像。第三类是进程与触发动作。BIG-IP 会对一批关键进程做监控进程无响应或者起不来的时候可以预设动作切换到备机、重启故障设备、只重启异常进程、或者不做处理只告警。这四种动作的激进程度完全不同选错了就会出现“进程抖一下就整体切走”或者“进程已经挂了但设备还觉得自己健康”这两种极端。提示进程监控动作建议按业务分级配置。核心转发相关进程用切换辅助类进程用重启进程采集类进程只告警避免非关键进程把整台设备拖下水。2.3 全冗余组网接入层堆叠怎么撑起后端服务器群实际项目里更常见的是全冗余方式两台 BIG-IP 往下接一组二层交换机交换机做堆叠后端服务器群全部挂在这组交换机上。这样组网的好处是端口数量不再受限于 BIG-IP 自身的物理端口数堆叠可以一层层扩几百台服务器也能接得下负载均衡的后端规模可以随业务增长往上堆。代价有两个。一是成本服务器普遍是千兆网卡接入交换机就必须配千兆端口用低端百兆或者混速的二三层交换机会出现端口速率与网卡不匹配表现出来就是丢包、重传、吞吐上不去这种问题在压力测试阶段特别隐蔽因为小流量下完全正常。二是瓶颈位置发生了转移堆叠交换机扩的是端口数量不是总的流量处理能力后端服务器数量一多交换机上行链路反而成了瓶颈。通常的做法是接入交换机用全千兆端口把多条上行链路做端口捆绑以 trunk 方式连到 BIG-IP靠链路聚合把上行带宽拉起来。这套结构里还要注意一点堆叠交换机自身也是单点。堆叠 cable 断一根通常还有冗余路径但如果是单台交换机承载全部上行那就等于把双机冗余的意义削掉了一半。设计时至少保证上行链路分属不同堆叠成员两台 BIG-IP 的下联也分别落在不同成员上。3. 串口心跳落地电平链路与切换时序怎么做串口心跳的配置量在所有方案里是最少的因为它几乎没有参数可调真正需要想清楚的是物理连接和切换时序。物理层没接对后面所有软件配置都是空谈时序没理顺切换是发生了但业务恢复时间会远超预期。3.1 物理连接与高电平监听的判定逻辑连接方式是把原装串口线两端分别插到两台设备的串口上中间不经过任何转换器、延长器、配线架。这一点必须写进实施规范因为现场施工时最容易出现的动作就是“线不够长加个延长线”而延长之后电平信号衰减Backup 侧可能读到一个介于高低之间的电平判定就开始飘——有时候误切有时候该切不切。这类问题没有任何日志能直接告诉你原因只能靠排除法。连接完成后两台设备之间形成的是一条只传电平、不传数据的链路。Active 侧持续输出高电平Standby 侧持续监听。监听逻辑是二值的有高电平就认为对端健康没有高电平就认为对端失效。中间不存在“半健康”的中间态也没有超时重传这类机制所以它的判定延迟非常短短到几乎等于电平消失的那一刻。正因为判定这么快串口心跳对链路质量的要求反而更高。线缆松动、接头氧化、串口模块故障都会瞬间被识别为对端失效并触发切换。听上去像是误判但从高可用角度看这是合理的保守策略——宁可多切一次也不能在对端已经死掉的情况下还傻等。3.2 一条心跳断掉之后的完整切换时序把切换过程按时间顺序拆开排障时才知道卡在哪一步。完整时序通常是这样Active 设备因故障、断电或人为操作停止在心跳线上输出高电平。Standby 设备监听到电平消失启动切换判定。Standby 把自己提升为 Active接管 traffic-group。新 Active 对外发送 ARP 广播把全部 VS 地址和浮动 IP 宣告到自己这侧。上游网关和交换机的 ARP 缓存与 MAC 表更新流量指向新设备。第 4 步是整个时序里最容易被低估的一环。ARP 广播发出去了不代表上游立刻认网关的 ARP 缓存有老化时间交换机 MAC 表有老化时间中间如果还隔着防火墙或者三代设备收敛时间会更长。所以业务侧感受到的中断时长往往不是切换动作本身耗时而是 ARP 收敛耗时。在设备上核对状态我一般用这几条命令# 查看本机在双机中的角色、对端设备名与当前 failover 状态 tmsh show cm device # 查看最近一次主备切换的时间点和触发原因排障第一入口 tmsh show sys failover # 手工把本机强制降为 standby用于在维护窗口内主动验证切换链路 # 注意这条会真实触发业务切换只能在停机窗口执行 tmsh run sys failover standbytmsh show cm device的输出里重点看两列本机当前是 active 还是 standby以及对端设备是否处于可达状态。如果本机显示 active但对端也显示 active那就是典型的双主问题一定出在心跳链路上而不是切换配置上。tmsh show sys failover给出的是切换原因常见的有心跳丢失、进程异常、手工切换三类看清楚原因再往下查比盲目翻配置快得多。tmsh run sys failover standby是主动触发的验证手段效果等同于把当前 Active 打下去。执行之后立刻去看备机是否接管、ARP 是否广播出去、业务是否在预期时间内恢复。这条命令我建议在割接前的演练阶段就跑一遍别等到真出事的时候才第一次验证。4. 网络心跳配置1028 端口、心跳 VLAN 与 Failover Peer 地址网络心跳比串口心跳多了一层规划工作要有一条独立的网络路径、一个专用的 VLAN、一对互相指向的地址。配置项本身不多但每一项都关系到切换能不能触发配错一个就会出现“心跳看起来通、切换就是不发生”的情况。4.1 心跳 VLAN 的地址规划与选路心跳 VLAN 的选法有两种一是两台设备之间单独拉一根网线划一个独立 VLAN二是复用 Internal VLAN。第一种更干净心跳流量和业务流量在物理上就隔开了任何一侧的广播风暴、大流量冲击都不会影响心跳判定。第二种省事但风险在于 Internal VLAN 上如果还跑着其他东西某天流量打满心跳报文被挤掉就会误触发切换。地址规划上两台设备各给自己的心跳接口配一个同网段地址例如 A 机用 10.10.10.1/24B 机用 10.10.10.2/24。这两个地址只用于心跳和对端识别不对外宣告也不要配成浮动地址。判断心跳 VLAN 规划是否合理有一个简单标准这条链路上除了心跳报文不应该有任何其他流量。还要确认 1028 端口在路径上是通的。心跳链路如果中间经过了防火墙、安全组或者 ACL一定要显式放通双向的 TCP 1028。单向可达是这类配置里最常见的问题——A 能到 BB 回不到 A设备上看着心跳有一半但切换判定永远不满足。4.2 从浮动地址到 Failover Peer 的配置序列配置顺序有讲究先配心跳对端再配 traffic-group 的主备顺序最后挂浮动地址。顺序反了不会报错但会出现地址挂上去了却不知道该跟谁走的情况。下面是一组典型的配置序列# 1. 指定故障切换对端地址取心跳 VLAN 内 B 机的地址 # 这一步建立了 A 到 B 的心跳指向B 机上要做对称配置指向 A tmsh modify cm device bigip-a failover unicast-peer 10.10.10.2 # 2. 声明 traffic-group 的主备顺序排在第一位的最先抢 Active # 设备名必须与 cm device 里的设备名完全一致大小写敏感 tmsh modify cm traffic-group traffic-group-1 ha-order bigip-a bigip-b # 3. 把浮动地址挂到 traffic-group 上让它跟着 Active 走 # 这里以 192.0.2.100/24 为例实际地址按业务网段替换 tmsh create net self 192.0.2.100/24 vlan external traffic-group traffic-group-1 # 4. 把心跳所在的 VLAN 标记为 fail-safe # 该 VLAN 断链时即触发切换判定属性名以设备上的 tmsh 补全为准 tmsh modify net vlan internal failsafe enabled第 1 步的failover unicast-peer是把对端地址告诉本机方向是单向的两台设备都要配而且必须互相指向对方的地址。只配一台的话那台设备知道对端在哪对端却不知道它在哪心跳就成了单通。第 2 步的ha-order决定优先级不是决定谁永远当主——正常情况下排在前面的先抢 Active但它挂掉之后后面的会接管等前面的恢复回来是否抢回还要看抢占设置。第 3 步挂浮动地址时traffic-group参数是关键不写这个参数地址就绑死在当前设备上切换时不会漂移。第 4 步的failsafe是网络心跳特有的保护把承载心跳的 VLAN 纳入监控这个 VLAN 一断设备就认为链路出了问题按预设策略处理。配置完成后用tmsh show cm traffic-group核对 traffic-group 的当前承载设备用tmsh list net self确认浮动地址确实带了 traffic-group 属性。这两条命令的输出是验收材料里最直接的一手证据。4.3 Fail-safe 的进程监控与触发动作选择网络心跳解决的是链路层面的健康判断进程监控解决的是设备自身的健康判断。有些故障不影响心跳设备照样收发心跳报文但转发进程已经卡死——这种情况下如果不做进程监控双机就形同虚设因为备机永远收不到切换信号。BIG-IP 对一批关键进程做了内置监控进程无响应或者起不来时按预设动作处理。可选项通常包括切换到备机、重启本机、重启异常进程、不做处理。选择逻辑取决于这个进程在转发链路里的位置进程类型建议动作理由核心转发相关切换到备机转发面已不可用留着也是黑洞配置同步相关重启异常进程不影响转发重启即可恢复监控采集相关只告警不做处理切走反而扩大影响面会话管理相关切换到备机会话表异常会导致大面积断流配置进程监控之前先把每个进程的作用搞清楚别照抄别人的动作模板。我见过把采集类进程配成“切换”的案例结果监控脚本抖动一次两台设备来回切了三轮业务中断时间比进程本身故障还长。进程监控的粒度应该比心跳更保守因为进程状态本来就有抖动不是所有抖动都值得付出一次全量切换的代价。5. 避坑与排查五类最容易在切换时翻车的问题双机冗余的配置界面看起来简单真正出问题的地方大多不在界面上而在链路、时序和边界条件里。下面这五类是我在实际项目里反复见到的按现象、原因、解决三段写遇到问题可以对着一条条排。5.1 心跳与状态类问题现象两台设备都显示 Active业务时通时断。原因是心跳链路实际不通两台设备各自听不到对方都认为自己该当主。常见触发点有三个心跳 VLAN 配在了不同 VLAN 上、1028 端口被中间设备拦了单向、串口线接触不良。解决步骤是先在两台设备上互相 ping 心跳地址确认双向可达再用抓包确认 1028 端口上有来有回最后检查串口线是否原装、是否被延长过。串口和网络两种心跳同时配的部署还要确认两条链路不是同时断的。现象心跳一切正常主设备断电后业务不切换。原因是切换判定没有绑定到实际链路。有的部署把心跳 VLAN 选成了 Internal VLAN而 Internal VLAN 又和业务流量混在一起链路断的是业务侧、心跳侧毫发无损设备自然认为一切正常。解决方式是把心跳 VLAN 独立出来同时在 fail-safe 里把业务侧的关键 VLAN 也纳入监控让“业务链路断了”这件事也能触发切换。现象切换发生了但恢复时间比预期长很多业务侧报了几十秒中断。根因通常不在切换动作而在 ARP 收敛。新 Active 发出 ARP 广播后上游网关的 ARP 缓存还没过期仍然把流量往老设备的 MAC 地址上发。解决思路有两条一是缩短上游网关的 ARP 老化时间二是确认新 Active 发出的 ARP 广播确实到了网关必要时在切换后主动触发一次地址宣告。验收阶段一定要实测这段收敛时间把它写进验收指标里。5.2 组网与容量类问题现象全冗余组网下压力测试跑到一定并发就开始丢包但设备 CPU 和内存都不高。原因多半在接入交换机服务器是千兆网卡交换机端口是百兆或者混速端口速率不匹配导致缓冲区打满。另一个可能是上行链路没有做端口捆绑所有流量挤在一条链路上。解决方式是接入层统一用全千兆端口上行做 trunk 聚合连到 BIG-IP同时用流量监控确认瓶颈到底在接入、在上行还是在设备本身。现象后端服务器加到一定数量后整体吞吐反而下降了。这是堆叠交换机成为瓶颈的典型表现。堆叠扩的是端口数不是交换容量服务器群一大堆叠内部互访和上行流量就把交换矩阵压满了。解决方式不是继续加堆叠成员而是把上行链路做捆绑提升带宽或者按业务把服务器群拆成多组、每组走不同的上行路径。设计阶段就要把“端口数够了但带宽不够”这种情况算进去。现象进程监控触发切换后备机接管了但故障进程在备机上同样起不来两台来回切。原因是这个进程的故障原因不在单机而在共享依赖上比如后端存储、认证服务或者配置源。这种情况下切换解决不了问题只会把故障放大成双机振荡。解决方式是给切换动作加次数限制和冷却时间同时把共享依赖也纳入监控出现依赖故障时选择告警而不是切换。6. 验收与答辩用三次切换实验证明这套双机真的能用配置完不算完能通过验收的判据是“敢不敢在业务低峰期真的切一次”。答辩或者交付时光讲拓扑和配置项说服力有限把三次实验的过程和结果摆出来比讲十分钟原理都管用。第一次实验验证串口心跳。在维护窗口内拔掉主设备串口线观察备机是否在预期时间内接管、浮动地址是否漂移、ARP 是否宣告出去。记录三个时间点拔线时刻、状态翻转时刻、业务恢复时刻。这三个数字之间的差值就是这套方案的真实切换指标。第二次实验验证网络心跳。断开心跳 VLAN 的链路或者用 ACL 屏蔽 1028 端口观察切换是否按 fail-safe 的预设策略触发。这一步重点看方向性——单向屏蔽和双向屏蔽的结果不一样单向屏蔽往往不触发切换正好用来验证前面的双向放通检查是否做到位。第三次实验验证进程监控。这个实验风险最高建议在测试环境做用受控方式让目标进程退出观察是切换、重启进程还是只告警与配置表逐条比对。验收项操作预期结果留存证据串口心跳切换断开串口线备机接管VS 与浮动 IP 漂移切换前后tmsh show cm device输出网络心跳切换屏蔽心跳 VLAN 的 1028 端口按 fail-safe 策略触发切换切换原因与时间戳截图进程监控动作受控退出目标进程动作与配置表一致无双机振荡进程状态与切换日志ARP 收敛切换后立即从上游网关测试业务在约定时间内恢复连续 ping 的丢包区间双主防护同时断开两条心跳不出现双主或按预设策略降级两台设备状态对比答辩时最容易被问到的两个问题是“切换需要多久”和“切过去之后业务怎么找回来”。第一个问题用实验记录的时间点回答第二个问题用 ARP 广播和 traffic-group 的机制回答两个答案都能指到具体的实验记录上就不会被认为是背下来的。从那以后我每做完一套双机配置都强制自己走一遍“断线—观察—记录”的流程哪怕客户说不用测、哪怕窗口只有十分钟。因为没实测过的切换只是配置界面上的一个绿色图标真出事的时候没人敢信它。希望这套结构和验收方法能帮到你。本文还有配套的精品资源点击获取