让网络运维更智能 4月01

Tags

Related Posts

让网络运维更智能

1.前言

随着我们的网络规模日趋庞大,网络工程师设备运维工作的压力也越来越大,如何找到一种高效的设备管理方法,也成为了每个网络运维工程师所关心的一大问题。以路由器管理工作为例,当网络中的路由器数目还不算太多的情况下,工程师们可以依靠自己熟练的技术及灵活的思维来妥当完成运维的工作,但是在设备数量呈倍数增长的今天,如果没有一个行至有效、完善的工作流程,那么保障网络及几十上百台路由器的健康,将是一项不可能完成的任务。

在《TCP/IP路由技术(第二卷)》一书的第九章就提到,“为了保证网络和众多路由器的健康,必须保证能够管理它们,包括主动式管理和被动式管理。此外,利用实验室或工具来测试和监控转发机制的效果,以确保网络和路由器能持续平滑地运行。”同时,文中也提供了一些有效的方法,如果我们用Mind Map把这些思路整理出来,便可以形成如下图所示的一个整体方案:

从Mind Map中可以看到,《TCP/IP路由技术(第二卷)》把路由器管理工作的要点分为4大类,包括策略及规程定义、监控协议、日常管理以及记账,而每个大类中还有许多分支的工作需要完成。可见路由器管理并非一件轻松的差事,那么面对这么多的细致工作,有没有一个办法能把它们有效的整合,从而提高我们的工作效率呢?

答案是肯定的。看到《TCP/IP路由技术(第二卷)》一书对路由器管理工作给出的定义及工作内容,我们很容易就联想到了Splunk,以及5位Cisco安全工程师利用Splunk来对分布在全球的众多防火墙进行管理的故事,既然已经有了这么一个高效管理网络设备的典范,我们也可以依样画葫芦,来探讨利用Splunk来高效管理路由器的可行性。下面我们就以Mind Map中描述的路由器管理工作作为思路,来做一一分析。

2.策略及规程定义

如果没有清晰的策略及规程,几乎不可能成功的管理大量路由器,必须用文档确定操作策略,明确不同的负责人以及各自的责任时间,当路由器的配置发生变更后需要用相关的文档记录下来,而当更熟练的工程师开始处理网络问题以及涉及网络管理时,规程则规定了需要遵循的步骤。

在规定用户期望从网络中获得相应QoS的策略时应包含相应服务不能满足时所要采取的动作,这些就被称为SLA。

2.1 SLA

SLA中规定的服务数量可以是向用户保证的响应时间和吞吐量等关键性能指标,一般也以网络可用性的百分比来表示,其余包括故障最大时间、计划故障时间以及故障恢复时间等,也是衡量一个网络SLA的重要指标,这部分内容需要由文档进行规范,而管理员需要把SLA规范熟记在心,而随时监控SLA中所规范的性能指标。

根据实际情况制定好SLA规范以后,我们就可以开始监控工作了。利用Splunk,我们可以对违反SLA规范的事件次数进行监控,以便对我们的网络管理工作重点进行快速调整。

如果我们对服务系统的业务响应时间有明确的SLA规范,那么对于系统的实时响应性也应该实时进行监控,以SLA规定的响应时间为基准线,了解当前系统的响应性能情况。

为了有效测量当前业务系统响应性能,我们需要选用一些外部协议工具,IP SLA是一个不错的选择。使用IP SLA的路由器可以执行周期性测测量,测量次数以及可用的测量类型十分丰富,例如ICMP ECHO作业以及TCP连接作业等。唯一的问题在于如何获取IP SLA的测量结果,现在,我们可以通过Netis的NTR引擎,将IP SLA测试包的交互情况汇总成为具体的响应时间数值,并通过Splunk进行实时监控。当然,直接通过业务数据交互的连接情况,也可以通过Netis的NTR引擎计算出当前服务的响应性能,并且通过这种方法获得的响应时间指标更加客观直接。

2.2 变更管理

变更管理策略是说明何时可以实施变更、由谁实施变更、如何记录和发布即将实施的变更以及如何记录整个变更的情况。

虽然每个企业的变更管理系统不尽相同,但无论是什么类型的变更管理系统,理论上都可以通过SQL语句或是自带的数据导出接口获取变更记录细节,进而我们可以在Splunk中将其展现出来,来打造我们的路由器统一管理平台。

2.3 上报规程及更新策略

明确定义的上报规程有助于清晰化每个工程师职责,同时尽可能节省故障处理的时间。而更新策略的重点在于通知与执行。利用Email或电话来进行沟通固然是最好的方法,但如果可以使用RSS来发送故障或培训通知,并利用Splunk的RSS Apps来进行接收,则不仅可以把所有事件都有效保存下来,也能够使我们的运维工作更加智能化。

3.监控协议

3.1 SNMP/RMON

