企业官网建设流程全解析

简介：面向F5 BIG-IP运维与网络高可用学习者的技术文档，围绕负载均衡双机冗余与全冗余解析展开，适合需要理解Active/Backup切换机制、规划高可用架构的初中级网络工程师参考。压缩包内共1个doc文件，约240KB，以专题文档形式集中梳理串口心跳与网络心跳两类冗余方式，并说明串口线电平检测、TCP 1028端口心跳、ARP广播触发流量切换等关键流程。内容还涉及Network FailSafe配置思路、Floating IP与Failover Peer IP设置、Redundancy Properties状态查看及System Fail-safe设置，同时讨论实际常用的全冗余组网及其扩展性、成本与交换机端口瓶颈。文档对BIG-IP关键进程监控与故障触发动作也有归纳，可帮助读者建立从心跳链路、地址漂移到进程级故障切换的完整排错框架，并对照检查双机冗余与全冗余部署中的配置盲点，提升故障定位与方案选型效率。已有300人学习。

1. 单机撑不住的那一刻：F5 负载均衡的双机冗余到底在解决什么

给 F5 负载均衡做高可用，很多人的第一反应是照着四层交换机的老经验上 VRRP：配个虚拟路由，一主一备，收工。真到 BIG-IP 上会发现这条路对不上——F5 的双机冗余不走 VRRP，它靠串口心跳线上的电平和 TCP 1028 端口上的心跳报文，由设备自己判断"对面还活着吗"，再决定要不要把浮动 IP 和 VS 抢过来。这套机制决定了三件事：切换多快、会不会双主、切完业务闪不闪断。做方案的人如果没把这三件事讲清楚，验收时一句"拔根线试试"就能让整套设计露馅。这篇讲的是一套可以直接照着配、照着验的双机冗余方案，适合要交付机房方案或做网络方向课设的人。

2. 两条心跳链路：串口电平心跳与 TCP 1028 网络心跳的判定差异

双机冗余的骨架其实就一句话：每台设备持续判断对端是不是还活着，一旦判定"对面没了"，就把自己从 Backup 提成 Active，并把所有 VS 和浮动 IP 通过 ARP 广播出去，告诉上下游"这些地址现在在我这边"。判断"对面活着没"的手段，F5 给了两条路——串口和网络。两者切换动作完全一样，差在信号怎么传、距离能拉多远、出问题时你能看到什么。

2.1 串口心跳：一根线上只有电平，没有报文

串口心跳是 F5 官方推荐的冗余方式，也是很多人第一次接触时最不适应的地方：两台 BIG-IP 之间用设备自带的串口线直连，线上跑的不是任何协议报文，而是电平。Active 设备负责在心跳线上持续产生一个高电平，Backup 设备一直监听这根线；当 Backup 监听到高电平消失，就认定对端已经不具备服务能力，立刻把自己切成 Active，然后对外发 ARP 广播，把 VS 和浮动 IP 全部宣告到自己这一侧，引发流量切换。

这套机制的好处是极简——没有协议栈、没有超时协商、没有报文丢失重传，一根线一个电平，判断逻辑短到几乎不会出错。代价也很明显：第一，串口线很短，官方给的限制是 50 英尺，两台设备必须摆得很近，跨机柜、跨楼层就别想了；第二，这根线上没有任何数据信号，意味着你排障时看不到"心跳质量""丢包率""延迟"这类指标，只有"有电平"和"没电平"两种状态，出问题是黑匣子式的；第三，电平判定是硬判断，线松了、串口模块坏了，都会被当成对端宕机，误切的风险要靠物理连接的可靠性来兜。

2.2 网络心跳：把"你还在吗"放进 TCP 1028

两台设备离得远的时候，串口线就废了，这时改用网络心跳：两台 BIG-IP 之间用网线连接，通过 TCP 的 1028 端口传递心跳信号。切换过程跟串口版是同一个剧本，只是把电平换成了报文：Active 侧持续产生心跳信号，Backup 侧监听；Backup 在一定时间内收不到心跳，就判定对端失联，把自己切换为 Active，同样对外发 ARP 广播宣告 VS 和浮动 IP。

