NETSCOUT带来转变 1月01

Tags

Related Posts

NETSCOUT带来转变

历经多年的网络流量分析工作,见识了各行各业的用户通过使用NetScout流量分析系统,在日常的网络运维、应用性能等流量管理分析工作中对他们工作方式的影响和改变。

这些用户,无论他们的IT技术是否高超,IT理念是否先进,他们都在利用NetScout的KFP(KPI – Flow – Packets)思路,由宏观到微观,由现象到本质,慢慢的对他们的网络流量和网络中承载的各种业务应用分析产生了心理变化,那就是由开始的认为网络流量分析繁琐冗杂,面对数据包时有畏惧心理,到后来轻松灵活的可视化网络流量,借助NetScout+Sniffer+NetisDali等分析工具把粗燥无味的数据包变得易于理解,并乐于主动从数据包中找到事情的真相。

在和用户进行沟通过程中,有时会听到来自用户的这些声音,“你们这个产品可有可无,你们不能给我带来价值!”、“抓包太复杂了,我保证网络畅通就可以了。”、“买了你们这个以后,能解决所有问题吗?”等等,这其实也代表了几类用户的心态,他们不愿意打破常规,他们更愿意墨守着当前的工作状态和工作模式,利用多年积累的知识和经验来对他们自己所管辖的工作范围进行着他们以为是熟能生巧、手到擒来的日常工作,并以此为来肯定他们的工作成绩。

我们并不否认这种工作模式。其实这样的日常工作是非常可行的,也是踏踏实实做事的典范,是非常值得肯定的。但问题是,随着IT技术的飞速发展,当前环境下,用户业务的持续发展和业务性能保障已经成为用户发展的最重要的大计之一,而这些业务,也越来越多的依赖于IT技术、依赖于网络。换句话说,用户的业务,根本上是一大堆的服务器,在对外提供服务的时候,是通过网络、并依赖网络。如若不能了解这些通过网络提供的业务,实际上是无法评估一套网络的质量好坏,也无法理性地判断一套系统的性能快慢。而且在出现各种问题、故障时,也没有更好的办法快速定位、及时解决。这时,从网络的角度出发,去洞悉网络中流经的各种流量,准确的说是各种业务、各种服务的流量,是数据包,通过分析这些流量,可以准确的获悉网络中的流量分布,可以得到一套系统在网络上传输的质量好坏,可以综合评估业务系统的性能好坏。更为关键的是,这些都可以通过一个可视化的、灵活方便的、顺其自然的平台来实现。而且,这个平台的投资,其实是远低于用户对IT基础建设的投资,并能得到丰硕的投资回报。这其实也回答了本段开头来自一些用户的前两个问题。

当然,这并不能解决所有问题,举个例子,有一次去某省运营商用户重要的计费部门沟通NetScout流量分析系统。用户很有想法,也提出了很多预期,希望NetScout能解决所有问题,大概意思是买了NetScout以后,是否就可以躺在家里睡大觉,能自动的被告知哪个营业部可能会有问题,出现问题后是在什么位置出现的,什么原因导致的,怎么解决,怎么改进。还有国内某知名保险行业用户,希望能通过NetScout实现对细微操作的分析,比如营业员点一个操作,要能自动分析出该操作的具体过程和各个过程中细微的响应分析等……其实,这都是正常的需求,都是可以理解的,我站在他们的角度我也希望能有这么一套系统,这对用户的业务保障将发挥巨大作用。我也相信随着技术的发展,有朝一日终能有这样的产品问世,来造福我们的IT人员,并解脱我们“起的早、干的多、睡的晚”的囧境。而就目前来讲,也许还真没有这样一种全能产品来满足这种全方位的需求。但我想表达的是,如果有部署NetScout这种基于数据包的流量分析系统,这些需求虽不能自动完成和完美的分析出来结果,但至少能让我们快速的看出点端倪,并会有分析问题的方向。而如若没有类似基于数据包的流量分析系统,那可能就真的对此没有任何办法,只能在面对性能问题时无法拒绝各种供应商的各种扩容方案。其实,我们完全可以借助当前的网络流量分析技术,在面对各种网络异常、应用性能问题时灵活、快速的定位问题,找到根源。当然有一点是,这不是万能的。

