企业官网建设流程全解析

简介：这份文档面向负责F5 BIG-IP运维与高可用架构设计的网络工程师，系统讲解双机冗余配置与全冗余解析，帮助解决设备故障时的流量切换与业务连续性问题。内容围绕串口心跳与网络心跳两种冗余方式展开，涵盖心跳线电平监控、TCP 1028端口心跳传递、Backup设备ARP广播触发流量切换等机制，并给出Network FailSafe、Floating IP与Failover Peer IP的配置示例，同时梳理实际常用的全冗余组网方式及其扩展性与成本权衡，还涉及BIG-IP对FailOver关键进程的监控与异常处理动作。资源包为1个doc文档，约240KB，结构紧凑，适合作为配置参考与排错思路手册。目前已有300人学习，适合需要掌握F5双机高可用部署与故障切换原理的中高级运维人员查阅。

1. 双机冗余不是“两台机器插上网线”那么简单

很多团队第一次做 F5 负载均衡的双机冗余配置，都会经历一个相似的翻车现场：两台设备都上架了，心跳线也接了，配置同步也显示成功，结果真到主设备断电那一刻，业务还是断了十几秒甚至更久。问题往往不在 F5 本身，而在于对“全冗余”这三个字的理解只停留在设备层面。

F5 的双机冗余，核心是 Active/Standby 架构下的故障切换能力。它要解决的是单台负载均衡设备成为整个业务链路单点的问题。适合谁？任何把 F5 放在生产入口、且业务中断成本高于两台设备采购成本的团队。但“全冗余”不只是设备冗余，还包括链路冗余、心跳冗余、配置同步冗余，以及最容易被忽略的——上游路由和下游服务器健康检查的联动。这篇笔记就按我实际落地的顺序，把双机冗余配置和全冗余解析拆开讲清楚，让你能照着复现，也能提前避开那些血泪坑。

2. 双机冗余的底层逻辑与选型：为什么 Active/Standby 仍是主流

2.1 双机冗余到底在冗余什么

F5 双机冗余的本质，是让两台设备对外表现为一个逻辑单元。常见做法是 Active/Standby：一台主设备承载全部流量，另一台待命，通过心跳检测主设备状态。主设备故障时，Standby 接管 VIP 和业务配置，继续提供服务。

这里有个反直觉的点：双机冗余并不等于“两台设备同时干活”。Active/Active 模式在 F5 上也能做，但它对配置一致性、会话同步和上游路由的要求高得多，稍有不慎就会出现流量回环或会话丢失。对于绝大多数业务场景，Active/Standby 是更稳妥的选择，因为它的故障边界清晰，排查路径短。

全冗余则是在 Active/Standby 基础上，把可能断掉的每一环都补上：

• 设备冗余：两台 F5，一主一备。
• 链路冗余：每台 F5 至少两条上联链路，分别接不同交换机。
• 心跳冗余：独立心跳线 + 网络心跳，避免单条心跳线故障导致双主。
• 配置同步：主设备配置变更后自动同步到备机，保证切换后配置一致。
• 健康检查联动：F5 对后端服务器的健康检查，要能触发 VIP 下线或切换。

只有这几层都覆盖到，才叫全冗余。只做设备冗余，链路一断，备机活着但业务照样不通。

2.2 选型理由：为什么不是“随便两台设备”

F5 双机冗余对设备型号没有强制要求完全一致，但强烈建议同型号、同版本。原因很实际：不同型号的接口数量、吞吐能力、SSL 处理能力不同，切换后备机可能扛不住主机的流量。不同软件版本之间，配置同步可能报错，甚至同步过去后部分配置不生效。

我一般会确认三件事再动手：

1. 两台设备软件版本一致，至少大版本相同。
2. 两台设备授权级别一致，特别是 SSL 和模块授权。
3. 心跳接口和业务接口分开，不要用业务口兼做心跳。

如果条件允许，备机配置可以比主机略高，但不要低。备机性能低于主机，切换后就是降级运行，业务感知可能比短暂中断更糟。

2.3 全冗余的拓扑长什么样

一个典型的全冗余拓扑是这样的：

• 两台 F5 通过独立心跳线直连，同时配置网络心跳作为备份。
• 每台 F5 的上联接口分别连接到两台不同的上游交换机。
• 每台 F5 的下联接口分别连接到两台不同的下游交换机。
• VIP 地址在主机上激活，备机通过配置同步和故障切换接管。
• 后端服务器双网卡分别接入下游两台交换机。

这个拓扑里，任意一台 F5、任意一条链路、任意一台交换机故障，业务都能继续。代价是布线复杂度和交换机端口消耗翻倍。值不值得做，取决于业务中断一分钟的损失是否高于这些硬件成本。

3. 双机冗余配置实操：从心跳到切换的完整命令

3.1 基础网络与心跳配置

先给两台设备配好管理 IP、业务 IP 和心跳 IP。以下命令在 tmsh 下执行，设备 A 为计划中的 Active，设备 B 为 Standby。

