CN103716191B - 一种提高图形化网管效率的方法 - Google Patents

Abstract

本发明公开一种提高图形化网管效率的方法，包括：定义管理信息基础（MIB）表，并创建一条空表项；通过创建的空表项下发参数，所述参数包括要执行的函数名和该函数对应参数信息；激活所述的空表项，被管设备根据网管服务器下发的函数名和函数参数来执行对应函数；函数执行完成后，将函数执行状态节点的值设置为完成状态，若执行失败，则向网管服务器上报一条出错信息，并结束；否则将该函数的返回值信息记录下来，然后向网管服务器上报一条成功消息，再将所述网管服务器收到被管设备上报的消息，根据需要读取该函数相关返回参数，最后根据所述相关返回参数再进行后续的各类逻辑处理。采用本发明，能够有效降低网管服务器的通信量，提高服务器性能。

Description

一种提高图形化网管效率的方法

技术领域

本发明涉及网络设备管理技术，尤其涉及一种提高图形化网管效率的方法。

背景技术

近些年来我国的宽带接入技术发展迅速，社区、楼宇、家庭等都接入了宽带光缆，越来越多的用户可以通过宽带光缆接入到互联网。

随着宽带技术飞速发展为网络运营商提供巨大商机的同时，网络规模不断扩大、网络设备数量不断增加，也给网络运营商对网络和网络设备的运营管理带来了巨大的困难和挑战。各类网络通信设备一般都会提供命令行网管和图形化网管两种管理方式。所述的命令行网管，基于通用语言基础架构（CLI），所述图形化网管基于简单网络管理协议（SNMP）。

由于不同厂商提供的CLI存在较大差异，且CLI也缺少配置向导、命令关联展示等手段，因此CLI堪称专家级的配置管理手段，需要较高的技术门槛。而图形化网管则由于提供了可视化的配置界面，能够将良好的配置向导、相关配置属性都关联在一个界面内等优点，对用户而言，上手快、易操作，友好性较佳，颇受用户青睐。

但是图形化网管采用的是基于客户端/服务器（C/S）架构，一般要通过独立于设备之外的客户端来连接设备，使得服务器端和客户端的所有信息交互都要通过发送数据包来完成，造成被管理设备上的所有信息和状态等的判断、读取都必须依靠消息交互来完成。如，服务器端的某项操作需要依靠客户端大量的基础数据作出某个判断结果时，通常的做法都是将所需要的全部基础数据都依靠网管查询消息读取上来，然后在服务器端参照客户端该功能的实现方法，进行同样的逻辑判断、处理、过滤等各类操作步骤，得出比较判断的处理结果，再继续后续处理流程。这样，既增大了服务器端的通信量，降低了服务器端的处理性能，又将服务器端的处理逻辑与客户端紧密耦合在了一起，使得客户端的处理逻辑一旦发生变化，则服务器端必须随之变化。

这种做法存在两大弊端：其一，由于需要读取大量基本信息导致服务器端的通信量较大，同时判断处理逻辑也放在服务器端进行，就势必增加服务器端的处理压力，造成服务器性能下降；其二，当客户端由于设计发生变化或者其他原因导致此项操作的逻辑处理方式发生变化时，服务器端也必须同步修改此逻辑的处理代码，使得服务器端的处理较多的受到客户端的约束，造成紧耦合。这是目前C/S架构的网管***在常规做法下无法完全避免的缺陷问题。

发明内容

有鉴于此，本发明的主要目的在于提供一种提高图形化网管效率的方法，以在某些处理中极大地降低服务器的通信量，提高服务器性能，从而在提高用户体验的同时，降低服务器端与客户端的耦合关系。

为达到上述目的，本发明的技术方案是这样实现的：

一种提高图形化网管效率的方法，先准备好网管服务器，包括：

A、定义管理信息基础MIB表，并创建一条空表项；

B、利用所述MIB表，将各类判断、比较和筛选的逻辑操作通过图形化网管所采用的协议下放到被管设备端，由被管设备执行所述的逻辑操作，由所述网管服务器负责传递数据和回读结果；

C、通过所述创建的空表项下发参数，所述参数包括要执行的函数名和该函数对应参数信息；

D、激活所述的空表项，被管设备根据网管服务器下发的函数名和函数参数来执行对应函数；

D、函数执行完成后，将函数执行状态节点的值设置为完成状态，如果执行成功，则执行步骤F，否则执行步骤E；

E、向网管服务器上报一条出错信息；然后结束本次执行过程；

F、将该函数的返回值信息记录下来，然后向网管服务器上报一条成功消息，再执行步骤G;

G、所述网管服务器收到被管设备上报的消息，根据需要读取该函数相关返回参数，最后根据所述相关返回参数再进行后续的各类逻辑处理。

其中，步骤G之后进一步包括：待全部操作执行完成后，删除之前所创建的表项。

