| |
症状
某网站IT经理顾先生是我们的老朋友了，三年前在Cisco大会上认识，彼此“情投意合”，“兄弟”几个经常在一起交流一些网民心得。他原先在一家国有大型企业中任信息中心主任，负责网络的规划、设计建设和管理维护事宜。有好长一段时间没有他的消息，免费的信箱失效，加之后来换了工作就失去了联系。正思量怎么设法跟他重新取得联络，没想到他却不请自到，来了个“自投罗网”，昨天他因网络问题来网络医院咨询时方知其现在已经辞职到了现在的网站。顾不上仔细询问对方的近况，他便直接进入主题：顾先生所负责的网站最近出现一些问题。白天时常会出现短暂的拥塞，上网用户反映访问购物频道之网上在线商城时经常点击无效，多次重复后仍没有任何反应。此现象已经持续的两周，网站老总责令他必须在两天内找出原因，解决用户无法点击购物的问题，否则……
故障出现在什么时候？一般是白天，晚上基本不出现。何时开始出现故障征兆的？没有什么征兆，突然出现又突然消失，很不稳定且没有什么规律。
那么从第一次故障现象出现到今天为止有多久了？就两周。
两周前你们对网络干了什么？比如调整网络结构、增加或删除网络设备、增加服务器、增删和更改网络用户等？没有。不过网站内容到是几乎天天在变，但这应该不会有什么影响。因为我们装有网管系统，可以随时查看网络个链路的流量状态。对链路的流量还分别设置了门限报警，如果出现流量异常值班人员会马上知道。再说，我们的内部网都是用的100Mbps的网卡，核心交换机使用千兆以太网连接。而网站出口只是8Mbps，出问题时检查过出口流量，从来就没有超过2Mbps，还不如不出故障时的访问流量大。因此，说由于出口瓶颈的原因在访问流量大造成访问困难显然是站不住脚的。对网上商场的服务器仔细检查并用备用服务器试着更换过，但没有任何作用。该用的办法都用过了，实在查不出问题出在哪里。
有没有做过捕包分析或延迟分析？做过，首先对有关的服务链路进行网管监察，发现链路流量一般只有5%左右，捕包分析发现出现故障是有较大延迟，但Ping包正常。当时试验在故障时在网站内任选一台工作站从网上商城服务器拷贝一个1000M的文件，拷贝速度很快。用协议分析仪的专家诊断系统对捕获的包进行分析，除了发现HSRP协议帧有3000个，其它未见异常。
诊断过程
三刻钟后，我们随顾先生来到该网站所在大厦。准备着手进行检查。
分析故障现象，指示网络主要的问题是访问某个指定的服务器时慢。一般的原因主要有：服务器资源不足，比如接口速度低、CPU速度低、内存不够、开通的应用窗口过多等；访问通道出现瓶颈，访问速度受限；通道上的设备出现处理延迟，影响通道访问的速度等。从内部网的反应看，拷贝文件的延迟很小，速度正常。基本说明网站的内部网络应该没有大问题。
为了确认访问通道上的是否有流量瓶颈或延迟超长，我们将网络故障一点通接入路由器的出口，将网络综合协议分析仪OptiView接入在线商城服务器通道。从路由器出发送50Mbps(50%)高流量Ping包指向OptiView，这种方法是为了检查该通道的通道能力。可以看到最大的通道能力是95Mbps(发送的流量相应的流量加上为95Mbps)，将流量帧改为一般的IP帧，无须服务器响应，流量仍为50%，此时安装在服务器链路中的OptiView收到的流量是50Mbps，说明网络一点通发送的50Mbps的流量已经全部“安全抵达”服务器。此时的网络状态非常“正常”。从OptiView测试对路由器Ping包的响应，显示时间为12微秒(0.012ms)，结论：此时此刻网络工作正常。
由于是不稳定出现的“软故障”，接下来我们需要在故障出现时进行测试，好在该故障每天白天都会出现，不怕它不来。
50分钟后，从外线来的电话报告“故障出现”。我们迅速用OptiView的移动网管查看该通道的流量状态，显示均小于10%，从OptiView上对网站的路由器做Ping检查，时间是1200ms。立即从OptiView发送50Mbps流量给网络一点通，报告收到的流量只有5M，看来不光45M的流量被通道给“滤除”了，而且还引入了很大延迟。检查网站的拓扑图，从图上标注的状况来看该访问通道应该都是100Mbps的以太网链路，中间经过5台交换机到达服务器。在OptiView上对路由器做路径“TraceSwitch”检查。结果显示路径已经改变！整个路径中多出了3台交换机，从而使得原来需要经过5台交换机就能到达服务器的访问包现在需要经过8台交换机才能到达服务器！追踪查看这3台交换机，发现相应链路端口工作状态都是100Mbps。逐级检查延迟响应时间，发现1200ms的延迟就出现在新增加的第一台交换机通道节点上。由于有备份交换机，为了缩短故障诊断时间，试着更换此交换机。10分钟后，交换机更换完毕，开机试验，故障现象消失。 |
|
|
| 【收藏】【打印】【进入论坛】 |
|
|
|
|
| |
|
|
|
