CN100471128C - 一种实现设备状态轮询的方法及装置 - Google Patents

Abstract

本发明适用于网络通信领域，提供了一种实现设备状态轮询的方法及装置，周期性向设备发送轮询请求，根据在超时时间内是否收到设备的应答检测设备的连通状态，所述方法包括：将待轮询设备分为多个设备组；对当前设备组内的设备发起轮询请求，在超时时间内集中等待接收当前设备组内的设备的应答；当超时时间到时对下一个设备组内的设备发起轮询请求，直至所述待轮询设备全部轮询完毕。本发明通过对设备进行分组，并依次对各组设备进行异步轮询方式，有效地缩短了轮询周期，能够及时反映出设备的状态，同时可以降低CPU的占用率。另一方面，本发明通过对检测中断的设备进行集中重复轮询，避免了设备闪断的情况，提高了设备状态检测的准确性。

Description

一种实现设备状态轮询的方法及装置

技术领域

本发明属于网络通信领域，尤其涉及一种实现设备状态轮询的方法和装置。

背景技术

随着网络技术的发展及广泛应用，网络规模越来越大，设备越来越多，例如电信网络动辄1000多台设备。如何有效地监控网络的运行状况，及时反映设备的连通、中断状态，保证网络的稳定性，以方便维护人员第一时间维护网络是非常重要的。如果一个设备因异常中断了很长时间造成所有业务中断，电信运营商直到用户投诉才发现设备中断，就会耽搁很多时间，这种情况的持续发生会给电信运营商的服务形象造成恶劣的影响，并可能导致较大的经济损失。

在现有技术中，通常通过网元管理后台定时与设备握手来监控设备的通断状态，如图1所示：

1.网元管理后台与设备握手，一般是取设备的sysObjectID(厂商标识符)；

2.若网元管理后台收不到设备的应答消息则表示设备状态为中断，否则状态为连通；

3.若本次握手的结果与上次不同，网元管理后台发送拓扑通知给拓扑模块刷新拓扑显示，并发送告警信息给告警模块。

在现有技术的一种方案中，网元管理后台采用同步方式对设备状态进行轮询，网元管理后台专门启动N个线程，N值根据设备数配置。每个线程采用SNMP(Simple Network Management Protocol，简单网络管理协议)的同步Get方法逐个地取设备的sysObjectID，网元管理后台向设备发送SNMP GET报文，即轮询请求消息，若在设定的超时时间内收到设备的应答，则认为设备是连通的，否则认为设备是中断的。在该方案中，网元管理后台发出轮询请求消息后必须等待设备的应答消息，直至超时才向下一个设备发出请求消息，导致检测周期太长，难以及时有效地反映设备的通断状态，举例如下：

 

假定条件(采用通用SNMP参数设置：SNMP参数5秒超时，3次重试)	检测时间
		最佳情况：设备数＝2000，全通，每个设备同步检测平均耗时1秒	2000秒
一般情况：设备数＝2000，1％设备中断，每个连通的设备同步检测耗时平均1.5秒	3370秒(＝2000*1％*20+2000*99％*1.5)
		最坏情况：设备数＝2000，全断	40000秒

由上表可以看出，当网络中有2000台设备时，采用一个线程+SNMP同步Get方式轮询一次设备，在最好的情况下也需要0.556小时检测一次，一般情况下需要0.936小时，最坏的情况下(设备全断)需要11.11个小时，这显然不能满足要求，即使同时采用10个线程去检测设备也无法及时地反映设备的通断状态，故该方案效率太低，尤其不能应用于较大容量的网络中。

