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

《如何解决虚拟化业务访问缓慢问题》由会员分享，可在线阅读，更多相关《如何解决虚拟化业务访问缓慢问题（9页珍藏版）》请在金锄头文库上搜索。

1、如何解决虚拟化业务访问缓慢问题 CSNA 网络分析认证培训 2001-2017 科来版权所有 科来官网 1 / 8 随着虚拟化的发展，越来越多的企业将应用系统部署在虚拟化环境中，传统的运维平台已经无法 满足在虚拟化中遇到的问题。 本案例中介绍如何通过科来回溯分析系统对应用虚拟化部署的故障进行排查。 问题描述问题描述 某省移动公司的业务管理系统目前已迁移到 Citrix 虚拟化平台， 但个别业务应用在迁移之后使用者 感受非常缓慢，因此需要通过网络回溯分析技术对这些业务访问缓慢的原因进行分析。 用户的内部信息系统拓扑示意图如下： 图-1 其中 Citrix 虚拟化平台服务器位于“网管核心业务区

2、”，各业务系统维护人员在“维护终端区”通过 Citrix 客户端连接到虚拟化平台，再通过虚拟化平台访问数据业务区的应用系统服务器。 使用者感受缓慢的应用主要是： 核心服务器 IP 虚拟化平台 IP 应用架构 某故障应用的管理平台 10.16.8.41 10.16.3.112 C/S 架构 分析过程分析过程 在“网管核心业务”区核心交换机旁路部署科来回溯分析系统，镜像交换机上联端口双向流量。 通过科来网络回溯分析系统 724 小时采集“网管核心业务区”的流量，针对出现缓慢的业务和发生 访问缓慢的时段进行重点数据分析。通过捕获 Citrix 平台与管理终端及业务服务器的交易过程，评估 访问缓慢应用

3、交易过程的网络传输延时和应用系统应答延时等性能参数，从而判断业务访问缓慢的根 本原因。 1.2.1 链路流量状况分析链路流量状况分析 首先通过科来回溯分析系统对“网管核心业务区”出口的链路流量状况进行整体评估，其目的是在 交换机上联链路上是否存在拥塞现象。 科来网络回溯分析系科来官网 2 / 8 图-2 图-3 通过上图中展示的上午 4 小时流量趋势及流量统计数据来看，“网管核心业务区”出口的流量并不 大，峰值流量为 37.51Mbps，远小于链路总带宽，因此可以排除“网管核心业务区”出口带宽利用率过 高导致应用访问缓慢的可能性。 1.2.2 故障应用管理平台通讯数据分析故障应用管理平台通讯

4、数据分析 1. 实测访问流量趋势分析 根据用户运维人员介绍，故障应用管理平台从打开客户端程序到终端显示初始界面大约需要 1 分 钟左右时间，严重影响使用者感受。 首先请用户运维人员实际访问一次故障应用管理平台， 从终端打开 Citrix 客户端程序， 到连接到虚 拟化平台，再到打开故障应用客户端显示初始界面，全部过程共用了约 50 多秒。 图-4 科来官网 3 / 8 通过对 Citrix 平台 IP10.230.3.112 的流量趋势进行精细分析，从上图中我们可以看出在这一次测试 访问时，从流量趋势图中可以看出从 15:58:30 秒测试开始到初始界面显示（当测试人员看到初始界面 时， 我

5、们从流量趋势图上看到明显的流量突发） 大约持续50多秒。 期间10.230.3.112主要与10.230.3.125 （测试终端） 、10.230.3.86（域控制器）和 10.161.8.41（业务服务器）等 3 个 IP 通讯。注：其他几个 IP 经过后续数据分析确认与本次测试访问无关。 整个访问过程所产生的流量不到 1MB，峰值速率约 4Mbps，期间 15:48:4515:49:22 这段时间几乎 没有什么流量，因此我们需要对这段时间通讯量很少的成因进行深入分析。 2. 通讯会话深入分析 我们下载了这段时间 10.230.3.112 的原始数据包，利用科来回溯分析系统专家分析模块的 T

6、CP 会 话重组功能分析本次测试访问所触发的 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 会

