开发者社区> 隽勇> 正文
阿里云
为了无法计算的价值
打开APP
阿里云APP内打开

[负载均衡案例分享系列] 一个由负载均衡使用模式导致间断访问失败问题的处理

简介: 本篇文章主要讨论的是负载均衡4层TCP模式下,一种罕见的部署访问模式导致的间断访问问题的处理过程。由此大家可以了解到: 1、4层TCP模式下负载均衡的工作原理 2、4层TCP模式下负载均衡访问部署的限制 3、4层TCP模式下负载均衡问题排查的常见思路
+关注继续查看

对于负载均衡的使用,相信大家都不陌生。常见的使用方法是在多台ECS上架设Web服务器后,前端配置负载均衡,将ECS作为后端Real Server,根据实际业务需求,配置TCP模式或HTTP/HTTPS模式提供服务。

本篇文章主要讨论的是负载均衡4层TCP模式下,一种罕见的部署访问模式导致的间断访问失败问题的处理过程。由此大家可以了解到:

1、4层TCP模式下负载均衡的工作原理

2、4层TCP模式下负载均衡访问部署的限制

3、4层TCP模式下负载均衡问题排查的常见思路


4层TCP模式下负载均衡的工作原理

首先,我们先来温习一下4层负载均衡的工作原理,参考知识点“负载均衡技术原理浅析”。

https://help.aliyun.com/knowledge_detail/39444.html?spm=5176.7839438.2.6.nvWFZU

4层TCP的负载均衡,使用Full NAT的工作模式,负载均衡集群引入local address(内网IP地址)的概念。

首先,我们设定相关的术语:

  • 访问负载均衡的客户端的IP为Client IP,简称CIP。
  • 负载均衡对外服务的IP为Virtual IP, 简称VIP。
  • 负载均衡集群内部的IP为Local IP, 简称LIP。
  • 负载均衡后端Real Server的IP为Real Server IP,简称RIP。

在客户端访问负载均衡的过程中,报文源地址->目的地址会从CIP->VIP转换为LIP->RIP,同时相应的源端口也会改变。而 LIP和RIP均为IDC内网IP,可以跨VLAN通讯。IN/OUT的数据流全部经过LVS,为了保证带宽,采用万兆(10G)网卡。如下是FULLNAT转发模式,当前仅支持TCP协议。

f84ff1a500d98d1b21ba5254e636eca8d80d293b
更深入一层,对于后端Real Server,如果负载均衡配置了"获取客户端IP地址",那是如何实现的呢?

如下图,对于运行该ECS的物理机NC,在NC的物理网卡和ECS虚拟网卡接口之间,有一个模块"SLB地址转换模块",专门用来实现LIP->RIP的包,转换为CIP->RIP,让Real Server可以获取到客户端的真实IP地址。

1fb3f45f6434bd5e9d4b65eca262210d3fa90092


案例处理过程

问题现象

客户反馈其内网SLB在业务流量较大的情况下,某些固定的ECS客户端访问内网SLB出现无法连接的情况。但与此同时,其它ECS客户端访问SLB正常;而且问题ECS客户端直接访问SLB后端Real Server的业务也没有问题。

部署架构比较简单.

   内网ECS <---> 内网SLB <--> 内网后端Real Server ECS

客户使用脚本,利用nmap或者nc每隔1秒访问负载均衡,尝试建立TCP连接,而后释放。

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

脚本如下:

#!/bin/bash
while true;do
nmap -Pn -p 9999 192.168.1.1 | awk "\$1 ~ /9999/ {print \$2}" | grep "filter"
sleep 1
done

注: 9999是负载均衡的TCP监听端口,192.168.1.1是负载均衡的VIP地址。


分析思路

由于负载均衡访问的链路过长,在处理负载均衡相关网络问题,我们可以根据整体网络链路,结合问题现象和对比测试,来定位问题发生的可能点。

一般而言,对于客户端访问量流量大的情况下才出现问题,我们会怀疑如下可能性:

  1. 云盾防护
    是否客户端的某些访问行为触发了云盾的防护机制,导致访问失败。
    跟进分析:未发现云盾的拦截日志中有相关记录,可排除。

  2. 物理机性能问题
    流量过高达到ECS 内网卡流量上限。
    跟进分析:检查发现ECS内网卡流量不高,可排除。

  3. 后端RS的问题
    后端RS的TCP内核参数配置不合理,导致TCP核心资源耗尽,例如Time Wait量过多导致新连接无法建立,或者后端RS的防火墙对于指定源地址丢包。
    跟进方案:检查/var/log/messages日志,检查sysctl.conf配置文件参数,检查防火墙配置,未发现可疑点。可排除。

  4. IDC中间链路问题
    是否中间交换机链路对于特定源IP、特定目的IP存在丢包情况。
    跟进方案:网络团队检查链路告警日志,未发现可疑点,升级相关设备驱动到最新版本后,问题依旧。可排除。

  5. 负载均衡或者NC物理机上相关模块的处理问题
    考虑到该问题仅仅在流量大情况下发生,结合客户端访问Real Server不存在丢包,仅仅是访问负载均衡失败,但考虑到负载均衡集群是为多个负载均衡实例提供服务,集群上其它负载均衡实例均正常工作。所以我们比较怀疑是否NC物理机处理存在问题。


