|
|
| 网络故障以某种症状表现出来，故障症状包括一般性的（如用户不能接入某个服务器）和较特殊的（如路由器不在路由表中）。对每一个症状使用特定的故障诊断工具和方法都能查找出一个或多个故障原因。一般故障诊断模式如下。
|
|
|
| . 当分析网络故障时，首先要清楚故障现象。应该详细说明故障的症候和潜在的原因。为此，要确定故障的具体现象，然后确定造成这种故障现象的原因和类型。例如，主机不响应客户请求服务。可能的故障原因是主机配置问题、网卡故障或路由器配置命令丢失等。
|
|
|
| . 收集需要的用于帮助隔离可能故障原因的信息。向用户、网络管理员、管理者和其他关键人物提一些和故障有关的问题。广泛地从网络管理系统、协议分析跟踪、路由器诊断命令的输出报告或软件说明书中收集有用的信息。
|
|
|
| . 根据收集到的情况考虑可能的故障原因。可以根据有关情况排除某些故障原因。例如，根据某些资料可以排除硬件故障，把注意力放在软件原因上。对于任何机会都应该设法减少可能的故障原因，以便尽快策划出有效的故障诊断计划。
|
|
|
| . 根据最后的可能的故障原因，建立一个诊断计划。开始仅用一个最可能的故障原因进行诊断活动，这样可以容易恢复到故障的原始状态。如果一次同时考虑一个以上的故障原因，试图返回故障原始状态就困难多了。
|
|
|
| . 执行诊断计划，认真做好每一步测试和观察，直到故障症状消失。
|
|
|
| . 每改变一个参数都要确认其结果。分析结果确定问题是否解决，如果没有解决，继续下去，直到解决。
|
|
|
|
|
|
|
| 目前测试需要面对的大多数系统是复杂的分布式多层应用，这些应用的特点是：网络是应用中的一个组件，应用对网络产生影响，同时网络对应用也会产生影响，这样的特点造成应用在网络上的容量需求很难估计，失败的风险较大。如何针对分布式多层应用进行网络故障定位，以及在应用线程级分析中的应用是迫切需要解决的问题。网络应用分析可以发现多种问题，例如，客户端是否对数据库服务器运行了不必要的请求；当服务器从客户端接受了一个查询，应用服务器是否花费了不可接受的时间与数据库服务器通信等。借助于网络应用分析工具，可以在投产前调整应用在网络上的性能。
|
|
|
| 目前成熟的网络应用分析工具很少，并且从事网络故障分析的成本很高。为了实现分布式应用分析，规避应用实施风险，可以重点考虑以下几个方面的测试：
|
|
|
|
|
|
|
|
|
|
|
|
|
| 网络应用分析的关键因素包括：会话信息、包信息、响应时间信息、负载信息、高峰信息、线程信息等。同时还可以采用一些网络应用分析技术，例如，响应时间预测技术与带宽模拟技术等。
|
|
|
| . 会话信息。指应用程序节点之间的会话信息，会话信息主要包括会话往返行程和会话流量信息。
|
|
|
| ①往返行程。一个往返行程是一对节点之间的一系列帧请求/回应。如下图所示的会话中，往返行程个数是2。一个应用程序如果具有较少的往返行程次数，那么它受网络品质的影响，例如网络延迟的影响较小，反之则较大。
|
|
|
|
|
|
|
| ②流量信息。会话的流量信息包括节点之间传输的字节数或者帧数目，如下图所示表示的是节点之间传输的字节数。
|
|
|
|
|
|
|
| 当捕捉到的节点很多，并且流量纷繁交织时，可以设定某种条件过滤流量。如下图一和如下图二所示，表示的是过滤前和过滤后的流量显示状态。
|
|
|
|
|
|
|
|
|
|
|
|
|
| 可以先对包信息进行解码，然后分析包的详细信息，还可以分析包与包之间的关系、一个时间段内包的数量和包尺寸平均大小，以及包与线程的关系等。如下图所示为利用工具监控与应用相关的包大小及传输方向。大量的红色表示不充足的流量，传输线之间的间隔表示存在延迟问题。
|
|
|
|
|
|
|
|
|
| 如下图所示，分解出客户端响应时间、网络传输时间以及服务器（包括Web服务器、应用服务器、数据库服务器等）的处理时间，为分段定位故障提供依据。
|
|
|
|
|
|
|
|
|
| 如下图所示显示了有效负载与其他负载的比例，来评估与业务相关的流量效率。
|
|
|
|
|
|
|
|
|
| 需要明确高峰发生的时刻以及高峰期的流量，以确定广域网的容量需求，如下图所示表示了一个应用的平均流量和高峰流量。
|
|
|
|
|
|
|
|
|
| 可以对某个线程进行分析，也可对线程之间的关系进行分析。如下图所示，每个线程中都包含了一组包信息，所以可以分析线程和包之间的关联。线程也可以解析为协议信息进行分析。在线程分析时还可以将有关联的线程设置为线程组来分析。
|
|
|
|
|
| 可以利用工具为实验室中得到的测试数据进行响应时间预测。要完成这项工作需要定义三类参数，分别是带宽、背景负载（利用率）以及延迟，例如可以模拟在与服务器通信的带宽、负载、延迟参数下预测某个会话的响应时间。
|
|
|
|
|
|
|
| 如下图一、如下图二和如下图三所示，可以看出随着带宽的逐渐递增，数据传输时间以及网络通信时间的变化趋势。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 带宽模拟的目的是为系统传输选择一个合适的带宽，使得系统的峰值流量可以接受。这些测试数据为选择带宽提供了依据。
|
|
|
|
|
|
|
| . 第一个例子命名为Taskl，访问一个网页，例如www.cnn.com，速度较慢，问题出在哪里？为了实现故障定位，需要关注的问题如下。
|
|
|
|
|
| 如下图所示，在初始的DNS请求之后有一个8秒的间隔，也就是服务器为了响应DNS请求花费了8秒钟时间。
|
|
|
|
|
|
|
| 如下图一和下图二所示，线程4、5、6所关联的数据包之间有10秒的时间间隔。
|
|
|
|
|
|
|
|
|
|
|
|
|
| 这个应用涉及一个DNS服务器和一个Web服务器“www..CNN.com”。如下图所示为应用会话图。
|
|
|
|
|
|
|
|
|
| 从下图所示可知有效负载达到90.9%，应用流量效率较高。
|
|
|
|
|
|
|
|
|
| 从下图可以看到，25～30秒之间应用产生了持续流量高峰，可以将这个高峰与相关执行的线程关联起来。
|
|
|
|
|
|
|
| . 第二个例子是一个对比测试，我们来看如下图所示的Task1与Task2的测试数据。
|
|
|
| Task1的执行时间是3.43秒，Task2的执行时间是5.71秒。为什么Task2的流量小于Task1，而执行时间却长于Task1？是否存在性能问题？
|
|
|
|
|
|
|
| 首先我们发现在应用执行的开始存在一个1秒的时间间隔，在2～5秒之间有一个超过2秒的时间间隔。如下图所示为应用Bounce图。
|
|
|
|
|
|
|
|
|
| 客户端发出一个请求，Web服务器响应，在1秒之后又发出了同样的HTTP/GET请求，说明第一个请求失败。如下图所示为HTTP线程与Bounce关联图。
|
|
|
|
|
|
|
| 最后一个Oracle SQL请求在物理时刻1.65秒时发生，而下一个HTTP/GET请求直到物理时刻4.88秒时才发生，说明在请求之间存在较长时间间隔，服务器空闲。
|
|
|
| 从如下图所示的Oracle线程与Bounce关联图可知，每个时间间隔之后，系统都在等待客户端，可以初步将故障定位在客户端，下面可以进一步验证。
|
|
|
|
|
|
|
| 从下图可以看出，响应时间分析显示客户端响应时间为4.6秒，总的响应时间为5.7秒，客户端响应时间占总响应时间的80%左右，客户端的响应时间较长。下面从线程代码级再做进一步验证。
|
|
|
|
|
|
|
| 从下图所示的线程分析可以看到，发生延迟的HTTP请求都发生在客户端。
|
|
|
|
|
|
|
|
|
|
|
| 物理层是OSI分层结构体系中最基础的一层，它建立在通信媒体的基础上，实现系统和通信媒体的物理接口，为数据链路实体之间进行透明传输，为建立、保持和断开计算机和网络之间的物理连接提供服务。
|
|
|
| 物理层的故障主要表现在设备的物理连接方式是否恰当、连接电缆是否正确、MODEM或CSU/DSU等设备的配置及操作是否正确等方面。
|
|
|
| 确定路由器端口物理连接是否完好的最佳方法是，使用show interface命令，检查每个端口的状态，解释屏幕输出信息，查看端口状态、协议建立状态和EIA状态。
|
|
|
|
|
| 数据链路层的主要任务是，使网络层无须了解物理层的特征而获得可靠的传输。数据链路层为通过链路层的数据进行打包和解包、差错检测，并具有一定的校正能力，协调共享介质。在数据链路层交换数据之前，协议关注的是形成帧和同步设备。
|
|
|
| 查找和排除数据链路层的故障，需要查看路由器的配置，检查连接端口的共享同一数据链路层的封装情况。每对接口要和与其通信的其他设备有相同的封装。通过查看路由器的配置检查其封装，或者使用show命令查看相应接口的封装情况。
|
|
|
|
|
| 网络层提供建立、保持和释放网络层连接的手段，包括路由选择、流量控制、传输确认、中断、差错及故障恢复等。
|
|
|
| 排除网络层故障的基本方法是：沿着从源到目标的路径，查看路由器路由表，同时检查路由器接口的IP地址。如果路由没有在路由表中出现，应该通过检查来确定是否已经输入适当的静态路由、默认路由或者动态路由。然后手工配置一些丢失的路由，或者排除一些动态路由选择过程的故障，包括RIP或者IGRP路由协议出现的故障。
|
|
|
