F5一台服务器故障时，健康检查会迅速标记其为宕机，Big-IP自动将新建连接和现有连接（根据会话保持策略）都导向其他健康成员，核心操作是检查Pool的健康监视器配置以及成员的启用状态，确保故障节点被自动隔离。
F5负载均衡器故障转移设置：自动切换的工作原理
F5 BIG-IP的故障转移不依赖“心跳线”或人工干预，而是依靠Pool成员的健康状态，每个Pool绑定了健康监视器（Monitor），监视器以特定频率向成员发送探测请求（如TCP ping、HTTP GET、SSL握手等），当连续几次探测失败，监视器就将该成员标记为“down”，BIG-IP立即将其从负载均衡候选列表中移除,新建连接全部转发到其他up状态的成员。
健康监视器类型与影响
- ICMP监视器：仅检查网络层可达性,无法识别应用层故障。
- HTTP监视器：发送指定URL请求，检查返回状态码或内容,能发现Web服务挂死。
- TCP半开监视器：只检查端口是否开放,节约资源但精度有限。
- 自定义监视器：通过外部脚本或扩展内容验证,适合复杂业务逻辑。
行业共识认为，生产环境至少使用HTTP监视器并设置合理的超时和重试次数,避免将仍在处理请求但接受新连接缓慢的节点误判为正常。
自动切换的触发条件
- 监视器连续失败次数达到预设阈值（如3次，间隔5秒）。
- 成员状态变为“down”（红色）。
- 如果Pool中有多个成员，BIG-IP将流量均匀分配到剩余健康成员；如果全部成员宕机,则返回自定义错误页面或指向备用Pool。
会话保持对故障转移的影响
- 源地址保持：客户端IP hash到同一成员，该成员宕机后，hash会重新计算，请求被分配到新成员，对用户无感知（但可能丢失会话状态）。
- Cookie插入：BIG-IP在响应中插入cookie记录成员，成员故障后，cookie失效，查询将重新分配,通常不影响业务。
- SSL会话ID保持：SSL会话缓存存放在成员上，故障后需要重新握手，但有BIG-IP的SSL卸载功能可以在设备端维持会话。
F5健康检查配置：精准监控服务器状态
配置健康检查是确保故障转移可靠的关键，在BIG-IP GUI中，路径为 Local Traffic → Monitors,或使用tmsh命令。
创建基本HTTP监视器
- 点击Create,选择Type为HTTP。
- 设置Interval（探测间隔，建议5-10秒）和Timeout（超时时间，建议16-31秒）。
- 设置Send String：如
GET /health.html HTTP/1.1rnHost: www.example.comrnrn。 - 设置Receive String：期望返回的正文内容，如
ok，如果响应中包含该字符串,则认为健康。 - 关联到Pool：在Pool的Health Monitors中添加该监视器。
高可用性配置建议
- 多监视器组合：一个Pool可以绑定多个监视器，BIG-IP默认所有监视器都通过才认为节点健康，例如同时使用ICMP和HTTP,避免网络层通但应用层挂的情况。
- 主动监视器与被动监视器：如TCP监视器作为基础，HTTP监视器深入验证,减少误判。
通过tmsh快速配置
tmsh create ltm monitor http my_http_monitor interval 5 timeout 16 send "GET /health HTTP/1.1rnHost: example.comrnrn" recv "OK" tmsh modify ltm pool my_pool monitor my_http_monitor
配置后，等待几个探测周期,即可在Pool状态中看到成员健康状态变化。
手动将故障服务器流量移走：自动失效时的应急操作
虽然自动切换是常态，但某些场景需要手动干预：监视器配置错误导致节点未下线，或需要临时移除节点进行维护,下面是两种最直接的方法。
通过GUI强制禁用成员
- 进入 Local Traffic → Pools → Pool Members。
- 找到目标成员，点击右侧的“Disable”或“Force Offline”。
- Disable：允许已有连接完成，但不再接受新连接（常用于优雅下线）。
- Force Offline：立即中断所有连接，不再接受新连接（用于紧急隔离）。
通过tmsh命令快速操作
# 禁用成员（优雅）
tmsh modify ltm pool my_pool members modify { 192.168.1.10:80 { state user-down } }
# 强制离线
tmsh modify ltm pool my_pool members modify { 192.168.1.10:80 { state user-up session user-disabled } }
之后检查成员状态,确认流量已转移。
一次性移除所有流量到特定节点（BIG-IP版本14+）
tmsh modify ltm pool my_pool members modify { 192.168.1.10:80 { priority-group 9 } }
将优先级组调高，使其成为备份节点,仅当主节点全部故障时才接收流量。
验证故障转移是否生效的三个关键方法
配置完成后，必须验证才能确保故障转移真实有效。据统计,相当一部分故障转移失败案例源于配置后未验证或验证方法本身不严谨。
监控Pool成员状态
- 通过GUI实时查看 Pool Status 列,确认成员变红或绿。
- 使用tmsh命令：
tmsh show ltm pool my_pool members，查看Monitor Status字段。
模拟故障测试
- 停止服务：在目标服务器上关闭Web服务进程（如systemctl stop nginx）。
- 观察切换：使用持续请求工具（如curl间隔请求）或直接看BIG-IP日志，日志路径：
/var/log/ltm类似pool member 192.168.1.10:80 monitor status down。 - 检查业务连续性
：在故障期间，原本指向该节点的请求是否被正常转发到其他节点,可以通过在两台服务器上部署不同页面内容来验证请求路由。
查看连接统计
- GUI中进入 Statistics → Module Statistics → Local Traffic，查看Pool的
Active Connections和Connection Transitions，确认故障节点连接数归零,其他节点连接数上升。
常见问题与解答
F5一台服务器故障后，已经建立的连接会断开吗？
这取决于BIG-IP的会话保持类型和故障转移策略，如果使用源地址保持，故障节点上的连接会被中断，客户端需要重新发起请求，新请求会分配到其他节点，如果使用Cookie插入且应用支持会话复制，连接可以无缝迁移，对于TCP/UDP流量，使用BIG-IP的TCP连接复用功能可以在故障时保持连接不中断,但需要额外配置。
为什么健康检查显示节点正常，但业务却报错？
常见原因是监视器探测的内容和实际业务不一致，例如监视器只检查了/health.html，但实际业务依赖于数据库或缓存服务，当依赖服务故障时，节点仍可能返回200但内容错误，建议使用自定义监视器模拟真实业务请求，并检查返回内容的完整性,而不仅仅是状态码。
手动禁用成员后，如何重新启用？
在GUI中点击成员，选择“Enable”或通过tmsh命令：tmsh modify ltm pool my_pool members modify { 192.168.1.10:80 { state user-up } }，如果之前是user-down，改为user-up；如果session user-disabled，改为session user-enabled，启用后监视器会重新探测,节点状态恢复为绿色。
核心结论：F5服务器故障转移依赖健康监视器的精准配置和合理阈值，自动切换是默认行为，手动操作作为补充，定期验证监视器有效性、模拟故障测试,是保持高可用的关键。
首发原创文章，作者：王坚，如若转载，请注明出处：https://test.idctop.com/article/513451.html