所述MIB表包括的表项有：节点ID、函数名、函数参数、函数状态及所述函数的执行结果。

所述的协议具体为简单网络管理协议。

所述的函数包含多个参数，需要定义多个节点用于传递参数。

所述方法同样适用于通过其他网管协议实现的图形化网管设备，只需该图形化网管设备满足将各类判断、比较和筛选逻辑操作通过所述图形化网管所采用的协议下放到被管设备端，由被管设备来完成所述的逻辑操作，而上层网管设备只负责传递数据和回读结果的条件即可。

本发明所提供的提高图形化网管效率的方法，具有以下优点：

1）应用本发明方法最大的作用在于，能够在特定情况下通过减少服务器端与客户端的信息交互，将服务器上部分复杂的、大量的逻辑判断、比较等操作下放到客户端，从而减轻服务器端的处理工作量，提高图形化网管效率。

2）应用本发明的方法，对原有的网管技术改动很小，容易实现，而且在很大程度上弱化了服务器与客户端的耦合关系，同时减轻服务器端的处理压力，提高服务器端的管理效率。

3）本发明方法，易于实现，可靠性高，对设备几乎没有任何约束条件。能够极大的提高图形化网管效率，减轻网络负担，对网络的稳定性也有很大促进作用。

4）本发明的方法，还支持各类并发操作，无论是同一个服务器的多个并发操作还是多个服务器之间的并发操作；各类逻辑判断、数据比较或筛选都无需再从客户端攫取巨量数据，减少了服务器端的处理量，提高了服务器效率，增强了用户体验；降低服务器端对客户端处理逻辑的依赖，并且在客户端的相关判断、比较、筛选逻辑发生变化时不影响服务器端。

附图说明

图1为本发明通过预定义的管理信息基础（MIB）表将复杂或大量的数据处理工作从服务器端下放到客户端的执行过程流程图。

具体实施方式

下面结合附图及本发明的实施例对本发明的提高图形化网管效率的方法作进一步详细的说明。

本发明的基本思想在于：将各类判断、比较和筛选等逻辑操作通过图形化网管所采用的协议下放到被管设备，由被管设备来完成这些操作，上层网管只负责传递数据和回读处理结果。将图形化网管从在海量基础信息中做简单重复的操作中解放出来，充分保证服务器的效率和性能。

图1为本发明通过预定义的管理信息基础（MIB）表将复杂或大量的数据处理工作从服务器端下放到客户端的执行过程流程图。需要图形化网管先在接口1上配置一个IP地址IP1，在配置之前需要检查设备上是否已经存在和IP1相同网段的IP地址。

如图1所示，该过程包括如下步骤：

步骤S：开始。

步骤S2：准备好网管服务器。

步骤S3：在定义好的管理信息基础（MIB）表中创建一条空表项，如表一所示。

此时，表项均为未激活状态，表一所示的函数名、函数参数、函数返回值等字段均为默认的无效值，函数执行状态节点等于未完成状态。

表一：

当图形化网管遇到需要从被管设备上获取大量基础数据做筛选、比较、判断等操作才能继续处理的情况时，即可应用本发明的上述表来执行如下的操作。

步骤S4：通过如表一所示创建的空表项下发参数。所述参数包括要执行的函数名和该函数对应参数等信息。例如，以某款交换机为例，将函数名设为sysIPConflictCheck，参数1设置为要下发的IP1。

这里，由于有的函数包含多个参数，需要定义多个节点用于传递参数，具体定义多少个（即上表中的functionParamN的N值）需根据具体实施环境确定。

由于有的函数有多个返回值，所以需要定义多个节点用于传递函数执行的返回值，具体定义多少个（即上表中的functionResultM的M值）需根据具体实施环境而定。

所述functionState，表示下发的函数是否执行完成，只有两种状态，完成和未完成，初始值为未完成状态。只有当此节点置为完成状态时，后续的函数返回值（即functionResult1……M等）才有实际意义，否则不应该读取函数返回值。

所述rowStatus，表示SNMP协议中标准的数据类型，通常定义在表格中，用于对此表格进行创建、修改和删除操作。这里定义一个rowStatus对象，表示此表项可以创建和删除，用于多个网管服务器或多个类似操作并发执行时使用。

实际应用中，无论哪个厂家的网管***都可以直接采用上述表项定义，唯一的不同在于N个函数参数和M个函数返回值中的N和M值的确定。一般而言，N和M都可以设置为10，基本可以适用于所有应用场景和被管设备。

图形化网管很多时候在配置、显示和过滤参数时，需要依赖设备中的大量数据（这些数据甚至可能分布于多个数据表中，操作起来极其麻烦），这个时候还可以通过操作上述表项来简化处理。

在操作前，先创建一条空表项的目的是为了支持并发，同时不和其他进程起冲突。还需要事先知道被管设备执行当前逻辑操作的管理函数接口，然后根据函数接口来下发函数名和函数参数。

