简介F5 BIG-IP双机冗余配置与全冗余解析是一份面向负载均衡运维及架构师的Word技术文档旨在理清F5设备实现高可用与负载均衡的冗余机制。压缩包共1个文件文件类型为doc整体大小约240KB便于离线阅读与查阅。文档重点对比串口心跳与网络心跳两种双机冗余方式前者通过串口电平监测主备状态并借助ARP广播完成流量切换后者基于TCP 1028端口传递心跳并支持Network FailSafe网络心跳配置同时给出Floating IP/Peer IP设置、FailOver触发进程监控以及全冗余L2交换机堆叠架构的优缺点。读者可从中获得从双机切换原理、配置示例到大规模服务器群扩展方案的完整认知也可作为F5高可用部署、故障切换与网络排障的直接参考尤其适合数据中心双机热备及关键应用负载均衡场景。资源已有299人学习下载适合需要系统理解F5冗余配置的网络工程师。1. 双机冗余的意义备机接管业务时真的能接住吗很多团队在采购F5负载均衡时第一诉求就是「别让设备变成单点」。两台F5接到同一套业务网段里主设备挂了自动切到备机听起来是件理所当然的事。但我见过不止一次这样的场景设备确实切换了VIP也确实从主设备漂到了备机可业务反而彻底中断了——备机上的配置是三个月前的pool里的后端节点全是旧地址或者连接镜像没开所有在线用户的会话在切换瞬间全部断裂支付请求直接超时。也就是说双机冗余不只是「买两台设备再配个心跳」那么简单它要解决的是三个连续问题配置什么时候保持一致状态能不能实时镜像流量凭什么从主设备平滑交接到备机。本文就把这背后的机制拆开再给出一套可以直接照抄的配置流程和检查清单让你在落地F5双机冗余时少走弯路。适合正在运维F5、或者正准备做负载均衡双机改造的工程师阅读。2. 双机冗余机制拆解硬件、心跳与配置同步三板斧2.1 硬件基础F5设备内部的冗余与两台设备的物理连接F5负载均衡设备本身是一台专用的网络设备跑的是自家TMOS操作系统。要在它之上做双机冗余第一层依赖其实是单台设备自身的硬件冗余能力。常见的物理形态里电源模块通常有双份风扇也是可热插拔的冗余配置硬盘一般做成RAID或者双盘镜像。这些部件级冗余保证的是「一台设备内部不要因为单个零件损坏就宕机」它是后面所有高可用逻辑的物理底座。虽然这部分平时感知不强但采购选型时值得确认一遍尤其是双电源模块和独立管理网口后面会讲到它们各自的作用。两台F5设备之间要建立冗余关系需要物理连接上打通两条路径一条是管理网络负责设备之间的信任建立和配置同步另一条是心跳链路负责实时探测对端设备是否存活。心跳链路推荐用独立的物理网口直连或者走一个专用的、不受业务拥塞干扰的VLAN。如果业务流量很大把心跳报文混在业务链路上传输很容易因为瞬时拥塞造成心跳超时进而触发误切换。这是很多双机环境里最隐蔽的坑后面避坑章节会展开说。设备之间的信任关系建立不同版本有不同实现方式常见是通过管理网络交换证书或者密钥完成认证。信任建立之后两台设备才会被允许做配置双向同步。这一步如果不做备机永远只是台「摆设」看似在线实际拿不到任何配置。2.2 状态检测与切换逻辑Active-Standby 是怎么判定的F5双机冗余最常见的运行模式是Active-Standby也叫主备模式。主设备承载全部流量备设备处于热备状态不接收业务流量但时刻准备接管。判断谁该接管靠的是一套状态检测机制检测对象包括心跳报文、TMM进程运行状态、硬件自检结果等。一旦主设备心跳丢失或者TMM进程异常备机会在预设的超时时间后将自己提升为Active同时通过ARP广播宣告VIP已经漂移到自己身上。这里需要分清两个概念设备故障切换和业务故障切换。F5的HA切换机制主要针对「设备级故障」比如整机断电、TMM进程崩溃、硬件自检失败。如果你的F5本身活着但它负责的pool里所有后端服务器都挂了此时F5不会触发主备切换因为这是后端业务层面的故障不是设备故障。很多新手在这里会踩坑以为双机冗余连后端服务的健康状态都会自动接管实际上那是另外一套健康检查策略的职责。此外还有一个容易混淆的概念浮动IP。在双机环境里F5上承载业务的VIP和self IP都归属于一个叫做traffic group流量组的逻辑对象。默认情况下所有资源都在同一个traffic-group-1里。主设备持有这个流量组的所有浮动对象备机平时不响应这些IP。切换发生时备机接管整个流量组浮动IP随之迁移。理解了这一点后面配置时你就会明白为什么要给VIP指定traffic group。2.3 配置同步与连接镜像决定「接管后业务可不可用」的两把钥匙主备设备之间有一个自动化的配置同步机制通常称为ConfigSync。它的工作方式是你在主设备上做的任何配置变更都会被推送到备机保证两台设备上的配置数据库完全一致。配置同步的内容覆盖VIP、pool、monitor、irule、数据组等所有对象。这个机制在部署时一定要验证否则主备之间配置不一致切换后业务一定出问题。我遇到过不止一次「备机接管后VIP出现了但pool是空的」的情况查下来就是同步链路不通或者自动同步被关掉了。连接镜像是另一个关键机制。它负责把主设备上的连接表、持久化会话等状态实时镜像到备机。为什么要镜像因为切换发生时如果备机没有这些状态数据所有在线用户的长连接都会断掉已经建立的TCP连接将无法续传。对于Web页面可能影响不大用户重新登录就行但对支付网关、即时通讯、文件上传这类长连接业务这就是事故。所以配置双机冗余时要按业务类型决定是否开启镜像。开启的代价是设备性能和镜像链路带宽都有额外开销不是所有业务都需要开但开了才能真正做到「无缝切换」。3. 双机冗余最小配置一份可以照抄的部署清单3.1 规划阶段三张表把地址和资源提前理清动手配置前我建议先用表格把地址规划写清楚避免配置到一半发现网段冲突。F5双机环境里至少涉及四类地址管理IP、心跳IP、业务self IP、浮动VIP。管理IP用于登录设备和管理网络通信心跳IP用于两台设备之间的状态探测self IP是F5接入业务网段的接口地址浮动VIP是最终提供给外部访问的虚拟服务地址。规划时有一个原则心跳链路要独立网段管理网段和业务网段建议也分开减少相互干扰。设备角色管理IP心跳IP业务self IP浮动VIP示例F5主设备192.168.24.1192.168.88.110.80.1.1/2410.80.1.100:80F5备设备192.168.24.2192.168.88.210.80.1.2/2410.80.1.100:80上面的例子是典型的单VIP场景。两台设备在业务网段各有自己的self IP用于和交换机、后端节点通信浮动VIP则共用一个地址平时由主设备持有并响应。规划时还要额外确定一件事配置同步走哪条链路。通常情况下同步报文走管理网络也可以指定走心跳链路视网络规模而定。我的习惯是让配置同步和心跳都走独立链路这样即便管理网络出问题也不影响配置同步和状态检测。3.2 部署步骤初始化、建信任、建流量组、配置同步以下是基于TMSH命令行风格的最小配置参考。不同版本的TMSH命令对象名称略有差异但整体逻辑一致实际部署时以你的版本命令参考为准。配置前请先将两台设备的管理IP和主机名按规划设置好。# ---- 以下命令在主设备上执行 ---- # 1. 修改主机名便于在设备组中清晰识别 tmsh modify sys global-settings hostname f5-ha-a # 2. 添加备机设备对象指定其管理IP tmsh create cm device f5-ha-b management-ip 192.168.24.2 # 3. 创建设备组类型为 sync-failover # 该类型同时负责配置同步和设备故障切换 tmsh create cm device-group dg-f5 devices { f5-ha-a f5-ha-b } type sync-failover # 4. 创建流量组 traffic-group浮动VIP后续会挂到这个组里 tmsh create cm traffic-group tg-web # 5. 创建后端节点和健康检查 tmsh create ltm pool pool-web monitor http members { 10.1.1.20:80 10.1.1.21:80 } # 6. 创建virtual server绑定traffic-group开启连接镜像 tmsh create ltm virtual vs-http destination 10.80.1.100:80 pool pool-web traffic-group tg-web mirror connection enabled上面命令的逻辑需要说明几点。type sync-failover这个设备组类型把配置同步和故障切换绑定在一起是最常用的组合。traffic-group tg-web决定了VIP归属哪个流量组切换时该流量组整体漂移。mirror connection enabled表示开启连接镜像备机上会同步主机的连接表切换时TCP连接可以继续存活。这里特别提醒mirror connection对吞吐量有影响如果业务对切换容忍度较高比如纯Web页面可以关掉镜像降低开销但像支付、上传类业务建议开启。创建完成后还需要执行一次配置同步。同步动作在主设备上执行# 将主设备当前配置手动同步到设备组中的所有设备 tmsh run cm config-sync to-group dg-f5 # 查看设备组同步状态确认同步成功 tmsh show cm device-group dg-f5to-group参数明确指定同步目标比直接使用config-sync全局同步更可控。首次部署时我建议手动执行同步不要依赖自动同步这样能直观确认两台设备之间的信任链路是否正常。同步完成后登录备机检查一下关键配置是否存在比如tmsh list ltm virtual vs-http能看到相同的VIP和pool定义。3.3 用一次切换验证配置是否真生效配置完成后不要直接认为高可用已经生效先做一次主动切换验证。在F5中强制主设备进入Standby状态的常见命令如下# 在主设备上执行让本机主动降级为standby tmsh run cm failover standby # 检查当前failover状态确认角色变化 tmsh show sys failover执行后观察两个现象一是主设备的show sys failover输出状态应从Active变为Standby二是备机的同一命令输出应变为Active。同时从客户端访问浮动VIP确认服务依然可用。如果VIP在切换后无法访问优先检查备机上VIP对应的pool是否有健康的成员、网关路由是否配置、ARP是否能正确学习到浮动IP。整个最小配置流程走完后你的F5双机冗余已经具备基础能力配置同步、状态检测、VIP漂移、连接镜像。但注意这距离真正的「全冗余」还有距离下一章展开讲全冗余到底要覆盖哪些层次。4. 全冗余解析从两台设备的HA到全链路无单点4.1 冗余层次对照表部件、设备、链路、网络与应用很多团队在验收F5双机项目时只验证了「主设备宕机后VIP漂移」这一个动作然后宣布高可用完成。但从真实的故障场景来看双机冗余解决的只是设备层冗余整条业务链路里还有其他单点。我把全冗余拆成六个层次每次做方案时对着这张表逐项排查会清晰很多。冗余层次关键对象实现方式最常见的疏漏部件级电源、风扇、硬盘双电源模块、冗余风扇、磁盘RAID双电源接到同一个PDU市电故障一起挂设备级两台F5设备Active-Standby 配置同步只建了设备对没验证配置同步链路级上联交换机、光模块、网线双上联、链路聚合、冗余端口光模块单点一根光纤断了整条路径失效网络级默认网关、三层路由、NAT浮动网关、双出口、BGP对等备机自带的网关路由和主设备不一致应用级会话、持久化、长连接连接镜像、持久化镜像镜像带宽不够切机后镜像丢包站点级整个机房或数据中心GSLB、DNS智能解析只有机房内双机没有跨站点容灾这个表里每一层都需要在方案设计时确认一次。部件级冗余通常由硬件形态决定采购时选双电源型号就能覆盖链路级冗余需要配合网络团队一起梳理F5的上联口和交换机下联口要接在不同交换机上避免一台交换机故障带走整条链路网络级冗余则要重点检查备机把VIP接管之后它的出向路由能不能正常工作很多非对称路由问题都是在这里埋下的。4.2 Active-Standby、Active-Active 与集群的取舍全冗余解析到设备形态时会面对三种常见方案Active-Standby、Active-Active、以及集群化部署。Active-Standby是最稳妥的默认选择配置简单、切换逻辑清晰、排障容易适合绝大多数生产环境。Active-Active则是把两台设备的资源分别承载不同VIP两台都是Active状态各自负责一部分流量这样两台设备的算力都被用上了但代价是配置复杂度翻倍切换时要清楚哪些资源绑在哪个流量组排障时也更考验对traffic group的理解。如果业务总量不大不建议为了利用率去做Active-Active一台备机常年空转不是浪费是高可用的必要成本。集群化部署是更进一步的形态通过虚拟化或专用硬件把多台设备组合成一个逻辑集群对外表现为单一负载均衡实体。这种方式适合超大规模流量场景但对运维能力要求很高故障域从设备级变成了集群级。对绝大多数业务而言Active-Standby已经能覆盖需求Active-Active适合有明确算力瓶颈的场景集群化则要慎重评估运维投入是否跟得上。4.3 全冗余中最容易漏掉的三处细节第一处是默认网关与非对称路由。F5的self IP接入三层网络后默认网关通常指向核心交换机的接口地址。主设备接管浮动VIP时入向流量正常到达但出向流量如果走了另一台设备的self IP就会出现流量从A进、从B出的非对称路径导致连接被中间设备丢弃。解决方式是在交换机上做VRRP或者让F5的self IP和浮动VIP都指向同一网关保证路径一致。第二处是镜像链路的带宽。连接镜像开启后主设备上的连接表会持续同步到备机这个同步流是有带宽消耗的。如果镜像流量和业务流量共用同一条拥塞链路高负载时镜像报文可能丢失导致备机上的连接表不完整切机后用户连接仍然会断。我的经验是镜像链路至少预留不低于业务峰值连接数的同步带宽独立VLAN传输最保险。第三处是管理网口与心跳网口的访问控制。有些环境为了安全把心跳链路放进防火墙策略里只放通特定端口结果F5之间的状态探测报文被防火墙拦截设备始终处于unknown状态。心跳探测协议和端口在不同版本上有差异配置防火墙放行规则前需要先确认版本对应的协议特征。要记住一句话冗余链路之间除了业务控制策略不要额外加安全设备去「把关」。5. 双机冗余部署的常见问题与避坑记录5.1 配置同步失效备机拿到旧配置现象切换测试时备机接管了VIP但VIP对应的pool为空或者pool里的成员还是已经下线了的旧地址业务直接中断。原因主设备上的配置变更没有同步到备机。常见情况是自动同步被关闭或者同步链路中断备机的配置停留在初始化时的状态。解决把「所有变更在主设备上进行、完成后手动执行一次config-sync」写成部署流程的固定步骤。每次变更后检查tmsh show cm sync-status的输出确认同步状态为绿色。另外建议定期把主备配置导出比对用文件差异对比工具检查是否存在分叉。同步是双机冗余的生命线这条线断了高可用就是空话。5.2 心跳误判引发的来回切换现象两台设备的状态在Active和Standby之间反复横跳VIP也在两台设备上来回漂移业务连接频繁中断。原因主备心跳链路不稳定常见于心跳流量意外混入业务链路业务高峰时拥塞导致探测报文超时或者心跳探测的两台设备之间经过了其他网络设备被链路震荡波及。解决将心跳链路改为独立物理直连或者放到不受业务影响的专用VLAN内。同时检查心跳报文的超时参数不同版本的默认超时值不同合理评估调大超时窗口给瞬时抖动留出余地避免心跳一抖就触发切换。我做这类排障时会先用抓包工具确认心跳报文收发是否连续再判断是链路问题还是参数问题。5.3 会话镜像未开启导致切换后全线掉线现象一次计划内切换演练备用设备成功接管VIP但所有在线用户的连接全部重置运维后台收到大量登录异常的反馈。原因virtual server上没有开启mirror connection备机没有主机的连接表。切换后客户端发起的TCP报文到达备机备机不认识这些连接只能回RST重置。解决对有状态业务支付、上传、长连接推送的virtual server开启连接镜像和持久化镜像。配置时注意mirror connection和persistence mirror是两件事前者管TCP连接状态后者管会话保持状态根据业务实际需求决定开启哪个。开启后要通过压力测试确认镜像对设备性能的影响在可接受范围内。5.4 主备版本不一致同步直接失败现象设备组同步状态持续异常配置同步时报错或者拒绝执行备机无法获取最新配置。原因主备系统的软件版本不一致备机版本较旧不支持主机上某些新版本的配置对象或irule函数。解决给设备组设定版本一致性要求升级时遵循「先备后主」的顺序先把备机升级到目标版本再手动切换让备机接管业务再升级原主设备。避免在版本不一致状态下强行同步也避免长期维持版本差异运行。每次设备版本变更后在变更记录里登记防止时间久了版本悄悄分化。5.5 错误的演练方式震停了生产流量现象工程师为了测试切换可靠性直接重启主设备上的TMM进程模拟故障结果备机接管后由于健康检查还没收敛流量出现短时黑洞生产报障。原因演练方式过激没有先评估备机的健康检查收敛时间。备机刚接管时它对pool成员的监控尚未完成第一次有效探测会暂时把成员标记为不可用。解决演练分梯队进行。第一梯队只做soft failover即run cm failover standby验证VIP漂移和基本连通性第二梯队再考虑重启TMM或者模拟掉电并且演练前通知业务方预留观察窗口。切换验证要循序渐进不要上来就用最暴力的方式测试。6. 把切换演练做成日常工作三次验证与一个回切模板双机冗余的验证不能一年做一次把切换演练做成周期性动作才能真正在故障来临时从容应对。我这里给出一套自己常用的验证节奏分三步。第一步是日常巡检每周看一眼tmsh show sys failover确认角色正常再查tmsh show cm sync-status确认配置同步没有积压。第二步是月度切换演练选择低峰期在主设备上执行run cm failover standby观察备机接管情况确认业务无感知后执行回切。第三步是季度深度演练模拟链路故障或TMM进程异常验证备机在更恶劣条件下的接管能力。# 日常巡检三段命令每次切换演练前必跑一遍 tmsh show sys failover tmsh show cm sync-status tmsh show sys mirror running回切操作也要有固定模板。现在active设备上确认业务状态正常然后执行run cm failover standby把流量切回原主设备再检查两台设备状态和同步状态。回切完成后别急着收工观察10到15分钟确认浮动VIP稳定在原主设备上镜像状态正常再宣布演练结束。这套流程跑顺之后切换动作在团队里就不再是高风险操作而是一个随时可以执行的标准动作。最后说一句经验之谈。我处理过一个生产环境看到配置同步时间戳和当前时间相差三个月当时就知道这个双机架构迟早要出问题。后来故障果然来了只不过不是设备宕机而是主设备做硬件维护时强制切机备机拿到的还是三个月前的配置。从那以后我把「配置同步时间戳检查」写进了所有F5巡检脚本里也建议你把同样的习惯建立起来——双机冗余不是买了两台设备就完事而是要让备机在每一刻都保持和主设备完全一致的配置和状态真正能接得住流量。希望帮到你。本文还有配套的精品资源点击获取