SNMP及RMON都是常用的网络管理协议,管理员通常可以利用SNMP来获取设备的运行信息,例如CPU利用率、内存利用率以及端口流量大小等,而RMON则大大的增强了SNMP所提供的能力,让管理员能通过管理平台查看更多关于节点以及节点间交互的信息。

我们尝试在Splunk上实现基于SNMP的路由器设备监控,为了让Splunk服务器可以接受到设备的SNMP消息,需要借助一个叫做Net-SNMP的小程序。Net-SNMP是一个针对SNMP的工具集,包含了多个处理SNMP信息的小工具。

对于路由器上预先设置好的SNMP Traps,需要使用Net-SNMP中的小工具snmptrapd来进行接收,并保存到一个文本文件中,snmptrapd的命令格式示例如下:
snmptrapd -Lf /opt/net-snmp/snmptrap.log –disableAuthorization=yes

命令运行后snmptrapd工具会开始接收设备发送过来的SNMP Trap,并记录在文件/opt/net-snmp/snmptrap.log中。

除了接收设备发送过来的SNMP Trap之外,当然还需要监控设备运行状况的数据,于是我们可以借助Net-SNMP中的另一个小工具snmpwalk,snmpwalk可以向路由器设备请求设备运行状况的相关数据,命令格式示例如下:
snmpwalk –v 2c –c public 10.0.0.155

其中2c为SNMP协议的版本号,public为设备与服务器协商的community字符串,10.0.0.155则为路由器设备发送SNMP信息的源端口IP地址。