步骤S5：网络管理员激活所述的空表项，被管设备根据网管下发的函数名和函数参数来执行对应函数sysIPConflictCheck，该函数有1个参数，其值为IP1。

这里，待函数名和函数参数等值下发完成后，要通过rowstatus对象来激活当前表项，这样做的目的是通知被管设备，网管已经完成了函数名和函数参数的下发，此时被管设备可以根据网管下发的各类参数来执行此函数了。

步骤S6：该函数已执行成功，将函数执行状态节点的值设置为完成状态。如果执行成功，则执行步骤S8，否则执行步骤S7。

步骤S7：若该函数执行失败，需要向网管服务器上报一条出错信息，如SNMP出错报文。网管服务器发现函数执行失败后，可以根据此结果给用户“由于IP地址冲突，所以配置失败”之类的提示，或进行其他逻辑处理。然后执行步骤S10，即一次完整的操作就此结束。

步骤S8：若该函数执行成功，还需将该函数的返回值等信息记录下来，然后需要向网管服务器上报一条成功消息（如，SNMP成功报文），随后执行步骤S9。

这里，网管通过判断functionState的值，来确认当前函数是否已经执行完成，只有当这个值指示下发的函数已经执行完成了，才可以去读取函数返回值节点，否则读取的就是没有意义的值。

步骤S9：网管服务器收到被管设备上报的消息，如SNMP成功报文，证明该函数执行成功了，然后就可以根据需要读取该函数相关返回参数，最后根据相关返回参数再进行后续的各类逻辑处理，比如数据筛选、比较、判断等。

这里，所述根据需要读取该函数相关返回参数，例如：可通过functionResult1、functionResult2、……、functionResultM节点读取。

步骤S10：本次处理流程结束。

这里，待全部操作执行完成后，还需要删除前面创建的表项，用来释放表项资源，以供后续操作继续使用。

【效果对比】

根据上述说明实施例，假如设备中已经配置了N个IP地址，则数据对比效果如表二所示。

表二：

从表二所示的对比结果不难看出，随着N值的增大，采用现有图形化常规处理方法所需要收发的报文急剧增多，但对本发明来说，则没有明显变化。

同时，由于常规处理中，数据的逻辑判断、筛选、比较等工作均在网管服务器端执行，因此网管服务器的压力很大。

因此，得出结论，报文数量N越大，则图形化常规处理的效率和性能越低下，而应用本发明则没有什么影响，两者的处理效率和性能的反差越大。

本发明虽然是以SNMP为例对C/S架构的被管设备的客户端和网管服务器进行说明，但是对于通过其他网管协议而实现的图形化网管设备，本发明方法也同样适用。只需满足将各类判断、比较和筛选等逻辑操作通过图形化网管所采用的协议下放到被管设备端，由被管设备来完成上述逻辑操作，上层网管设备（如网管服务器）只负责传递数据和回读结果，应用本发明方法，均能够将图形化网管从在海量基础信息中做简单重复的操作中解放出来，充分保证网管服务器的效率和性能。

以上所述，仅为本发明的较佳实施例而已，并非用于限定本发明的保护范围。

Claims (5)

1.一种提高图形化网管效率的方法，先准备好网管服务器，其特征在于，包括：

A、定义管理信息基础MIB表，并创建一条空表项；

B、利用所述MIB表，将各类判断、比较和筛选的逻辑操作通过图形化网管所采用的协议下放到被管设备端，由被管设备执行所述的逻辑操作，由所述网管服务器负责传递数据和回读结果；

C、通过所述创建的空表项下发参数，所述参数包括要执行的函数名和该函数对应参数信息；

D、激活所述的空表项，被管设备根据网管服务器下发的函数名和函数参数来执行对应函数；

D、函数执行完成后，将函数执行状态节点的值设置为完成状态，如果执行成功，则执行步骤F，否则执行步骤E；

E、向网管服务器上报一条出错信息；然后结束本次执行过程；

F、将该函数的返回值信息记录下来，然后向网管服务器上报一条成功消息，再执行步骤G;

G、所述网管服务器收到被管设备上报的消息，根据需要读取该函数相关返回参数，最后根据所述相关返回参数再进行后续的各类逻辑处理。

2.根据权利要求1所述的提高图形化网管效率的方法，其特征在于，步骤G之后进一步包括：待全部操作执行完成后，删除之前所创建的表项。

3.根据权利要求1所述的提高图形化网管效率的方法，其特征在于，所述MIB表包括的表项有：节点ID、函数名、函数参数、函数状态及所述函数的执行结果。

4.根据权利要求1所述的提高图形化网管效率的方法，其特征在于，所述的协议具体为简单网络管理协议。

5.根据权利要求1所述的提高图形化网管效率的方法，其特征在于，所述的函数包含多个参数，需要定义多个节点用于传递参数。