在现有技术的另一方案中，网元管理后台设置一个定时器(例如：5分钟触发一次)，每次进入定时器处理后，采用异步方式逐个构造SNMP消息，并下发GET报文给设备，然后等待设备的应答消息，即网元管理后台连续向所有设备发送轮询请求消息，在设定的超时时间内集中等待应答，这种方式有一些改进，它能及时地反映出设备的通断情况，但也有一些明显的缺陷，例如采用异步发送会造成网元管理后台在短时间内密集地接收到设备的应答报文，造成网元管理后台处理峰值和极高的CPU(Central Processing Unit，中央处理单元)占用率(可以达到50％以上)，影响网元管理后台对其他业务的处理。另外，此方案在每次轮询检测时都要初始化SNMP参数，在大容量的网络环境下会较大地消耗CPU性能。而且此方案难以解决设备闪断问题，即设备由于业务忙，造成在较短的时间内不能回应消息，如果采用通用的SNMP参数(5秒超时、3次重试)，则设备短暂中断21秒肯定会被检测成中断，这种设备实际状态连通但被检测成中断的情况会给维护人员带来不必要的维护工作，而当轮询周期设置成小于一次轮询的实际时间时则会造成定时器信号堆积，即轮询任务堆积。

发明内容

本发明的目的在于提供了一种实现设备状态轮询的方法，旨在解决现有技术中存在的采用同步轮询带来的轮询周期长、无法及时反映设备状态和采用异步全发、集中等待应答带来的占用太多CPU资源的问题。

本发明的另一目的在于提供一种实现设备状态轮询的装置。

为实现上述发明目的，本发明提供了一种实现设备状态轮询的方法，周期性向设备发送轮询请求，根据在超时时间内是否收到设备的应答检测设备的连通状态，所述方法包括：

将待轮询设备分为多个设备组；

对当前设备组内的设备发起轮询请求，在超时时间内集中等待接收当前设备组内的设备的应答；

当超时时间到时对下一个设备组内的设备发起轮询请求，直至所述待轮询设备全部轮询完毕。

所述方法进一步包括：

在对所述待轮询设备进行第一次轮询时，初始化轮询参数；

如果后续轮询进程中轮询参数改变，通过接收消息将轮询参数重新初始化；

所述轮询参数包括设备IP地址、设备标识号、上一次设备的轮询状态、设备的SNMP参数以及设备状态轮询下发的消息包。

所述轮询参数保存在用户配置文件中，供后续轮询进程调用。

所述方法进一步包括：

当次组内的轮询过程中，如果在超时时间内没有收到设备返回的应答，则将没有返回应答的设备放入设备中断列表；

当所述待轮询设备全部轮询完毕后，对所述设备中断列表中的设备进行重复轮询。

轮询的周期通过定时器的定时周期控制，定时周期初始值为预设值，在轮询过程中，当上次全部各个组的轮询实际工作时间小于所述预设值时，将上次全部各个组的轮询实际工作时间与所述预设值的差值作为下次全部各个组的轮询的定时周期，否则重新设置定时器的定时周期。

为实现上述发明目的，本发明还提供了一种实现设备状态轮询的装置，周期性向设备发送轮询请求，根据在超时时间内是否收到设备的应答检测设备的连通状态，所述装置包括：

轮询控制单元，用于将待轮询设备分为多个设备组，对当前设备组内的设备发起轮询请求，在超时时间内集中等待接收当前设备组内的设备的应答，当超时时间到时对下一个设备组内的设备发起轮询请求，直至所述待轮询设备全部轮询完毕；

定时单元，用于设置轮询周期，触发所述轮询控制单元执行设备状态轮询操作。

所述轮询控制单元进一步包括：

轮询参数初始化单元，用于在对所述待轮询设备进行第一次轮询时，初始化轮询参数，如果后续轮询进程中轮询参数改变，通过接收消息将轮询参数重新初始化；

所述轮询参数包括设备IP地址、设备标识号、上一次设备的轮询状态、设备的SNMP参数以及设备状态轮询下发的消息包。

所述装置进一步包括存储单元，用于存储所述轮询参数，供后续轮询进程调用。

所述装置进一步包括设备中断列表，用于存储当次组内的轮询过程中在超时时间内没有返回应答的设备的信息；

