《CSNA网络分析认证专家实战案例》课件-第36章

第36章某移动公司虚拟化迁移后应用缓慢分析案例36.1故障描述 36.2分析过程36.3总结

某省移动公司的业务管理系统目前已迁移到Citrix虚拟化平台，但个别业务应用在迁移之后使用者感觉非常缓慢，因此需要通过网络回溯分析技术对这些业务访问缓慢的原因进行分析。36.1故障描述用户的内部信息系统拓扑示意图如图36-1所示。其中，Citrix虚拟化平台服务器位于“网管核心业务区”，各业务系统维护人员在“维护终端区”通过Citrix客户端连接到虚拟化平台，再通过虚拟化平台访问数据业务区的应用系统服务器。

图36-1使用者感觉缓慢的应用主要是某应用管理平台(具体名称隐去)，其核心服务器IP为10.16.8.41，虚拟化平台IP为10.16.3.112，该应用为C/S架构。

在“网管核心业务区”核心交换机旁路部署科来回溯分析系统(见图36-1)，镜像交换机上联端口双向流量。

通过科来回溯分析系统7

×

24小时采集“网管核心业务区”的流量，针对出现缓慢的业务和发生访问缓慢时段的数据进行重点分析。通过捕获Citrix平台与管理终端及业务服务器的交易过程，评估访问缓慢应用交易过程的网络传输延时和应用系统应答延时等性能参数，从而判断业务访问缓慢的根本原因。36.2分析过程36.2.1链路流量状况分析

首先，通过科来回溯分析系统对“网管核心业务区”出口的链路流量状况进行整体评估，目的是判断在交换机上联链路上是否存在拥塞现象，如图36-2所示。

通过图36-2中展示的上午4小时流量趋势及流量统计数据来看，“网管核心业务区”出口的流量并不大，峰值流量为37.51Mbps，远小于链路总带宽，因此可以排除“网管核心业务区”出口带宽利用率过高导致应用访问缓慢的可能性。

图36-236.2.2故障应用管理平台通信数据分析

1.实测访问流量趋势分析

根据用户中一些相关技术人员介绍，故障应用管理平台从打开客户端程序到终端显示初始界面，大约需要1分钟左右时间，严重影响使用者感受。我们请用户技术人员实际访问一次故障应用管理平台，从终端打开Citrix客户端程序，到连接到虚拟化平台，再到打开故障应用客户端显示初始界面，全部过程共用了50多秒。通过对Citrix平台IP10.230.3.112的流量趋势进行精细分析，如图36-3所示，这一次测试访问从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秒这段时间几乎没有什么流量，因此我们需要对这段时间通信量很少的原因进行深入分析。

图36-3

2．通信会话深入分析

我们下载了这段时间IP10.230.3.112的原始数据包，利用科来回溯分析系统“专家分析”模块的“TCP会话重组”功能分析本次测试访问所触发的TCP会话流。

在图36-4中，我们使用了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，经过核实这是故障应用管理平台的服务端口。

图36-4

3．域登录过程响应时间分析

从会话列表中我们可以看出，与域登录相关的若干会话中，有个别会话持续时间比较长。因此，我们接下来对登录过程中触发的各会话进行精细分析。

由于TCP通信过程中三次握手是由操作系统的TCP进程执行的，不需要应用系统干预，因此我们可以将三次握手延时看作客户端到服务端的网络响应时间(RTT)。图36-5中，10.230.3.112与域控制器的445端口的会话三次握手延时为2.97毫秒，网络延时非常小。从后续应用层数据交互过程中我们可以看出，域控制器的服务端应答时间也非常小(1毫秒左右)。

图36-5整个会话在开始约996毫秒后事务处理完成，其后有约20秒的空闲时间，会话应用层关闭，如图36-6所示。

图36-6从这个会话交互过程我们可以判断，该会话虽然持续20多秒时间，但在1秒之内已经完成了登录过程必须的数据交互。

通过对其他域登录所触发的会话分析我们发现，这些会话均在1秒之内完成了有效数据交互，可以确定整个域身份验证过程从15时58分34秒开始，到15时58分36秒已经验证完成。因此，Citrix平台客户端登录的身份验证过程并不会直接导致用户感觉缓慢。

4．故障应用管理平台应用会话响应时间分析

Citrix虚拟化平台与10.161.8.41应用服务器之间建立的两个TCP会话，三次握手延时和服务器应用层响应时间也很短，如图36-7所示。

但是，从会话整体延时统计中我们可以看出，整个会话的主要时间占用源自“客户端空闲时间”，如图36-8所示。

图36-7

图36-8“客户端空闲时间”是指客户端与服务端一次应用层交互完成后，到下一次发起应用层请求的间隔时间。在故障应用平台客户端打开的过程中并没有额外需要人工干预的过程，因此，出现大量“客户端空闲时间”说明客户端系统(10.230.3.112)或客户端程序处理出现问题，导致不能及时向服务端发送下一次应用层请求。

从会话交易时序图中我们可以看到，两个会话均有一次明显的客户端空闲，如图36-9和图36-10所示。

图36-9

图36-10可以判断，这些客户端空闲是使用者感觉缓慢的直接原因，很可能是这段时间客户端程序处理过于缓慢，导致很长一段时间没有发送应用层请求。

在其他时段，我们随机选择了一些10.230.3.112与10.161.8.41的TCP会话，均发现了相同的客户端空闲，如图36-11所示。我们还发现，在较长的客户端空闲后，10.230.3.112发起的主要是两个应用层请求：

selectright_id,right_type,module_id,module_name,right_name,right_valuefromtco_role_rightswhererole_id=…andright_type=…

selectuserid,config_class_name,config_version,configfromtap_wf_userRelatedConfigswhereuserid=…andconfig_class_name=…andconfig_version=…

图36-11至此，我们推断故障应用平台的客户端程序在发送上述两个查询之前的处理过程过于缓慢，建议系统研发人员对程序处理过程进行深入分析。

5．Citrix平台响应时间分析

用户终端与Citrix平台(10.230.3.112)之间的会话，三次握手和应用层响应时间也非常快，如图36-12所示。

图36-12在故障应用管理平台会话的客户端空闲时间内，10.230.3.112与10.230.3.125之间只有少量的数据交互，在15:59:21.336时刻可以看到10.230.3.112向10.230.3.125发送了大量大数据包，如图36-13所示。

图36-13而这一时刻与10.230.3.112在长时间等待后向10.161.8.41发送新的应用层请求的时间点比较吻合(滞后3毫秒)，这说明Citrix平台在应用软件处理完成后能够很快地将处理后的图像数据发送给用户终端。

可以判断，Citrix平台并没有对用户访问造成明显的延时(以上延时不包括Citrix客户端程序处理图像数据到最终显示出来的时间)。

故障应用管理平台用户感受缓慢的原因与网络基础设施、Citrix平台、10.161.8.41服务器无关，造成缓慢的主要原因是10.23