专利名称：一种视频监控场景中的容灾方法和设备的制作方法
技术领域：
本发明涉及通信技术领域，特别涉及一种视频监控场景中的容灾方法和设备。
背景技术：
如图1所示，为现有技术中进行监控的网络结构示意图，其中，包含以下组件
流媒体服务器(Media Server,MS)，在网路中分布式部署，用于实现组播媒体流转 发分发和单播媒体流转发分发，以及历史数据视频点播(Video OnDemand， VOD)点播，基于 Web的用户管理界面。 视频管理服务器(Video Management Server, VM)，用于认证、配置、控制信令转 发、报警接收转发、自检、网管和全系统管理。 视频客户端(Video Client, VC)，用于实现视频数据的播放。 在上述系统中，具体的数据传输的实现依赖于以下两种协议 视频管理协议(Video Manage Protocol, VMP)，是针对网络互联协议(Internet
Protocol, IP)视频监控系统的一种管理控制协议。主要用于VM视频管理服务器对所有的
编解码器、客户端和匿数据管理服务器、MS流媒体交换服务器的管理控制。 —般管理协议(General Manage Protocl， GMP)，是VC与VM之间的私有协议。 如图2所示，为现有技术中进行监控的方法的流程示意图，具体包括以下步骤 步骤S201、 VC用户VC1、 VC2、 VC3、 VC4、 VC5、 VC6点播ECl (EmbeddedController，
嵌入式控制器)实况，通过GMP协议将此操作命令反馈给VM ; 步骤S202、VM收到VC1、VC2、VC3、VC4、VC5、VC6的GMP请求建立实况的报文后，向 MSI发送APPLY (Request)报文；选择MSI是因为VM视频管理服务器上已经指定了 ECl通 过MS1转发； 步骤S203、 VM收到MSI的回应后，再往EC1、各VC的MP发送Setup报文，建立监 控关系； 步骤S204、EC1将一路实时视频流转发到MSI，MSI将实时视频流分发到VC1、VC2、 VC3、VC4、VC5、 VC6 ; 步骤S205、释放监控关系前，VM向MSI发Delete资源释放请求； 步骤S206、 VM等待MSI回应成功后，与EC1、各VC的MP分别释放监控关系； 步骤S207、 VC1、VC2、VC3、VC4、VC5、VC6客户端收到VM发送的Release请求消息
并发送Release应答消息后，将向VM再次主动发送Release请求消息，主动释放已释放过
一次但有可能释放不成功的监控关系；VM收到这一消息后不需做出任何应答。 监控环境中部署流媒体服务器，EC指定使用MS进行分发时，当MS设备意外故障，
如MS设备掉电、服务重启、网线松动等原因，会导致VC客户端点播实况中断。 在实现本发明的过程中，发明人发现现有技术至少存在以下问题 监控环境中部署MS流媒体服务器，EC指定使用MS进行分发时，当MS设备意外故
障，如MS掉电、服务重启、网线松动等原因，会导致VC客户端点播的实况流中断；而VM通过保活机制确认MS是否在线，无法实时侦测MS状态； 全网在多个网段中部署的MS设备无法互相热备，资源无法得到充分利用；通过更 改配置将EC对应MS修改为其他在线MS，无法快速恢复用户正在点播的实况。
发明内容
本发明提供一种视频监控场景中的容灾方法和设备，在流媒体服务器发生故障 后，通过选择容灾流媒体服务器，保证视频监控业务的正常进行。 为达到上述目的，本发明一方面提供了一种视频监控场景中的容灾方法，应用于 包括多个视频客户端、多个视频监控设备、多个流媒体服务器和一个视频管理服务器的系 统中，所述方法包括 所述视频管理服务器接收到至少一个视频客户端发送的故障告警消息，并根据所 述故障告警消息确定对应的故障流媒体服务器； 所述视频管理服务器确定能够分担所述故障流媒体服务器业务的至少一个容灾 流媒体服务器； 所述视频管理服务器根据各视频管理服务器所发送的自身的资源占用情况，确定 能够分担所述故障流媒体服务器业务的至少一个容灾流媒体服务器； 所述视频管理服务器向所述容灾流媒体服务器发送携带所述故障流媒体服务器
的业务信息的通知消息，并向所述故障流媒体服务器所对应的各视频客户端发送业务建立
消息，将所述故障流媒体服务器的业务切换到所述容灾流媒体服务器中。 优选的，所述视频管理服务器接收到至少一个视频客户端发送的故障告警消息之
前，还包括 所述流媒体服务器按照反馈周期向视频管理服务器发送自身的资源占用情况； 相应的，所述视频管理服务器根据各视频管理服务器所发送的自身的资源占用情
况，确定能够分担所述故障流媒体服务器业务的至少一个容灾流媒体服务器。 优选的，各所述流媒体服务器按照反馈周期向视频管理服务器发送自身的资源占
用情况，具体包括 各所述流媒体服务器在接入系统后，向所述视频管理服务器发送自身能够支持的 最大连接数量和最大出口带宽的信息； 各所述流媒体服务器按照所述反馈周期，向所述视频管理服务器发送自身当前保 持的连接数量和当前占用的出口带宽的信息。 优选的，所述视频管理服务器根据各视频管理服务器所发送的自身的资源占用情
况，确定能够分担所述故障流媒体服务器业务的至少一个容灾流媒体服务器，具体为 所述视频管理服务器根据各流媒体服务器所发送的自身的资源占用情况，判断当
前剩余的各流媒体服务器所剩余的可连接数量和剩余出口带宽资源是否高于或等于所述
故障流媒体服务器最近一次所上报的保持的连接数量和占用的出口带宽资源； 如果所述视频管理服务器判断存在一个流媒体服务器符合要求，则确定所述流媒
体服务器为容灾流媒体服务器； 如果所述视频管理服务器判断存在多个流媒体服务器符合要求，则按照预设的选 择规则，确定其中的一个流媒体服务器为容灾流媒体服务器；
如果所述视频管理服务器判断没有流媒体服务器符合要求，则确定所剩余的可连 接数量和剩余出口带宽资源之和符合要求的多个流媒体服务器为容灾流媒体服务器。
优选的，所述视频管理服务器所接收到至少一个视频客户端发送的故障告警消 息，具体为 当当前系统中的视频客户端接收不到流媒体服务器发送的视频信息数据时，向所 述视频管理服务器发送的故障告警消息。 优选的，所述视频管理服务器确定所述故障告警消息所对应的故障流媒体服务 器，具体为 所述视频管理服务器轮询当前系统中的所有流媒体服务器，确定轮询失败的流媒 体服务器为故障流媒体服务器。 优选的，所述视频管理服务器向所述容灾流媒体服务器发送携带所述故障流媒体 服务器的业务信息的通知消息，具体为 所述视频管理服务器根据所述故障流媒体服务器所承担的多个业务，分别通过多 个通知消息携带各业务所对应的发送端和接收端的信息，发送给所述视频管理服务器。
另一方面，本发明还提供了一种视频管理服务器，应用于包括多个视频客户端、多 个视频监控设备、多个流媒体服务器和一个视频管理服务器的系统中，包括
接收模块，用于接收至少一个视频客户端发送的故障告警消息； 确定模块，与所述接收模块相连接，用于根据所述接收模块所接收到的故障告警 消息确定对应的故障流媒体服务器； 容灾模块，与所述接收模块和所述确定模块相连接，用于确定能够分担所述确定 模块所确定的故障流媒体服务器业务的至少一个容灾流媒体服务器； 处理模块，与所述容灾模块相连接，用于向所述容灾流媒体服务器发送携带所述 故障流媒体服务器的业务信息的通知消息，并向所述故障流媒体服务器所对应的各视频客 户端发送业务建立消息，将所述故障流媒体服务器的业务切换到所述容灾模块所确定的容 灾流媒体服务器中。 优选的，所述接收模块，还用于接收各所述流媒体服务器按照反馈周期所发送自 身的资源占用情况； 相应的，所述容灾模块，还与所述接收模块相连接，用于根据所述接收模块所接收 到的各视频管理服务器所发送的自身的资源占用情况，确定能够分担所述确定模块所确定 的故障流媒体服务器业务的至少一个容灾流媒体服务器。 优选的，所述确定模块根据所述故障告警消息确定对应的故障流媒体服务器，具 体为 所述确定模块轮询当前系统中的所有流媒体服务器，确定轮询失败的流媒体服务 器为故障流媒体服务器。 与现有技术相比，本发明具有以下优点 通过应用本发明的技术方案，在多网段部署多个MS的监控环境中，在三层环境中 流媒体服务器发生故障后，实现实况业务流量的快速恢复，并根据正常流媒体服务器资源 利用率，合理分担故障流媒体服务器工作，提高了系统的稳定性和资源利用效率。
图1为现有技术中进行监控的网络结构示意图；
图2为现有技术中进行监控的方法的流程示意图； 图3为本发明所提出的一种视频监控场景中的容灾方法的流程示意图；
图4为本发明所提出的一种监控网络的结构示意图； 图5为本发明所提出的一种具体应用场景下的视频监控场景中的容灾方法的流 程示意图； 图6为本发明所提出的一种视频监控场景中的容灾方法的信令交互流程示意图；
图7为本发明所提出的一种视频管理服务器的结构示意图。
具体实施例方式
为了解决现有技术的问题，本发明在多网段部署多个MS的监控环境中，提供一种 容灾方法，实现三层环境中单台MS故障后实况流量快速恢复，并根据正常MS设备资源利用 率，合理分担故障MS工作。 本发明所提出的一种视频监控场景中的容灾方法，应用于包括多个视频客户端、
多个视频监控设备、多个流媒体服务器和一个视频管理服务器的系统中。 如图3所示，为本发明所提出的一种视频监控场景中的容灾方法的流程示意图，
具体包括以下步骤 步骤S301、视频管理服务器接收到至少一个视频客户端发送的故障告警消息。
其中，视频管理服务器所接收到至少一个视频客户端发送的故障告警消息，具体 为 当当前系统中的视频客户端接收不到流媒体服务器发送的视频信息数据时，向视 频管理服务器发送的故障告警消息。 步骤S302、视频管理服务器确定故障告警消息所对应的故障流媒体服务器。
在具体的应用场景中，本步骤所应用的具体方式是 视频管理服务器轮询当前系统中的所有流媒体服务器，确定轮询失败的流媒体服 务器为故障流媒体服务器。 步骤S303、视频管理服务器确定能够分担故障流媒体服务器业务的至少一个容灾 流媒体服务器。 为了更加有效的实现本发明所提出的技术方案，在上述系统中还可以设置各所述 流媒体服务器按照反馈周期向视频管理服务器发送自身的资源占用情况，以便为容灾设备 的选择提供相应的依据。 其中，各所述流媒体服务器按照反馈周期向视频管理服务器发送自身的资源占用 情况，具体包括 各所述流媒体服务器在接入系统后，向所述视频管理服务器发送自身能够支持的 最大连接数量和最大出口带宽的信息； 各所述流媒体服务器按照所述反馈周期，向所述视频管理服务器发送自身当前保 持的连接数量和当前占用的出口带宽的信息。 根据前述的资源占用情况信息，本步骤的具体实现流程包括
视频管理服务器根据各流媒体服务器所发送的自身的资源占用情况，判断当前剩 余的各流媒体服务器所剩余的可连接数量和剩余出口带宽资源是否高于或等于故障流媒 体服务器最近一次所上报的保持的连接数量和占用的出口带宽资源； 如果视频管理服务器判断存在一个流媒体服务器符合要求，则确定流媒体服务器 为容灾流媒体服务器； 如果视频管理服务器判断存在多个流媒体服务器符合要求，则按照预设的选择规 则，确定其中的一个流媒体服务器为容灾流媒体服务器； 如果视频管理服务器判断没有流媒体服务器符合要求，则确定所剩余的可连接数
量和剩余出口带宽资源之和符合要求的多个流媒体服务器为容灾流媒体服务器。 步骤S304、视频管理服务器向容灾流媒体服务器发送携带故障流媒体服务器的业
务信息的通知消息，并向故障流媒体服务器所对应的各视频客户端发送业务建立消息，将
故障流媒体服务器的业务切换到容灾流媒体服务器中。 其中，视频管理服务器向容灾流媒体服务器发送携带故障流媒体服务器的业务信 息的通知消息，具体为 视频管理服务器根据故障流媒体服务器所承担的多个业务，分别通过多个通知消
息携带各业务所对应的发送端和接收端的信息，发送给视频管理服务器。 与现有技术相比，本发明具有以下优点 通过应用本发明的技术方案，在多网段部署多个MS的监控环境中，在三层环境中
流媒体服务器发生故障后，实现实况业务流量的快速恢复，并根据正常流媒体服务器资源
利用率，合理分担故障流媒体服务器工作，提高了系统的稳定性和资源利用效率。 为了进一步阐述本发明的技术思想，现结合具体的应用场景，对本发明的技术方
案进行说明。 如图4所示，为本发明所提出的一种监控网络的结构示意图，在该网络中，VC1、 VC4点播EC1的实况，VC2、VC5点播EC2的实况，所有VC都设置为通过MS接收实况流，用户 事先设置好EC与MS的对应转发关系，这里EC1、 EC2对应MS1 。 当MS 1出现故障时，根据本发明所提出的技术方案，具体的实现流程如图5所示， 包括以下流程 步骤S501、 VC无法收到实况流，向VM告警。 VC客户端增加一种告警触发机制，当突然接收不到MS转发过来的实况流时，即向 与自己建立监控关系的VM设备发出告警报文。 这里使用GMP协议，可增加一种报文类型，用于通知VM，转发实况流的MS可能出现 故障。例如，当MS1出现故障时，VC1、VC2、 VC4、VC5都会触发告警通知VM。
步骤S502、 VM收到告警后，触发MS轮询机制。 VM原本是通过保活机制确认MS是否在线，不具备即时性；这里修改为VM只要收 到VC上报的告警通知报文后立刻触发MS轮询机制，检查所管理的MS，发现MS1故障，其他 MS均正常； 这里还需要增加一种机制MS周期性上报资源利用情况，如MS支持的最大连接 数，MS支持的最大出口带宽和MS当前的连接数、MS当前为转发音视频流所占用的出口带 宽。前2个数据在MS连接上线后汇报，后2个数据每隔一定周期汇报一次。这里使用VMP协议，可增加一种报文类型，用于MS上报资源利用情况。VM服务器上也需要增加一个表项， 用于记录每个MS当前的资源利用率。 需要指出的是，上述的资源利用情况的上报机制指示本发明所提出的一种为选择 容灾设备而进行的优选设置，在能够达到相同的技术效果的前提下，人工设置资源配比，或 者按照一定优先级规则确定容灾设备选择顺序等方案也都可以作为本发明技术方案的容 灾选择依据，这样的变化并不影响本发明的保护范围。 步骤S503、 VM检查出MS1故障，根据MS1连接数的其他MS资源利用率找出替代 MS。 当VM发现MS1故障后，根据出故障的MS的最近一次的资源利用率和其他正常的 MS当前的资源利用率，选出接管故障MS的新的MS，可能是一个，也可能是二个。
步骤S504、VM根据VC与其建立的监控关系判断出需要发送给替代MS的APPLY报 文中必要的地址信息，该报文不要求MS回应。例如MS2可以接管所有的业务，VM根据与EC1、EC2、VC1、VC2、VC4、VC5的MP建立 的监控关系，判断出需要发送给MS2的2个APPLY报文中需要附带的相关信息，发送两个 APPLY报文是因为故障MS1为ECl和EC2服务，APPLY报文中所携带主要信息如下
(1) IE_RECEIVER_ADDRESS信息视频流接收端的地址信息，包括两组地址信息EC1发送端的地址和MS2接收端的 地址；另一个APPLY报文中该字段内容为EC2发送端地址和MS2接收端的地址；
(2) IE_SENDER_ADDRESS信息 视频流发送端的地址信息，包括两组地址信息MS2发送端的地址和VC1、VC4接收
端的地址；另一个APPLY报文中该字段内容为MS2发送端的地址和VC2、VC5接收端的地址。 如果MS2无法接管所有的业务，则VM选出MS2、 MS3共同分担MS1的现有业务，则
VM发送给MS2的APPLY报文包括EC1、 VC1、 VC4的信息，VM发送给MS3的APPLY报文包括
EC2、 VC2、 VC4的信息；下面仍然以MS2能够分担MS1的业务为例来讲解。 步骤S505、 VM同时给与MS1相关的EC、 VC发送SETUP报文，刷新已建好的监控关系。 需要进一步指出的是，为了加快恢复VC1、VC2、VC4、VC5的实况流，这里VM在发送 APPLY报文给MS2的时候，可以不要求等待MS2的回应报文，就开始同时给EC1、 EC2发送 SETUP报文。 也就是MS1故障时VM为发送给MS2的APPLY报文设置一个标志位，该标志位的意 义是不要求回应报文；同时该SETUP报文用于通知EC1、 EC2刷新发送实况流的目的地址为 MS2的接收端的地址。 同样，为了加快恢复业务，这里同样要求VM不必等待EC1和EC2的回应报文；在发 送SETUP报文给EC1、 EC2的同时，VM发送SETUP报文给VC1、 VC4、 VC2、 VC5，这些SETUP报 文的目的是强制要求VC1、VC4接收的EC1的实况流的源地址为MS2的发送端的地址，VC2、 VC5接收的EC2的实况流的源地址为MS3的发送端的地址，这里同样要求VM不必等待VC1 、 VC2、VC4、VC5的回应报文。 这里发送的SETUP报文可以增加一种控制字段，用于通知EC和VC设备收到后，不 必发送回应报文，并且收到后立刻刷新之前建立好的监控关系，而不是重建监控关系。
至此，MS1上所有中断的连接已迁移到MS2和MS3上。 需要进一步指出的是，上述的不要求回应报文的相关设置均是为提高处理速度， 而对本发明所提出的技术方案所进行的优选实施方案的完善，是否回应报文并不会影响本 发明的保护范围。 步骤S506、EC将实况流转发到替代MS上，替代MS将实况流转发到VC，业务恢复。
因为VM是根据VC的告警触发轮询MS设备，所以不必等待超时就能很快知道各MS 的状态；并查询相应资源利用率表项，找出接管业务的MS，并根据该故障MS所对应的EC、 VC与VM建立的监控关系，反推出需要发送的APPLY报文中所必须的地址信息，这样就不必 等待VC重新发起的GMP请求报文；而VM向MS发送的APPLY报文的同时也向相关EC和VC 发送SETUP报文，而不再是等待MS回应后才发SETUP报文给EC，也不再等待EC回应后才发 SETUP报文给VC，强制EC、 VC刷新之前建好的监控关系。这样就大大縮短了故障后实况流 恢复时间。 当VC3、 VC6需要点播EC1的实况时，VM发现此时MS1仍然故障，则选定下一个可 用MS进行替代，之后的流程按照正常流程进行处理； 当MSI恢复后，新发起的点播与MSI对应的EC1、 EC2实况流的请求，VM使用MSI 进行转发；被MS2、MS3接管的业务不必切换回来，除非用户终止业务。 相应的信令交互示意图如图6所示，具体流程与上述图5所示的流程相类似，在此 不再另行叙述。 与现有技术相比，本发明具有以下优点 通过应用本发明的技术方案，三层网络中部署多台MS设备，使用一台VM进行管理 的监控环境中，各个MS互相备份，MS部署更加灵活，可靠性更高，在单台MS出现故障时，能 快速恢复所中断的实况业务。 为了实现本发明的技术方案，本发明还提出了一种视频管理服务器，应用于包括
多个视频客户端、多个视频监控设备、多个流媒体服务器和一个视频管理服务器的系统中，
各流媒体服务器按照反馈周期向视频管理服务器发送自身的资源占用情况。 如图7所示，为本发明所提出的一种视频管理服务器的结构示意图，具体包括 接收模块71，用于接收至少一个视频客户端发送的故障告警消息； 确定模块72，与接收模块71相连接，用于确定接收模71块所接收到的故障告警消
息所对应的故障流媒体服务器； 其中，确定模块72确定故障告警消息所对应的故障流媒体服务器的方式，具体为 确定模块72轮询当前系统中的所有流媒体服务器，确定轮询失败的流媒体服务器为故障 流媒体服务器。 容灾模块73，与确定模块72相连接，用于确定能够分担确定模块72所确定的故障 流媒体服务器业务的至少一个容灾流媒体服务器； 处理模块74，与容灾模块73相连接，用于向容灾流媒体服务器发送携带故障流媒 体服务器的业务信息的通知消息，并向故障流媒体服务器所对应的各视频客户端发送业务 建立消息，将故障流媒体服务器的业务切换到容灾模块所确定的容灾流媒体服务器中。
其中，携带所述故障流媒体服务器的业务信息的通知消息，具体为所述视频管理 服务器根据所述故障流媒体服务器所承担的多个业务，分别通过多个通知消息携带各业务所对应的发送端和接收端的信息，发送给所述视频管理服务器。 需要进一步指出的是，在具体的应用场景中，接收模块71还用于接收各流媒体服 务器按照反馈周期所发送自身的资源占用情况。 其中，为了更加有效的实现本发明所提出的技术方案，在上述系统中还可以设置 各所述流媒体服务器按照反馈周期向视频管理服务器发送自身的资源占用情况，并通过接 收模块71进行接收，以便为容灾设备的选择提供相应的依据。 其中，接收模块71接收到的各所述流媒体服务器按照反馈周期向视频管理服务 器发送自身的资源占用情况，具体包括 各所述流媒体服务器在接入系统后，向所述视频管理服务器发送自身能够支持的 最大连接数量和最大出口带宽的信息； 各所述流媒体服务器按照所述反馈周期，向所述视频管理服务器发送自身当前保 持的连接数量和当前占用的出口带宽的信息。 相应的，容灾模块73还与所述接收模块71相连接，用于根据所述接收模块71所 接收到的各视频管理服务器所发送的自身的资源占用情况，从而，确定能够分担所述确定 模块所确定的故障流媒体服务器业务的至少一个容灾流媒体服务器。 需要指出的是，上述的资源占用情况的上报机制指示本发明所提出的一种为选择 容灾设备而进行的优选设置，在能够达到相同的技术效果的前提下，人工设置资源配比，或 者按照一定优先级规则确定容灾设备选择顺序等方案也都可以作为本发明技术方案的容 灾选择依据，这样的变化并不影响本发明的保护范围。
与现有技术相比，本发明具有以下优点 通过应用本发明的技术方案，在多网段部署多个MS的监控环境中，在三层环境中
流媒体服务器发生故障后，实现实况业务流量的快速恢复，并根据正常流媒体服务器资源
利用率，合理分担故障流媒体服务器工作，提高了系统的稳定性和资源利用效率。 通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到本发明可以通
过硬件实现，也可以借助软件加必要的通用硬件平台的方式来实现。基于这样的理解，本发
明的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储
介质(可以是CD-R0M， U盘，移动硬盘等)中，包括若干指令用以使得一台计算机设备(可
以是个人计算机，服务器，或者网络设备等)执行本发明各个实施场景所述的方法。 本领域技术人员可以理解附图只是一个优选实施场景的示意图，附图中的模块或
流程并不一定是实施本发明所必须的。 本领域技术人员可以理解实施场景中的装置中的模块可以按照实施场景描述进 行分布于实施场景的装置中，也可以进行相应变化位于不同于本实施场景的至少一个装置 中。上述实施场景的模块可以合并为一个模块，也可以进一步拆分成多个子模块。
上述本发明序号仅仅为了描述，不代表实施场景的优劣。 以上公开的仅为本发明的几个具体实施场景，但是，本发明并非局限于此，任何本 领域的技术人员能思之的变化都应落入本发明的保护范围。
权利要求
一种视频监控场景中的容灾方法，其特征在于，应用于包括视频客户端、视频监控设备、流媒体服务器和视频管理服务器的系统中，所述方法包括所述视频管理服务器接收到至少一个视频客户端发送的故障告警消息，并根据所述故障告警消息确定对应的故障流媒体服务器；所述视频管理服务器确定能够分担所述故障流媒体服务器业务的至少一个容灾流媒体服务器；所述视频管理服务器向所述容灾流媒体服务器发送携带所述故障流媒体服务器的业务信息的通知消息，并向所述故障流媒体服务器所对应的各视频客户端发送业务建立消息，将所述故障流媒体服务器的业务切换到所述容灾流媒体服务器中。
2. 如权利要求1所述的方法，其特征在于，所述视频管理服务器接收到至少一个视频 客户端发送的故障告警消息之前，还包括所述流媒体服务器按照反馈周期向视频管理服务器发送自身的资源占用情况； 相应的，所述视频管理服务器根据各视频管理服务器所发送的自身的资源占用情况， 确定能够分担所述故障流媒体服务器业务的至少一个容灾流媒体服务器。
3. 如权利要求1所述的方法，其特征在于，各所述流媒体服务器按照反馈周期向视频 管理服务器发送自身的资源占用情况，具体包括各所述流媒体服务器在接入系统后，向所述视频管理服务器发送自身能够支持的最大 连接数量和最大出口带宽的信息；各所述流媒体服务器按照所述反馈周期，向所述视频管理服务器发送自身当前保持的 连接数量和当前占用的出口带宽的信息。
4. 如权利要求3所述的方法，其特征在于，所述视频管理服务器根据各视频管理服务 器所发送的自身的资源占用情况，确定能够分担所述故障流媒体服务器业务的至少一个容 灾流媒体服务器，具体为所述视频管理服务器根据各流媒体服务器所发送的自身的资源占用情况，判断当前剩 余的各流媒体服务器所剩余的可连接数量和剩余出口带宽资源是否高于或等于所述故障 流媒体服务器最近一次所上报的保持的连接数量和占用的出口带宽资源；如果所述视频管理服务器判断存在一个流媒体服务器符合要求，则确定所述流媒体服 务器为容灾流媒体服务器；如果所述视频管理服务器判断存在多个流媒体服务器符合要求，则按照预设的选择规 则，确定其中的一个流媒体服务器为容灾流媒体服务器；如果所述视频管理服务器判断没有流媒体服务器符合要求，则确定所剩余的可连接数 量和剩余出口带宽资源之和符合要求的多个流媒体服务器为容灾流媒体服务器。
5. 如权利要求1所述的方法，其特征在于，所述视频管理服务器所接收到至少一个视 频客户端发送的故障告警消息，具体为当当前系统中的视频客户端接收不到流媒体服务器发送的视频信息数据时，向所述视 频管理服务器发送的故障告警消息。
6. 如权利要求1所述的方法，其特征在于，所述视频管理服务器确定所述故障告警消 息所对应的故障流媒体服务器，具体为所述视频管理服务器轮询当前系统中的所有流媒体服务器，确定轮询失败的流媒体服务器为故障流媒体服务器。
7. 如权利要求1所述的方法，其特征在于，所述视频管理服务器向所述容灾流媒体服 务器发送携带所述故障流媒体服务器的业务信息的通知消息，具体为所述视频管理服务器根据所述故障流媒体服务器所承担的多个业务，分别通过多个通 知消息携带各业务所对应的发送端和接收端的信息，发送给所述视频管理服务器。
8. —种视频管理服务器，其特征在于，应用于包括多个视频客户端、多个视频监控设 备、多个流媒体服务器和一个视频管理服务器的系统中，包括接收模块，用于接收至少一个视频客户端发送的故障告警消息；确定模块，与所述接收模块相连接，用于根据所述接收模块所接收到的故障告警消息 确定对应的故障流媒体服务器；容灾模块，与所述确定模块相连接，用于确定能够分担所述确定模块所确定的故障流 媒体服务器业务的至少一个容灾流媒体服务器；处理模块，与所述容灾模块相连接，用于向所述容灾流媒体服务器发送携带所述故障 流媒体服务器的业务信息的通知消息，并向所述故障流媒体服务器所对应的各视频客户端 发送业务建立消息，将所述故障流媒体服务器的业务切换到所述容灾模块所确定的容灾流 媒体服务器中。
9. 如权利要求8所述的视频管理服务器，其特征在于，所述接收模块，还用于接收各所 述流媒体服务器按照反馈周期所发送自身的资源占用情况；相应的，所述容灾模块，还与所述接收模块相连接，用于根据所述接收模块所接收到的 各视频管理服务器所发送的自身的资源占用情况，确定能够分担所述确定模块所确定的故 障流媒体服务器业务的至少一个容灾流媒体服务器。
10. 如权利要求8所述的视频管理服务器，其特征在于，所述确定模块根据所述故障告 警消息确定对应的故障流媒体服务器，具体为所述确定模块轮询当前系统中的所有 媒体服务器，确定轮询失败的流媒体服务器为 故障流媒体服务器。
全文摘要
本发明公开了一种视频监控场景中的容灾方法和设备，在多网段部署多个MS的监控环境中，在三层环境中流媒体服务器发生故障后，实现实况业务流量的快速恢复，并根据正常流媒体服务器资源利用率，合理分担故障流媒体服务器工作，提高了系统的稳定性和资源利用效率。
文档编号H04N7/24GK101720035SQ20091025025
公开日2010年6月2日 申请日期2009年12月11日 优先权日2009年12月11日
发明者林鹏程, 顾雷雷 申请人:杭州华三通信技术有限公司