所有的站点都是从小型站点逐步发展而来的，在此过程中，最大的挑战来自于大量的用户，安全环境恶劣，高并发访问，以及大量的数据，任何简单的业务处理，一旦需要处理数以P计的数据，以及面对上亿的用户，都会变得非常棘手。
当客户反馈其内部网络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物理机的处理是否有问题。
还没有评论，来说两句吧...