差别在于"一定时间内"这四个字。串口是电平消失即刻触发，网络心跳必须有一个超时窗口，窗口太短会在网络抖动时误切，太长会让真实故障的切换时间被拉长。配置网络心跳时，要在 Network FailSafe 里指定一个 VLAN 专门承载心跳信号，这个 VLAN 通常是两台 BIG-IP 之间的独立直连 VLAN，或者 Internal VLAN。我一般强烈建议走独立直连：把心跳塞进业务 VLAN 里，等于让心跳和业务共享同一条命，业务侧一个广播风暴或 STP 收敛，心跳跟着抖，双机就开始互相猜疑。

2.3 四条切换动作与两种方式的选型边界

不管走哪条路，一次完整的切换都是同样的四步，这四步也是后面所有排障的对照基准：

选型上给一个朴素结论：两台设备在同一机柜、追求最快最稳的切换，用串口心跳；跨机柜、跨机房、或者机柜位置将来会动，用网络心跳。两者并不互斥，实际项目里我见过同时配两条的，串口做主判定、网络做备份判定——但这时候要想清楚"两条同时失效才切换"还是"任一条失效就切换"，否则会掉进第 5 章要讲的坑里。

3. 配置落地：心跳 VLAN、Floating IP、Peer IP 与 FailSafe 的配置顺序

配置这件事最怕顺序错。同一个功能，先配地址再建 VLAN，和先建 VLAN 再配地址，结果可能一样，但排障成本差很远。这一章按"物理连接 → VLAN → 地址 → 心跳对端 → FailSafe → 进程监控"的顺序走一遍，每一步都说明白为什么要这么做、参数怎么改。

3.1 先定心跳 VLAN：独立链路还是 Internal

物理上先把两台设备的心跳口用网线直连，然后把这个口划进一个独立 VLAN。心跳 VLAN 的选型只有两个答案：独立直连 VLAN，或者复用 Internal VLAN。独立直连的好处是心跳路径上只有心跳流量，任何业务侧的异常都污染不到它，坏处是每台设备要多占一个口；复用 Internal 省端口，但等于把心跳和后台服务器流量绑在一条线上，后台一拥塞，心跳延迟就上去了。

配置时给 VLAN 打一个不会和业务冲突的 tag，习惯上用靠近上限的值，比如 4094，这样一眼就能在配置里认出它是心跳专用。下面是心跳 VLAN 与心跳地址的最小配置骨架，命令用 tmsh 表示：

# 心跳 VLAN：把两台设备直连的物理口 1.1 划进来，tag 4094 避免与业务 VLAN 冲突 tmsh create net vlan ha_vlan tag 4094 interfaces add { 1.1 { } } # 心跳地址（Self IP）：两台设备各配一个同网段地址，只用于心跳，不承载业务 tmsh create net self 10.255.0.1/30 vlan ha_vlan allow-service default # 备份设备上执行对应的一条，地址换成 .2 # tmsh create net self 10.255.0.2/30 vlan ha_vlan allow-service default

这几条命令里，tag 4094决定心跳帧在交换机上走哪个广播域，如果两台设备是直连而非过交换机，tag 是否一致不影响连通性，但建议保持一致，方便将来改成过交换机时不用返工；/30是够用的最小网段，心跳只需要两个地址；allow-service default表示这个 Self IP 允许承载管理类服务，心跳本身不需要开业务端口。地址配完先互 ping 一次，通了再往下走，这一步省掉，后面所有现象都会指向错误的方向。

3.2 Floating IP 与 Failover Peer IP 的配置顺序

心跳通了之后才配地址对。这里有两个容易混的概念：Floating IP 是"跟着 Active 走"的业务地址，也就是切换时被 ARP 广播出去的那批地址；Failover Peer IP 是"告诉本机，对端的心跳地址是哪个"，用于网络心跳的报文投递。前者决定业务能不能接上，后者决定设备能不能互相看见。

