负载均衡f5配置

F5的负载配置界面长得像九十年代的遗留物，但你别小看它。均衡我见过太多团队在LTM（本地流量管理器）上栽跟头，负载不是均衡不会配，而是负载配的时候脑子里没图景。你敲下tmsh命令或点开GUI的均衡瞬间，得清楚流量是负载怎么流进、穿过、均衡流出的负载——这才是关键。

拿最基础的均衡虚拟服务器（Virtual Server）来说。你在上面定义一个IP和端口，负载比如10.0.0.10:443，均衡底下挂一组真实服务器（Pool Member），负载像是均衡192.168.1.2和192.168.1.3，端口都是负载8443。默认轮询算法下，F5会把新连接轮流扔给这两台机器。听起来简单？可一旦你加了SSL卸载，F5就得先做一次TLS握手，把HTTPS流量解密成HTTP，再转发给后端。这时候你如果忘了在客户端SSL配置里导入证书，或者没在HTTP Profile里开启X-Forwarded-For头，后端应用拿到的客户端IP全是F5自己的——排查问题能让你疯掉。

我印象最深的一次故障，是某电商大促前夜，节点健康检查突然全红。运维同事盯着F5面板，看Pool Member状态从UP变DOWN，又变UP，像心跳图一样抖动。最后发现是健康检查的路径写错了——F5默认用GET请求去探/，但他们的应用实际需要访问/healthz才返回200。就这么一个字符差异，导致F5不断把流量从故障节点摘除又加回，后端日志里全是连接重置。改一行配置，三分钟解决，但那一晚的紧张感我到现在还记得。

说到配置技巧，iRule是F5的灵魂。它像一段嵌入在流量路径里的小脚本，能让你做精细控制。比如你只想让来自特定IP段的请求访问某个Pool，其他一律返回403，用iRule几行就搞定：

when HTTP_REQUEST {  if {  [IP::addr [IP::remote_addr] equals 10.0.0.0/8] } {  pool internal_pool } else {  HTTP::respond 403 content "Forbidden" } } 

这玩意儿灵活，但也危险。生产环境里我见过有人写了个死循环iRule，直接把F5的CPU打到100%，整个站点瘫痪。所以我的习惯是，任何iRule先在一个测试虚拟服务器上跑几天，观察日志和性能计数器，确认没问题再上生产。

持久性（Persistence）是另一个容易踩坑的地方。默认情况下，F5按连接分发流量，但HTTP是无状态的——用户点击一次页面可能建立多个连接。如果你做的是购物车应用，用户把商品加到购物车后刷新一下，请求被分到另一台后端，购物车信息全没了。这时候你得启用源地址持久化（Source Address Persistence），让同一个客户端IP始终落到同一台服务器上。但别滥用——如果整个公司出口只有一个公网IP，那所有员工都会被钉在一台服务器上，负载均衡直接失效。更精细的做法是用HTTP Cookie持久化，让F5在响应里植入一个加密Cookie，后续请求按Cookie值分配。

F5的配置工作从来不是敲命令那么简单，它考验的是你对应用架构的理解。你得知道后端服务能不能水平扩展，会话状态存在本地还是Redis里，健康检查应该探哪个端口哪个路径。把这些问题想清楚了，F5配置只是表达你的设计而已。想不清楚，再漂亮的配置面板也只是个华丽的错误发生器。