深入理解Net-Snmp
上QQ阅读APP看书,第一时间看更新

1.2 网络管理框架

网络管理涉及面非常广,大到互联网,小到一个设备甚至一个单片机。管理的对象,可以是整个设备或网络,也可以是运行在设备中一个进程或账户,可以是软件也可以是硬件。但无论是哪种解释和描述,都可以将网络管理中涉及的对象划分为主从管理和被管理的关系,它们之间通过某种网络互连。

实际上,1.1节中介绍的几大网络机构定义标准的过程是一项巨大的工程,包含从框架到细节的各个方面。目前,主要有两大网络管理体系结构:基于OSI参考模型的CMIP和基于TCP/IP参考模型的SNMP。

CMIP体系结构是一个通用的模型,支持该模型的通信实体间可以是平等的关系也可以是主从的关系。这两种关系既支持分布式管理又支持集中式管理。

SNMP体系结构继承于SGMP,该模型的通信实体间不是平等的关系,而是主从的关系,属于集中式管理模型。不过,如今的SNMP已经支持分布式管理模型了。这里,我们不局限于某种具体的体系结构,而是从网络管理的通用概念来讲述最基本的模型。

1.2.1 网络管理模型

到目前为止,我们探讨了什么是网络管理,以及有哪些管理标准或协议等。不过还没有清晰地界定网络管理中的对象,也就是网络管理所作用的对象、实体及组成。在这里不准备将涉及的人包括在内,而仅介绍网络管理中直接作用的对象。

在网络管理的术语里其组成包括以下几个对象:网络管理者、管理系统、管理进程、管理者(Manager)、被管理者/代理(Agent)、管理信息库(MIB,Management Information Base)、网络管理协议。下面介绍其中几个重点对象。

1.网络管理者

我们知道网络管理者理应是一个庞大的计算机系统。不过在实际的开发或维护过程中,往往会使用简化的工具来完成设备的测试和调试。比如会使用工具软件、命令行等方式作为控制台,这在本书的后续章节中会涉及,读者可以把它们理解成简化的、模拟的网络管理者。

2.被管理者/代理

把被管理设备称为网络设备,或称为网元(Element Management),比如一台联网的嵌入式设备(如路由器),这只是一种概念性的描述,可以从不同的上下文或层次去理解以上的含义;代理常常表示一个网络实体,在一些环境下直接对应一台被管理的物理设备,在其他的上下文语境中可以理解为一个运行的进程(程序实体),比如snmpd的后台进程。

换一种角度分析,我们也可以把网元中实际运行的代理进程称为网元接口。该接口允许管理者发送请求到该网元,如获取代理的某些状态量;网元也可以发送信息给管理者,如在发生预定义事件时(如电压超过阈值),向管理者通告该事件的发生以反映某种状态的变化。

虽然两者可以互相发送信息,但是两者的角色还是有很大差别的,它们是一种不对称的关系。也就是说,如果从网络链接模式来区分管理者和代理的话,两者可对应为C/S(Client/Server,客户端/服务器)结构。代理,在常规思维的理解上反而成了“服务器”,管理者沦为“客户端”。因为代理也确实可以响应多个管理者(尽管不一定支持并发——代理多线程)

另外需要注意的是,一般情况下管理者和代理之间的角色不会互换,不过它们之间是一种相对的关系,而不是绝对的关系。

一个代理在某些情况下,对应一个网元,它作为某个管理者代理的同时也作为另外一个网元的管理者。

一个管理者在某个管理层中除了作为一个“真正”的管理者外,还可以作为更高管理层的代理,诸如收集、处理、转发信息到上层管理者。这与人类的社会管理结构是相似的。这种角色或者功能,在SNMP协议及后续章节要介绍的Net-SNMP中都已经实现了。

下面介绍在代理中到底如何实现Proxy(代理角色)的功能的。首先,了解在代理中是如何表示现实世界中要管理的内容的。

3.管理对象

从直观的物理层面上来理解,管理内容又可称为被管理对象。举个简单的例子,假设有一台联网设备是基站供电系统,该系统的核心是一块ARM嵌入式芯片,该芯片上运行着很多的进程(程序),其中包括一个网络管理的代理进程。假设需要管理的内容有以下几项:

·该系统的用电状态包括:市电、电池、太阳能发电、风能发电、油机发电等;

·该系统中相关的传感器用于检测当前系统的电压、电流、温度、湿度等;