顺序上先配 Floating IP，再配 Peer IP。Floating IP 挂在 traffic-group 上，一个 traffic-group 可以带一组浮动地址；配完之后在设备上确认这些地址当前归属哪台设备，正常情况下应该全部在 Active 侧。Peer IP 则是在设备对象上填对端的地址，GUI 里就是 Failover Peer IP 那一栏，底层对应的是设备对象的单播地址配置。两者填错一个，典型现象是心跳显示正常但切换后业务不通，或者切换动作压根不触发。

# 1) 浮动地址：业务地址挂在 traffic-group 上，切换时随 Active 走 tmsh modify cm traffic-group traffic-group-1 floating-ips add { 192.168.100.10 } # 2) 心跳对端：把对端设备的心跳地址告诉本机（GUI 中即 Failover Peer IP） # 不同版本命令字有差异，配完用 tmsh list cm device 核对，别只信回显

参数上要盯住两点：Floating IP 必须和业务网段同网段，否则上下游的 ARP 学不到；Peer IP 必须填对端心跳 VLAN 上的地址，不是管理地址，也不是业务 Self IP。这一点踩坑率极高——管理网通、业务网通，唯独心跳地址填成了管理地址，表面上一切正常，真拔线时才发现判定源根本不通。

3.3 Network FailSafe 与 Redundancy Properties 状态核对

Network FailSafe 的作用是给心跳 VLAN 加一道保险：当承载心跳的 VLAN 本身失效（比如直连线的对端口 down 了），设备能感知到"我连心跳路径都没了"，从而触发相应动作。配置入口在 System → System Fail-safe，把心跳 VLAN 勾选为监控对象。

配完不要急着测切换，先去 System → Redundancy Properties 看状态。这个页面能看到当前设备是 Active 还是 Backup、对端是否可达、traffic-group 的归属。我的习惯是把这一步做成检查清单：

这一步的意义在于把问题掐死在"还没上业务"的阶段。等到业务跑起来再发现双 Active，那就是生产事故，不是配置练习了。

3.4 进程监控：把 System Fail-safe 的动作定下来

设备活着不等于服务活着。BIG-IP 内部有一批关键进程，F5 对这些进程做了严格监控，一旦某个进程无响应或起不来，系统可以按预先设定的动作处理。可选动作有四种：切换到备份设备、重启故障设备、重启异常进程、不做处理。这四种动作的代价完全不同，选错比不配更糟。

我一般的做法是：只对真正影响转发面和管理面的核心进程配"切换"或"重启进程"，其余一律"不做处理 + 告警"。把所有进程都配上切换，等于给设备装了一个随时会误判的开关，一个非关键进程抖动就把整个业务甩到备机，这种设计在评审时是站不住的。

4. 触发源全景：从设备级心跳到进程级监控的判定叠加

配到这一步，设备其实已经有好几个"可以触发切换"的理由了：心跳线断了、心跳 VLAN 失效了、关键进程挂了。多个触发源叠在一起，最容易出的问题不是"不切"，而是"乱切"。这一章把这些触发源摊开，讲清楚谁优先、怎么防抖。

4.1 三层触发源的关系

第一层是链路级：串口电平消失，或网络心跳超时。这是最快的判定，通常在秒级完成。第二层是 VLAN 级：Network FailSafe 监控到心跳 VLAN 失效，这层比链路级更"宏观"，它管的是整条路径。第三层是进程级：System Fail-safe 监控到关键进程异常，这层最慢，因为它要等进程真正无响应或起不来。

三层不是并列的开关，而是越往下越"重"：链路级切换只动地址归属，进程级动作可能带设备重启。所以配置时要做减法——链路级交给心跳，进程级只保留最核心的几个，中间层按需。全都开满，等于给自己埋了一堆误触发点。

4.2 防抖：为什么切换不能太灵敏

网络心跳的超时窗口就是最原始的防抖。窗口设得太短，业务侧一次短暂拥塞就能让 Backup 认定对端已死，然后两边同时认为自己是 Active，形成双主；窗口设得太长，真实故障时切换时间被拉长，前端用户已经超时了，备机还没接管。

