以“服务为中心” 今非昔比的网络故障诊断 5月01

Tags

Related Posts

以“服务为中心” 今非昔比的网络故障诊断

Netis自主研发的CrossFlow产品线发布不久,已经获得了中国银联、招商银行、北京移动等诸多客户的认可。相较于传统网络管理方式,“以服务为中心”的CrossFlow NPM一出现即让大家又惊又爱。本期,我们采访Netis 产品部Head —— Wizard He,一起探讨网络故障诊断的变革,听听CrossFlow NPM的神奇之处。

注:Wizard简称W

随着网络地位的日渐提高,网络的定义已经产生了巨大的变化,要谈谈今非昔比的网络故障诊断,首先让我们重新理解这今非昔比的网络。

W:我们都已习惯地将网络看作提供基础架构。其实在很多大规模的金融机构或运营商里,这个概念已经在被慢慢调整。为什么呢?因为如果仅仅把网络看成是一个基础架构,它就无法抽象成网络对上层应用提供的支持。这样一来,网络的地位其实是被自己给放低了。

那么,它对应用提供着什么样的服务呢?

W:事实上,我们可以通过这个问题来理解网络的重要意义。

首先,网络能对上层的应用提供连接的支持。不基于网络的应用根本不存在,哪怕是SNA,也是over在IP上面的。

第二,网络是直接面向应用提供服务的。目前很多应用的开发过程其实是一个局域网的应用。但如果要交付出去,它就成了一个广域网的应用。局域网跟广域网的场景是完全不一致的。这两者之间带来的延迟、性能影响,也是不一致的。这时,在网络中,我们能够将这些情况测量出来,并且精确地说出网络对应用的影响到底是什么。

第三,不同的连接方式适用于不同的应用模式。比如TCP的连接方式就非常多。第一种是常规的TCP连接,3次握手;第二种是TCP的长连接,建立完连接后,这个连接就不拆掉;第三种叫做TCP的异步双工的长连接,这是完全不一样的一种连接机制。

此外,还有一些额外的附加功能,比如负载均衡。传统而言,诸如像F5、Radware、思科的ACE这样的一些设备,是一种负载均衡。但很多时候,像IBM message queue MQ这样的服务,是在主机内部做多通道的负载均衡。在多通道的机制下,一旦出现消息的堵塞,主机的管理员是很难判定出这样一个事件的。即使MQ这样的监视工具,最快也需要5分钟才能把问题挖掘出来。但基于网络,我们可以快速地了解到这个问题。通过观察TCP多通道连接,了解哪个TCP的通道里跑的流量是最大的,Flow的数量是最高的。由此可以判定最多的TCP通道跟最少的TCP通道之间的差值。差值一旦超过原先设定的阈值,就会自动产生告警。

由此可以看到,网络对我们而言不仅是一个基础架构,更为我们提供了非常多有价值的东西去挖掘。这些都是网络能够对应用提供服务的一种体现。而这,也引出了我们CrossFlow NPM最初的设计理念——“以服务为中心”。

在CrossFlow NPM产品在网络故障诊断中是如何实现“以服务为中心”的?

W:第一,我们叫“服务路径图”(Service Path View)。它是一个可视化的网络服务路径,完整地在所见即所得的视图里,为用户融合并还原网络设备、应用设备,梳理业务逻辑和服务路径。因此,仅在一张视图里就可以对问题进行分析和处理。

第二,是我们的创新的专家系统。专家系统引入了服务场景与应用场景的概念。怎么理解呢?比如在广域网组中,由于带宽的限制发生了一些TCP重传,这是非常常见的。但若在一个局域网里,以万兆进行连接,两台服务器连接在一台思科65上,这时再产生大量的重传就不合理了。所以,我们的专家引擎引入应用场景,它会去分析这到底是广域网还是局域网。同时,广域网还有两种属性,外连机构还是分公司。很多时候分公司的应用都是可控的,但如果是外联机构,这就可能意味着争议的产生,是需要具体区分的。所以,我们的专家系统还融合了服务的场景。

第三,是我们的指标统计。一旦故障发生,尤其是比较重大的故障,我们需要快速切换到关注的环节,选择关注的时间段,看到一些实时化的指标:实时的流量、实时地看是否有一些TCP的重传和重置、实时地看当前连接的客户端数量是否发生了变化……这样,才能够最快速地处理和解决问题。

第四,自动故障诊断和定位。当早期预警根据专家系统告诉我们,现在有个分公司的建连不成功,我们可以点击自动化故障诊断。详细的诊断结果会告诉我们,到底是哪个分公司,因为什么原因才发生了建连不成功。同时,在Web界面的视图中显示故障位置、故障样本。

第五,早期预警。它可以帮助我们将传统意义上的被动诊断走到事前。在服务动态视图里,如果部署了抓包点,就会在服务路径视图里有所标示,指示我们抓到多少可能会对服务产生影响的事件。