抓包分析

为了准确定位问题,我们需要在问题情况下,进行必要的抓包对比分析。

注:为了保障客户数据的安全性,我们对所有IP地址进行隐藏

客户端内网CIP为:xxx.xxx.88.100, 内网SLB为xxx.xxx.23.111,内网Real Server为xxx.xxx.98.79

所以实际链路是

xxx.xxx.88.100(客户端ECS)<--> SLB:xxx.xxx.23.111 端口 18056 <--> 后端ECS: xxx.xxx.98.79 端口 8056

注:因为客户端有绕过SLB到RS的实际业务,所以在客户端,Real Server,Real Server所在NC抓包会发现大量8056端口的包。


客户端抓包

fbda09d65c3d4b50f4c597429d37242c689e5c8d

注:此处的网络包分析使用微软Network Monitor工具,与Wireshark分析方法类似。


编号2268. 客户端源端口46690直接访问Real Server的8056端口的SYN包。

编号2270. 客户端源端口21521访问负载均衡VIP的18056端口的SYN包,后续没有得到响应 (这是我们重点关注的包)。

编号2271. 客户端源端口46696直接访问Real Server的8056端口的SYN包。


Real Server所在NC的物理网卡抓包


抓包条件tcp[13] & 2 == 2 and tcp port 8056,抓取网络包如下:

20:31:36.424279 proto: TCP (6), length: 52) xxx.xxx.88.100.46690 > xxx.xxx.98.79.8056: S, cksum 0xc894 (correct), 3791054471:3791054471(0) win 14600

20:31:36.424350 proto: TCP (6), length: 52) xxx.xxx.98.79.8056 > xxx.xxx.88.100.46690: S, cksum 0x6b50 (correct), 4256391041:4256391041(0) ack 3791054472 win 14600

如上两个包是客户端源端口46690的SYN包是直接访问Real Server的8056端口的三次握手交互。

20:31:36.436453 proto: TCP (6), length: 60) xxx.xxx.124.161.5004 > xxx.xxx.98.79.8056: S 3171571935:3171571935(0) win 14600

该网络包为负载均衡集群将客户端源端口21521访问SLB IP 18056端口的SYN包通过Full NAT模式转换后,通过Local IP xxx.xxx.124.161的源端口5004发给后端Real Server。

这说明负载均衡集群没有丢包,该SYN包到达了NC的物理网卡。

20:31:36.445127 proto: TCP (6), length: 52) xxx.xxx.88.100.46696 > xxx.xxx.98.79.8056: S, cksum 0x92d2 (correct), 2695912842:2695912842(0) win 14600

20:31:36.445194 proto: TCP (6), length: 52) xxx.xxx.98.79.8056 > xxx.xxx.88.100.46696: S, cksum 0x1e24 (correct), 2827406360:2827406360(0) ack 2695912843 win 14600

如上客户端源端口46696的SYN包是直接访问Real Server的8056端口。


后端Real Server抓包

d6c4324219b7435c0a1c02730e897911478f6941


可以看到客户端访问Real Server 源端口为46690以及46696的包,但是无法看到SLB LIP转发的SYN包,所以该网络包丢在NC的物理网卡和后端Real Server的虚拟化接口上。

通过引入NC虚拟化同学,我们确认该问题是由于TCP 会话冲突导致。因为客户端通过本地IP地址和随机源端口直接访问后端Real Server,而客户端访问负载均衡VIP的包会被负载均衡更改五元组后,经过NC的“SLB地址转换模块”后,以CIP->RIP的方式发给后端Real Server。

在流量大的情况下,通过SLB LIP过来的以CIP->RIP访问后端Real Server的包,会与之前客户端直接以CIP->RIP的包存在冲突,导致NC无法将访问负载均衡的网络包发到后端ECS,造成问题。

而该问题仅仅在内网客户端同时访问内网负载均衡和后端的内网Real Server的部署模式,以及大流量的情况下才会出现。


负载均衡的使用建议

关于该问题,我们已经与负载均衡开发团队沟通,当前我们认为该方式不符合负载均衡的使用场景,建议客户避免该使用场景,后续会有相应的官方文档详细说明。

因此,请务必确保SLB使用模式的合理性,避免前端ECS同时访问SLB VIP以及直接后端ECS。在流量大的情况下,会出现会话冲突情况,导致通过SLB访问的会话出现无法访问的情况。

a08afe15fdf050297eb5fce9916d8790dc6112b9

排查技术分享

