博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
WAF+SLB负载不均衡案例分享
阅读量:7084 次
发布时间:2019-06-28

本文共 855 字,大约阅读时间需要 2 分钟。

hot3.png

问题演变过程

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

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

问题描述

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

问题梳理

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

aa2e6d240f180908031715c253cb1903572.jpg

  • 配置情况

    1. SLB:TCP监听,WRR转发算法,开启会话保持
    2. 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的权重都调整为一致。

本文为云栖社区原创内容,未经允许不得转载。

转载于:https://my.oschina.net/u/1464083/blog/3049257

你可能感兴趣的文章
react js踩坑之路(一)
查看>>
django项目设计
查看>>
[iOS]如何给Label或者TextView赋HTML数据
查看>>
C# To IL(四)
查看>>
监听时间变动事件Intent.ACTION_TIME_TICK
查看>>
MarkChanges: Jmeter
查看>>
Data truncation: Incorrect datetime value: 'May 15, 2019 4:15:37 PM
查看>>
JS Date.Format
查看>>
程序员的十大经验和教训
查看>>
数据生成树 ---新增
查看>>
#if和#ifdef区别
查看>>
cpu故障定位 top strace pstack
查看>>
[转] 多进程 join && daemon
查看>>
centos下将系统预置yum源更换为阿里云源
查看>>
Shell.Users 提权
查看>>
Spring通过注解注入有参
查看>>
HttpServletRequest应用(转)
查看>>
java.lang.ClassNotFoundException: org.apache.juli.logging.LogFactory的解决办法
查看>>
NGUI类关系图
查看>>
【java集合框架源码剖析系列】java源码剖析之HashSet
查看>>