许多企事业单位对业务系统的性能、稳定性和扩展性有很高的要求。在业务网络环境中,负载均衡设备由于能对网络设备和服务器的带宽、吞吐量和数据处理能力进行扩容而备受青睐。然而负载均衡设备作为流量转发的一个环节,如果发生故障,也有可能导致业务访问失败,与正如本案例所示。
客户端通过x.x.96.171访问客服web,负载均衡设备-1的ip为x.x.96.169,负载均衡设备-2的ip为x.x.96.170,负载均衡设备-1和负载均衡设备-2通过自身的ip与客服web通讯,负载均衡设备一方面转发客户端的请求,另一方面将收到的响应转发给给客户端。
图 12-1
客户端通过x.96.171访问web服务器,会出现“404 not found”提示:
图 12-2
本故障中出“404 not found”错误的可能性原因有两个:第一个是客户发起的请求不存在;第二个是负载均衡设备转发客户端的请求时发生异常。
针对第一个可能性原因进行分析:通过提取“404 not found”会话中的客户端请求并直接访问,就可以确定客户的请求是否有效,经验证,该客户端请求可以直接访问,因此排除了第一个原因。
针对第二个可能性原因进行分析:对比分析客户端的请求与负载均衡设备转发的请求,便可以确定负载均衡设备的转化是否存在问题。而这一环节这也是这次分析的重点。
通过客户反馈,科来网络分析工程师找出错误提示的会话并提取关键字:
图 12-3
详细查看错误会话并与客户进行确认,判断错误提示具有以下特征:每个出错页面的content=“weblogic server”;数据流信息包括客户端ip、sessionid等关键字。之后提取正常访问数据,为后期对比分析做准备。
图 12-4
客户端的请求里包括详细的get请求、客户端ip、sna_cookie和login_cookie信息。
图 12-5
负载均衡设备(x.x.96.70)发起请求,包含的信息与客户端发出的请求信息一致。
由于此类现象不定期出现,想要完整抓取客户端到负载均衡设备和负载均衡设备到客服web的所有数据,就需要部署科来网络回溯分析系统并镜像负载均衡设备端口进行数据采集,等业务故障重现后再提取数据包进行分析,拓扑图如下。
图 12-6
客户端(x.x.138.210)发起get请求,请求数据大小为1.601kb,内容包括客户端ip、 sna_cookie和login_cookie等信息,服务器10.189.96.xxx响应“404 not found”,客户端的端口为1359。
图 12-7
图 12-8
客户端的请求里包括详细的get请求,客户端ip、sna_cookie和login_cookie信息,且服务器的错误响应包含content=“weblogic server”。
提取负载均衡设备与服务器的通讯,设置高级过滤器:(请求里的cookie有客户端的ip信息,数据流包括weblogic server,还可以通过sessionid等)。
图 12-9
图 12-10
负载均衡设备(x.x.96.70)发起请求,请求数据826b,小于客户端的请求数据(未见get请求),服务器响应“404 not found”,负载均衡设备的端口为1359,与客户端的端口一样。
与客户端的请求综合对比分析可知,负载均衡设备与服务器端通讯的请求不完整,未见sna_cookie信息,但通过login_cookie,客户端ip,sessionid等信息可以确定这是与客户端请求负载均衡设备的同一会话,且服务器的错误响应包含content=“weblogic server”。
图 12-11
负载均衡设备转发的请求与客户端发出的请求不一致,导致客户端访问客服web出现“404 not found”提示,该问题与客户端和服务器无关,应是负载均衡设备的转发存在bug。
当应用出现不能访问时,我们通常会怀疑是某个网络设备或端点设备的问题,比如本案例我们怀疑是应用负载均衡的问题,但如果缺乏有效的手段和工具,排查问题将会耗费大量的时间。
通过网络分析技术能够帮助用户进行数据包级的精细分析,可以看出数据包在传输中是否存在异常,迅速定位异常节点,从而进行快速排障。