通过该案例的分析,作为阿里云售后支持团队,我们也希望客户了解到如下的一些排查建议。

抓包是否必要?

在分析网络问题的过程中,抓包分析确实是最准确定位问题的方式。但是我们不建议未经分析,全链路抓包定位问题,这比较低效、而且耗时。

最好的方式是首先通过合理的对比测试,已有日志分析来排除可能原因,尽量的缩小问题范围,而后在必要的网络链路节点,通过合理的使用tcpdump的抓包条件,对比分析定位问题。

例如,该案例中,客户仅仅是TCP连接建立失败,但由于客户实际业务流量较大,抓取所有包分析明显不合理。使用tcpdump时,利用过滤条件"host 192.168.1.1 and tcp[13]&2==2", 仅仅抓取指定IP地址以及TCP三次握手建立连接的TCP SYN包和SYN+ACK包,这样包的量较少而且比较容易定位问题。

负载均衡集群是否可以抓包?

由于负载均衡集群的流量非常大,不建议在负载均衡抓包。一般而言,涉及到负载均衡的抓包有2种情况:

  1. 怀疑负载均衡丢包
  2. 健康检查失败

在上述情况下,我们建议如下4点抓包对比定位问题。

  1. 客户端
  2. 后端Real Server所在的NC物理网卡
  3. 后端Real Server的虚拟网卡接口
  4. 后端Real Server的操作系统内部
如上就是一个负载均衡案例处理的具体流程,我们之后也会继续分享一些负载均衡实际案例的处理分析过程以及最佳实践。

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
Nginx-负载均衡
章节目录 什么是负载均衡 使用负载均衡要解决的问题 基于LVS的中间件架构 GSLB SLB 四层负载均衡和七层负载均衡 Nginx 负载均衡 配置语法 负载均衡配置实战 什么是负载均衡 当用户请求量增加至单台服务器不能及时处理的时候 即(单台服务器可接受能够建立连接的并发请求超过上限时), 那么就需要横向扩容应用服务器来多当前场景下的高并发请求做处理, 负载均衡正是将高并发请求分流至水平节点上不同应用服务器的一种技术。
1413 0
Nginx-负载均衡-server参数
章节目录 后端服务器在负载均衡调度中的状态 backup 状态演示 后端服务器在负载均衡调度中的状态 参数 含义 down 当前的server暂时不参与负载均衡 backup 预留的备份服务器 max_fails 允许请求失败的次...
822 0
nginx进阶-动静分离,负载均衡
nginx进阶-动静分离,负载均衡, nginx动静分离,负载均衡简单使用
3118 0
nginx 负载均衡配置
        企业在解决高并发问题时,一般有两个方向的处理策略,软件、硬件,硬件上添加负载均衡器分发大量请求,软件上可在高并发瓶颈处:数据库+web服务器两处添加解决方案,其中web服务器前面一层最常用的的添加负载方案就是使用nginx实现负载均衡。
1150 0
nginx做反向负载均衡,后端服务器获取真实客户端ip
nginx增加header配置 server { listen 80; server_name admin.
1193 0
nginx笔记4-负载均衡带来的问题以及解决办法
接着笔记3,将笔记三的改造一下,现在分别启动两个Tomcat,在页面获取session。如图所示: tomcat2的session: tomcat1的session:    根据上图发现,每个tomcat取到的session不一样。
1166 0
nginx笔记3-负载均衡算法
1.nginx测试:先从官网下载nginx 官网网址为:http://nginx.org/  然后找到stable version的版本下载,因为这版本是最稳定的,不要去下载最新,因为不稳定,如下图: 下载解压后即可 这里还要对解压后的nginx的conf目录下的nginx.conf配置如下图: 上图中的proxy_pass http://test-service;意思是只有test-service下面的tomcat才能通过我的反向代理。
961 0
第五章:nginx静态+代理+缓存+负载均衡详解
一、静态资源WEB服务 非服务器动态运行生成的文件 配置语法-文件读取 Synatax: sendfile on| off Default: sendfile off; Context: http,server,location,if in loc...
978 0
+关注
隽勇
隽勇, 阿里云技术服务专家,擅长网络、Windows相关技术,专注于弹性计算方面的技术研究,曾就职微软,坚信&ldquo;对技术负责,更对用户负责&rdquo;。
文章
问答
来源圈子
更多
作为全球云计算的领先者,阿里云为全球230万企业提供着云计算服务,服务范围覆盖200多个国家和地区。我们致力于为企业、政府等组织机构提供安全可靠的云计算服务,给用户带来极速愉悦的服务体验。
+ 订阅
文章排行榜
最热
最新
相关电子书
更多
负载均衡是如何支撑几亿手机微博用户访问的 -高性能负载均衡研发和应用实践
立即下载
架构分析、数据整合、负载均衡,梦想旅行解析云上实践
立即下载
阿里云网络-SLB负载均衡产品介绍
立即下载