当轮询设备全部轮询完毕后，所述轮询控制单元对所述设备中断列表中的设备进行重复轮询。

轮询的周期通过定时器的定时周期控制，定时周期初始值为预设值，在轮询过程中，当上次全部各个组的轮询实际工作时间小于所述预设值时，将上次全部各个组的轮询实际工作时间与所述预设值的差值作为下次全部各个组的轮询的定时周期，否则重新设置定时器的定时周期。

本发明通过对设备进行分组，并依次对各组设备进行异步轮询方式，有效地缩短了轮询周期，能够及时反映出设备的状态，同时可以降低CPU的占用率。另一方面，本发明通过对检测中断的设备进行集中重复轮询，避免了设备闪断的情况，提高了设备状态检测的准确性。

附图说明

图1是适用本发明的系统结构示意图；

图2是本发明提供网元管理后台对设备状态轮询的实现流程图；

图3是本发明提供的设备状态轮询装置的结构图。

具体实施方式

为了使本发明的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。

本发明将待检测设备分组，采用SNMP异步方式依次对各组设备进行轮询，使得在不占用太多CPU资源的基础上，实现对设备状态的快速、准确轮询。

在本发明中，网元管理后台将全部待测设备分为多个组，每组有多个设备，具体将设备分多少个组以及每组中有多少个设备可以根据网络结构的复杂程度灵活设置。典型的，将N个设备平分为M组，每组中的设备个数相同。

对设备进行分组后，网元管理后台采用伪同步方式进行轮询操作，即网元管理后台先对第一组设备发送第一包轮询请求消息，然后在超时时间内集中等待接收第一组设备中各个设备返回的应答消息，超时时间到后再对第二组设备发送第二包轮询请求消息......，重复这个过程直至轮询完所有设备。在对每一组设备进行轮询时采用异步方式，即连续向该组内的所有设备发送轮询请求消息，然后在一定时间内集中接收该组内所有设备的应答消息。

网元管理后台对设备进行轮询的周期通过定时器来控制，定时器时间到触发一次轮询，也可以通过线程中循环执行及时间等待处理等方法实现。

当网络比较繁忙时，对设备检测的花费时间较长，因此单次轮询时间大大增加，如果轮询的实际时间大于定时器设定的轮询周期预设值，就会出现本次轮询还在执行中，但定时器下一个或更多个周期的计数已经完成，因而造成定时器任务的堆积的现象。如果增大定时器的轮询周期预设值，又会使轮询周期过长，使得网元管理后台不能及时地监控到设备的通断状态。

为了避免定时器任务的堆积，同时避免轮询周期过长造成网元管理后台不能及时地监控到设备的通断状态，本发明对定时器的定时周期进行灵活配置。进程启动时创建轮询设备与网管连通性的定时任务，并创建一个定时器，采用配置文件中的PingInterval参数值为定时周期。第一次定时器时间到，后台进程首先删除定时器，再初始化设备队列及其SNMP消息，最后重新创建一个以PingInterval参数值为定时周期的定时器。后续每次轮询任务处理中，依次记录本次轮询开始时间，删除定时器，轮询设备处理结束后，记录本次轮询结束时间，把本次轮询结束时间与开始时间的差值PingDiff与PingInterval参数值比较，若PingInterval-PingDiff>0，则将(PingInterval-PingDiff)作为定时周期重新创建一个定时器，否则取SNMP参数中的一个固定参数值重新创建一个定时器，以后每一次轮询结束后都按照上述方法重新创建定时器。

为了提高轮询效率，减少性能开销，并考虑到实际应用中设备的SNMP参数一般是不会轻易修改的，本发明在网元管理后台对设备进行第一次轮询时完成轮询参数的初始化操作，主要是根据数据库中的设备信息及配置文件中的轮询参数初始化全局设备轮询队列的轮询参数，包括设备IP地址、设备ID(标识号)、上一次设备的轮询状态、设备的SNMP参数以及设备状态轮询下发的消息包等，供后续轮询过程直接使用，在轮询过程中若轮询参数有改变，再通过接收消息重新初始化，避免现有技术中在每次轮询检测时都要初始化轮询参数，在大容量的网络环境下较大地消耗CPU性能的问题。