最后,是我们的故障案例知识库。一旦发生一个事件,我们希望将来可以防微杜渐,希望在内部形成一个比较好的交流机制,可以在广域网、局域网、网管组内对发生的事件一起探讨,这时就需要一个能再现事件发生场景的案例库。

将故障诊断从事后推进到事前,果真是往日不可比拟的大跨越。它需要什么前提条件吗?

W:是的。它需要三个基本要素:第一,网络服务通道的可用性,比如:建立连接的成功率、连接是否异常终止等;第二,网络自身的性能,比如:是否存在丢包、重传,是否设置不当导致性能瓶颈等;第三,网络负载量,像并发连接数、流量/客户量等等。而以上介绍的,就是CrossFlow NPM产品以“以服务为中心”为核心思想,集合起的六大功能的一个重要模块。

除了故障诊断之外,CrossFlow NPM是否也能助紧张的排障工作一臂之力?

W:我们在实时监测所需要保障的重要服务时,有些用户会说,“我需要保障的服务非常非常多,我不可能只盯着这个界面去看。”这没有问题。第一,我们可以把产生的一些告警全部发送到用户的告警平台,在里面呈现出来。第二,针对故障的投诉,我们可以看一些指标的变化。通过查看一些早期的预警,我们可以明确指出网络层是不是有异常,把问题给定位出来。定位出问题,排除故障,服务重新恢复后,继而保存现场,形成报告。同时,报告还能够变成最终需要展现给相关部门的一个案例库。所以,这是我们的一个期望,希望能够重塑原先网络部门一般分析网络故障的流程。

CrossFlow NPM是怎样征服用户的?有故事可以与我们分享吗?

W:有趣的故事非常非常多。就拿我们的某个银行客户来说,我们分析过他的一个网银问题,就是他的CPU的利用率间歇地会达到100%。当时就非常的奇怪,为什么会间歇性的达到100%?他们安全组的人员发现,当CPU达到100%的时候,网络当中有非常多64字节的小包,这简直就是一个典型的安全的案例。他的安全组分析了两个礼拜,依然没有结果。

这时,他们网络部门介入,而我们正是协助于他们网络部门。我们非常清楚整个银行的网元架构。它的前面有负载均衡设备,然后Web Server,Web Server后又有负载均衡,接着应用服务器。应用服务器连他的数据库,数据库之后连他的前置,到他后面不同的电子渠道里面去进行访问。

Web Server有间歇性的CPU利用率100%,所以,我们抓的数据很简单,仅把Web Server前面的那段数据都给抓出来,就是负载均衡设备的前后,也就是Web Server。所以,Web Server前也就是这两个最关键的路径。

这个时候,通过CrossFlow NPM去分析、判断,而我们发现了一个很有意思的现象:那些小包都在负载均衡设备后出现。

那么到底是什么小包呢?我们需要对它分析一下。如果都是syn包,又是64字节,那就是syn flood,这是很容易去判断的,但可惜不是。实际上,它们都是Fin包,有大量的64字节的Fin包出现在负载均衡设备后。Fin包是用来拆链的,拆链是不是正常也是我们一个重要的判断依据。我们再去判断Fin包什么时候出现。根据分析,在负载均衡设备向服务器声明零窗口的时候,就会出现Fin包。Fin包多到什么程度?多到一秒钟有十几万个,这是Fin Storm。我们知道,百兆以太网一秒钟最大有14.8万个数据包传输。在这里,虽然是千兆的连接,但十几万个数据报文,都是小包的话,加上原来业务的流量,就足以让他的HP的CPU利用率达到100%。当时,我们很快就判定出来,这是个负载均衡问题。这是因为,在负载均衡设备前没有出现这个问题,而在负载均衡设备后出现了。但那个Fin包,首先从负载均衡设备发起的,是由负载均衡设备这边声明了零窗口后,他才有这样一个现象。

后来,我们联系了F5的厂商。我们很明确向他们指出了这样的一个问题。他们承认说,这是F5的一个BUG。当F5自己的性能达到极限时,当声明零窗口的时候,可能会触发Fin storm,就是Fin风暴这样一个现象。

困扰用户两个礼拜的问题,通过我们CrossFlow NPM的一些指标迎刃而解。“以服务为中心”的理念,CrossFlow NPM的价值,就这样让我们的用户深深感动。

可以通过哪些方式对CrossFlow NPM了解更多呢?

W:大家可以登陆我们Netis的官方网站www.netis.com.cn 了解我们的CrossFlow 产品线,也可以关注我们的官方微博(上海天旦网络)、《奔流》杂志等等,我们期待与更多人分享与探讨“以服务为中心”的理念。

Netis产品部门的每一个人都是充满信念和斗志的战士,为了CrossFlow产品线的日臻完美,他们披星戴月、披荆斩棘。一个新版本的Release是下一战斗的开始,他们从未松懈。难怪乎,我们的CrossFlow NPM产品会给客户带来如此之大的惊喜。我们一起期待他们在CrossFlow NPM和BPC不断创新的征程中获得更大的成就!