进程监控同理。进程重启本身需要时间，如果监控周期比重启时间还短，会出现"刚拉起又被判定异常"的循环，设备在这种循环里反复执行切换动作，日志刷得飞快，业务断续。我通常会把监控周期设成明显大于进程正常重启耗时的值，并且对同一个进程配置连续失败次数的门槛，而不是一次失败就动手。

4.3 用一次演练把触发源验证清楚

光看配置页面看不出触发源之间的关系，必须做实打实的演练，而且要分项做：只拔串口线、只断心跳 VLAN、只停一个被监控的进程，分别观察切换是否发生、耗时多少、业务是否闪断、日志里是谁先报的警。三项分开做一遍，再看叠加情况——比如心跳断了的同时进程也异常，设备是按哪个理由切的。

演练的价值不在于"证明它能切"，而在于"证明它只在该切的时候切"。这一点在后面第 6 章的验收表里会落成具体条目。

5. 全冗余组网与容量边界：L2 堆叠、Trunk 捆绑与交换机瓶颈

单看两台设备的主备，只解决了"设备坏了怎么办"，没解决"线断了怎么办""端口不够怎么办"。实际项目里更常见的是全冗余组网：BIG-IP 的每个业务口都分成两条腿，分别接到两台（或一组堆叠的）L2 交换机上，交换机侧做堆叠，服务器双网卡分别接两台交换机。这样任何一条线、任何一个交换机端口、任何一台交换机整机挂掉，业务都还能走另一条腿。

5.1 全冗余拓扑的两条腿

拓扑描述起来不复杂：两台 BIG-IP 做主备，每台的上行/下行各出两个口，分别接入两台 L2 交换机的对应端口；两台交换机做堆叠，逻辑上是一台设备；后台服务器如果双网卡，也分别接两台交换机。这个结构的好处是扩展性——交换机可以通过堆叠无限扩展端口，后台服务器群规模可以做得很大，为大批量服务器做负载均衡时端口数量不再是瓶颈。

扩展性之外还有性能前提：如果用的是性能良好的千兆扩展交换机，在保证连接速度和质量的前提下，可以同时为大批量服务器提供负载均衡，应用的并发连接处理能力和响应速度都会明显提升。这句话反过来读就是：交换机选型不到位，全冗余只是把单点故障换成了集体瓶颈。

5.2 端口能堆叠，流量堆不起来

这是全冗余方案里最容易被忽略的一句实话：扩展交换机增加的是后台服务器群的接入数量，提高的是并发连接的处理能力，但它不能提高网络流量的处理能力。后台服务器数量堆到一定程度，扩展交换机会先成为瓶颈，而不是 BIG-IP 先撑不住。

所以上行链路要提前规划捆绑。通常的做法是把扩展交换机的多个千兆口做成 Trunk，以链路聚合的方式与上级的 BIG-IP 3400 连接，用多链路分担流量，抬高整条上行通道的吞吐上限。这里的前提是交换机端口和 BIG-IP 端口都要支持聚合，且两端的聚合模式要匹配——一端做静态聚合、另一端做动态协商，链路起不来或者只有一条在工作，是这类方案里最常见的翻车点。

5.3 成本与选型的账

全冗余的缺点也很直接：部署成本高。如果后台服务器普遍使用千兆网卡，交换机就必须配相对高端的全千兆设备，用低端二三层交换机的端口去接千兆网卡，端口速率不匹配带来的丢包和效率下降，会让整套负载均衡的效果打折。这一条在预算评审时最容易被砍，砍完之后的典型症状是：平时跑得好好的，压测一上来就开始丢包，查半天查不出配置问题。

我的建议是把选型账算在前面：先按后台服务器数量和单机并发估算总连接数，再按业务峰值估算总吞吐，两个数字分别对照交换机的背板能力和上行的 Trunk 带宽，任何一个不满足，就在方案里写明这是已知瓶颈，而不是等到上线后被动解释。

6. 避坑清单：五类最容易翻车的现象、原因与处置

6.1 心跳显示正常，拔线却不切换

