问题描述
某省移动公司的业务管理系统目前已迁移到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，网络延时非常小。
后续应用层数据交互过程中，我们可以看出域控制器的服务端应答时间也非常小(1ms左右)。
整个会话在开始后约996ms后事务处理完成，其后有约20s的空闲时间，会话应用层关闭。如下图：
图 7
从这个会话交互过程我们可以判断，该会话虽然持续20多秒时间，但在1秒之内已经完成了登录过程必须的数据交互。
通过对其他域登录所触发的会话分析，我们发现这些会话均在1秒之内完成了有效数据交互，可以确定整个域身份验证过程从15：58：34开始，到15：58：36已经验证完成。因此Citrix平台客户端登录的身份验证过程并不会直接导致用户感受缓慢。
04故障应用管理平台应用会话响应时间分析
Citrix虚拟化平台与10.161.8.41应用服务器之间建立的两个TCP会话，三次握手延时和服务器应用层响应时间也很短，如下图。
图 8
但是从会话整体延时统计中，我们可以看出整个会话的主要时间占用源自“客户端空闲时间”，如下图。
图 9
“客户端空闲时间”是指客户端与服务端一次应用层交互完成后，到下一次发起应用层请求的间隔时间，在故障应用平台客户端打开的过程中并没有额外需要人工干预的过程，因此出现大量“客户端空闲时间”说明客户端系统(10.230.3.112)或客户端程序处理出现问题，导致不能及时向服务端发送下一次应用层请求。
从会话交易时序图中，我们可以看到两个会话均有一次明显的客户端空闲，如下图。
图 10
图 11
可以判断，这些客户端空闲是使用者感受缓慢的直接原因，很可能是这段时间客户端程序处理过于缓慢，导致很长一段时间没有发送应用层请求。
在其他时段，我们随机选择了一些10.230.3.112与10.161.8.41的TCP会话，均发现了相同的客户端空闲，如下图。
图 12
并且我们发现在较长的客户端空闲后，10.230.3.112发起的主要是两个应用层请求：
select right_id， right_type， module_id， module_name， right_name， right_value from tco_role_rights where role_id =… and right_type=….
select userid， config_class_name， config_version， config from tap_wf_userRelatedConfigs where userid=… and config_class_name=… and config_version=…
至此，我们推断故障应用平台的客户端程序，在发送上述两个查询之前的处理过程过于缓慢，建议系统研发人员对程序处理过程进行深入分析。
05Citrix平台响应时间分析
用户终端与Citrix平台(10.230.3.112)之间的会话，三次握手和应用层响应时间也非常快，如下图。
图 13
在故障应用管理平台会话的客户端空闲时间内，10.230.3.112与10.230.3.125之间只有少量的数据交互，在15：58：21.336时刻可以看到10.230.3.112向10.230.3.125发送了很多大数据包，如下图。
图 14
而这一时刻与10.230.3.112在长时间等待后向10.161.8.41发送新的应用层请求的时间点吻合(滞后3ms)，这说明Citrix平台在应用软件处理完成后能够很快的将处理后的图像数据发送给用户终端。
可以判断Citrix平台并没有对用户访问造成明显的延时(以上延时不包括Citrix客户端程序处理图像数据到最终显示出来的时间)。
核心关注：拓步ERP系统平台是覆盖了众多的业务领域、行业应用，蕴涵了丰富的ERP管理思想，集成了ERP软件业务管理理念，功能涉及供应链、成本、制造、CRM、HR等众多业务领域的管理，全面涵盖了企业关注ERP管理系统的核心领域，是众多中小企业信息化建设首选的ERP管理软件信赖品牌。
转载请注明出处：拓步ERP资讯网http://www.toberp.com/
本文标题：案例｜如何解决虚拟化业务访问缓慢问题
本文网址：http://www.toberp.com/html/consultation/10839420745.html
相关文章
