透过MH370看网络自动化监控

引子

MH370已经消失4个月了,这个严重的灾难也被蒙上了神秘的面纱,找不到消失的任何记录。也意味着,马航无法确保这种事情不会再次发生,人类生活在恐惧中。这就运营者需要面对的压力——避免故障。当飞机过于依赖自动系统,而未对运行状态进行监测的时候,运营者实际上对故障发生、进展、举措是无能为力的。网络上的运营也是一样,如果无法了解网络运行状态,运营也只能靠运气,我们要通过一些技术手段逐步驱散笼罩在运营上空的恐惧。

挑战

网络监控是一个老话题了,有一个现象非常形象地描述了这种状况——网络出现故障后,往往是网络业务最先发现业务受到影响,然后运营监控大屏幕会出现流量图陡降,再然后才是运营者们开始挨个服务器/设备地ssh/telnet抓取信息,试图查找问题所在。

目前也有网管,可以对网络设备的链路状态、资源利用率,还有许多日志记录路由邻居的变化、登陆操作记录等等。就运营角度来说,这些记录都是网络原子事件,还缺乏一种手段对这些原子数据进行系统性分析,得出更有益的结论,如——2台设备之间的路由协议邻居关系中断是因为2台设备之间互联链路中断造成的,或者更进一步,某条链路中断后,其余设备的路由应该是变成什么样。

聪明地迎接挑战

当前的挑战是网管是监控原子信息,运营监控故障往往会慢业务一拍,运营排障基本靠人。解决思路尝试将运营排障思路固化,描述成机器可以运行的程序,这个程序对网管原子监控信息进行bigdata分析处理,实现更实时和自动化的网络监控——智能报警和智能定位。

原理与案例

图1 Multi-Root结构的数据中心网络

结合案例分析原理会使这个方案更接地气。如图1所示,当前的数据中心已经是一个典型的Multi-Root,2或3级的拓扑:

l 网络运行的核心是路由;

l 路由的来源是基于网络拓扑的IP分配;

l 网络拓扑和IP分配则来源于网络规划;

l 有规划意味着路由计算有正确范本。

网络中每一台设备的路由形成都源自于在这个拓扑结构上的IP分配,拓扑的和IP分配都是来自于网络规划,而规划信息是运营者最终判断路由学习是否正确的依据——我们称之为范本。

来看一下数据中心内就范本用于以一台Spine交换机为Root的转发路径路由判断的案例:

图2 数据中心内Spine-Leaf间路由、MAC-ARP-VLAN判断

如图2,Leaf ToR Switch2的接入子网是10.10.0.64/26,在

1. Spine Switch与Leaf ToR Switch2之间的路由邻居关系是正常的;

2. Leaf ToR Switch2上的接入子网是Up的。

Spine Switch上就应该有一条路由10.10.0.64/26 next-hop是Leaf ToR Switch2,否则,路由出了问题。

1. Spine Switch与Leaf ToR Switch1之间的路由邻居关系是正常的;

2. Spine Switch上有10.10.0.64/26这条路由。

Leaf ToR Switch1上也应该有一条路由10.10.0.64/26 next-hop是SpineSwitch,否则路由也是出了问题

多条经过不同Spine的转发路径形成相互独立的ECMP关系,因此通过独立地监控不同Spine形成的转发路径即可对网络进行完整地监控。除了路由的监控,对于数据中心服务器的NIC-VLAN-IP-MAC和交换机端口对应关系也可以形成范本,在图2中:

l 服务器的范本并不是规划得来的,而是基于当服务器上架之后手工信息的录入,这些信息通过Server DB进行维护;

l 这些信息包括服务器NIC名,连接交换机名和端口编号,NIC上配置的VLAN-IP-MAC的对应关系,这些信息Server DB也可以通过对服务器采集进行比对,确保录入信息的准确;

l Server DB保存的信息传递到网管系统后,经过处理可以得到服务器的ARP-交换机VLAN关系,MAC-交换机端口-VLAN对应关系,这就是范本;