·被定义为告警事件的情形:例如在系统运行过程中出现的市电停电、电池被过度使用等。

当然该系统还有大量的其他信息,如系统参数等,这里就不一一列出了。

在真正的管理之前,需要确定如何描述以上三种被管理对象的物理特性。在实际的代理进程中,用电状态可以使用C语言中的枚举类型表示;电压、电流、温度、湿度等都可以使用double型的变量表示(或者使用整型变量和精度共同表示浮点型变量);如果有多组电池,则使用相应的数组表示即可;告警事件可以使用一个短整型变量表示(比如,1表示有告警)。

假设我们已经实现了上述的代理进程,那么又该如何告知管理者有这些被管理对象,以便管理者对其进行管理呢?

解决的方法是和管理者约定好,以某种格式和语言定义以上的被管理对象,并将定义好的内容,以某种方式存于告知管理者。管理者在系统启动时或需要时,读取管理对象,在必要时对以上的被管理对象进行管理。

在网络管理系统中,以上的约定常由管理信息库MIB来实现(还存在XML格式或指令格式CLI)。管理者通过MIB对代理进行获取或设置会对应到真实的物理对象上,因此也可以把MIB看成是管理设备的一种“接口”。

既然有库的概念,那么可以将MIB类比为虚拟的静态数据库。不过有两点需要注意:首先它不是真正的数据库,只是一个纯文本文件(ASCII文件),包含了该设备可被管理的对象,与该设备相关联;其次,该MIB文件不会变动,它是一种标准,一旦发布到现实的网络世界里,除非设备的管理信息有升级、更新,否则一旦发布,跟随设备的MIB就固定下来了。

通过以上对被管理信息的规定,实现了被管理对象从现实世界到虚拟世界的抽象。一个被管理对象在MIB中为一个条目,多个被管理对象映射的集合组成了一个MIB(第4章还会进一步介绍MIB——SNMP中的MIB概念)。这里需要提醒读者的是,MIB并不是SNMP中特有的概念,虽然提到MIB就会想到SNMP,那只不过是因为SNMP使用广泛罢了。MIB作为物理设备管理信息的一般概念性的描述,是通过Agent实现的,不同协议的Agent所支持或实现的MIB在定义格式上不一定一致,这种不一致表现为约定上的不一致或表达方式的不一致。

以上对管理者、代理、管理信息库(MIB)的描述可以用图释之,如图1-3所示,网络设备由传感器采样电压、电流,分别以volt,current表示,并通过MIB告知管理者。

图1-3 管理者、代理及MIB

具体的MIB定义,请参考后续章节的内容。

4.网络管理协议

当代理已经明确可支持的管理对象,同时管理者已经知道待监控的对象后,下一步当然就是两者如何“联络”以完成对对象的管理。在网络管理中,网络是互相通信的前提,管理者和代理的通信过程通过网络来承载,如何理解对方通过网络传过来的“语言”,是最为关键的一步。网络中传输二进制流,二进制数字10可以理解成十进制数字的2,可以理解成具体的数值电压2伏,还可以理解成某个数据类型的标志,以及某个命令控制字等。

相应的解决方案就是针对具体的网络管理协议,定义“语法”“语义”“时序”,即数据和控制信息结构、格式的语法、如何响应或控制的语义、对语义响应顺序的时序。

在运行多种网络协议(不仅仅是SNMP)的计算机系统中,每个通过网络传入的协议数据流又是如何被管理的上层应用所识别的呢?答案就是端口,一个端口号和一个IP地址的组合即是网络编程中常说的网络套接字,往往某种具体的协议都被绑定在指定的网络端口上。对于网络通用协议,一般使用的是知名端口,并且在实现时一般不允许更改,否则会导致通信失败。比如,常见的有FTP使用的20和21端口、SSH使用的22号端口、HTTP使用的80端口。在SNMP中使用161作为监听端口,162作为Trap端口,虽然这两个端口我们可以进行配置,但不建议更改。如果以上端口被防火墙关闭,绑定在以上端口的协议(程序)是无法正常运行的,很明显网络管理是典型的分布式应用。

1.2.2 网络管理模式与技术

在不同的应用场合,网络管理的组织架构是不一样的,所投入的成本也是差异很大的。针对这种不同的网络拓扑结构,其实现的技术也是不同的。

1.网络管理模式