此时屏幕输出许多数字串,看起来似乎没什么意义,但实际上这些数字串为设备存储在mib库中的oid,每一个数字串都代表一个设备运行状况的指标,因此在这里我们需要进行一些简单的翻译工作。由于每一个厂商及设备的oid规范不禁相同,以Cisco路由器为例,我们需要借助厂商提供的mib查询工具(http://tools.cisco.com/ITDIT/MIBS/MainServlet)来进行查询每一个oid的具体含义。而我们也可以根据查找到的oid利用snmpwalk工具来得到我们所需要了解的设备信息,例如,我们查询到Cisco路由器avgBusy5(CPU5分钟利用率的平均值)的oid为.1.3.6.1.4.1.9.2.1.58,我们可以把snmpwalk查询的命令修改为 snmpwalk -v 2c -c public 10.0.0.155 .1.3.6.1.4.1.9.2.1.58 >> /opt/net-snmp/snmpavgbusy5 并且利用crontab等任务计划工具让命令按一定的频率自动运行,同时把结果输出到/opt/net-snmp/snmpavgbusy5文件中。

如此一来,我们只需在Splunk中进行简单的处理,便可以对设备的CPU利用率进行监控了,如果有必要,我们还可以把SNMP的采样时间频率提高,得到更精确的路由器运行指标。

4.日常管理

4.1 日志记录/syslog

要掌握网络中众多路由器的运行状况,日志记录当然是必不可少的工作,一般网络设备都会有日志记录的功能,但是要将这些日志发送到我们的统一监控平台上进行管理查询则需要用到syslog,syslog是一个运行于Unix服务器上的守护进程,会收集信息并存储在日志文件中,那么Splunk只需对这些日志文件进行监控即可。

为了让路由器的日志能够通过syslog发送到Splunk服务器上,首先要在路由器上做好相关配置,以Cisco路由器为例,命令示例如下:
Router(config)#logging 10.0.0.150(配置 syslog服务器地址,可以定义多个)
Router(config)#service timestamps debug datetime localtime show-timezone msec
Router(config)#service timestamps log datetime localtime show-timezone msec(syslog 信息包含时间戳)
Router(config)#logging facility local3(定义 facility 级别,缺省为local7,可以设置从 local0到local7)
Router(config)#logging trap warning(定义severity 级别缺省为 infor级别)

同时,我们还需要配置好Splunk服务器的syslog进程来接收路由器的日志消息,具体方法如下:

  1. 修改/etc/sysconfig/syslog,把SYSLOGD_OPTIONS=”-m 0″ 修改为SYSLOGD_OPTIONS=”-r -m 0″
  2. 修改/etc/syslog.conf ,增加local6.* /opt/net-snmp/routersyslog.log 一行,把设备号为local6的设备日志保存在/opt/net-snmp/routersyslog.log文件中。

完成后,所有指定的路由器日志将会保存在在Splunk服务器的routersyslog.log文件中,我们便可以开始利用Splunk来对这些日志进行加工分析了。

4.2 配置管理

为了确保能将最近的配置恢复到路由器中,我们需要维护所有网络设备的配置文件,并周期性的下载所有的配置文件,这样做不仅可以在路由器配置丢失时可以快速恢复,同时也可以方便我们将所有配置都作为历史记录有效保存。

我们知道在Cisco的路由器中,可以通过命令Router#copy running-config tftp来把当前运行的配置保存到tftp服务器上,但是如果可以自动、定时的完成配置的保存会不会更智能?幸好路由器厂商们已经帮我们想好了这个问题,以Cisco路由器为例,我们可以通过以下的配置来自动、定时的将设备的配置保存到我们的tftp服务器上:
Router(config)#kron policy-list tftp
Router(config-kron-policy)#cli show run | redirect tftp://10.0.0.150/r2-config
Router(config-kron-policy)#exit
Router(config)#kron occurrence tftp at 23:28 Sun recurring
Router(config-kron-occurrence)#policy-list tftp

我们已经定义好让路由器每个周日的23:28自动将配置保存到tftp服务器上,那么接下来的事情就只需要在Splunk服务器上开启好tftp服务便可以了。

路由器已经自动将运行配置以文本文件r2-config的形式保存到了tftp服务器上,接下来的工作就变得简单了,只需在基于Splunk的统一管理平台中做好相应的界面进行查询展示即可。

4.3 故障管理

可信赖的网络需要良好的故障管理机制,需要尽可能快地发现潜在和现有故障,以便快速采取措施来解决问题,希望在用户感知网络故障之前,网络管理平台就能检测到设备的链路故障。

采用SNMP Trap来进行故障管理是一个选择,但是由于SNMP利用UDP来发送Trap,因而无法保障描述故障的消息能够到达管理平台。在《TCP/IP路由技术第二卷》中给出另一个建议,采用ICMP ping对路由器进行轮询,以确定每个路由器是否可达,因此,IP SLA的ICMP Echo作业也是一个不错的选择。

除此之外,我们知道Splunk可以通过运行脚本来获取数据,我们可以建立一个简单脚本,内容是只是去ping一些IP地址,然后在Splunk的管理->数据导入->脚本界面中增加该脚本的数据源,并设置好脚本执行的时间间隔。

完成以后Splunk便会定时获取脚本的运行结果了,下图便是Splunk定时获取脚本中ping 22.0.0.1 –c 10的执行结果。

有了轮询路由器的方法以及结果,接下来我们便可以利用这些数据来进行视图的编辑以及告警的创建了。

4.4 安全管理

路由器的安全管理主要在于三方面,一是加密认证的方法,主要是依赖于密码管理以及外部认证系统,我们可以利用Splunk的集成来完成这部分内容;二是访问控制列表的管理,这一点我们可以通过前面配置管理的方法来进行监控;三是路由器行为的监控,我们可以通过日志监控来实现这个目标,另外Splunk提供的几个Cisco Security的app也可以很好的完成这项工作。

4.5 NetFlow

收集流量流的统计信息可以用来计算网络的使用率情况,特别是在实施流量工程或基于使用量对网络用户进行审计时。这样NetFlow就是一个非常有用的功能,NetFlow可以在路由器上标识出各种流量流,并把统计信息导出到管理平台上。

为了让基于Splunk的统一管理平台能够读取到路由器的NetFlow统计信息,我们需要在Splunk主机上借助一个叫做Flow-tools的小工具,Flow-tools是一个运行在Linux下的简易工具,专门用来收集NetFlow的信息,并且还可以将这些信息导出成为文本文件。在配置好路由器的NetFlow以后,可以在Splunk主机上下载并安装Flow-tools,然后建立一个文件夹来存放收集的NetFlow数据:
mkdir /opt/netflow

运行/usr/bin/flow-capture -N -1 -z 6 -n 250 -V 5 -w /opt/netflow 0/0/9996让Flow-tools通过9996端口接收NetFlow数据。

若/opt/netflow下有生成一个以当日日期为名的文件夹,则说明接收NetFlowDE 配置正确。

进入文件夹查看发现NetFlow的数据已经收集成功并保存为特定格式的文件。

下一步运行/usr/bin/flow-print -fo <ft-v05.200x-xx-xx.xxxxx+xxxx>> ./test将NetFlow数据输出成为文本文件test,如果需要长期对NetFlow进行收集还可以编写一个简单的shell脚本让Flow-tools的工具定时自动运行。

下面便可以在Splunk中对test文件进行索引并根据可到的数据来加工相关的视图以及报表了。

5. 结束语

当我们设定好运维目标以及运维计划之后,还需要一个管理平台来支撑我们的管理工作。上文以路由器管理为例,描述了一个支撑管理平台的搭建过程,但是网络设备种类繁多,为了更好的搭建适合我们自己的管理平台,平台本身理应满足以下条件:

  1. 支撑管理平台应该足够健壮灵活,能够很方便的在平台中增加新的内容;
  2. 支撑管理平台需足够安全,可以灵活设置安全策略;
  3. 支撑管理平台能够将我们的需求落地,否则没有意义;
  4. 支撑管理平台运行需足够稳定,不会遗漏任何我们需要的信息。

让我们也搭建一个属于自己的管理平台,智能化我们的网络运维工作吧!

Peter