l 将各个ToR上采集到的ARP、MAC信息和范本进行比较,就很容易判断出是否有服务器使用违规IP进行通信,是否伪造MAC等;

这种原理也很容易推广到一些更复杂的场景,比如路由聚合,大多数网络规划都会将数据中心园区外部的路由以汇聚路由的方式发送到数据中心内部,汇聚路由的处理往往会比较复杂,涉及到汇聚路由的协议类型、distance、协议内优选顺序等等,稍有考虑不周,汇聚路由就有可能不会发送到数据中心内,而从规划角度,汇聚路由下发条件很简单,以图3为例:

图3 通过园区Border对园区内外路由进行聚合

l Border是数据中心园区的边界,是路由汇聚点,连接着多个园区数据中心和园区外网络;

l 规划要求是只要Border上有非数据中心1始发的10.0.0.0/8范围内的路由(如数据中心2的路由和园区外路由),数据中心1就应该有一条10.0.0.0/8的路由指向Border;

l 为了避免其余路由协议邻居故障导致一些路由消失影响路由汇聚,往往会在Border添加黑洞路由引入路由协议的方式,增加了方案复杂性,对于整个方案工作正常与否,非常有必要对数据中心内的汇聚路由进行监控。

根据对以上场景的分析,对聚合路由的判断可以形成非常简单的范本,可以抛弃Distance、协议内外优选原则等,要远比路由协议的判断要简单:

1. DataCenter1 Spine与Border间的路由邻居关系是正常的;

2. Border上存在next-hop不是DataCenter1 Spine的10.0.0.0/8范围内的路由,这些路由有可能是来自于另外一个IDC,如DataCenter2,也有可能来自于Border外部的网络;

3. DataCenter1 Spine上就应该有一条路由10.0.0.0/8 next-hop是Border,否则,路由出了问题。

同样的,这个范本可以推广到Leaf上:

1. Spine Switch与Leaf ToR Switch1之间的路由邻居关系是正常的;

2. Spine Switch上有10.0.0.0/8这条路由;

3. Leaf ToR Switch1上也应该有一条路由10.0.0.0/8 next-hop是Spine Switch,否则路由也是出了问题。

虽然路由是网络转发的核心,而实际的网络中,会因为ECMP路由的原因,底层的转发表FIB在转发时使用hash的形式选择唯一的路由,对FIB hash的评判是“是否足够均匀”,而这方面的监控一直是空白:

l 所有匹配同一条路由的数据包在转发平面被不同的因子(如5元组、3元组、2元组等)定义成不同的流,不同的流通过hash算法映射到这条路由不同ECMP上,由于流的定义和流量大小没有关系,因此实际的ECMP链路利用率并不是规划中的流量负载均衡,而是流数量负载均衡;

l ECMP目前的监控也是比较薄弱的,有可能出现这种情况传统的网管是不会告警的,ECMP路由正常,但转发流量却一边是100%另外一边是0%,智能的网管应该产生告警,让我们检查一下是否hash的因子没有配置正确或者设备出现了故障;

l 在路由层面的ECMP确定好outputinterface正好是一个LACP聚合组,在流量在LACP聚合组内形成L2ECMP,这时候同样采用hash进行流数目负载均衡,也会出现物理端口在LACP中处于active成员状态,但实际链路利用率相比于其余链路利用率低很多的情况,这种情况也同样应该进行告警。

既然判断的准则是均匀,而每个物理端口上的流量信息也是可以通过网管进行采集的,因此程序进行判断处理也不会复杂:

图4 路由形成的L3 ECMP和LACP形成的L2 ECMP场景

ECMP有L3和L2两个层面,比如Leaf1上就是2条L3 ECMP路由

1. 每条activeroute都对应一个output-if;

2. 两个output-if的流量负载采集后在后台进行对比分析。

