发明内容
本发明提供一种监控设备的管理方法和设备,用以解决在级联监控的情况下,中间服务器发生故障时的处理机制不完善的问题。
为达到上述目的,本发明一方面提供了一种监控设备的管理方法,所述方法至少包括以下步骤:
服务器获取自身直接管理的下级服务器上报的监控设备的信息,所述下级服务器上报的监控设备的信息中包含所述下级服务器上报的监控设备所直接归属的服务器的信息,以及所述服务器管理所述监控设备的管理路径信息;
所述服务器在本地管理自身所对应的监控设备的信息,其中,所述服务器所对应的监控设备包括直接归属于所述服务器的监控设备和/或所述服务器直接管理的下级服务器上报的监控设备,所述服务器在本地所管理的自身所对应的监控设备的信息包含所述服务器所对应的各监控设备所直接归属的服务器的信息,以及所述服务器管理所述监控设备的管理路径信息。
其中,所述服务器在本地管理自身所对应的监控设备的信息之后,还包括:
当所述服务器存在上级服务器时,所述服务器将本地管理的自身所对应的监控设备的信息上报给所述上级服务器,其中,所述服务器所对应的监控设备包括直接归属于所述服务器的监控设备和/或所述服务器直接管理的下级服务器上报的监控设备,所述服务器在本地所管理的自身所对应的监控设备的信息包含所述服务器所对应的各监控设备所直接归属的服务器的信息,以及所述服务器管理所述监控设备的管理路径信息。
其中,所述下级服务器上报的监控设备所直接归属的服务器的信息,具体包括:
所述下级服务器上报的监控设备所直接归属的服务器的IP地址信息、端口信息,及其所支持的域间规范;
所述服务器所对应的各监控设备所直接归属的服务器的信息,具体包括:
所述服务器所对应的各监控设备所直接归属的服务器的IP地址信息、端口信息,及其所支持的域间规范;
所述服务器管理所述监控设备的管理路径信息,具体为:
所述服务器管理所述下级服务器上报的监控设备所需要经过的各级服务器的信息。
其中,当所述服务器确定所述下级服务器发生故障时,所述方法还包括:
所述服务器判断自身与所述下级服务器上报的监控设备之间是否存在其他路径;
如果有,所述服务器通过所述其他路径与所述下级服务器上报的监控设备建立业务关系;
如果没有,且所述下级服务器上报的监控设备所直接归属的服务器不是发生故障的所述下级服务器,所述服务器根据之前获取到的所述服务器管理所述监控设备的管理路径信息,向与所述下级服务器上报的监控设备建立业务关系的其他下级服务器发送业务关系更新消息,并在收到相应的业务关系更新确认后,将返回所述业务关系更新确认的其他下级服务器作为替换服务器,建立所述下级服务器上报的监控设备的业务关系。
其中,所述服务器向与所述下级服务器上报的监控设备建立业务关系的其他下级服务器发送业务关系更新消息,具体包括:
所述服务器根据之前获取到的所述服务器管理所述监控设备的管理路径信息,按照各所述其他服务器所处级别从高到低的顺序,依次向与所述下级服务器上报的监控设备建立业务关系的各所述其他下级服务器发送业务关系更新消息。
其中,当所述服务器确定发生故障的所述下级服务器的故障恢复时,还包括:
所述服务器接收故障恢复的所述下级服务器的注册请求,并完成注册操作,通过故障恢复的所述下级服务器建立所述下级服务器上报的监控设备的业务连接;
所述服务器向所述替换服务器发送业务还原通知,以使所述替换服务器恢复与故障恢复的所述下级服务器之间的业务连接。
另一方面,本发明还提供了一种服务器,至少包括:
获取模块,用于获取所述服务器直接管理的下级服务器上报的监控设备的信息,所述下级服务器上报的监控设备的信息中包含所述下级服务器上报的监控设备所直接归属的服务器的信息,以及所述服务器管理所述监控设备的管理路径信息;
管理模块,用于管理所述服务器所对应的监控设备的信息,所述服务器所对应的监控设备包括直接归属于所述服务器的监控设备和/或所述服务器直接管理的下级服务器上报的监控设备,所述服务器在本地所管理的自身所对应的监控设备的信息包含所述服务器所对应的各监控设备所直接归属的服务器的信息,以及所述服务器管理所述监控设备的管理路径信息。
其中,该服务器,还包括发送模块,用于在所述服务器存在上级服务器时,将所述管理模块所管理的所述服务器所对应的监控设备的信息上报给所述上级服务器,其中,所述服务器所对应的监控设备包括直接归属于所述服务器的监控设备和/或所述服务器直接管理的下级服务器上报的监控设备,所述服务器在本地所管理的自身所对应的监控设备的信息包含所述服务器所对应的各监控设备所直接归属的服务器的信息,以及所述服务器管理所述监控设备的管理路径信息。
其中,该服务器,还包括检测模块和判断模块,
所述检测模块,用于检测所述下级服务器是否发生故障;
所述判断模块,用于当所述检测模块确定所述下级服务器发生故障时,判断所述服务器与所述下级服务器上报的监控设备之间是否存在其他路径;
所述发送模块,还用于在所述判断模块的判断结果为有时,通过所述其他路径与所述下级服务器上报的监控设备建立业务关系,而在所述判断模块的判断结果为没有,且所述下级服务器上报的监控设备所直接归属的服务器不是发生故障的所述下级服务器时,根据之前所述获取模块所获取到的所述服务器管理所述监控设备的管理路径信息,向与所述下级服务器上报的监控设备建立业务关系的其他下级服务器发送业务关系更新消息,并在收到相应的业务关系更新确认后,将返回所述业务关系更新确认的的其他下级服务器作为替换服务器,建立所述下级服务器上报的监控设备的业务关系。
其中,所述发送模块,具体用于根据之前所述获取模块所获取到的所述服务器管理所述监控设备的管理路径信息,按照各所述其他服务器所处级别从高到低的顺序,依次向与所述下级服务器上报的监控设备建立业务关系的各所述其他下级服务器发送业务关系更新消息。
其中,所述获取模块,还用于当所述检测模块确定发生故障的所述下级服务器的故障恢复时,接收故障恢复的所述下级服务器的注册请求,并完成注册操作,通过故障恢复的所述下级服务器建立所述下级服务器上报的监控设备的业务连接;
所述发送模块,还用于当所述检测模块确定发生故障的所述下级服务器的故障恢复时,向所述替换服务器发送业务还原通知,以使所述替换服务器恢复与故障恢复的所述下级服务器之间的业务连接。
与现有技术相比,本发明所提出的技术方案具有以下优点:
通过应用本发明的技术方案,在级联监控的场景中,各级联服务器在进行监控设备的信息传输过程中,将该监控设备所直接归属的服务器的信息,以及所述服务器管理所述监控设备的管理路径信息一并进行上报,在中间服务器发生故障时,上级服务器可以为发生故障的中间服务器选择替换服务器,保障与该监控设备之间的业务连接的正常工作,从而,使级联监控场景中单个中间服务器的故障不会影响其他监控业务的正常实现,提高相应的监控系统的可靠性,简化故障处理和恢复的操作流程,提高相应的处理效率。
具体实施方式
如背景技术所述,在级联监控场景中,现有的监控机制是将监控设备进行设备推送和目录推送处理。
其中,设备推送是指在监控业务中,如果下级服务器要把自己管理的监控设备交给上级服务器使用,需要将监控设备的信息放到SIP的NOTIFY(通知)消息的消息体中,通过发送此NOTIFY消息给上级服务器,使得上级服务器可以管理和使用此监控设备。
而目录推送是指在上面的设备推送的过程中,如果监控设备是在下级服务器中的某个特定的组织下,下级服务器可以将此组织的目录信息也一起放到SIP的NOTIFY消息发给上级服务器。这样上级服务器就知道下级服务器推送过来的监控设备放在哪个特定组织所对应的目录下,便于管理。
但是,通过上述的设备推送和目录推送处理,不同的服务器之间所进行域间目录推送只是说明此监控设备是挂在下级服务器的哪个组织下面。但此组织是属于这个下级服务器的,还是属于该下级服务器所管理的另一个服务器的,则没有明确说明,并且,这样的信息在目前的目录推送方案中是没有涉及的。因此,造成了服务器对于监控设备具体位置的不确定,一旦上报该监控设备信息的下级服务器发生故障,则无法定位监控设备的实际位置,也无法建立相应的替换业务链接,从而,会导致业务中断。
为了解决上述问题,本发明通过在服务器间交互的监控设备信息中进一步携带监控设备所直接归属的服务器的信息,以及服务器管理该监控设备的管理路径信息,从而,当中间服务器发生故障时,服务器可以根据监控设备所直接归属的服务器的信息,以及服务器管理该监控设备的管理路径信息,在该监控设备的业务路径中找到替换服务器,并恢复业务连接,保障业务的正常实现。
如图2所示,为本发明提出的一种监控设备的管理方法的流程示意图,具体包括以下步骤:
步骤S201、服务器获取自身直接管理的下级服务器上报的监控设备的信息,所述下级服务器上报的监控设备的信息中包含所述下级服务器上报的监控设备所直接归属的服务器的信息,以及所述服务器管理所述监控设备的管理路径信息。
在具体的实施场景中,所述下级服务器上报的监控设备所直接归属的服务器的信息,具体包括以下信息的一种或多种:
所述下级服务器上报的监控设备所直接归属的服务器的IP地址信息、端口信息,及其所支持的域间规范。
在实际应用中,为了表示监控设备的实际位置,上述的信息也可以包括其他的信息内容,凡是能够表示监控设备所归属的服务器信息的信息类型,都应属于本发明的保护范围。
而所述服务器管理所述监控设备的管理路径信息,具体为该服务器管理所述下级服务器上报的监控设备所需要经过的各级服务器的信息。
这样的信息获取为后续的替换服务器的确定,以及相应的域间通信规范的协商奠定了基础。
步骤S202、所述服务器在本地管理自身所对应的监控设备的信息,其中,所述服务器所对应的监控设备包括直接归属于所述服务器的监控设备和/或所述服务器直接管理的下级服务器上报的监控设备,所述服务器在本地所管理的自身所对应的监控设备的信息包含所述服务器所对应的各监控设备所直接归属的服务器的信息,以及所述服务器管理所述监控设备的管理路径信息。
去步骤S201相类似,在具体的实施场景中,所述服务器所对应的各监控设备所直接归属的服务器的信息,具体包括以下信息的一种或多种:
所述服务器所对应的各监控设备所直接归属的服务器的IP地址信息、端口信息,及其所支持的域间规范。
在实际应用中,为了表示服务器所对应的各监控设备的实际位置,上述的信息也可以包括其他的信息内容,凡是能够表示服务器所对应的各监控设备所归属的服务器信息的信息类型,都应属于本发明的保护范围。
而所述服务器管理所述监控设备的管理路径信息,具体为该服务器管理所述下级服务器上报的监控设备所需要经过的各级服务器的信息。
通过本步骤的处理,服务器将自身所管理的监控设备,以及自身以下的各级服务器所对应的监控设备的信息统一进行管理,在正常状态下的应用过程中,这些监控设备都被本服务器视为自身所直接管理的监控设备,可以进行直接的调用和管理。
在具体的应用场景中,当该服务器存在上级服务器,且该上级服务器需要与该服务器上所管理的监控设备建立业务连接时,该服务器将本地管理的监控设备的信息上报给该上级服务器。
其中,所述服务器所对应的监控设备包括直接归属于所述服务器的监控设备和/或所述服务器直接管理的下级服务器上报的监控设备,所述服务器在本地所管理的自身所对应的监控设备的信息包含所述服务器所对应的各监控设备所直接归属的服务器的信息,以及所述服务器管理所述监控设备的管理路径信息。
通过这样的方式,级联监控系统中的各级服务器一方面管理着自身以及下级服务器所对应的监控设备,另一方面,还将这样的监控设备信息上报给自身的上级服务器,从而,使级联监控系统中的各服务器都能全面的管理自身以下的所有监控设备的信息。
在完成了上述的信息交互后,各级服务器都已经获取了自身以下的各级服务器所对应的监控设备的信息,之后,服务器自身对于级联监控系统中自身的下级服务器进行通信状态检测,具体的检测规则可以根据实际需要进行设置,可以是该服务器的主动检测,也可以是该服务器与下级服务器之间的保活报文交互,或者也可以是下级服务器定期的状态上报报文,当然也可以是能够达到通信状态检测的其他方式,具体应用哪种方式进行通信状态的检测,并不会影响本发明的保护范围。
需要指出的是,上述的服务器自身对于级联监控系统中自身的下级服务器进行通信状态检测的过程中,所检测的目标服务器实际为该服务器下的直接下级服务器,而对该下级服务器的更下级的服务器,则不用本服务器进行检测,而是由下级服务器去进行检测,这样,层层递进的检测模式一方面充分的分摊了各级服务器的检测工作量,另一方面,也可以使检测的准确率和效率得到提高。
当所述服务器通过检测,确定自身的一个或多个下级服务器发生故障时,相应的处理过程包括:
所述服务器判断自身与该发生故障的下级服务器所上报的监控设备之间是否存在其他路径。
如果有,所述服务器通过该其他路径与相应的监控设备建立业务关系。其中的替换路径可能是源于当前级联监控系统中的多路径设置。
如果没有,且该监控设备所直接归属的服务器不是发生故障的下级服务器,那么,该服务器根据之前获取到的该服务器管理该监控设备的管理路径信息,向与该监控设备建立业务关系的其他下级服务器发送业务关系更新消息,并在收到相应的业务关系更新确认后,将返回所述业务关系更新确认的其他下级服务器作为替换服务器,建立与该监控设备的业务关系。
需要指出的是,上述过程所给出的其他下级服务器可能是发生故障的下级服务器所管理的下一级的服务器,甚至是更下一级或下几级的服务器;而业务关系更新消息的发送的规则可以是向级别最接近的一个或多个其他下级服务器发送业务关系更新消息,也可以是向所有处于级联链路中的各其他下级服务器全部发送该业务更新消息,当然,发送的方式可以是按照一定的规则依次发送,也可以是按照广播的方式一次性发送,这样的变化并不影响本发明的保护范围。
当然,如果没有其他路径,且监控设备所归属的服务器就是发生故障的所述下级服务器,那么,服务器将无法通过其他方式与该监控设备恢复业务连接,因此,只能中断与该监控设备的业务连接,但是,这样的情况下,这个发生故障的下级服务器对于相应的监控设备来讲,也不再是中间服务器而是该监控设备所直接归属的服务器,所以,不再是本发明所讨论的范围,在此不作过多说明。
需要进一步指出的是,对于整个级联监控系统的影响,所述服务器发送业务关系更新消息的操作可以设置相应的规则,例如,如果多个其他下级服务器都返回了业务关系更新确认,那么,本服务器可以优先将与自身的级别相差较少的服务器作为替换服务器。
在实际的应用场景中,可以采用的一种具体的处理方式为:所述服务器根据之前收到的该监控设备的管理路径信息,按照级别从高到低的顺序,依次向与所述监控设备建立业务关系的其他下级服务器发送业务关系更新消息,并等待业务关系更新确认,如果没有收到业务关系更新确认,则继续向下一级的服务器发送业务关系更新消息,直至收到一个业务关系更新确认,并将返回该业务关系更新确认的服务器确定为替换服务器。
在确定了相应的替换服务器后,如果所述服务器确定发生故障的所述下级服务器的故障恢复,那么,还将包括相应的故障恢复流程,具体包括:
所述服务器接收故障恢复的所述下级服务器的注册请求,并完成注册操作,通过所述下级服务器建立所述监控设备的业务连接。
所述服务器向所述替换服务器发送业务还原通知,以使所述替换服务器恢复与故障恢复的所述下级服务器之间的业务连接。
另一方面,如果是在之前发生中间服务器的故障时,是通过其他路径建立的替换的业务连接,那么,可以根据实际需要,将业务连接重新建立在故障恢复的服务器所对应的路径上,也可以保持当前的通信状态,而以故障恢复的服务器所对应的路径为备份路径,对当前的业务链接进行保护,具体应用哪种规则并不会影响本发明的保护范围。
与现有技术相比,本发明所提出的技术方案具有以下优点:
通过应用本发明的技术方案,在级联监控的场景中,各级联服务器在进行监控设备的信息传输过程中,将该监控设备所直接归属的服务器的信息,以及所述服务器管理所述监控设备的管理路径信息一并进行上报,在中间服务器发生故障时,上级服务器可以为发生故障的中间服务器选择替换服务器,保障与该监控设备之间的业务连接的正常工作,从而,使级联监控场景中单个中间服务器的故障不会影响其他监控业务的正常实现,提高相应的监控系统的可靠性,简化故障处理和恢复的操作流程,提高相应的处理效率。
为了进一步阐述本发明的技术思想,现结合具体的应用场景,对本发明的技术方案进行说明。
如图3所示,为本发明实施例中的一个多级的典型监控组网的结构示意图。
以行政区划为例,假设服务器D属于区级管理平台,服务器D下面管理着摄像头X,为方便说明,后文均以摄像头作为监控设备的示例进行说明,这样的名称变化并不会影响本发明的保护范围。
服务器D上面的服务器C属于县级管理平台,其具有查看区级管理平台(服务器D)所有摄像头的权限。
服务器C上面的服务器B属于市级管理平台,其具有查看所有县级管理平台(服务器C)的摄像头的权限,当然,这里面也包括区级管理平台(服务器D)的摄像头X,因为,在服务器B看来,摄像头X是属于服务器C管理范围的摄像头。
最上面的服务器A属于省级管理平台,具有查看所有的下级服务器(包括服务器B、服务器C和服务器D)的摄像头的权限,当然,这里面也包括区级管理平台(服务器D)的摄像头X,因为,在服务器A看来,摄像头X是属于服务器B管理范围的摄像头。
上述的级联监控网络的部署示例只是说明支持多级多域的组网,在实际的应用场景中,同样平级多域的组网方式也可以应用本发明所提出的技术方案,流程和多级多域一样,为了简化说明,在此不再重复描述,但这并不会影响本发明的保护范围。
为了在中间服务器出现故障时,实现上级服务器的相关业务不受影响,本发明所提出的技术方案主要涉及到以下两个方面的改进:
(1)对现有的推送信息进行扩充,将摄像头所直接归属的服务器信息携带于相应的推送信息中,通知给上级服务器。
(2)新增主动业务关系更新/还原的消息,在出现中间服务器的故障时,通过主动业务关系更新/还原的消息,与替换服务器建立相应的业务连接。
首先,对第(1)点改进进行详细说明:
为了克服现有技术中的摄像头归属信息的不明确的问题,在本发明所提出的技术方案中,在相应的推动信息中加上标识,使得上级服务器能够知道这个推送的是目录还是服务器。如果推送的是服务器,则推送信息中要加上服务器的通讯IP和端口,以及支持的域间规范。
以下提供一个推送目录的XML消息示例以供参考:
其中,<DomainFlag>,<CommInfo>和<SupportProtocol>三个字段为新增字段。DomainFlag表示这是一个服务器,CommInfo表示通讯信息为192.168.30.88,端口为5066,SupportProtocol表示支持的域间通信规范为“域间规范-A”。
增加推送时的信息是为了让上级服务器能够知道下级服务器所推送过来的摄像头所对应的服务器的信息以及域间通信协议。以便重新建立业务关系的时候,上级服务器知道此摄像头所对应的所有服务器路径,并且可以协商两个服务器之间的通信规范。
需要进一步指出的是,上述的携带摄像头所归属服务器的信息的方式还可以用其他方式代替。
例如,由于域间互联协议对于摄像头的编码都有相应的规划,如果对于摄像头的级联关系不从推送消息中得知,还可以通过对摄像头的编码进行分析。因为每个互联协议中,对于摄像头的编码定义都是有一套规则的,根据此规则也可以知道摄像头是从属于哪个服务器的。
如图4所示,摄像头的编码一共18位的编码,各位的编码内容所表示的信息如图4所示,通过对该编码信息的分析,就知道这个摄像头是属于哪里的服务器的监控设备,从而,可以直接访问此服务器来与该摄像头建立相应的业务关系,这样的方式同样属于本发明的保护范围。
另一方面,对于上述的第(2)点改进,本发明结合图5至图9进行介绍,
如图5所示,为本发明实施例中的一种存在故障的级联监控场景的示意图,在该场景中,服务器B出现异常,无法再向服务器A进行注册,也无法处理来自服务器C的消息。
在该场景中,可以在服务器A上应用本发明所提出的一种监控设备的管理方法,相应的流程示意图如图6所示,具体包括以下步骤:
步骤S601、服务器A发现服务器B离线。
具体的发现方式可以是通过保活消息或其他方式来体现,如果服务器A在一段时间内没有收到服务器B的保活消息,则认为服务器B离线。
步骤S602、服务器A检测到服务器B离线之后,分析确定替换服务器。
首先,服务器A查看接收到的所有的服务器信息,通过分析按照前述的规则扩充过的推送消息,可以知道外域摄像头的级联关系信息。
这里的摄像头的服务器信息就是摄像头经过的服务器的推送路径信息。在如图3所示的示例中只有一个级联关系:摄像头X是由服务器D推送给服务器C,再由服务器C推送给服务器B,服务器B再推送给服务器A。
在外部的复杂组网中,很多时候不只有这么简单的业务关系,如图7所示,服务器D可以将摄像头X再推送给服务器F,服务器F又将摄像头推送给服务器A。
当存在多条级联关系的时候,按照用户配置的优先级进行选择。例如,在图7所示的应用场景中,摄像头X是通过不同服务器(服务器B、服务器C和服务器F)推送给服务器A的,如果服务器A要查看摄像头X的实况,需要选择其中一条业务关系进行通信。这时需要用户手动配置或根据相应的规则选择相应的路径配置业务关系,如:用户希望信令经过服务器B→服务器C→服务器D进行传输,使得服务器B、服务器C可以对信令进行处理,那么,服务器A-服务器B-服务器C-服务器D的路径将成为主路径,而服务器A-服务器F-服务器D的路径将作为备用路径。
当在步骤S601中服务器A确定服务器B离线时,本步骤中需要根据用户配置的优先级规则进行业务关系更新选择:
如果用户配置的是其它业务关系(服务器F→服务器D)优先,则服务器A直接选择其它业务关系(服务器F→服务器D)为新的主路径,继续进行业务。
但是,如果用户配置的是原业务关系优先,就需要进行业务更新,从而执行步骤S603。
步骤S603、服务器A构造一条SIP.info消息去通知服务器B的下级服务器C,查看服务器C能否作为替代服务器。
步骤S604、服务器C收到此SIP.info消息,判断自身是否可以作为替代服务器。
经过权限判断,如果服务器C确定允许自身作为替代服务器,则向服务器A回复SIP.200OK响应。
相反,如果服务器C鉴权失败或者网络不通,则回复失败响应。
步骤S605、服务器A如果收到回复失败响应,则转向步骤S608。如果收到成功响应,则执行步骤S606,等待服务器C进行注册。
步骤S606、服务器C开始根据SIP.info消息的地址信息,向服务器A进行注册。
步骤S607、服务器A收到此注册请求,将服务器C的状态置为在线,同时更新业务关系,将摄像头X的服务器关系直接更新为服务器C。
服务器A直接发送实况请求到服务器C。
步骤S608(图中未示出)、服务器A如果收到SIP.info的错误响应,表示服务器C也有异常,则再查找服务器列表中的级联关系,继续构造新的SIP.info消息发给服务器D,服务器D的处理流程同服务器C。
在实际的操作中,由于网络问题或者服务器自身的故障,不一定每次的SIP.info消息都能收到响应,如果服务器A没有收到SIP.info的响应,那么,服务器A会进行一定数量(例如:三次)的重发尝试,如果一直没有响应,则认为服务器C有异常,继续将SIP.info消息发给服务器D,进行服务器D是否可以作为替代服务器的尝试。
在上述的过程中,设置尝试数量可以有效的避免对于故障服务器的频繁尝试所带来的资源浪费。
经过以上处理过程,如果服务器C确认自身可以作为替代服务器,那么,将形成下面图8所示的新业务关系,整个网络的监控业务又可以正常进行。
如果上述的服务器B的故障得以恢复,那么,本发明还进一步提出的业务关系的还原流程,其流程示意图如图9所示,包括以下步骤:
步骤S901、当服务器B的异常恢复时,会重新向服务器A进行注册。
步骤S902、服务器A通过注册消息感知到服务器B己经正常,查询发现需要进行业务还原。
步骤S903、服务器A根据新的业务关系,向服务器C发送业务还原消息通知其业务还原,并且不再处理来自服务器C的消息(保活等)。
需要进一步指出的是,这里服务器A发送的业务还原消息不需要等待响应,无论业务还原消息丢失或者服务器C处理失败,服务器A都不会再处理任何来自服务器C的消息,这样,服务器C一样会保活失败,保活失败之后服务器C也会触发业务还原流程,即执行步骤S904中的业务还原流程。
步骤S904、服务器C收到业务还原消息时,停止向服务器A注册,并且转向原来配置的服务器B注册。
在注册成功后,整个网络的业务关系还原。
与现有技术相比,本发明所提出的技术方案具有以下优点:
通过应用本发明的技术方案,在级联监控的场景中,各级联服务器在进行监控设备的信息传输过程中,将该监控设备所直接归属的服务器的信息,以及所述服务器管理所述监控设备的管理路径信息一并进行上报,在中间服务器发生故障时,上级服务器可以为发生故障的中间服务器选择替换服务器,保障与该监控设备之间的业务连接的正常工作,从而,使级联监控场景中单个中间服务器的故障不会影响其他监控业务的正常实现,提高相应的监控系统的可靠性,简化故障处理和恢复的操作流程,提高相应的处理效率。
为了实现本发明的技术方案,基于前述的说明,本发明还提出了一种服务器,其结构示意图如图10所示,该服务器具体包括:
获取模块101,用于获取所述服务器直接管理的下级服务器上报的监控设备的信息,所述下级服务器上报的监控设备的信息中包含所述下级服务器上报的监控设备所直接归属的服务器的信息,以及所述服务器管理所述监控设备的管理路径信息。
管理模块102,用于管理所述服务器所对应的监控设备的信息,所述服务器所对应的监控设备包括直接归属于所述服务器的监控设备和/或所述服务器直接管理的下级服务器上报的监控设备,所述服务器在本地所管理的自身所对应的监控设备的信息包含所述服务器所对应的各监控设备所直接归属的服务器的信息,以及所述服务器管理所述监控设备的管理路径信息。
进一步的,该服务器还包括发送模块103,用于在所述服务器存在上级服务器时,将所述管理模块102所管理的所述服务器所对应的监控设备的信息上报给所述上级服务器,其中,所述服务器所对应的监控设备包括直接归属于所述服务器的监控设备和/或所述服务器直接管理的下级服务器上报的监控设备,所述服务器在本地所管理的自身所对应的监控设备的信息包含所述服务器所对应的各监控设备所直接归属的服务器的信息,以及所述服务器管理所述监控设备的管理路径信息。
该服务器还包括检测模块104和判断模块105。
所述检测模块104,用于检测所述下级服务器是否发生故障。
所述判断模块105,用于当所述检测模块104确定所述下级服务器发生故障时,判断所述服务器与所述下级服务器上报的监控设备之间是否存在其他路径。
所述发送模块103,还用于在所述判断模块105的判断结果为有时,通过所述其他路径与所述下级服务器上报的监控设备建立业务关系,而在所述判断模块105的判断结果为没有,且所述下级服务器上报的监控设备所直接归属的服务器不是发生故障的所述下级服务器时,根据之前所述获取模块101所获取到的所述服务器管理所述监控设备的管理路径信息,向与所述下级服务器上报的监控设备建立业务关系的其他下级服务器发送业务关系更新消息,并在收到相应的业务关系更新确认后,将返回所述业务关系更新确认的的其他下级服务器作为替换服务器,建立所述下级服务器上报的监控设备的业务关系。
在具体的应用场景中,所述发送模块103具体用于根据之前所述获取模块101所获取到的所述服务器管理所述监控设备的管理路径信息,按照各所述其他服务器所处级别从高到低的顺序,依次向与所述下级服务器上报的监控设备建立业务关系的各所述其他下级服务器发送业务关系更新消息。
另一发面,所述获取模块101还用于当所述检测模块104确定发生故障的所述下级服务器的故障恢复时,接收故障恢复的所述下级服务器的注册请求,并完成注册操作,通过故障恢复的所述下级服务器建立所述下级服务器上报的监控设备的业务连接。
相应的,所述发送模块103还用于当所述检测模块104确定发生故障的所述下级服务器的故障恢复时,向所述替换服务器发送业务还原通知,以使所述替换服务器恢复与故障恢复的所述下级服务器之间的业务连接。
与现有技术相比,本发明所提出的技术方案具有以下优点:
通过应用本发明的技术方案,在级联监控的场景中,各级联服务器在进行监控设备的信息传输过程中,将该监控设备所直接归属的服务器的信息,以及所述服务器管理所述监控设备的管理路径信息一并进行上报,在中间服务器发生故障时,上级服务器可以为发生故障的中间服务器选择替换服务器,保障与该监控设备之间的业务连接的正常工作,从而,使级联监控场景中单个中间服务器的故障不会影响其他监控业务的正常实现,提高相应的监控系统的可靠性,简化故障处理和恢复的操作流程,提高相应的处理效率。
通过以上的实施方式的描述,本领域的技术人员可以清楚地了解到本发明可以通过硬件实现,也可以借助软件加必要的通用硬件平台的方式来实现。基于这样的理解,本发明的技术方案可以以软件产品的形式体现出来,该软件产品可以存储在一个非易失性存储介质(可以是CD-ROM,U盘,移动硬盘等)中,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者网络设备等)执行本发明各个实施场景所述的方法。
本领域技术人员可以理解附图只是一个优选实施场景的示意图,附图中的模块或流程并不一定是实施本发明所必须的。
本领域技术人员可以理解实施场景中的装置中的模块可以按照实施场景描述进行分布于实施场景的装置中,也可以进行相应变化位于不同于本实施场景的一个或多个装置中。上述实施场景的模块可以合并为一个模块,也可以进一步拆分成多个子模块。
上述本发明序号仅仅为了描述,不代表实施场景的优劣。
以上公开的仅为本发明的几个具体实施场景,但是,本发明并非局限于此,任何本领域的技术人员能思之的变化都应落入本发明的保护范围。