说到网络管理体系结构,就不得不说网络管理模式了。所谓的网络管理模式就是人们对网络管理和网络架设的总结。网络管理模式分为集中式管理模式、分布式管理模式,以及两者结合的混合式管理模式,针对不同的应用场景可使用不同的管理模式。

(1)集中式管理模式

集中式管理模式是一种最为简单,且应用极其广泛的管理模式。集中管理是一种典型的“一对多”的关系,即一个管理者和多个被管理者。一个管理者负责多个被管理者,完成信息的收集、控制等管理功能。由于所有的信息流都流向管理者,往往管理者一方(管理者自身及管理者方的网络)将成为通信、响应的瓶颈。管理者一方是否具有可靠性也成为整个管理系统的瓶颈,管理者自身功能的扩展也将影响整个网络管理。集中式管理模式的责任集中于管理者,这种管理模式一般应用于小型网络和专用网络,如企业网络、典型的C/S网络结构等。

集中式管理模式的结构示意图,如图1-4所示。

图1-4 集中式管理模式的结构示意图

(2)分布式管理模式

分布式管理模式就是网络管理的功能分布到网络中的多个节点,这是一种典型的“多对多”的关系。分布式管理可以看作是集中式管理模式中的管理功能分散到其他的管理网络者或者被管理者,而减轻了原管理者的负担,削弱了集中管理中的“上下级”关系。分布式管理中的“头号”管理者倾向于业务层、逻辑层面的管理。由于其是多个网络实体承担网络功能的一部分,成为某种具有自我管理功能的自治单元,使得分布式管理模式成为大型网络及要求具有自适应性、扩展灵活的网络管理模式。

在SNMP版本演进的过程中,直到SNMP v2版本才支持分布式管理模式。

分布式管理模式的结构示意图,如图1-5所示。

图1-5 分布式管理模式的结构示意图

(3)混合式管理模式

集中式管理模式和分布式管理模式各有优缺点,适合的应用场景也不尽相同,而如今的网络是局域网与广域网的互联,是公用与专用网的互联,是不同架构的网络互联,单一的管理模式已不能满足如此复杂的应用需求。而混合式管理模式是集中和分布式管理模式的有机结合,其优势互补。混合式管理模式能实现部分集中、部分分布,还可实现分级管理功能,这全面满足了网络管理的需求,因此被广泛地应用于跨地区、跨部门的网络互联管理中。

2.网络管理技术

与网络管理模式的具体管理过程相辅相成的,自然就是网络管理技术了,下面就让我们来看看网络管理技术的具体实现。

(1)基于轮询的管理

所谓轮询即管理者主动按照某种策略(算法)查询或设置被管理者,以实现网络管理。这是一种典型的管理者“请求”,被管理者“响应”的通信过程。由于其对被管理者“周而复始”且大量的请求,往往会出现网络拥塞等状况。首先,具体在设计策略时应考虑及时性的需求,以及网络是否健壮,是否满足轮询的操作要求。其次,考虑是否能容忍较大的通信开销。实际运用中也可以使用快照的方式替代频繁的轮询。被管理者,定期保存需要管理的信息快照,其间隔为原始的轮询周期、存于指定的目录,并按照某种约定命名。间隔某个原始的轮询周期后,再将所有信息打包上传,从而减少轮询的频率。

(2)基于事件的管理

基于事件管理中的事件可以理解为引起“回调”或“中断”的信号。实际指的是当被管理者出现某种“异常”时,如出现状态由正常到高的变化,会主动将该情况上报给管理者。使得出现问题时,能有针对性地、及时性地处理这种异常。这里有几点需要注意:

·事件可以是警报、配置的改变、日志事件、其他预定义的事件。

·此通信过程中的发起者为被管理者,而不是管理者,该事件不是请求,管理者不一定需要响应该事件。

·管理者应该事先“注册”了被管理中的该事件。

在SNMP中是使用Trap的方式实现事件驱动的。如果读者熟悉网络编程,可类比地理解这两种实现的差异。事件驱动和轮询分别对应网络编程的术语中的回调和轮询,比较知名的网络I/O复用模型中的epoll和select就类似于该模式。类似于网络管理模式中的混合式网络管理,其管理过程也可以是轮询驱动和事件驱动的结合。一般情况下,管理者通过轮询被管理者,以提供各种网络管理功能。当被管理者出现某种事件时(如异常情况),其会主动向管理者发出告警通知,以及时引起管理者的重视并进行后续的查询和处理等操作。