# 设备 A 心跳接口配置 create net vlan ha_vlan { interfaces { 1.1 { } } } create net self 192.168.100.1/24 { vlan ha_vlan allow-service { default } } # 设备 B 心跳接口配置 create net vlan ha_vlan { interfaces { 1.1 { } } } create net self 192.168.100.2/24 { vlan ha_vlan allow-service { default } }

逻辑说明：心跳接口用于两台设备之间交换健康状态和同步配置。allow-service { default }允许默认服务通过，包括心跳和配置同步所需端口。参数上，心跳 IP 必须同网段，且不要和业务网段重叠。如果心跳线直连，接口速率建议固定为 1000M 全双工，避免自协商出问题。

配置完成后，用ping验证两台设备心跳互通。如果 ping 不通，先查接口状态和 VLAN 配置，不要急着往下做。

3.2 设备组与信任关系建立

F5 双机冗余通过设备组（Device Group）和信任关系（Trust）来管理。先在两台设备上分别创建信任。

# 设备 A 上添加设备 B 为信任设备 create cm trust-domain /Common/trust_domain { ca-device /Common/device_a ca-device /Common/device_b } # 设备 B 上执行相同操作，指向设备 A create cm trust-domain /Common/trust_domain { ca-device /Common/device_b ca-device /Common/device_a }

逻辑说明：信任域建立后，两台设备才能交换证书和配置信息。ca-device指定对端设备名称，名称必须和设备自身的主机名一致。常见坑是设备主机名改过但信任域里没更新，导致同步失败。

建立信任后，用tmsh show cm sync-status查看同步状态。正常应显示两台设备都在信任域内。

3.3 创建故障转移组与流量组

故障转移组（Failover Group）决定哪台设备是 Active，流量组（Traffic Group）决定 VIP 在谁身上激活。

# 创建故障转移组 create cm failover-group /Common/failover_group { members { /Common/device_a { } /Common/device_b { } } active-bonus 10 network-failover enabled } # 创建流量组 create cm traffic-group /Common/traffic_group { ha-order { /Common/device_a /Common/device_b } auto-failback enabled failback-delay 60 }

逻辑说明：active-bonus给设备 A 更高的优先级，让它默认成为 Active。network-failover enabled表示网络故障也能触发切换，这是全冗余的关键。auto-failback enabled让主机恢复后自动切回，failback-delay 60延迟 60 秒，避免主机刚恢复还不稳定就切回。

参数怎么改：如果希望主机恢复后不自动切回，把auto-failback设为disabled。如果心跳不稳定，可以适当增大failback-delay。

3.4 VIP 与配置同步

把业务 VIP 绑定到流量组，并开启配置同步。

# 创建 VIP 并绑定流量组 create ltm virtual vs_web { destination 10.0.0.100:80 ip-protocol tcp pool pool_web profiles { http { } tcp { } } traffic-group /Common/traffic_group } # 开启配置同步 modify cm device /Common/device_a { configsync-ip 192.168.100.1 mirror-ip 192.168.100.1 }

逻辑说明：traffic-group指定 VIP 归属的流量组，故障切换时 VIP 会从主机漂移到备机。configsync-ip和mirror-ip用于配置同步和连接镜像。连接镜像能让已建立的会话在切换后继续，减少业务感知。

配置完成后，在主机上执行tmsh run cm config-sync to-group /Common/failover_group，把配置同步到备机。同步成功后，备机上应该能看到相同的 VIP 和 Pool 配置，但 VIP 不激活。

3.5 验证切换是否真的生效

配置做完不等于切换成功。我一般会做三次验证：

1. 手动切换：在主机上执行tmsh run sys failover standby，观察备机是否接管 VIP，业务是否中断。
2. 断心跳切换：拔掉心跳线，观察是否触发网络故障切换。
3. 断上联链路切换：断开主机上联交换机端口，观察是否切换。

每次验证都要记录业务中断时间。如果中断超过 3 秒，检查连接镜像和路由收敛配置。

4. 全冗余解析：链路、心跳与健康检查的联动

4.1 链路冗余怎么配才不断

链路冗余不只是多插一根网线。F5 上要做的是把上联接口加入同一个 VLAN，并配置链路聚合或生成树。常见做法是每台 F5 用两个接口分别接两台交换机，接口做 LACP 聚合。

# 创建链路聚合 create net trunk trunk_uplink { interfaces { 1.2 { } 1.3 { } } lacp enabled lacp-mode active } # 把聚合口加入业务 VLAN create net vlan business_vlan { interfaces { trunk_uplink { } } }

逻辑说明：LACP 主动模式能和交换机协商聚合，单条链路故障时流量自动切到另一条。注意两台交换机之间也要做堆叠或跨设备聚合，否则 F5 的聚合口两端接不同交换机，可能协商失败。

4.2 心跳冗余：独立心跳线加网络心跳

独立心跳线断了，如果只有一条心跳，两台设备会互相认为对方故障，出现双主。双主比单点故障更可怕，因为两个 VIP 同时激活，上游路由混乱。

解决办法是配置网络心跳作为备份。在故障转移组里启用network-failover，并确保管理网或业务网也能互通心跳。

