DIY编程器网

标题: 基于SNMP的网络监控系统研究与设计 [打印本页]

作者: admin 时间: 2014-10-12 14:39
标题: 基于SNMP的网络监控系统研究与设计
简单网络管理协议SNMP(Simple Network Management Protocol)是为网络管理系统提供的底层网络管理的框架。其应用范围非常广泛，诸多种类的网络设备、软件和系统中都有所采用。SNMP协议发展到目前的第3版，已经成为一个非常成熟的网络管理协议[1]。不过由于每个设备的支持程序有所不同，所以面向SNMP的成熟网络管理框架依然非常少见[2]。在SNMP的支持方面，Cisco是走在最前沿的[3]，除了完整地支持RFC1213中MIB-2的定义外，还在部分设备中支持RFC2819和RFC2021中的RMON。基于Cisco的主流性，开发“可扩展”的基于SNMP的网络管理框架变得非常现实。
1 开发平台与架构的选择

.NET平台的C#语言有着丰富的语言特性，例如Lambda表达式(在Auto-Topology控件及软件框架中已多次使用)可以显著地提升开发效率，而且支持C#的官方开发环境Visual Studio是公认的更加有助于团队协作的集成开发环境。再者，C#中匿名对象、对象初始化器、闭包支持LINQ等利于DSL表现的特性，加之良好的异步编程支持，使C#成为了首选语言，自然，首选的平台则为.NET。

软件必须面对的两个基本问题是“通用性”与“可扩展性”。所谓通用性，就是在绝大多数的网络环境中都能够使用的基本功能；所谓可扩展性，就是在保证通用的前提下，充分发挥特有设备特别功能的能力。这使得通用框架的设计难度加大。

如何使网络管理任务充分简化是需要重点考虑的，软件的工作方式将会影响操作的行为，C/S结构或者纯粹的单体软件无疑有着更为强大的图形展现能力，而B/S结构则在伸缩性与跨平台方面有着更为良好的表现。一个较为折衷并且有经济效益的选择，就是在框架级别实现通用与跨平台，在表现层分离为不同的解决方案。最终，软件采用了普通软件的工作方式。

虽然可以自主开发SNMP底层的通讯类库来支持整个项目，但考虑到开发周期等因素，还是寻求一款更为优秀的开源组件来承担基础通讯。有两款开源组件可供选择：SnmpSharpNet和SharpSnmpLib。在仔细研究了这两款组件后发现，SharpSnmpLib更新频率更高，而且代码更加利于维护，于是选择SharpSnmpLib来支持开发。

2 系统分析

2.1 重点问题

由于SNMP协议在不同的设备上支持的情况不同，所以要求软件的一些通用功能兼容大部分设备，这是很有挑战的。常见的网络管理任务基本都建立在以拓扑图为蓝本的扩展之上，所以无论设备如何不同、协议支持情况有多复杂，自动网络拓扑发现功能是一个不能缺少的核心功能。如何在兼容常见设备的基础上实现扩展功能成为研究的重点问题。

2.1.1 与现有的大部分硬件设备保持兼容

与其说实现兼容，倒不如理解为只使用大部分硬件都能支持的功能来实现。一个显而易见的解决方案就是只使用RFC1213中定义的MIB-2功能组。MIB-2中定义了网络管理中经常使用的对象，并且得到了绝大多数设备的支持。如果只使用MIB-2中定义的功能来支撑软件的核心功能，那么软件与硬件的兼容性问题自然也会少很多。

2.1.2 通过SNMP的方式得到网络拓扑

SNMP协议的相关功能中没有直接获取拓扑结构的对象，在一些私有MIB中（例如Cisco中关于CDP的相关对象）有这样直接的功能，但是对网络环境与设备要求苛刻（CDP协议只在纯Cisco网络中有用，虽然有部分非Cisco开始支持CDP，但是数量很少）[4]，所以这不是一个通用的解决方案。

为了保持设备和网络的兼容性，前面提到应该采用“保守”的对象来实现核心功能，所以拓扑图的自动发现只能从MIB-2中查找相应的解决方案。网络拓扑，顾名思义就是网络设备之间的逻辑关系，那么反映到网络技术中，最为直接的对应就是路由表。但是路由表中只有网络设备间的关系，支持SNMP的PC信息却不在路由表中。如何解决支持SNMP的PC发现呢？一个方案就是查找网络设备中的“地址转换表”，这其中有PC的IP信息，通过对这些PC逐一进行SNMP测试，就可完整地支持整个SNMP网络[5]。另外，需要知道设备自身接口的IP，这在MIB-2的IP功能组（1.3.6.1.2.1.4）中都有定义。