7、话，通讯服务端口为 8006，经过核实这是故障应用管理平台的服务端口。 3. 域登录过程响应时间分析 从会话列表中我们可以看出和域登录相关的若干会话中有个别会话持续时间比较长，因此我们首 先对登录过程中触发的各会话进行精细分析。 科来官网 4 / 8 图-6 由于 TCP 通讯过程中三次握手是由操作系统的 TCP 进程执行的，不需要应用系统干预，因此我们 可以将三次握手延时看作客户端到服务端的网络响应时间（RTT） 。上图中 10.230.3.112 与域控制器的 445 端口的会话三次握手延时为 2.97ms，网络延时非常小。 后续应用层数据交互过程中，我们可以看出域控制器的服务端应答时间

8、也非常小（1ms 左右） 。 整个会话在开始后约 996ms 后事务处理完成，其后有约 20s 的空闲时间，会话应用层关闭。如下 图： 图-7 从这个会话交互过程我们可以判断，该会话虽然持续 20 多秒时间，但在 1 秒之内已经完成了登录 过程必须的数据交互。 通过对其他域登录所触发的会话分析，我们发现这些会话均在 1 秒之内完成了有效数据交互，可 以确定整个域身份验证过程从 15:58:34 开始，到 15:58:36 已经验证完成。因此 Citrix 平台客户端登录 的身份验证过程并不会直接导致用户感受缓慢。 4. 故障应用管理平台应用会话响应时间分析 Citrix 虚拟化平台与 10.1

9、61.8.41 应用服务器之间建立的两个 TCP 会话，三次握手延时和服务器应 用层响应时间也很短，如下图。 科来官网 5 / 8 图错误错误!文档中没有指定样式的文字。文档中没有指定样式的文字。-8 但是从会话整体延时统计中，我们可以看出整个会话的主要时间占用源自“客户端空闲时间”，如 下图。 图-9 “客户端空闲时间”是指客户端与服务端一次应用层交互完成后，到下一次发起应用层请求的间隔 时间，在故障应用平台客户端打开的过程中并没有额外需要人工干预的过程，因此出现大量“客户端 空闲时间”说明客户端系统（10.230.3.112）或客户端程序处理出现问题，导致不能及时向服务端发送 下一次应用

10、层请求。 从会话交易时序图中，我们可以看到两个会话均有一次明显的客户端空闲，如下图。 图-10 科来官网 6 / 8 图-11 可以判断，这些客户端空闲是使用者感受缓慢的直接原因，很可能是这段时间客户端程序处理过 于缓慢，导致很长一段时间没有发送应用层请求。 在其他时段，我们随机选择了一些 10.230.3.112 与 10.161.8.41 的 TCP 会话，均发现了相同的客户 端空闲，如下图。 图-12 并且我们发现在较长的客户端空闲后，10.230.3.112 发起的主要是两个应用层请求： select right_id, right_type, module_id, module_n

11、ame, 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= 至此，我们推断故障应用平台的客户端程序，在发送上述两个查询之前的处理过程过于缓慢，建 议系统研发人员对程序处理过程进行深入分析。 科来官网 7

12、 / 8 5. Citrix平台响应时间分析 用户终端与 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 平台在

13、应用软件处理完成后能够很快的将处理后的图像数据发送给用户终端。 可以判断 Citrix 平台并没有对用户访问造成明显的延时（以上延时不包括 Citrix 客户端程序处理图 像数据到最终显示出来的时间） 。 分析结论分析结论 故障应用管理平台用户感受缓慢的原因与网络基础设施、Citrix 平台、10.161.8.41 服务器无关； 主要造成缓慢的原因是 10.230.3.112 上的故障应用管理客户端程序处理缓慢造成的，这一问题以 下两种可能性： 运行在10.230.3.112上的应用客户端程序在开启时需要占用大量系统资源， 导致处理缓慢。（需科来官网 8 / 8 要研发人员对客户端程序进行优化） 10.230.3.112虚机的处理性能不足，影响了客户端程序运行效率。 （为该业务的客户端程序分配更多的虚拟机资源） 价值价值 在应用向虚拟化迁移后出现的应用访问故障，由于虚拟主机、网络等都处于良好的运行状态，大 多数情况下会考虑虚拟化平台的兼容性问题，很难在短时间内定位故障。通过网络分析，我们可以快 速定位到故障原因的根源，提升了故障恢复效率。