e-works数字化企业网  »  文章频道  »  基础信息化  »  企业上云

案例|如何解决虚拟化业务访问缓慢问题

2017/7/22    来源:今日头条    作者:佚名      
关键字:虚拟化  运维平台  
随着虚拟化的发展,越来越多的企业将应用系统部署在虚拟化环境中,传统的运维平台已经无法满足在虚拟化中遇到的问题。
    问题描述
 
    某省移动公司的业务管理系统目前已迁移到Citrix虚拟化平台,但个别业务应用在迁移之后使用者感受非常缓慢,因此需要通过网络回溯分析技术对这些业务访问缓慢的原因进行分析。
 
    用户的内部信息系统拓扑示意图如下:
 
    案例|如何解决虚拟化业务访问缓慢问题
 
图 1
 
    其中Citrix虚拟化平台服务器位于“网管核心业务区”,各业务系统维护人员在“维护终端区”通过Citrix客户端连接到虚拟化平台,再通过虚拟化平台访问数据业务区的应用系统服务器。
 
    使用者感受缓慢的应用主要是:
 
案例|如何解决虚拟化业务访问缓慢问题
 
    分析结论
 
    故障应用管理平台用户感受缓慢的原因与网络基础设施、Citrix平台、10.161.8.41服务器无关;主要造成缓慢的原因是10.230.3.112上的故障应用管理客户端程序处理缓慢造成的,这一问题以下两种可能性:
 
  • 运行在10.230.3.112上的应用客户端程序在开启时需要占用大量系统资源,导致处理缓慢。(需要研发人员对客户端程序进行优化)
 
  • 10.230.3.112虚机的处理性能不足,影响了客户端程序运行效率。(为该业务的客户端程序分配更多的虚拟机资源)
 
    价值
 
    在应用向虚拟化迁移后出现的应用访问故障,由于虚拟主机、网络等都处于良好的运行状态,大多数情况下会考虑虚拟化平台的兼容性问题,很难在短时间内定位故障。通过网络分析,我们可以快速定位到故障原因的根源,提升了故障恢复效率。
 
    分析过程
 
    在“网管核心业务”区核心交换机旁路部署科来网络回溯分析系统,镜像交换机上联端口双向流量。通过科来网络回溯分析系统7×24小时采集“网管核心业务区”的流量,针对出现缓慢的业务和发生访问缓慢的时段进行重点数据分析。通过捕获Citrix平台与管理终端及业务服务器的交易过程,评估访问缓慢应用交易过程的网络传输延时和应用系统应答延时等性能参数,从而判断业务访问缓慢的根本原因。
 
    链路流量状况分析
 
    首先通过科来网络回溯分析系统对“网管核心业务区”出口的链路流量状况进行整体评估,其目的是在交换机上联链路上是否存在拥塞现象。
 
案例|如何解决虚拟化业务访问缓慢问题
 
图 2
 
案例|如何解决虚拟化业务访问缓慢问题
 
图 3
 
    通过上图中展示的上午4小时流量趋势及流量统计数据来看,“网管核心业务区”出口的流量并不大,峰值流量为37.51Mbps,远小于链路总带宽,因此可以排除“网管核心业务区”出口带宽利用率过高导致应用访问缓慢的可能性。
 
    故障应用管理平台通讯数据分析
 
    01实测访问流量趋势分析
 
    根据用户运维人员介绍,故障应用管理平台从打开客户端程序到终端显示初始界面大约需要1分钟左右时间,严重影响使用者感受。
 
    首先请用户运维人员实际访问一次故障应用管理平台,从终端打开Citrix客户端程序,到连接到虚拟化平台,再到打开故障应用客户端显示初始界面,全部过程共用了约50多秒。
 
    案例|如何解决虚拟化业务访问缓慢问题
 
图 4
 
    通过对Citrix平台IP10.230.3.112的流量趋势进行精细分析,从上图中我们可以看出在这一次测试访问时,从流量趋势图中可以看出从15:58:30秒测试开始到初始界面显示(当测试人员看到初始界面时,我们从流量趋势图上看到明显的流量突发)大约持续50多秒。期间10.230.3.112主要与10.230.3.125(测试终端)、10.230.3.86(域控制器)和10.161.8.41(业务服务器)等3个IP通讯。注:其他几个IP经过后续数据分析确认与本次测试访问无关。
 
    整个访问过程所产生的流量不到1MB,峰值速率约4Mbps,期间15:48:45~15:49:22这段时间几乎没有什么流量,因此我们需要对这段时间通讯量很少的成因进行深入分析。
 
    02通讯会话深入分析
 
    我们下载了这段时间10.230.3.112的原始数据包,利用科来网络回溯分析系统专家分析模块的TCP会话重组功能分析本次测试访问所触发的TCP会话流。
 
案例|如何解决虚拟化业务访问缓慢问题
 
图 5
 
    在上图中我们使用了TCP会话开始发包时间进行会话排序,从中可以看出在15:58:34时刻测试终端10.230.3.125向10.230.3.112发起建立了Citrix会话,该会话一直持续到采样结束;在Citrix会话建立之后,10.230.3.112向域控制器10.230.3.86发起建立了若干TCP会话,从其通讯端口和协议类型来看是域身份验证相关的会话;在15:58:45时刻,10.230.3.112向故障应用平台服务器10.161.8.41发起建立了两个TCP会话,通讯服务端口为8006,经过核实这是故障应用管理平台的服务端口。
 
    03域登录过程响应时间分析
 
    从会话列表中我们可以看出和域登录相关的若干会话中有个别会话持续时间比较长,因此我们首先对登录过程中触发的各会话进行精细分析。
 
案例|如何解决虚拟化业务访问缓慢问题
 
图 6
 
    由于TCP通讯过程中三次握手是由操作系统的TCP进程执行的,不需要应用系统干预,因此我们可以将三次握手延时看作客户端到服务端的网络响应时间(RTT)。上图中10.230.3.112与域控制器的445端口的会话三次握手延时为2.97ms,网络延时非常小。
 

责任编辑:李欢
本文为授权转载文章,任何人未经原授权方同意,不得复制、转载、摘编等任何方式进行使用,e-works不承担由此而产生的任何法律责任! 如有异议请及时告之,以便进行及时处理。联系方式:editor@e-works.net.cn tel:027-87592219/20/21。
e-works
官方微信
掌上
信息化
编辑推荐
新闻推荐
博客推荐
视频推荐