服务器CPU满载,谁之过?

01 运维口水战

某天,突如其来的问题发生了,面向互联网用户的一套业务系统中的某台Web服务器出现的异常,CPU跑满了。大量的用户页面非常慢,有时甚至访问不了。对于运维人员来说,犹如晴天霹雳。

网络运维人员迅速检查到该服务器经过的各个网络设备的运行情况,网络设备都运行正常,到服务器的流量也不大。并且,同一区域的其它服务器运行也是正常的。网络运维人员初步结论:应该不是网络原因造成的,让应用运维人员检查一下软件运行情况吧。

与此同时,应用运维人员检查了程序的运行日志,程序也没有运行异常,只是发现程序在处理大量的tcp连接。应用运维人员让网络运维人员查一下,这些大量访问服务器的tcp连接是哪里过来的。

网络运维人员在负载均衡设备上查看了该服务器的并发tcp连接是挺大的,但是无法深入找出是哪些客户端发起的tcp连接。因为这个服务器是面向互联网的应用,网络运维人员初步判断,有可能是互联网的DDOS攻击导致的。现有的网络安全防护水平,还无法清洗这些DDOS流量。

最终,运维组之间陷入了僵局,业务系统处于异常状态已经快一天了。

02 神州灵云NetSensor登场

根据问题的症状,神州灵云技术顾问建议部署以下流量采集点。分别在互联网入口、负载均衡前后、防火墙前后以及服务器上联的位置同时进行流量采集。

图1:部署拓扑

部署说明:

抓包接口1:硬件探针的接口1是接入互联网流量到F5负载均衡设备入口的镜像流量,F5与互联网接入交换机直接是Trunk端口,可以通过Vlan ID区分出电信、联通、移动的流量。

抓包接口2:硬件探针的接口2是接入防火墙与互联网接入交换机的互联链路镜像流量。

抓包接口3:硬件探针的接口2是接入防火墙与核心接入交换机的互联链路镜像流量。

抓包接口4:硬件探针的接口4是接入关键数据库服务器的进行流量。

公网用户访问web应用交互逻辑:

公网用户访问58.xxx.224.12的80端口,F5做了源IP地址的转换。公网IP访问这个58.xxx.224.12时,F5将所有的会话转换为172.xxx.0.97去访问内网web服务器172.xxx.199.9

03 专家分析

流量与并发连接数对比分析:

对这个web应用,在F5前端和防火墙前端的抓包接口进行流量速率和并发连接数对比发现,互联网访问到这个web服务器经过F5前和防火墙前的流量分别是0.76Mbps和0.38Mbps。从流量上看,访问这台服务器的流量非常小,导致服务器CPU利用率100%应该不是流量因素造成的。

从F5前端和防火墙前端的并发连接数上看,互联网进来的并发连接数在10:31分时为54个,而在防火墙前端的并发连接数为22832个。同一应用的前后端抓包口的并发量相差巨大。进入“流量精分”进行深度分析。

深度分析:

查询10:06-11:06这一个小时,172.xxx.0.97访问172.xxx.199.9的tcp会话清单发现,172.xxx.0.97与172.xxx.199.9产生了64155条tcp会话,而这些TCP会话的总流量都是几KB。从tcp会话总流量上看,肯定不是一个正常的业务交互的流量范围。

选择一个tcp会话,进行解码分析发现,172.xxx.0.97与172.xxx.199.9的tcp会话只是建立了三次握手后中断了,没有数据交互。因此判断这些tcp会话应该是F5的健康检查数据包,但是这样高并发的健康检查肯定是一个异常的行为。

解决方法:

在F5上修改了对这台web服务器的健康检查策略后,问题解决。从发现问题到找出问题只花了5分钟。

04 优化建议

通过这次F5健康检查异常所发现的问题不单单是F5的健康检查机制的bug,最终导致的一个F5作为攻击源发起的TCP全连接攻击。这也是对web服务器的一个压力测试。通过数据包解码分析发现,F5向web服务器建立了tcp连接后,F5不传输任何应用数据包时,服务器是在将近10分钟内把这个会话Reset掉的。

Web服务器10分钟内的无应用数据交互的TCP会话断开时间太长了,需要做一下调优,尽量把这个超时时间缩短。

  • 发表于:
  • 原文链接https://kuaibao.qq.com/s/20190420A05ONO00?refer=cp_1026
  • 腾讯「云+社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。

扫码关注云+社区

领取腾讯云代金券