modify cm failover-group /Common/failover_group { network-failover enabled }

同时，心跳接口和网络心跳不要走同一条物理链路。独立心跳线走直连，网络心跳走管理网，两者物理路径分离。

4.3 健康检查联动 VIP 下线

后端服务器全挂时，F5 默认不会切换，因为设备本身是好的。但业务已经不可用。全冗余要求健康检查能触发 VIP 下线或切换。

# 创建健康检查 create ltm monitor http monitor_web { destination *:80 send "GET /health HTTP/1.1\r\nHost: example.com\r\n\r\n" recv "200 OK" interval 5 timeout 16 } # 绑定到 Pool modify ltm pool pool_web { monitor monitor_web }

逻辑说明：interval 5每 5 秒检查一次，timeout 16超时 16 秒。如果所有成员都不可用，Pool 状态变为 down，VIP 可以配置为 down 时触发故障转移。这需要在虚拟服务器上设置service-down-action。

参数怎么改：健康检查间隔太短会增加服务器负担，太长会延迟故障发现。一般 5 到 10 秒比较平衡。超时时间要大于服务器正常响应时间，避免误判。

5. 避坑与排查：双机冗余最常见的五个翻车点

5.1 配置同步成功但切换后配置不生效

现象：备机显示同步成功，切换后部分 VIP 或 Pool 不存在。

原因：配置同步只同步已提交的配置，未提交的变更不会同步。另外，设备组里没有包含的对象不会同步。

解决：同步前执行tmsh save sys config，确保配置已保存。检查设备组是否包含所有相关对象，必要时手动添加。

5.2 双主：两台设备同时 Active

现象：两台设备都显示 Active，VIP 冲突，业务时通时断。

原因：心跳线故障且网络心跳未启用，两台设备互相认为对方挂了。

解决：立即断开一台设备的业务口，恢复心跳后重新同步。预防措施是启用网络心跳，并确保心跳路径物理分离。

5.3 切换后会话丢失，用户被强制重新登录

现象：切换后已登录用户掉线，需要重新认证。

原因：连接镜像未配置或镜像 IP 不通。

解决：检查mirror-ip配置，确保两台设备镜像 IP 互通。对于 HTTPS 等长连接，连接镜像能显著减少感知。

5.4 自动切回导致业务抖动

现象：主机恢复后自动切回，业务短暂中断。

原因：auto-failback启用且failback-delay太短。

解决：增大failback-delay到 120 秒以上，或关闭自动切回，改为手动切换。

5.5 健康检查误判导致 VIP 下线

现象：后端服务器正常，但 F5 认为不可用，VIP 下线。

原因：健康检查字符串和实际响应不匹配，或超时太短。

解决：用curl手动验证健康检查 URL 的响应，调整send和recv字符串。超时时间至少设为正常响应时间的 2 倍。

6. 进阶技巧：用 iRules 和 SNMP 把切换做成可观测

双机冗余配置完成后，最怕的是“切换了但没人知道”。我一般会加两样东西：iRules 记录切换事件，SNMP 告警推送到监控。

先看 iRules，在切换时往日志里写一条带时间戳的记录：

when CLIENT_ACCEPTED { if { [active_members pool_web] == 0 } { log local0. "POOL_DOWN: pool_web has no active members at [clock format [clock seconds]]" } }

逻辑说明：active_members返回当前活跃成员数，为 0 时写日志。log local0.输出到本地日志，方便后续用 syslog 收集。参数上，local0是日志级别，可以根据需要改成local1或local2。

再配 SNMP 告警，让监控系统能收到切换事件：

# 配置 SNMP 告警目标 modify sys snmp { agent-address 10.0.0.200 sys-contact "ops-team" sys-location "dc-1" } create sys snmp traps { traps { snmp_trap_destination 10.0.0.201 { community public port 162 } } }

逻辑说明：agent-address是 F5 的 SNMP 代理地址，snmp_trap_destination指定告警接收服务器。F5 会在故障切换、心跳丢失、Pool 全挂时发送 trap。监控系统收到后可以自动触发工单或通知。

验证方法：手动执行tmsh run sys failover standby，观察监控系统是否收到 trap。如果没有，检查 SNMP 社区字符串和防火墙端口。

最后一个技巧是关于切换时间的测量。我习惯在业务侧部署一个每分钟请求一次 VIP 的探针，记录响应时间。切换发生时，探针会记录到一次超时或延迟尖峰。这个数据比 F5 自身的日志更接近真实用户体验。多次切换测试后，你会得到一个切换时间基线，比如 2.3 秒。以后任何配置变更后，再测一次，如果切换时间明显变长，说明某处配置退化了。

这些年来我最大的教训是：双机冗余的配置本身不难，难的是每次变更后都重新验证切换。很多团队配好之后就不再碰，直到真出故障才发现某个新加的配置没同步过去。我现在养成的习惯是，任何涉及 VIP、Pool、路由的变更，变更后必须做一次手动切换验证，并记录切换时间。这个习惯帮我提前发现了至少三次配置同步遗漏。

希望帮到你。

本文还有配套的精品资源，点击获取