下面根据NetScout用户的一个非常简单的例子,形象地说明一下,利用NetScout这个KFP的分析思路,稍微改变一下日常工作的问题处理方式,在出现问题时,定能发挥相当大的作用。

背景:

某运营商IDC托管机房网络基础设施升级改造,这是好事。随着业务的发展壮大,网络流量也持续增加,之前的设备性能已无法满足增长的网络流量。某期升级改造过程中换上了性能更强的防火墙,安全性更好的同时保证了更好的性能。该用户没有部署类似NetScout的流量分析系统。

问题:

某天开始,外网用户访问该IDC托管的业务服务器时明显变慢,内网用户访问外部系统时也明显变慢。共同点是大家都穿过了新升级的防火墙。

一般分析思路:

很明显,肯定是防火墙出了问题,因为经过用户分析,只要穿过新升级的防火墙,就会有慢的现象,而一旦避开此墙,则恢复正常。那问题的重点自然而然就落在了防火墙身上。经查,该新升级的防火墙确实有异常,从问题发生开始,防火墙的CPU、内存利用率明显升高,经过用户、集成商和防火墙厂家的多方努力分析,始终无法找到根本原因,只能推测是防火墙的性能出了问题。

NetScout分析思路:

还好,这个问题困扰了他们几天后,他们找到了我们。毫不夸张的说,我们在配置好分析的设备、要求用户在防火墙里面的交换机上做了个镜像后,只用了2分钟、共三步就定位了问题原因并告知用户快速解决了这个问题。首先宏观地观察流量的组成部分,这也是KFP分析思路中的K,即KPI。了解网络中的各种现象,包括流量大小、组成分布、响应快慢等。

通过这个饼图,我们发现了37%的DNS流量,第一反应这几乎就是有问题的,正常的网络中,不太可能有超过三成的DNS流量。没关系,这只是鼠标轻轻一点的时间,我们再来看下37%的DNS流量是谁引起的,也就是KFP分析思路中的F,即Flow,是哪些IP地址、哪些会话引起了这个现象。

很明显,是41.98这个该IDC机房托管的一台业务主机到一个国外的93.120.73.193的DNS请求引发了这37%的DNS流量。

这实际上已经可以做出判断了,是41.98这台主机由于某种原因(病毒、攻击等)导致发送大量DNS请求经过防火墙出去,最终影响了穿越防火墙的所有网络访问。隔离该主机后,问题立刻得到解决。下面是隔离该主机后,DNS流量恢复正常。

一般问题到此已有定论,故障也已解决,倘若想继续挖掘问题根本原因,可进一步解码分析,也就是KFP分析思路中的P,即Packets,因为数据包是不会说谎的,数据包总能告诉我们事情的真相。

通过Sniffer解码发现,都是41.98这台主机到93.120.73.193的非正常DNS请求,时间间隔几乎为0,而且都是64字节的UDP小包,造成DNS风暴,导致防火墙性能下降,影响通过防火墙的各种业务访问。至此,一个完整的问题分析过程就结束了,这在实际操作中就是点几下鼠标、上下文相互关联分析的过程,2分钟就把困扰用户多日的“疑难问题”迎刃而解了。

这个简单的故障诊断问题分析反应了一个工作方式的改变,那就是通过网络、透过网络、借助网络,在网络中捕获数据包,通过数据包来展示网络性能、业务性能,再配合用户之前的各种知识经验积累,一定会有明显不一样的改变,一定会带给用户非同凡响的分析体会。这只是万万千千用户分析案例中非常简单的一个,只是想表达一个想法,借助网络数据包,通过灵活、易用的分析平台,稍微改变下思路,优化一下工作方式,也许就会发现,其实抓包也没那么高深莫测,故障诊断也可以信手拈来,性能问题同样可以迎刃而解!

——Eric