2.2 难点问题

2.2.1 拓扑图的布局

拓扑图的机制确定之后，另一个难题就是如何将各个设备以及相关线路布置在屏幕上。由于设备之间的唯一关系就是相互间的链路，没有与物理结构相关的数据可以获得，所以要想完全通过软件绘制出与物理结构相同或相似的拓扑图是非常困难的，可以参考的相关资料和论文非常少[6]。

拓扑图的分布是个学术难题，环状权值分布仅作为一种理论尝试，为了今后有更好的理论支撑，可以灵活地修改布局算法，软件在开发过程中采用“策略模式”（Strategy）将布局算法抽象出来，易于替换。

2.2.2 映射领域模型到存储模型

领域模型记录了一个系统中的关键概念和词汇表，显示出了系统中的主要实体之间的关系，并确定了它们的重要方法和属性。对于一个SNMP应用系统来说，主要的领域模型就是SNMP实体。另外一个扩展功能就是对网络设备的“管理”，这涉及到资产评估、设备统计、维修管理等相关的应用，换句话讲，如何将软件获取到的信息与现实中的设备对应起来，是软件需要解决的一个方面。

3 总体描述及框架设计

3.1 系统核心

系统实现所涉及的核心问题分别如下：

(1)如何获取和绘制拓扑结构图，并合理地调整拓扑样式；
(2)同步引擎的合理调度，以及信息存储结构；
(3)功能的合理分类，以及对相关OID的分析、组织、建模；
(4)基础构建块的选择。

由于系统采用了分层开发，以及可扩展性等多方面的考虑，软件在逻辑上分为4层——持久层、基础层、业务层、表示层，基本的工作模式如图1所示。

3.2 存储模型

存储模型为“设备管理”以及相关的扩展应用提供持久化的机制，并为统计、分析等要求查询对比历史数据的需求提供基础。

对于数据库的选择，从成本上考虑，有Microsoft SQL Server Express、Microsoft SQL CE、MongoDB、NoSQL可供选择，而从部署上考虑有MongoDB、部分NoSQL、Microsoft SQL CE可选择，最后从性能上考虑，采用Microsoft SQL CE来支持存储模型。
经过持久后的数据可以在相对固定的时间内有效，在此基础上，进行统计、跟踪、分析等功能就会迅速许多，同时，网络的负荷也会明显降低。

3.3 领域逻辑设计

系统与SNMP网络交互的主要逻辑依赖于SNMP协议所传输的SNMP对象数据，SNMP对象又依赖于相关的MIB来描述其特性与结构。软件所需要的领域逻辑主要集中在对SNMP实体的操作上，但是SNMP的操作是对程序不友好的。也就是说，无法通过流畅的API来操作SNMP使之为软件所用。所以需要设计一种领域逻辑，将SNMP的特定领域转化为程序友好的领域。考虑图2所示的领域转化。

SNMP的操作原语被转化为对应的编程概念，使SNMP的领域完整地转化为程序设计的领域。这为AOP编程以及存储模型的扩展奠定了基础。

4 系统实现

4.1 环状权值分布

拓扑图的排序算法被叫“环状权值分布”，主要是因为引入了设备在网络中 “权重”的概念。由于布局的主要目的是让主要设备能够分布且合理定位在屏幕上，所以拓扑布局的算法首先是找出那些“权重”最高的设备，并依此排序进行设备定位。算法主要的步骤有：

(1)设备按“权重”排序。系统主要面向的是路由及交换设备，所以对拓扑图最为敏感的信息就是“路由”信息。如果一个设备核心的路由数量高于其他的设备，则该设备就是所谓的“核心设备”。

(2)最高权重优先定位。步骤(1)已经确定了最为核心的设备以及按“权值”排序后的设备分组。最为核心的设备是第一组，它们将以屏幕正中央为圆心，均匀分布在某个半径的圆圈上。半径的确定取决于要定位的设备数量，数量越多半径值越大。当这些设备定位结束时，也就确定了此设备在屏幕中心点的角度(&ang;θ)，此角度将作为下个步骤定位的依据。