如果route1对应的output-if负载达到80%,route2则只有20%,这说明我们需要分析Leaf1上的L3Hash因子。在Spine1的情况会复杂一些,因为这是一个L2/L3混合ECMP场景:

1. L2ECMP首先要检查所有成员链路状态是否是selected;

2. 将有selected成员端口流量负载采集回后台分析。

通过后台分析,可以得出2个LACP组之间L3ECMP均衡是否正常,也可以判断某个LACP组内L2均衡是否正常,如果不正常,运营的同事可以提前介入调查,是否需要调整hash因子。

意义

从这些案例,可以总结出,只要人可以判断的网络故障,将判断条件固化之后,网管系统也可以进行判断,并且会比人的判断更加迅速和实时。

更深远的意义在于,正常情况下,人只能一台一台设备地检查是否有故障,效率低下,准确率还会因为人的疲劳程度有所变化,而采用网管系统则不会存在这个问题,对于数据中心内的海量设备,它可以轻松完成巡检,将一些配置上存在的问题、稍纵即逝的bug都发现到,可以在网络稳定时解决这些问题并且推动厂家优化实现网管响应方式,延长无故障运行时间,是一种治未病的方案,这种机制可以使MH370这种不知所踪悲剧发生的概率大大降低。

对于网络的自动化监控是一种智能的体现,本文介绍的案例只是开始,更智能的监控我们会在后面几期文章中进行分享。

原文发布于微信公众号 - 鹅厂网事(tencent_network)

原文发表时间:2014-07-30

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏顶级程序员

Wi-Fi 爆重大安全漏洞,Android、iOS、Windows 等所有无线设备都不安全了

移动设备横行的时代,Wi-Fi 已成为现代人生活的必备要素之一。但近日有计算机安全专家发现,Wi-Fi 设备的安全协议存在漏洞,如今用于保护 Wi-Fi 网络...

35140
来自专栏工科狗和生物喵

总算搞定了域名(好吧,我一开始忘了)

正文之前 我是从大二下学期开始入程序员这个坑的。那个时候恰逢遇到了我计算机方面的启蒙学长,然后他带着我走了一段很长的路,其中就包括网站建设这个方面。我前端后端都...

754130
来自专栏Albert陈凯

2018-06-21 Java技术栈知识小全--东西有点多,很有料

原文地址:https://github.com/aalansehaiyang/technology-talk

11030
来自专栏程序人生

从 gitlab 事件中吸取的教训

题注:这是一篇去年的文章,今早看到 gitlab 运维人员愚蠢地 rm -rf, 心有戚戚焉,故而重发这篇文章,供大家参考。 ---- 这两天不是很太平,程序圆...

397100
来自专栏大数据文摘

深度解析12306数据泄露之谜

32420
来自专栏知无涯

Ubuntu 15.10 中文桌面版/服务器正式版下载 - 华丽免费易于入门的 Linux 操作系统

671100
来自专栏Jerry的SAP技术分享

SAP成都研究院李三郎:SCP Application Router简介

作为成都研究院里同时精通Java, JavaScript和ABAP这三门编程语言的数位同事之一,Ben曾经先后担任了成都CRM Fiori开发团队,S4CRM开...

44260
来自专栏Web 开发

我也来刷到CM7.1

2011年10月10日,著名的的Android第三方ROM团队CyanogenMod发布了最新的稳定版CM7.1,同时提供大量机型的支持~

8600
来自专栏智能大石头

MF前传——探索者二号简介

   因为探索者一号供不应求,远超预期,并且我们自己设计制造的成本太高,所以没有再次生产。而是选择较高性价比的第三方STM32开发板作为MF学习板,是为探索者二...

241100
来自专栏FreeBuf

看我如何破解一台自动售货机

毫无疑问,自动售货机是非常受欢迎的东西,我们总会从中购买获取一些小零食。早几年前,自动售货机只接受离线的硬币支付,之后,也慢慢采用了普及的NFC技术功能。如果我...

2.3K30

扫码关注云+社区

领取腾讯云代金券