某网站的集群技术的使用原理讲解

  所有的站点都是从小型站点逐步发展而来的,在此过程中,最大的挑战来自于大量的用户,安全环境恶劣,高并发访问,以及大量的数据,任何简单的业务处理,一旦需要处理数以P计的数据,以及面对上亿的用户,都会变得非常棘手。

图怪兽_ca67cb6bc7301de32e6bdf69dd4991ab_26994.png

当客户反馈其内部网络SLB业务流量较大时,一些固定的ECS客户端无法连接内部网络SLB。但同时,其他ECS客户端正常访问SLB;而问题ECS客户端直接访问SLB后端RealServer的业务也没问题。

部署架构相对简单。

内部网络ECS<->内部网络SLB<->内部网络后端RealServerECS。

用户使用脚本,使用nmap或nc每1秒访问一次平衡负载,尝试在释放之前建立TCP连接。

当脚本打印filter时,连接失败。从客户端抓取包来看,客户端发送的TCPSYN包没有得到SLB返回的SYN+ACK响应。

脚本如下:

#!/bin/bash

whiletrue;do。

nmap-Pn-p192.168.1.1|awk"\$1~/9999/{print\$2}"|grep"filter"

sleep1

done

注意:9999是TCP监控端口,192.168.1.1是VIP地址。

分析思路。

由于负载平衡访问链路过长,在处理负载平衡相关网络问题时,我们可以根据整个网络链路,结合问题现象和比较测试来确定问题的可能性。

一般来说,在客户端访问量大的情况下出现问题,我们会怀疑以下可能性:

云盾防护

客户端的一些访问行为是否触发了云盾的保护机制,导致访问失败。

跟踪分析:没有发现云盾截取日志中有相关记录,可以排除。

物理机械性能问题

过多的流量达到ECS网卡流量上限。

跟踪分析:检查发现ECS中的网卡流量不高,可以排除。

后端RS问题。

TCP核心参数配置不合理,导致TCP核心资源耗尽,如TimeWait数量过多,导致新连接无法建立,或后RS防火墙丢失指定源地址。

跟踪方案:检查/var/log/messages日志,检查sysctl.conf配置文件参数,检查防火墙配置,无疑问题。可以排除。

IDC中间链接。

中间交换机链路是否丢失了特定源IP和特定目的IP。

跟踪方案:网络团队检查链接报警日志,未发现可疑点。升级相关设备驱动到最新版本后,问题依然存在。可以排除。

负载平衡或NC物理机上相关模块的处理。

考虑到这个问题只发生在流量大的情况下,客户端访问RealServer没有丢包,只是访问负载平衡失败,但考虑到负载平衡集群为多个负载平衡实例提供服务,集群上的其他负载平衡实例正常工作。因此,我们怀疑NC物理机的处理是否有问题。

分享:

相关推荐