1.2.3 网络管理功能

网络管理功能是网络管理需求的实现,是网络管理的本质。不过在不同的视角、维度,通过不同的方式可以定义多种网络管理的参考模型,以此来构建网络管理。比较著名的网络管理功能模型有:FACPS功能模型(Fault、Accounting、Configuration、Performance、Security、故障、计费、配置、性能、安全)、OAM&P功能模型(Operation、Administration、Maintenance、Provisioning、运营、管理、维护、供应)、TOM功能模型(Telecoms Operations Map,电信运营图)等。

以上的模型中最为著名的要属ISO定义的网络管理的五项管理功能模型(FACPS)了,以下是其具体定义。

·故障管理(Fault Management):故障的监测、隔离、排除,尽可能地维持网络的运行目标。主要内容包括设备、软件、服务故障的管理,主要涉及对网络的状态获取和告警。落实到实处(应该想到开发的实际过程)时又可细分为告警监控、维护和检测错误日志、接收和处理错误通告、跟踪和定位故障、执行网络诊断、修改故障。例如,SNMP协议的Trap功能所提供的告警主动上报机制。

·计费管理(Accounting Management):度量用户对网络资源的使用情况,其主要涉及数据收集,统计消费等。落实到实处时又可细分为计费数据的采集、数据的管理与维护、对用户使用情况的通知和准备并有计划地进行资源限制、整体费用的计算等。例如,通过SNMP协议周期性地采集计费数据。

·配置管理(Configuration Management):完成对网络设备的发现、网络功能和服务的配置与审核。其涉及具体资源的配置、备份与恢复以及应用程序的映像管理。落实到实处时又可细分为参数管理、启动与关闭设备、收集设备当前信息、重要事件的通告、改变设备配置等。例如,使用SNMP协议的设置命令完成系统配置数据的备份或恢复。

·性能管理(Performance Management):包括性能监测功能、性能分析功能、管理控制功能,主要涉及网络吞吐、延迟、质量,以及系统CPU、负载、内存的使用情况等。落实到实处时又可细分为统计信息的收集、设备历史日志的分析以及计算性能指标的判断、优化与调整等。例如,结合网络管理系统生成性能走势图。

·安全管理(Security Management):支持网络应用安全策略。主要涉及管理上的安全和安全上的管理。落实到实处包括通信双方的身份认证及鉴权机制;创建、删除、控制安全服务和机制;发布和报告与安全相关的信息和事件、用户组及权限管理。例如,SNMP协议中通信双方认证的共同体(Community)机制。

以上对五大管理功能模型的描述是对整个网络管理的宏观概述,是对网络管理一个方向性的指导。这里介绍的模型也是功能简化后的模型,以至于某种具体的管理功能不能清晰地按照上述模型来归类。比如告警功能,可同时存在于五项管理功能中。

另外,在实际的网络管理和运营中,还包括诸如网络规划、网络操作人员的管理等,这是一个范围界定的问题。同时,并非单一的网络管理应用必须包含所有的五大功能,这是没有必要的。其实,网络管理功能的实现与具体的应用场景有关。比如,当只针对某种具体的设备进行检测和控制,并且该设备只服务于特定领域或只局限于“内部”使用时,对该网络设备的管理并不会涉及以上描述的所有管理功能。不过,对于服务于社会的电信行业,完善的网络管理系统应该具有上述五项网络管理模型最基本的功能。

一般来说,网络管理有处于被动的含义,即只有当网络出现(异常)情况时,才会被动地采取措施。实际上OSI网络管理标准中定义的五大功能包含的内容,在理解时可以适当地延伸。尤其是在近些年移动互联网逐渐火热这个大的环境下,网络管理有向网络分析发展的趋势,网络管理逐渐倾向于周期/定期性地获取网络设备的各项数据,然后进行分析、预测,提前管理可为决策提供支持,这使得网络管理更具有主动性!

最后要说明的是网络管理存在多种网络模型(标准),这里涉及一个选择性或实现的问题。其实在真实的网络运营和管理中,并不一定会完全参考以上的各种模型,最终的实现还是来自实际需求,毕竟需求才是王道。不论是网络管理需求,还是软件开发需求,在其实现中总是要把大事化小、小事化了,将其实现到分门别类的模块化中。就像在Linux内核的“标准”下有多种发行版本一样,实现网络管理也有多种方法!