同时，为了减少现有技术中由于设备短暂忙而被检测成中断给维护人员带来不必要的维护工作，本发明在轮询完一遍设备后，将检测中断的设备放入一个中断列表中，然后再对中断的设备轮询，在轮询完所有的设备后再对中断设备列表中的设备进行重试，可以有效地解决由于设备短暂忙而被检测成中断的问题。例如现有设备数1000台，取设备sysObjectID的正常响应时间在5秒以内，但设备由于业务忙造成连续21秒无法回应轮询请求消息，假定采用标准的SNMP设置(5秒超时，3次重试)，设备检测肯定为中断状态。但在本发明中，SNMP超时时间为10秒，重试1次，总时间未变，但由于是分了两次检测，重试的这次检测就可以检测出设备状态正常了。

图2示出了本发明提供的设备状态轮询的实现流程，详述如下：

在步骤S201中，定时器时间到触发轮询操作，判断是否是第一次轮询，是则执行步骤S202，否则执行步骤S203；

在步骤S202中，进行初始化操作，初始化S NMP消息以及初始化全局设备和设备状态队列，结束本次轮询；

全局的设备状态队列包含两种状态信息，即上一个轮询周期的状态和当前轮询的状态，便于每两个相邻轮询周期的状态进行比较，以进行后续拓扑、告警处理等。

在步骤S203中，将全局设备队列做待轮询设备队列初值，将待轮询设备队列中的设备进行分组，清空中断设备列表；

在步骤S204中，取出一组设备，异步发送轮询请求消息；

在步骤S205中，在超时时间内等待接收设备返回的应答消息；

在步骤S206中，判断在超时时间内是否收到设备的应答消息，是则执行步骤S207，否则执行步骤S208；

在步骤S207中，将设备放入中断设备列表；

在步骤S208中，修改设备状态为连通；

在步骤S209中，判断待轮询队列中的设备是否全部轮询完毕，是则结束本次轮询，否则返回执行步骤S204；

在步骤S210中，判断中断设备列表是否为空，是则结束本次轮询，否则执行步骤S211；

在步骤S211中，判断重试次数是否为0，是则结束本次轮询，否则执行步骤S212；

在步骤S212中，将中断设备列表中的设备作为待轮询队列，返回执行步骤S204，同时将重试次数减1，必要时同样要对中断设备列表中的设备进行分组轮询处理，例如在设备比较多时。

作为本发明的一个实施列，将上述轮询周期预设值PingInterval、设备分组数、重试次数和超时时间等常用SNMP参数保存在配置文件中，并可以通过GUI(Graphic User Interface，图形用户接口)前台界面提供给用户，方便用户修改及维护，使本发明适用于各种规模的网络。

图3示出了本发明提供的实现设备状态轮询的装置的结构，为了便于描述，仅示出与本发明相关的部分，上述已经描述的内容不再重复描述。

定时单元301设置设备状态轮询周期，可以是定时器，也可以通过线程中循环执行及时间等待处理等方法实现。定时器时间到，触发轮询控制单元303启动轮询线程，发起轮询操作。设备状态轮询周期可以按照上述描述灵活设置。

存储单元302用于以配置文件的方式存储轮询周期预设值PingInterval、设备分组数M、重试次数和超时时间等常用SNMP参数，并可以通过GUI(GraphicUser Interface，图形用户接口)前台界面提供给用户。

轮询控制单元303对待检测设备进行分组，然后读取存储单元302中的轮询参数，依次对每组设备进行异步方式轮询，向设备发送轮询请求消息，并接收设备返回的应答消息。

在第一次对设备状态轮询时，轮询参数初始化单元3031将轮询参数进行初始化，并将初始化的轮询参数送往存储单元302保存。

