共计 793 个字符，预计需要花费 2 分钟才能阅读完成。
问题演变过程
时间点 1：高防 +WAF+SLB+ 2 台 ECS
时间点 2：高防 +WAF+SLB+ 4 台 ECS
问题描述
在时间点 1 时，没有发现明显的负载不均衡的情况。在时间点 2 时，出现大部分请求都打到了其中一台 ECS 上。需要定位问题原因
问题梳理
- 问题链路
是 SLB 后端的 ECS 出现负载不均衡的请求，那么直接影响这个转发算法的，是 WAF 以及 SLB。那么和高防没有关系了。
配置情况
- SLB：TCP 监听，WRR 转发算法，开启会话保持
- WAF：无特殊配置，域名直接回源负载均衡 IP
问题点 1：轮询算法 + 会话保持
措施：尝试修改轮询算法为 WLC，会话保持时间调短。
然而这个优化措施效果并不明显，由于开启了会话保持，那原有负载不均衡的情况下，调整 WRR 算法到 WLC 的算法，没有实现预期的 WLC。
但是从另外一个角度来说，如果源 IP 非常分散的场景下，即使有会话保持，理论上还是应该在经过一个较长的时间段之后，依然能够到达均衡。
这里由于是使用 WAF 的回源地址进行访问，所以对负载均衡来说，客户端的公网 IP 地址是固定的，一直是固定的几个；从而调整 WLC+ 会话保持的调整收效甚微。
问题点 2：会话保持模板刷新问题
措施：尝试关闭会话保持。
稍有成效：关闭会话保持后，经过一段时间的通信，4 台 ECS 初步的开始均衡，但是到了一个固定值之后；没有继续均衡，一直保持着 1:2 的状态。
这里有 2 个知识点：
1、WLC 算法的计数开始是从调整为这个算法的时间点开始的；那么如果历史开始就出现不均衡，那么开启后还是会不均衡的。
2、由于 WAF 的回源地址与 SLB 的通信一直在，没有断过所以历史的会话保持的效果依然存在，已经会话保持的 IP，依然会发给对应负载均衡的 RS，导致不均衡。
推荐的解法为：使用负载均衡的权重功能，将连接数多的机器的权重调低，待 4 台机器的连接数基本均衡后，将 RS 的权重都调整为一致。
本文作者：枫凡
阅读原文
本文为云栖社区原创内容，未经允许不得转载。
正文完