(3)“卫星”设备布局。与核心设备相联接的设备都归类为该核心设备的卫星设备， “卫星”设备的具体分布算法如下：

假定有n个核心设备，那么每个核心设备的卫星设备只可以分布在360/n的扇形范围内，如图3所示。

图3中有3个核心设备，被分为A、B、C三个扇形区域，以R2为例，它的3个卫星设备就分布在B区域，且在B扇形内根据&ang;θ均匀分布，半径会以卫星设备的数量作相应的修正。
(4)绘制链路连线。核心设备区域的连线允许交错，因为这部分的连线几乎不太可能做到不交叉。由于分布是基于环的，所以连线即便有交错，问题也不会很严重。卫星设备的连线主要是对上一个设备的，这种情况下可以直连，如果卫星设备之间有连线，则可对卫星设备的布局会做一些小调整，尽量不出现连线的过度交叉。

此时如果发现x设备与z设备间有连线，就会根据屏幕上的空间对x或z的位置做一些小的调整，以让x与z的连线分布得更为合理。

4.2 MIB模块的实现

为命名方便，基于简单网络管理协议的网络监控系统简称为SNMS。根据MIB的命名方式，在1.3.6.1.4.1节点下自定义了一个名为Tute（888）的节点，在该节点下定义SNMS(1)节点。

定义了MIB中的对象标识符以后，就需要对软件只能够涉及到的、需要管理的对象进行划分，在此，将SNMS这个系统分为system、user和file三部分，分别定义为system（1）、user（2）和file（3），如图4所示。

4.3 Trap模块的实现

为了使软件在设备出现事件时能得到通知，在SNMP这个背景下就意味着需要一种能够接收Trap的机制。设备在自己所能够支持的事件范围内，通过定义不同含义的Trap报文，按照设备自身所配置的接收对象将Trap发送出去。

4.3.1 统一侦听Trap版本

SNMP协议不同的版本对应着不同的Trap格式。然而对SNMS自身来说，这些Trap的版本并没有什么意义，软件所需要的仅仅是必要的标识和对应标识的意义。所以需要一种机制将这些版本的Trap进行统一。

软件采用的方式是使用中间层来代理。使用TrapMonitor来侦听所有版本的Trap，通过不同的处理最终触

发TrapComing事件，并将处理之后生成的TrapInfoEventArgs传入，供订阅者使用。

4.3.2 Trap信息翻译

Trap包含的信息成百上千，若都由软件来解析其信息将是一件非常耗时且庞大的工程。况且由于SNMP自身的可扩展性，软件无法预测其后出现的新Trap定义，所以考虑这样一种机制：对Trap进行建模，将其核心抽象为一种可扩展可配置的模式。

这种机制使得软件可以轻松适应不同的场景，而且部署起来也很方便。软件自身也集成了Trap信息的配置功能，可以避免手动接触XML文件。

4.3.3 Trap过滤

如何过滤出有用的Trap信息非常关键，这是由系统的“管理”性质决定的。系统决定采用一种类似于网络ACL的做法，提出了白名单和黑名单的过滤模式。类似于Trap信息翻译，系统也采用了基于XML的做法，将过滤规则保存在更加灵活部署的XML文件中。这里白名单是指所有Trap到达后只显示名单中规则匹配的Trap；黑名单是指所有Trap到达后不显示规则匹配的Trap。

5 测试及部署

最终的测试环境选用了最为常用的网络设备——中型路由式数据交换网络。环境使用5台Cisco 7200路由器与7台Cisco 3640交换机搭建，并配置了相关的路由协议，最后开启SNMP功能和Trap功能。

系统对“中型路由式数据交换网络”环境进行拓扑发现，测试效果如图5所示。

图6是在一个真实网络环境中进行系统测试得到的网络拓扑。

作为基于SNMP的上层应用软件系统，软件除了实现核心的拓扑发现机制与拓扑布局外，还不断地完善软件框架，使其能适应不同的上层开发。软件理想的演进路线是做成一个基于SNMP的基础框架，在此框架之上可以不断地扩充应用。由于SNMP协议本身的成熟性，这种需求的框架有着很大的潜力。

欢迎光临 DIY编程器网 (http://diybcq.com/)