设备中断列表304中记录了轮询过程中没有向轮询控制单元303返回应答消息的设备，轮询控制单元303对各组设备轮询完后，对设备中断列表304中设备进行集中重复轮询。

以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内所作的任何修改、等同替换和改进等，均应包含在本发明的保护范围之内。

Claims (10)

1、一种实现设备状态轮询的方法，周期性向设备发送轮询请求，根据在超时时间内是否收到设备的应答检测设备的连通状态，其特征在于，所述方法包括：

将待轮询设备分为多个设备组；

对当前设备组内的设备发起轮询请求，在超时时间内集中等待接收当前设备组内的设备的应答；

当超时时间到时对下一个设备组内的设备发起轮询请求，直至所述待轮询设备全部轮询完毕。

2、如权利要求1所述的设备状态轮询方法，其特征在于，所述方法进一步包括：

在对所述待轮询设备进行第一次轮询时，初始化轮询参数；

如果后续轮询进程中轮询参数改变，通过接收消息将轮询参数重新初始化；

所述轮询参数包括设备IP地址、设备标识号、上一次设备的轮询状态、设备的SNMP参数以及设备状态轮询下发的消息包。

3、如权利要求2所述的设备状态轮询方法，其特征在于，所述轮询参数保存在用户配置文件中，供后续轮询进程调用。

4、如权利要求1所述的设备状态轮询方法，其特征在于，所述方法进一步包括：

当次组内的轮询过程中，如果在超时时间内没有收到设备返回的应答，则将没有返回应答的设备放入设备中断列表；

当所述待轮询设备全部轮询完毕后，对所述设备中断列表中的设备进行重复轮询。

5、如权利要求1所述的设备状态轮询方法，其特征在于，轮询的周期通过定时器的定时周期控制，定时周期初始值为预设值，在轮询过程中，当上次全部各个组的轮询实际工作时间小于所述预设值时，将上次全部各个组的轮询实际工作时间与所述预设值的差值作为下次全部各个组的轮询的定时周期，否则重新设置定时器的定时周期。

6、一种实现设备状态轮询的装置，周期性向设备发送轮询请求，根据在超时时间内是否收到设备的应答检测设备的连通状态，其特征在于，所述装置包括：

轮询控制单元，用于将待轮询设备分为多个设备组，对当前设备组内的设备发起轮询请求，在超时时间内集中等待接收当前设备组内的设备的应答，当超时时间到时对下一个设备组内的设备发起轮询请求，直至所述待轮询设备全部轮询完毕；

定时单元，用于设置轮询周期，触发所述轮询控制单元执行设备状态轮询操作。

7、如权利要求6所述的设备状态轮询装置，其特征在于，所述轮询控制单元进一步包括：

轮询参数初始化单元，用于在对所述待轮询设备进行第一次轮询时，初始化轮询参数，如果后续轮询进程中轮询参数改变，通过接收消息将轮询参数重新初始化；

所述轮询参数包括设备IP地址、设备标识号、上一次设备的轮询状态、设备的SNMP参数以及设备状态轮询下发的消息包。

8、如权利要求7所述的设备状态轮询装置，其特征在于，所述装置进一步包括存储单元，用于存储所述轮询参数，供后续轮询进程调用。

9、如权利要求6所述的设备状态轮询装置，其特征在于，所述装置进一步包括设备中断列表，用于存储当次组内的轮询过程中在超时时间内没有返回应答的设备的信息；

当轮询设备全部轮询完毕后，所述轮询控制单元对所述设备中断列表中的设备进行重复轮询。

10、如权利要求6所述的设备状态轮询装置，其特征在于，轮询的周期通过定时器的定时周期控制，定时周期初始值为预设值，在轮询过程中，当上次全部各个组的轮询实际工作时间小于所述预设值时，将上次全部各个组的轮询实际工作时间与所述预设值的差值作为下次全部各个组的轮询的定时周期，否则重新设置定时器的定时周期。

Images