f5 会话保持 负载均衡_WEB应用系统负载不均衡问题排查记录

故事发生背景：客户业务系统是在公网提供WEB服务的网站，在客户的网络结构中，经过SSL安全网关后经过F5 BIGIP-LTM进行负载均衡。客户之前是由SSL安全网关进行业务负载，后来由于其他考量决定采用F5负载均衡的产品。但是上线F5后出现一个问题，流量经过F5后负载一直不均衡，流量主要集中在一台服务器节点上。SSL安全网关为信安世纪TLS/SSL卸载设备。

到达客户现象后，开始排查问题，很简单的思路，负载不均衡的主要影响因素之一就是F5上面的会话保持策略，进过查看配置后发现果然是源地址会话保持，询问客户的网络工程师后发现所有的客户端经过SSl安全网关后都会被转换成SSL安全网关的地址。这样流量经过F5后，对于F5来说都是从一个客户端来的，F5上又是采用的源地址会话保持的策略，所以经所谓的“同一个”客户端的请求始终保持在一台服务器节点上；

找到问题后的处理步骤：跟信安世纪厂家沟通是够可以不做地址转换，但是信安世纪厂家不愿意更改源地址透传，觉得改动太大，后来沟通的结果是让SSL网关将客户端源地址像F5一样将源地址插入到HTTP X-Forword-For字段中，F5通过irule的策略将流量请求中XFF中的源地址取出来做会话保持；

但是通过irules打出log后看到XFF中的源地址也是同一个，醉了。客户最前面的NAT设备也会将地址映射为同一个IP，唉，，只能换种方法了。

第二阶段排查，将会话保持策略更换为cookie的方式。(可能有人会质疑，为什么不在一开始就使用cookie的保持方式，通过地址区分不开就要通过用户的cookie的方式，是因为我同事之前给这个客户远程过说换成cookie策略后负载依然不均衡，同时会带来另一个问题，就是应用系统访问慢。)

此时更换为cookie的会话保持策略就需要找到问题根源解决问题，这个时候就需要把策略更换别cookie的方式，同时抓包查找问题。

经过抓包分析后发下一个问题，客户的同一个TCP流中，存在多个用户的请求数据。造成F5在区分连接的负载均衡时无法发挥它的强大威力，变成了睁眼瞎。

数据包分析如下：