WAF+SLB负载不均衡案例分享

问题演变过程

时间点1：高防+WAF+SLB+2台ECS
时间点2：高防+WAF+SLB+4台ECS

问题描述

在时间点1时，没有发现明显的负载不均衡的状况。在时间点2时，出现大部分请求都打到了其中一台ECS上。须要定位问题缘由

问题梳理

• 问题链路
  是SLB后端的ECS出现负载不均衡的请求，那么直接影响这个转发算法的，是WAF以及SLB。那么和高防没有关系了。

• 配置状况

  1. SLB：TCP监听，WRR转发算法，开启会话保持
  2. WAF：无特殊配置，域名直接回源负载均衡IP

问题点1：轮询算法+会话保持

措施：尝试修改轮询算法为WLC，会话保持时间调短。
然而这个优化措施效果并不明显，因为开启了会话保持，那原有负载不均衡的状况下，调整WRR算法到WLC的算法，没有实现预期的WLC。

可是从另一个角度来讲，若是源IP很是分散的场景下，即便有会话保持，理论上仍是应该在通过一个较长的时间段以后，依然可以到达均衡。
这里因为是使用WAF的回源地址进行访问，因此对负载均衡来讲，客户端的公网IP地址是固定的，一直是固定的几个；从而调整WLC+会话保持的调整收效甚微。

问题点2：会话保持模板刷新问题

措施：尝试关闭会话保持。
稍有成效：关闭会话保持后，通过一段时间的通讯，4台ECS初步的开始均衡，可是到了一个固定值以后；没有继续均衡，一直保持着1:2的状态。
这里有2个知识点：
一、WLC算法的计数开始是从调整为这个算法的时间点开始的；那么若是历史开始就出现不均衡，那么开启后仍是会不均衡的。
二、因为WAF的回源地址与SLB的通讯一直在，没有断过因此历史的会话保持的效果依然存在，已经会话保持的IP，依然会发给对应负载均衡的RS，致使不均衡。

推荐的解法为：使用负载均衡的权重功能，将链接数多的机器的权重调低，待4台机器的链接数基本均衡后，将RS的权重都调整为一致。

原文连接
本文为云栖社区原创内容，未经容许不得转载。