现象是 Redundancy Properties 里两台设备互相可见、状态一主一备，但真把心跳线拔掉，备机纹丝不动。原因通常有两个：一是 Failover Peer IP 填成了管理地址，心跳报文实际没走在心跳 VLAN 上；二是 Network FailSafe 里没有勾选心跳 VLAN，线断了设备感知不到这条路径已失效。处置方法是先在心跳 VLAN 内互 ping 验证二层连通，再逐一核对 Peer IP 与 FailSafe 监控对象，两项都对齐后再做拔线演练。

6.2 两台设备同时宣称自己是 Active

现象是上下游 ARP 表剧烈抖动，业务时通时断，两台设备的状态页都显示 Active。原因是心跳判定窗口太短，网络轻微抖动就让备机误判对端已死；或者两台设备的心跳配置不对称，一边能收到心跳、另一边收不到。处置时先把超时窗口放大到能覆盖正常抖动，再逐项比对两侧的心跳 VLAN、地址段、Peer IP 是否完全对称，最后检查是否存在两条心跳路径但判定策略写成了"任一失效即切换"。

6.3 切换成功，业务却闪断几秒

现象是切换动作正确执行、新 Active 也拿到了浮动 IP，但前端有明显闪断。原因是第 4 步的 ARP 广播没有被上下游及时接受——上游路由或交换机的 ARP 缓存还没过期，仍然把流量往老设备送；或者下游服务器的网关 ARP 表没刷新。处置方式是缩短上游设备的 ARP 老化时间、确认浮动 IP 的广播范围覆盖到所有相关网段，并在验收时把"切换后业务恢复时间"作为独立指标测量，而不是只看"切换是否发生"。

6.4 进程监控把好设备切走了

现象是业务本身没问题，但设备频繁切换，日志里能看到某个进程被反复判定异常。原因是给非关键进程配了切换动作，或者监控周期短于进程正常重启耗时，形成"判定异常—重启—再判定异常"的循环。处置是把动作降级为"重启进程 + 告警"，只对真正影响转发的核心进程保留切换动作，同时把监控周期调到明显大于进程重启耗时，并加入连续失败次数门槛。

6.5 堆叠做完，带宽不升反降

现象是全冗余组网完成后，端口数量上去了，但压测吞吐反而比单链路时更低，偶发丢包。原因是上行 Trunk 两端聚合模式不匹配，实际只有一条链路在工作；或者扩展交换机本身是低端设备，端口与服务器千兆网卡速率不匹配，拥塞时先丢包。处置是逐条核对聚合配置的两端模式与哈希方式，用流量验证每条成员链路都在承载；同时核对交换机端口速率与背板能力，不满足就如实写进方案的已知限制。

7. 验收与答辩：用一张切换演练表把方案钉死

这套方案能不能交，不取决于配置页面多漂亮，取决于你能不能当着评审的面把每一次切换复现出来。我一般准备一张演练表，分项做、分项记，做完这张表，方案里 90% 的争议都会自动消失。

表格里最容易被忽略的是最后两行。很多人只测"切过去"，不测"切回来"，结果演练当天切得干净利落，回切时发现浮动 IP 卡在备机、ARP 表半天不刷新，场面很难看。回切必须单独作为一项，而且要记录耗时。

答辩环节通常会被问三个点，提前想清楚能省很多解释。第一，为什么选串口心跳而不是网络心跳——答距离、判定速度、官方推荐三者之间的取舍，不要说"因为默认"。第二，切换时间是多少、怎么测的——给具体数字和测量方法，不要给"很快"。第三，全冗余的瓶颈在哪——老实承认扩展交换机的吞吐上限，并说明 Trunk 捆绑和千兆全端口选型是怎么缓解的，比强行说"没有瓶颈"可信得多。

从那以后我每次做双机冗余的方案，不管客户催得多急，都会强制走一遍"配完 → 状态核对 → 分项演练 → 填表"这四步，一步不省。因为这套东西的坑几乎全在"看起来正常"的阶段，你不主动去拔那根线，它就永远等着在业务高峰期替你拔。希望这套结构能帮到你，照着改地址段就能用。

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