CN104503861A - 一种异常处理方法及系统、代理设备与控制装置 - Google Patents

Abstract

本发明实施例提供一种异常处理方法及系统、代理设备与控制装置。其方法包括：物理机的代理设备监控被监控对象是否发生异常；所述被监控对象为运行在物理机上的虚拟机、或者运行在物理机上的虚拟机中的应用或者应用组；当所述被监控对象发生异常时，物理机的代理设备向控制装置发送所述被监控对象的异常消息，以便所述控制装置将自身存储的所述被监控对象的状态信息更新为异常状态信息；接收所述控制装置发送的配置策略消息，所述配置策略消息由所述控制装置根据所述被监控对象的状态信息进行配置；根据所述配置策略消息进行异常处理。采用本发明实施例的异常处理方案在实现虚拟机的HA过程中，灵活性较高。

Description

一种异常处理方法及系统、代理设备与控制装置

本申请是于2012年04月20日提交中国专利局、申请号为201210118536.4、发明名称为“一种异常处理方法及系统、代理设备与控制装置”的中国专利申请的分案申请。

技术领域

本发明实施例涉及信息技术(Information Technology，简称：IT)领域，尤其涉及一种异常处理方法及系统、代理设备与控制装置。

背景技术

虚拟化技术实现对系统的虚拟化，虚拟化技术通过在物理机上添加虚拟机监控程序(Virtual Machine Monitor，简称VMM)实现。VMM又被称为监管程序(Hypervisor)。从应用程序的角度看，VMM运行在虚拟机上的物理机(即实体计算机)上。虚拟化技术能够使得在一台物理机上生成至少一个不同的虚拟机，各虚拟机分别运行至少一个不同或相同的操作系统。虚拟化技术通过将不同的应用运行在不同的虚拟机上，可以避免不同应用之间的互相干扰，例如，在一个应用的崩溃时，不会影响其它应用。

现有技术中，分别设置在两个物理机(主设备侧的物理机和备设备侧的物理机)中的虚拟机互为主备虚拟机，主设备侧的物理机中的虚拟机称为主虚拟机，备设备侧的物理机中的虚拟机称为备虚拟机。主虚拟机由主设备侧的物理机中的VMM来监控，备虚拟机由备设备侧的物理机中的VMM来监控。具体地，在主设备侧的物理机中的VMM和备设备侧的物理机中的VMM中均设置有代理(Agent)来监控各自所在物理机上的主虚拟机或者备虚拟机。两个VMM的代理通过心跳互相感知，若主设备侧的物理机中VMM上的代理监控到该主设备侧的物理机上的主虚拟机发生异常时，通过心跳消息通知备设备侧的物理机的VMM上的代理，以拉起备设备侧物理机上的备虚拟机，使得备设备侧的物理机上的备虚拟机代替主设备侧的物理机上的主虚拟机开始运行，以实现对虚拟机的进行异常处理，从而保证虚拟机的正常运行，实现虚拟机的高可用性(High Availability；HA)。

发明人在实现本发明的过程中，发现现有技术中至少存在如下缺点：

现有技术的技术方案仅能对虚拟机的异常进行处理，而无法对虚拟机中的应用或者应用组发生异常，或者虚拟机所在的物理机的发生异常进行处理，因此现有技术的异常处理方案的灵活性较差。

发明内容

本发明实施例提供一种异常处理方法及系统、代理设备与控制装置，用于解决现有技术中异常处理方案的灵活性较差的缺陷，以便提高异常处理的灵活性。

一方面，本发明实施例提供一种异常处理方法，包括：

物理机的代理设备监控被监控对象是否发生异常；所述被监控对象为运行在所述物理机上的虚拟机、或者运行在所述物理机上的虚拟机中的应用或应用组；

当所述被监控对象发生异常时，所述物理机的代理设备向控制装置发送所述被监控对象的异常消息，以便所述控制装置将自身存储的所述被监控对象的状态信息更新为异常状态信息；

所述物理机的代理设备接收所述控制装置发送的配置策略消息，所述配置策略消息由所述控制装置根据所述被监控对象的状态信息进行配置；

所述物理机的代理设备根据所述配置策略消息进行异常处理。

另一方面，本发明实施例还提供一种异常处理方法，包括：

控制装置监控物理机是否发生异常，其中，所述物理机上运行至少一个虚拟机，所述至少一个虚拟机中每一个虚拟机上运行至少一个应用；

当所述物理机发生异常时，所述控制装置将自身存储的所述物理机上每一个虚拟机的状态信息、以及所述每一个虚拟机中每一个应用的状态信息更新为异常状态信息；

所述控制装置根据预设的配置策略消息进行异常处理。

再一方面，本发明实施例提供一种代理设备，包括：

监控模块，用于监控被监控对象是否发生异常；所述被监控对象为运行在所述物理机上的虚拟机、或者运行在所述物理机上的虚拟机中的应用或应用组；

发送模块，用于当所述被监控对象发生异常时，向控制装置发送所述被监控对象的异常消息，以便所述控制装置将自身存储的所述被监控对象的状态信息更新为异常状态信息；

接收模块，用于接收所述控制装置发送的配置策略消息，所述配置策略消息由所述控制装置根据所述被监控对象的状态信息进行配置；

异常处理模块，用于根据所述配置策略消息进行异常处理。

又一方面，本发明实施例还提供一种控制装置，包括：

监控模块，用于监控物理机是否发生异常，其中，所述物理机上运行至少一个虚拟机，所述至少一个虚拟机中每一个虚拟机上运行至少一个应用；

更新模块，用于当所述物理机异常时，将自身存储的所述物理机上每一个虚拟机的状态信息、以及所述每一个所述虚拟机中每一个应用的状态信息更新为异常状态信息；

异常处理模块，用于根据预设的配置策略消息进行异常处理。

再另一方面，本发明实施例还提供一种异常处理系统，包括主设备侧物理机、备设备侧物理机和控制装置，其中，

所述主设备侧物理机和所述备设备侧物理机互为主备机；所述主设备侧物理机和所述备设备侧物理机上分别设置有虚拟机监控装置，所述主设备侧物理机和所述备设备侧物理机上运行有至少一个虚拟机，且所述至少一个虚拟机中每个虚拟机上运行有至少一个应用或应用组；且每个所述虚拟机监控装置中设置有如上所述的代理设备；控制装置分别与所述主设备侧物理机和所述备设备侧物理机上的代理设备相通信，且所述两个代理设备互相通信。

再又一方面，本发明实施例还提供一种异常处理系统，包括主设备侧物理机、备设备侧物理机和控制装置，所述主设备侧物理机和所述备设备侧物理机互为主备机；所述控制装置采用如上所述的控制装置，所述主设备侧物理机和所述备设备侧物理机分别与所述控制装置相通信

本发明实施例的异常处理方法及系统、代理设备与控制装置，通过采用上述技术方案，能够克服现有技术中仅能对虚拟机的异常进行处理，而无法对虚拟机中的应用或者应用组的异常进行处理的缺陷，或者无法对虚拟机所在的物理机的异常进行处理的缺陷，采用本发明实施例的技术方案，不仅可以对虚拟机的异常进行处理，还能够对虚拟机中的应用或者应用组，或者虚拟机所在的物理机的异常进行处理，因此，本发明实施例的异常处理方案在实现虚拟机的HA过程中，灵活性较高。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作一简单地介绍，显而易见地，下面描述中的附图是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1为本发明实施例提供的一种异常处理系统的架构图。

图2为本发明一实施例提供的异常处理方法的流程图。

图3为本发明另一实施例的异常处理方法的流程图。

图4为本发明一实施例提供的异常处理方法的信令图。

图5为本发明另一实施例提供的异常处理方法的信令图。

图6为本发明又一实施例提供的异常处理方法的信令图。

图7为本发明再一实施例提供的异常处理方法的信令图。

图8为本发明实施例提供的代理设备的结构示意图。

图9为本发明实施例提供的控制装置的结构示意图。

图10为本发明一实施例提供的异常处理系统的结构示意图。

图11为本发明另一实施例提供的异常处理系统的结构示意图。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

图1为本发明实施例提供的一种异常处理系统的架构图。如图1所示，本实施例中的HA Controller具体可以为本发明实施例中的控制装置，HAAgent具体可以为本发明实施例中的代理设备。其中物理机A为主设备侧的物理机，物理机B为备设备侧的物理机。VMM A为主设备侧的虚拟机监控器(或虚拟机监控装置)，VMM B为备设备侧的虚拟机监控器。在VMM A上设置的HA Agent为主设备侧的代理设备，在VMM B上设置的HA Agent为备设备侧的代理设备。如图1所示，物理机A和物理机B上的HA Agent均可以与控制装置HA Controller通信，图1中的Guest OS为客户端操作系统(Operating system，简称：OS)。VM(主机)为设置在主设备侧的物理机A上的一个虚拟机，VM(备机)为设置在备设备侧的物理机B上的一个虚拟机。VM(主机)和VM(备机)互为主备的虚拟机。

如图1所示，其中Vif0为虚拟机的虚拟网卡，作为应用心跳网卡。该网卡和实际的物理网卡并不互通，它只和VMM的Br0互通。Vif1为虚拟机的虚拟网卡，作为应用消息接收网卡，该网卡和实际的物理网卡并不互通，它只和VMM的Br1互通。Vifn为应用的业务网卡，应用通过该类型网卡进行应用数据发送、消息处理。这类型网卡和实际的物理网卡是互通的。

Br0为VMM上的网桥bridge，它仅和Vif0连通，它并没有绑定物理网卡，因此，Br0和Vif0的广播信息不会影响其他网络。Br1为VMM上的网桥bridge，它仅和Vif1连通，它并没有绑定物理网卡，同样，Br1和Vif1的广播信息不会影响其他网络。Brn为VMM上的网桥bridge，它和Vifn连通，它绑定物理网卡，因此可以和其他虚拟机上的业务通信。

MSend为心跳信息发送模块，虚拟机中的应用通过它发送心跳信息。MRev为消息接收模块，应用通过它接收HA Agent的控制信息，来实现对业务的启动，停止等操作。本实施例中的应用1、应用n为跑在虚拟机上的具体业务，比如企业信息管理系统、网上购书系统等，它通过本方案提供的HA框架实现自身业务的HA切换。应用通过MSend发送心跳信息，来声明它是“可用”的。

VM(主机)为应用所在的主机，在发生异常前承担应用的运行环境。VM(备机)：应用所在的备机，在VM(主机)发生异常时，接管VM(主机)的应用。VMM A为VM(主机)所在的Hypervisor。VMM B为VM(备机)所在的Hypervisor。物理机A为主机侧的实际的物理机，物理机B为备机侧的实际的物理机。交换机为实际的交换机设备。

其中需要说明的是，本实施例中的Vifn、Brn仅作示例性说明，以说明Vifn、Brn和Vif0，Vif1，Br0，Br1的差异：Vifn、Brn是和外部网络互通的，而Vif0，Vif1，Br0，Br1仅仅是VMM内部的私有虚拟网络。

本实施例中，HA Controller具体为一个控制装置，起到策略控制中心的作用，控制每种应用或者应用组或者虚拟机或者物理机发生异常后的HA行为，通过向HA Agent发送控制消息，实现了应用的主备切换。主设备侧的HA Agent会时时监视应用状态，一旦发现应用状态异常后，会通知HAController，HA Controller记录了所管理应用的状态信息，这样用户或者其他系统可以通过HA Controller查询各应用的状态信息。HA Controller记录了应用的如下信息：应用ID、所在主机ID、所在应用组ID、应用状态(正常、异常、未知等)、时间等信息。

其中HA Agent接收HA Controller的调度，通过br0监控虚拟机虚拟网卡的网络流量，通过Br1向虚拟机发送消息。HA Agent可以同时监听多个VM里面的多个应用的心跳信息。

其中，需要说明的是，虚拟机监控器可以采用硬件或软件的方式实现；在采用硬件的方式实现虚拟机监控器时，虚拟机监控器中的代理设备可以采用硬件或软件的方式实现。

基于图1所示的系统架构图，本发明实施例提供一种异常处理方法，如图2所示。本实施例的异常处理方法的执行主体为物理机的代理设备，具体地，该物理机的代理设备位于物理机中的虚拟机监控器中。本实施例的异常处理方法，具体可以包括如下步骤：

100、物理机的代理设备监控被监控对象是否发生异常；

其中，本实施例中的被监控对象为运行在物理机上的虚拟机、或者运行在物理机上的虚拟机中的应用或应用组；

其中，需要说明的是，本实施例中的应用组可以由一组能够相互影响的应用构成，如果该应用组中一个应用出现异常，该应用组中的其他应用会受到影响，此时认为该应用组出现异常；

101、当被监控对象发生异常时，物理机的代理设备向控制装置发送被监控对象的异常消息，以便控制装置将自身存储的被监控对象的状态信息更新为异常状态信息；

其中，需要说明的是，当监控对象正常时，代理设备不执行任何操作，继续监控即可；

102、物理机的代理设备接收控制装置发送的配置策略消息，该配置策略消息由控制装置根据被监控对象的状态信息进行配置；

103、物理机的代理设备根据配置策略消息进行异常处理。

本实施例的异常处理方法可以用于监控主设备侧的虚拟机、还可以用于监控主设备侧的虚拟机中的应用或应用组是否发生异常，并在发生异常时进行异常处理，以实现虚拟机的HA。因此本实施例中的代理设备具体可以为上述图1所示的架构图中的HA Agent。此时对应地本实施例的控制装置具体可以为上述图1所示架构图中的HA Controller。

本实施例的异常处理方法，通过采用采用上述技术方案，能够克服现有技术中仅能对虚拟机的异常进行处理，而无法对虚拟机中的应用或者应用组，进行异常处理的缺陷，采用本实施例的技术方案，不仅可以对虚拟机的异常进行处理，还能够对虚拟机中的应用或者应用组的进行异常处理，因此，本实施例的异常处理方案在实现应用、应用组或者虚拟机的HA过程中，灵活性较高。

可选地，在上述图2所示实施例的基础上，还可以包括如下可选技术方案，形成上述图2所示实施例的扩展实施例。

在图2所示实施例的扩展实施例中，上述图2所示实施例中的物理机为主设备侧的物理机，物理机的代理设备为主设备侧的代理设备；此时在图2所示实施例的扩展实施例中，102中物理机的代理设备接收到的配置策略消息用于指示代理设备重启被监控对象，当重启的次数达到预设阈值，被监控对象仍然异常时，则通知备设备侧拉起被监控对象。或者，102中物理机的代理设备接收到的配置策略消息用于指示代理设备进行通知备设备侧拉起被监控对象，此时，可以不在主设备侧重启该被监控对象，而直接在备设备侧拉起该被监控对象。

进一步可选地，在配置策略消息指示重启被监控对象时，当重启的次数达到预设阈值，被监控对象仍然异常时，主设备侧的代理设备通知备设备侧拉起被监控对象，此时对应的步骤103“物理机的代理设备根据配置策略消息进行异常处理”，具体可以包括如下步骤：

(1)主设备侧的代理设备根据配置策略消息，重启被监控对象；并更新重启次数；

例如，当第一次重启被监控对象时，重启次数设为1，以后每次重启一次被监控对象，重启次数加1；

(2)主设备侧的代理设备判断被监控对象是否恢复正常；若代理设备判断被监控对象恢复正常，执行步骤(3)；否则，执行步骤(4)；

(3)主设备侧的代理设备向控制装置发送被监控对象重启成功的消息，以便控制装置将该控制装置中存储的被监控对象的状态信息更改为正常状态信息，结束；

(4)主设备侧的代理设备判断重启次数是否达到预设阈值；若重启次数未达到预设阈值时，执行步骤(1)；否则，确定重启截止，执行步骤(5)；

例如，若预设阈值为3，第二次重启后被监控对象仍然异常，则继续执行步骤(1)；

(5)主设备侧的代理设备向备设备侧的代理设备发送拉起被监控对象的消息。

当该配置策略消息用于指示通知备设备侧拉起被监控对象，此时对应的步骤103“代理设备根据配置策略消息进行异常处理”仅包括上述步骤(5)。

其中，需要说明的是，术语“拉起被监控对象”具体是指在备设备侧运行被监控对象，运行在主设备侧的被监控对象发生异常时，可以通过通知被设备侧运行被监控对象来为用户提供不间断的服务。

本实施例的主设备侧的代理设备，若与备设备侧的代理设备无法通信时，主设备侧的代理设备可以通过控制装置向备设备侧的代理设备发送拉起被监控对象的消息；例如代理设备向控制装置发送让备设备侧的代理设备拉起被监控对象的消息，控制装置接收该让备设备侧的代理设备拉起被监控对象的消息，并向备设备侧的代理设备发送拉起被监控对象的消息，这样，备设备侧的代理设备接收到该消息之后，拉起被监控对象，如拉起虚拟机、或者拉起虚拟机中的应用或者应用组。

可选地，在图2所示实施例的扩展实施例中，当被监控对象为运行在物理机上的虚拟机中的应用时，步骤100中的“物理机的代理设备监控被监控对象是否发生异常”，具体可以包括：若物理机的代理设备在预设时间段内未接收到虚拟机中的应用广播的心跳消息，则物理机的代理设备确定虚拟机中的应用发生异常，否则，物理机的代理设备确定虚拟机中的应用正常。

可选地，在图2所示实施例的扩展实施例中，若被监控对象为运行在物理机上的虚拟机中的应用组时，步骤100中的“物理机的代理设备监控被监控对象是否发生异常”，具体可以包括：若物理机的代理设备在预设时间段内未接收到所述应用组中的任意一个应用广播的心跳消息，则物理机的代理设备确定虚拟机中的应用组异常，否则，物理机的代理设备确定虚拟机中的应用组正常。

可选地，在图2所示实施例的扩展实施例中，若被监控对象为运行在物理机上的虚拟机时，步骤100中的“物理机的代理设备监控被监控对象是否异常”，具体可以包括：若物理机的代理设备在预设时间段内未接收到虚拟机中的所有应用广播的心跳消息，则物理机的代理设备确定虚拟机发生异常，否则确定虚拟机正常；或者物理机的代理设备通过信令监测确定虚拟机的状态是否发生异常。

例如图1所示的异常处理系统架构图中，在物理机A一侧为主设备侧，在主设备侧，代理设备(HA Agent)接收应用(如应用1)广播的心跳消息，在具体实现时，可以在每个虚拟机中设置有心跳消息发送模块(也可以称为Msend模块)、虚拟机的虚拟网卡Vif0。对应地在VMM上设置有网桥Br0，网桥Br0仅和虚拟机的虚拟网卡Vif0连通，它并没有绑定物理网卡，因此，网桥Br0和虚拟机的虚拟网卡Vif0的广播信息不占用任何物理网络资源，从而能够有效地节约网络资源。

应用可以通过该心跳消息发送模块(如Msend模块)发送心跳消息，虚拟机的虚拟网卡vif0作为应用心跳网卡，再把心跳消息转给VMM中的网桥Br0，最终该消息由VMM中的代理设备监听并接收到。而且应用每过一定的时间间隔就会广播心跳消息，在不考虑从心跳消息发送模块到VMM中的代理设备之间的链路故障的情况下，若应用正常，代理设备就会监听并接收到该应用的心跳消息。若应用发生异常，代理设备就接收不到该应用的心跳消息。若在预设的时间长度内，代理设备检测不到该应用的心跳消息，则确定该应用发生异常。

其中需要说明的是，本实施例的心跳消息中可以包括该消息ID，应用ID、应用名称、应用状态，以及该应用所属虚拟机所在的物理机的IP。

上述实施例的异常处理方法，通过采用采用上述技术方案，能够克服现有技术中仅能对虚拟机的异常进行处理，而无法对虚拟机中的应用或者应用组进行异常处理的缺陷，采用本实施例的技术方案，不仅可以对虚拟机的异常进行处理，还能够对虚拟机中的应用或者应用组的异常进行处理，因此，本实施例的异常处理方案在实现虚拟机的HA过程中，灵活性较高；其次，主设备侧的代理设备监控到异常时，根据配置策略消息向备设备侧的代理设备发送拉起所述被监控对象的消息，使得在主设备侧发生异常时，能够及时地启用备设备侧的被监控对象，从而可以为用户提供连续的服务；另外，主设备侧的代理设备监控到有异常发生时，主设备侧的代理设备重启被监控对象，若重启后恢复正常，则无需向备设备侧发送拉起被监控对象的消息，从而节约了通信开销；再次，主设备侧的代理设备监控到有异常发生时，主设备侧的代理设备重启被监控对象，若重启次数达到预设阈值，且被监控对象仍然异常，则向备设备侧的代理设备发送拉起重启被监控对象，从而能够提供连续的服务，保证能够向用户提供不间断的服务；上述实施例中，通过采用上述技术方案对应用、或者应用组或者虚拟机进行的监控，能够有效地保证对异常的监控的效率，从而能够在应用、或者应用组或者虚拟机发生异常时，对异常进行及时处理，从而保证了应用、或者应用组或者虚拟机的HA。

图3为本发明另一实施例的异常处理方法的流程图。如图3所示，本实施例的异常处理方法的执行主体为控制装置。本实施例的异常处理方法，具体可以包括如下步骤：

200、控制装置监控物理机是否发生异常；

其中，本实施例中物理机上运行至少一个虚拟机，至少一个虚拟机中每一个虚拟机上运行至少一个应用；

201、当物理机发生异常时，控制装置将自身存储的物理机上的每一个虚拟机的状态信息、以及每一个虚拟机中每一个应用的状态信息更新为异常状态信息；

202、控制装置根据预设的配置策略消息进行异常处理。

本实施例的异常处理方法用于监控物理机是否发生异常，并在发生异常时进行异常处理，实现虚拟机的HA。本实施例的控制装置具体可以为图1所示的架构图中的HA Controller。

本实施例的异常处理方法，通过采用采用上述技术方案，能够克服现有技术中而无法对虚拟机所在的物理机的异常进行处理的缺陷，采用本实施例的技术方案，不能够对虚拟机所在的物理机的异常进行处理，因此，本实施例的异常处理方案在实现虚拟机的HA过程中，灵活性较高。

可选地，在上述图3所示实施例的基础上，还可以包括如下可选技术方案，形成上述图3所示实施例的扩展实施例。

可选地，在图3所示实施例的扩展实施例中，当物理机具体为主设备侧的物理机时，步骤202中的控制装置中预设的配置策略消息具体用于指示重启主设备侧的物理机，当主设备侧的物理机重启的次数达到预设阈值，且主设备侧的物理机仍然异常时，通知备设备侧拉起主设备侧的物理机上运行的至少一个虚拟机中的每一个虚拟机，以及至少一个虚拟机中的每一个虚拟机上运行的至少一个应用中的每一个应用；或者该预设的配置策略消息具体可以用于指示通知备设备侧拉起主设备侧的物理机上运行的至少一个虚拟机中的每一个虚拟机，以及至少一个虚拟机中的每一个虚拟机上运行的至少一个应用中的每一个应用，以使得备设备侧的虚拟机或者虚拟机中的应用代替主设备侧的虚拟机运行或者虚拟机中的应用运行，以保证为用户提供不间断的服务，从而实现HA。此时，不在主设备侧重启该主设备侧的物理机上运行的至少一个虚拟机中的每一个虚拟机，以及至少一个虚拟机中的每一个虚拟机上运行的至少一个应用中的每一个应用，而直接由备设备侧拉起主设备侧的物理机上运行的至少一个虚拟机中的每一个虚拟机，以及至少一个虚拟机中的每一个虚拟机上运行的至少一个应用中的每一个应用。

进一步可选地，当预设的配置策略消息用于指示重启主设备侧的物理机，当主设备侧的物理机重启的次数达到预设阈值，主设备侧的物理机仍然异常时，控制装置通知备设备侧拉起主设备侧的物理机上运行的至少一个虚拟机中的每一个虚拟机，以及至少一个虚拟机中的每一个虚拟机上运行的至少一个应用中的每一个应用，此时对应的步骤202中“控制装置根据预设的配置策略消息进行异常处理”，具体可以包括如下步骤：

(a)控制装置根据配置策略消息，重启主设备侧的物理机；并更新重启次数；

例如，当第一次重启被监控对象时，重启次数设为1，以后每次重启一次被监控对象，重启次数加1；

(b)控制装置判断主设备侧的物理机是否恢复正常；当主设备侧的物理机恢复正常，执行步骤(c)，否则，执行步骤(d)；

(c)控制装置将存储的主设备侧的物理机上的至少一个虚拟机中每一个虚拟机的状态信息、以及至少一个虚拟机中每一个虚拟机上的至少一个应用每一个应用的状态信息更新为正常状态信息；结束；

(d)控制装置判断重启次数是否达到预设阈值；当重启次数未达到预设阈值时，执行步骤(a)；否则，确定重启截止，执行步骤(e)；

例如，若预设阈值为3，第二次重启后被监控对象仍然异常，则继续执行步骤(a)；

(e)控制装置对主设备侧的物理机进行下电处理；执行步骤(f)；

(f)控制装置向备设备侧的物理机发送拉起主设备侧的物理机上运行的至少一个虚拟机中每一个虚拟机，以及至少一个虚拟机中每一个虚拟机上运行的至少一个应用中的每一个应用；可选地，还可以进一步执行步骤(g)；

(g)当备设备侧的物理机成功拉起主设备侧的物理机上运行的至少一个虚拟机中每一个虚拟机，以及至少一个虚拟机中每一个虚拟机上运行的至少一个应用中的每一个应用之后，控制装置将存储的主设备侧的物理机上的至少一个虚拟机中每一个虚拟机的状态信息、以及至少一个虚拟机中每一个虚拟机上的至少一个应用中的每一个应用的状态信息更新为正常状态信息。

进一步可选地，当预设的配置策略消息用于指示通知备设备侧拉起主设备侧的物理机上运行的至少一个虚拟机中每一个虚拟机，以及至少一个虚拟机中每一个虚拟机上运行的至少一个应用中的每一个应用，此时对应的步骤202中“控制装置根据预设的配置策略消息进行异常处理”可以包括上述步骤(e)和步骤(f)，进一步地还可以包括上述步骤(g)。

可选地，在图3所示实施例的扩展实施例中，步骤200“控制装置监控物理机是否发生异常”，具体可以包括：若控制装置在在预设时间段内未接收到主设备侧的物理机上的代理设备广播的心跳消息时，则确定主设备侧的物理机发生异常，否则确定主设备侧的物理机正常。其中主设备侧的物理机上的代理设备设置在主设备侧的物理机的虚拟机监控器中。

通过采用上述异常处理方法，能够对虚拟机所在的物理机的异常进行处理，实现了虚拟机所在物理机的HA。

上述实施例的异常处理方法，通过采用采用上述技术方案，能够对虚拟机所在的物理机的异常进行处理，克服了现有技术不能对虚拟机所在的物理机的异常进行处理的缺陷；另外，当控制装置监控到主设备的物理机发生异常时，根据配置策略消息对主设备侧的物理机进行下电处理，并向备设备的物理机发送拉起被监控对象的消息，使得在主设备侧的物理机发生异常时，能够及时地启用备设备侧的物理机，从而可以为用户提供连续的服务；另外，当控制装置监控到主设备的物理机发生异常时，控制设备重启被监控对象，若重启后恢复正常，则无需向备设备侧发送拉起被监控对象的消息，从而节约了通信开销；再次，当控制装置监控到主设备的物理机发生异常时，控制设备重启被监控对象，若重启次数达到预设阈值，且被监控对象仍然异常，则向备设备侧的代理设备发送拉起重启被监控对象，从而能够提供连续的服务，保证能够向用户提供不间断的服务；上述实施例中，通过采用上述技术方案对虚拟机所在物理机进行的监控，能够有效地保证对异常的监控的效率，从而能够在虚拟机所在物理机发生异常时，对异常进行及时处理，从而保证了虚拟机所在物理机的HA。

上述实施例的异常处理方法均可以在上述图1所示实施例中的异常处理系统架构中来实现。下面以结合上述图1所示实施例的异常处理系统架构，详细介绍上述图2和图3所示实施例的异常处理的技术方案。

图4是本发明一实施例提供的异常处理方法的信令图。如图4所示，基于上述图1所示实施例的异常处理系统架构，以监控虚拟机中的一个应用为例详细介绍本发明的技术方案。本实施例的异常处理方法，具体可以包括如下步骤：

300、VMM A侧的HA Agent监控VM(主机)中运行的应用1是否有异常；

本实施例中的VMM A侧的HA Agent为主设备侧的代理设备；VM(主机)为运行在VMM A所在的物理机A上的VM。

具体地，VM(主机)上的应用启动后，通过MSend向Vif0广播心跳信息；本实施例中的心跳消息中包含的主要信息有：消息ID，应用ID，应用名称，应用状态，主机IP等信息。由于VM上会多个应用，如果这多个应用都需要监控的，每个应用都需要发送心跳信息。

VM(主机)的应用通过MSend发送到VM(主机)的虚拟网卡Vif0，Vif0再把消息转到Br0，最终消息由VMM A上的HA Agent接收处理。其中Br0相当于一台的虚拟交换机，虚拟网卡Vif0连接到虚拟交换机Br0上。

VMM A上的HA Agent时时监听虚拟交换机Br0的心跳信息，一旦有心跳消息过来，马上接收该心跳消息。其中如果某个应用是可用的，它就会持续发送心跳信息，否则就不发送。因为一个HA Agent需要同时监控多个应用的状态，因此，HA Agent接收到心跳消息后，首先需要判断该心跳是哪个应用的心跳，以此来决定该应用的状态是否正常。举例来说，如果可以持续接收到某个应用A的心跳，则认为这个应用A是正常的。如果持续一段时间后，无法接收到该应用A的心跳信息，则认为该应用A发生异常。HA Agent通过持续的监听多个应用的心跳信息，HA Agent可以实现对多个应用的状态监控。

VM(主机)上应用定时通过MSend向Vif0广播心跳信息，如果业务故障，将会终止心跳信息广播。一旦应用终止心跳消息广播，HA Agent就会无法接收到该应用的心跳信息，如果持续一段时间后，HA Agent仍然无法接收该应用的心跳消息，则HA Agent认为该应用异常。

本实施例中以监控虚拟机VM(主机)中的应用1为例介绍本发明的技术方案。通过上述方式VMM A侧的HA Agent可以监控到应用1是否异常。

301、VMM A侧的HA Agent发现应用1异常后，则向HA Controller发送通知HA Controller应用1异常的消息；其中消息具体可以包含消息ID，HA Agent(VMM A)ID，应用ID，应用状态(状态为异常)等信息。

302、HA Controller接收到消息后，更改应用1状态信息为“异常”。

303、HA Controller通知VMM A侧的HA Agent该应用1的HA配置策略；该配置策略具体是先重启该应用1，如果重启失败再在备机拉起该应用1，且在该配置策略中还可以设置有重启预设阈值次数，例如优先地可以设置重启预设阈值次数为3次，即当3次重启均失败后，此时再再备机拉起该应用1。

304、VMM A侧的HA Agent接收该配置策略，通过Br1向Vif1广播重启消息，例如该重启消息中包含消息ID，应用ID，启动脚本，停止脚本等信息。

305、VM(主机)中的MRev接收到重启消息后，调用应用的停止脚本停止业务，然后再调用启动脚本重新拉起应用1；如果重启成功，执行步骤306，否则，执行步骤309。

306、VM(主机)中的MSend向VMM A侧的HA Agent发送应用1重启成功消息。

307、VMM A侧的HA Agent接收到重启成功消息后，向HA Controller发送更新应用1状态信息的消息。

308、HA Controller接收到更新应用1状态信息的消息后，更新应用1状态信息为“正常”。

309、如果重启次数达到重启预设阈值，则VM(主机)中的MSend向VMM A侧的HA Agent发送应用1拉起失败的消息。

该步骤与306并列。如果重启失败，但重启次数未达到重启预设阈值时，此时返回步骤304继续重启。

310、VMM A侧的HA Agent接收到应用1拉起失败的消息后，向VMMB侧的HA Agent发送“拉起备机应用”消息，以通知VMM B侧的HA Agent在备机侧拉起应用1，该“备机应用启动”消息中包含消息ID，VMM A侧的HA Agent的ID、应用ID、应用启动脚本、应用停止脚本等信息。

311、VMM B侧的HA Agent接收到备机应用启动”消息后，通过Br1向Vif1广播“应用启动”消息，该“应用启动”消息中包含消息ID，应用ID，启动脚本，停止脚本等信息。

312、VM(备机)中的MRev接收到“应用启动”消息后，MRev对运行环境检查后拉起该应用1。

具体地VM(备机)中的MRev进行环境检查具体包括VM(备机)中的MRev检查应用是否安装，检查启动脚本、停止脚本是否存在等；环境检查通过后，MRev通过调用该应用的启动脚本，拉起该应用1。

313、VM(备机)中的MRev拉起成功后，VM(备机)中的MSend向VMM B侧的HA Agent发送拉起成功消息。

314、VMM B侧的HA Agent接收到拉起成功消息，向HA Controller发送更新应用1状态信息的消息。

315、HA Controller接收到VMM B侧的HA Agent发送的更新应用1状态信息的消息后，更新应用1状态信息为“正常”。

本实施例中的VM(主机或者备机)中的MRev和MSend可以设置在一起，作为一个收发模块。

本实施例的异常处理方法，通过采用采用上述技术方案，VMM A侧的HA Agent监控到应用1异常时，根据配置策略消息先重启应用1，若重启后应用1仍异常，且重启次数达到预设阈值时，VMM A侧的HA Agent向VMMB侧的HA Agent发送拉起应用1的消息，使得在VMM A侧发生异常时，能够及时地启用VMM B侧的应用1，从而可以为用户提供连续的服务；通过采用上述技术方案对应用进行的监控，能够有效地保证对异常的监控的效率，从而能够在应用发生异常时，对异常进行及时处理，从而保证了应用的HA。

图5是本发明另一实施例提供的异常处理方法的信令图。如图5所示，基于上述图1所示实施例的异常处理系统架构，以监控虚拟机中的一个应用组为例详细介绍本发明的技术方案。本实施例的异常处理方法，具体可以包括如下步骤：

400、VMM A中的HA Agent检测VM(主机)中的应用组是否有异常。

其中VM(主机)是运行在VMM A所在的物理主机上。

其中应用组是由一组应用组成的，例如包括VM(主机)中的应用1、应用n和其他应用。应用组的每个应用都需要定期的发送心跳信息，VMM A中的HA Agent实时检测该应用组内每个应用的状态，一旦发现有一个应用状态异常，则认为该应用组状态异常。

401、当VMM A中的HA Agent发现VM(主机)中的应用组异常后，向HA Controller发送更新应用组状态信息的消息。

402、HA Controller接收到更新应用组状态信息的消息后，更新应用组状态信息为“异常”。

403、HA Controller通知VMM A侧的HA Agent该应用组的HA配置策略；该配置策略具体是停止本地的该应用组，在备机拉起该应用组。需要注意的是，在实际应用中，该配置策略可以采用上述图2或者图3的所示实施例的扩展实施例中的配置策略，在此不再一一举例。

404、VMM A侧的HA Agent接收该配置策略，向VM(主机)中的MRev发送停止应用组内的应用的停止消息，该停止消息中包含该应用组中各应用ID、应用停止脚本等信息。

405、VM(主机)中的MRev接收到该停止消息后，依次停止应用组内的各应用。

406、VM(主机)中的MSend向VMM A中的HA Agent发送应用组停止成功的消息。

407、VMM A中的HA Agent接收到该应用组停止成功的消息后，VMMA中的HA Agent向VMM B中的HA Agent发送启动应用组的启动消息，该启动消息中包含应用组ID，应用启动脚本等信息。

408、VMM B中的HA Agent接收到该启动消息后，向VM(备机)中的MRev发送拉起该应用组的消息。

409、VM(备机)中的MRev依次拉起应用组内的应用。

410、VM(备机)中的MSend向VMM B中的HA Agent发送应用组拉起成功的消息。

411、VMM B中的HA Agent通知HA Controller更新应用组状态信息。

412、HA Controller接收到消息后，更新应用组状态信息为“正常”

本实施例的异常处理方法，通过采用采用上述技术方案，VMM A侧的HA Agent监控到应用组异常时，根据配置策略消息向VMM B侧的HA Agent发送拉起该应用组的消息，使得在VMM A侧发生异常时，能够及时地启用VMM B侧的应用组，从而可以为用户提供连续的服务；通过采用上述技术方案对应用进行的监控，能够有效地保证对异常的监控的效率，从而能够在应用组发生异常时，对异常进行及时处理，从而保证了应用组的HA。

图6是本发明又一实施例提供的异常处理方法的信令图。如图6所示，基于上述图1所示实施例的异常处理系统架构，以监控虚拟机为例详细介绍本发明的技术方案。本实施例的异常处理方法，具体可以包括如下步骤：

500、VMM A中的HA Agent监控VM(主机)是否有异常，

其中VM(主机)是运行在VMM A所在的物理主机上。

具体地，HA Agent监控VM(主机)是否有异常包括：当预设时间段内未接收到虚拟机中的所有应用广播的心跳消息，或者通过监测确定虚拟机的状态异常时，确定虚拟机异常，否则确定虚拟机正常。如果HA Agent发现持续一段时间内，某个需要监控的VM内部应用的心跳信息为零，则认为该VM状态异常。或者通过调用系统信令来监测VM(主机)的状态，并确定VM(主机)的状态是正常还是异常。

501、VMM A中的HA Agent发现VM(主机)异常后，向HA Controller发送更新VM(主机)所有应用状态信息的更新消息。

502、HA Controller接收到更新消息后，更新该VM(主机)以及该VM(主机)的所有应用状态信息为“异常”。

503、HA Controller向VMM A侧的HA Agent发送该虚拟机的配置策略；该配置策略具体可以是先重启该VM(主机)1次，如果重启失败再在备机拉起该VM。

504、VMM A侧的HA Agent接收该配置策略，对VM(主机)尝试重新启动。

505、如果重启成功，则VMM A侧的HA Agent向HA Controller发送更新VM(主机)及该VM(主机)中的所有应用状态信息的更新消息。

506、HA Controller接收到更新消息后，更新该VM状态信息及该VM中的所有应用状态信息为“正常”。

507、如果重启失败，则VMM A侧的HA Agent向VMM B侧的HA Agent发送拉起VM(备机)的拉起消息。

508、VMM B侧的HA Agent接收到拉起消息后，启动VM(备机)。

509、VM(备机)启动后，VMM B侧的HA Agent向HA Controller发送VM(备机)启动成功。

510、HA Controller把VM(备机)状态信息置为“主机”。

511、VMM B侧的HA Agent持续监听VM(主机)上的各应用的心跳信息，一旦发现有各应用的心跳信息，则认为该VM(主机)已经成功启动。

512、VMM B侧的HA Agent向HA Controller发送更新该VM(主机)中各应用的状态信息的更新消息。

513、HA Controller接收到更新消息后，更新该VM(主机)中各应用状态信息为“正常”。

本实施例的异常处理方法，通过采用采用上述技术方案，VMM A侧的HA Agent监控到虚拟机异常时，根据配置策略消息先重启虚拟机，若重启后虚拟机仍异常，且重启次数达到预设阈值时，VMM A侧的HA Agent向VMMB侧的HA Agent发送拉起该虚拟机的消息，使得在VMM A侧发生异常时，能够及时地启用VMM B侧的虚拟机，从而可以为用户提供连续的服务；通过采用上述技术方案对应用进行的监控，能够有效地保证对异常的监控的效率，从而能够在虚拟机发生异常时，对异常进行及时处理，从而保证了虚拟机的HA。

图7是本发明再一实施例提供的异常处理方法的信令图。如图7所示，基于上述图1所示实施例的异常处理系统架构，以监控HA Agent所在VMM所属的物理机为例详细介绍本发明的技术方案。本实施例的异常处理方法，具体可以包括如下步骤：

600、HA Controller监控物理机A是否有异常。

其中HA Controller和VMM A中的HA Agent之间有一个网络心跳检测，如果持续一段时间内，HA Controller无法检测到VMM A中的HA Agent的心跳信息，则认为该VMM A中的HA Agent的状态异常，从而认为所在的物理机A出现异常。

601、HA Controller发现物理机A异常后，更新其中的物理机A的状态信息为“异常”。

602、HA Controller更新该物理机A上运行的VM以及VM的所有应用的状态信息为“异常”。

603、HA Controller对物理机A实行下电处理。

604、HA Controller通知物理机B依次拉起物理机A上的VM。

例如具体地，可以通知物理机B上的VMM B上的HA Agent依次拉起物理机A上的VM。

605、拉起成功后，物理机B向HA Controller返回拉起成功响应。

例如物理机B上的VMM B上的HA Agent向HA Controller返回拉起成功响应。物理机B升级为主设备侧。

606、HA Controller更新VM的状态信息为“正常”。

可选地，步骤602之后，HA Controller也可以对该物理机A进行重启，当物理机A重启预设阈值次数后仍异常，再进行步骤603-606。

本实施例的异常处理方法，通过采用采用上述技术方案，HA Controlle监控到物理机A有异常时，根据配置策略消息通知物理机B依次拉起物理机A上的VM，使得在物理机A发生异常时，能够及时地启用物理机B，从而可以为用户提供连续的服务；通过采用上述技术方案对物理机进行的监控，能够有效地保证对异常的监控的效率，从而能够在物理机发生异常时，对异常进行及时处理，从而保证了物理机的HA。

上述图4-图7所示实施例中的配置策略仅用于举例，实际应用中的配置策略可以参考上述图2或图3所示的实施例，在此不再赘述。

图8为本发明实施例提供的物理机中的代理设备的结构示意图。如图8所示，本实施例的代理设备，具体可以包括：监控模块10、发送模块11、接收模块12和异常处理模块13。

其中，监控模块10用于监控被监控对象是否发生异常；被监控对象为运行在物理机上的虚拟机、或者运行在物理机上的虚拟机中的应用或者应用组；

发送模块11与监控模块10连接，发送模块11用于当监控模块10监控被监控对象发生异常时，向控制装置发送被监控对象的异常消息，以便该控制装置将自身存储的被监控对象的状态信息更新为异常状态信息；

接收模块12用于接收控制装置发送的配置策略消息，该配置策略消息由控制装置根据被监控对象的状态信息进行配置；

异常处理模块13与接收模块12连接，异常处理模块13用于根据接收模块12接收的配置策略消息进行异常处理。

本实施例的代理设备，通过采用上述模块实现异常处理的实现机制与上述相关方法实施例的实现机制相同，详细可以参考上述相关方法实施例的记载，在此不再赘述。

本实施例的代理设备，通过采用上述模块，能够克服现有技术中仅能对虚拟机的异常进行处理，而无法对虚拟机中的应用或者应用组的异常进行处理的缺陷，采用本实施例的技术方案，不仅可以对虚拟机的异常进行处理，还能够对虚拟机中的应用或者应用组的异常进行处理，因此，本实施例的异常处理方案在实现应用、应用组或者虚拟机的HA过程中，灵活性较高。

可选地，在上述图8所示实施例的基础上，进一步还可以包括如下技术方案。

首先，图8所示实施例的代理设备中的物理机为主设备侧的物理机，物理机的代理设备为主设备侧的代理设备。

其中配置策略消息可以用于指示重启被监控对象，当重启的次数达到预设阈值，被监控对象仍然异常时，通知备设备侧拉起被监控对象。或者该配置策略消息还可以用于指示通知备设备侧拉起被监控对象。

可选地，当配置策略消息用于指示通知备设备侧拉起被监控对象时，本实施例的物理机的代理设备中，异常处理模块13具体用于根据配置策略消息，通知发送模块11向备设备侧的代理设备发送拉起被监控对象的消息。发送模块11还用于在接收到异常处理模块13发送的通知消息时，向备设备侧的代理设备发送拉起被监控对象的消息。

可选地，当配置策略消息用于指示重启被监控对象，当重启的次数达到预设阈值，被监控对象仍然异常时，通知备设备侧的代理设备拉起被监控对象时，本实施例的代理设备中，异常处理模块13具体用于根据接收模块12接收的配置策略消息，重启被监控对象；并更新重启次数；并判断重启被监控对象之后，被监控对象是否恢复正常；以及判断重启次数是否达到预设阈值。当重启后被监控对象仍然异常，且重启次数未达到预设阈值时，再次重启被监控对象；并更新重启次数，直到确定被监控对象仍然异常，且重启次数达到预设阈值时，确定重启截止；其中，发送模块11还用于当异常处理模块13确定重启截止时，向备设备侧的代理设备发送拉起被监控对象的消息。

进一步可选地，在异常处理模块13重启被监控对象之后，当监控模块监控10监控到被监控对象恢复正常时，发送模块11还用于向控制装置发送被监控对象重启成功的消息，以便该控制装置将控制装置中存储的被监控对象的状态信息更改为正常信息。

进一步可选地，发送模块11具体用于通过控制装置向备设备侧的代理设备发送拉起被监控对象的消息。

可选地，图8所示实施例的代理设备中，当被监控对象为运行在物理机上的虚拟机中的应用时，监控模块10具体用于在预设时间段内接收模块12未接收到虚拟机中的应用广播的心跳消息时，确定虚拟机中的应用异常，在预设时间段内接收模块12接收到虚拟机中的应用广播的心跳消息时，确定虚拟机中的应用正常。其中，接收模块12还用于接收虚拟机中的应用广播的心跳消息。

可选地，图8所示实施例的代理设备中，当被监控对象为运行在物理机上的虚拟机中的应用组时，监控模块10监控模块具体用于在预设时间段内接收模块12未接收到虚拟机中的应用组中的任意一个应用广播的心跳消息时，确定虚拟机中的应用组发生异常，在预设时间段内接收模块12接收到虚拟机中的应用组中的任意一个应用广播的心跳消息时，确定虚拟机中的应用组正常。其中，接收模块12还用于接收虚拟机中的应用组中的任意一个应用广播的心跳消息。

可选地，图8所示实施例的代理设备中，当被监控对象为运行在物理机上的虚拟机时，监控模块10监控模块具体用于在预设时间段内接收模块12未接收到虚拟机中的所有应用广播的心跳消息时，确定虚拟机异常；在预设时间段内接收模块12接收到虚拟机中的所有应用广播的心跳消息时，确定所述虚拟机正常；其中，接收模块12还用于接收虚拟机中的所有应用广播的心跳消息。

其中，监控模块10还可以具体用于通过信令监测确定虚拟机的状态是否发生异常。

上述实施例的代理设备，通过采用上述模块实现异常处理的实现机制与上述相关方法实施例的实现机制相同，详细可以参考上述相关方法实施例的记载，在此不再赘述。

上述实施例的代理设备，通过采用上述模块，能够克服现有技术中仅能对虚拟机的异常进行监控，而无法对虚拟机中的应用或者应用组进行异常进行处理的缺陷，采用本实施例的技术方案，不仅可以对虚拟机的异常进行监控，还能够对虚拟机中的应用或者应用组的异常进行处理，因此，本实施例的异常处理方案在实现应用、应用组或者虚拟机的HA过程中，灵活性较高。其次，本实施例的代理设备为主设备侧的代理设备时，当监控到异常时，根据配置策略消息向备设备侧的代理设备发送拉起所述被监控对象的消息，使得在主设备侧发生异常时，能够及时地启用备设备侧的被监控对象，从而可以为用户提供连续的服务；另外，主设备侧的代理设备监控到有异常发生时，主设备侧的代理设备重启被监控对象，若重启后恢复正常，则无需向备设备侧发送拉起被监控对象的消息，从而节约了通信开销；再次，主设备侧的代理设备监控到有异常发生时，主设备侧的代理设备重启被监控对象，若重启次数达到预设阈值，且被监控对象仍然异常，则向备设备侧的代理设备发送拉起重启被监控对象，从而能够提供连续的服务，保证能够向用户提供不间断的服务；上述实施例中，通过采用上述技术方案对应用、或者应用组或者虚拟机进行的监控，能够有效地保证对异常的监控的效率，从而能够在应用、或者应用组或者虚拟机发生异常时，对异常进行及时处理，从而保证了应用、或者应用组或者虚拟机的HA。

图9为本发明实施例提供的控制装置的结构示意图。如图9所示，本实施例的控制装置，可以包括监控模块20、更新模块21和异常处理模块22。

其中，监控模块20用于监控物理机是否发生异常；其中，该物理机上运行至少一个虚拟机，至少一个虚拟机中每一个虚拟机上运行至少一个应用；

更新模块21与监控模块20连接，更新模块21用于当监控模块20监控到物理机异常时，将自身存储的物理机上每一个虚拟机的状态信息、以及每一个虚拟机中每一个应用的状态信息更新为异常状态信息；

异常处理模块22与监控模块20连接，异常处理模块22用于当监控模块20监控到主设备侧的物理机异常时，根据预设的配置策略消息进行异常处理。

本实施例的控制装置，通过采用上述模块实现异常处理的实现机制与上述相关方法实施例的实现机制相同，详细可以参考上述相关方法实施例的记载，在此不再赘述。

本实施例的控制装置，通过采用上述模块能够克服现有技术中仅能对虚拟机的异常进行处理，而无法对虚拟机所在的物理机的异常进行处理的缺陷，采用本实施例的技术方案，不仅可以对虚拟机的异常进行处理，还能够对虚拟机所在的物理机的异常进行处理，因此，本实施例的异常处理方案在实现虚拟机的HA过程中，灵活性较高。

可选地，在上述图9所示实施例的基础上，进一步还可以包括如下技术方案。

图9所示实施例中，该物理机为主设备侧的物理机；该配置策略消息具体可以用于指示重启主设备侧的物理机，当主设备侧的物理机重启的次数达到预设阈值，主设备侧的物理机仍然异常时，通知备设备侧拉起主设备侧的物理机上运行的至少一个虚拟机中的每一个虚拟机，以及至少一个虚拟机中的每一个虚拟机上运行的至少一个应用中的每一个应用。或者该配置策略消息具体可以用于指示通知备设备侧拉起主设备侧的物理机上运行的至少一个虚拟机中的每一个虚拟机，以及至少一个虚拟机中的每一个虚拟机上运行的至少一个应用中的每一个应用。

可选地，当配置策略消息用于指示通知备设备侧拉起主设备侧的物理机上运行的至少一个虚拟机中的每一个虚拟机，以及至少一个虚拟机中的每一个虚拟机上运行的至少一个应用中的每一个应用。本实施例的控制装置中，异常处理模块22具体用于根据配置策略消息，对主设备侧的物理机进行下电处理；向备设备侧的物理机发送拉起主设备侧的物理机上运行的至少一个虚拟机中每一个虚拟机，以及所述每一个虚拟机上运行的每一个应用的消息。

更新模块21还用于在备设备侧的物理机成功拉起主设备侧的物理机上运行的每一个虚拟机，以及所述每一个虚拟机上运行的每一个应用之后，将自身存储的主设备侧的物理机上每一个虚拟机的状态信息、以及所述每一个虚拟机上中每一个应用的状态信息更新为正常状态信息。

可选地，上述异常处理模块22还可以用于当监控模块20监控到主设备侧的物理机异常时，根据配置策略消息，重启主设备侧的物理机；并更新重启次数；判断重启之后，主设备侧的物理机是否恢复正常；以及判断重启次数是否达到预设阈值；当确定主设备侧的物理机未恢复正常，且重启次数未达到预设阈值时，再次重启所述主设备侧的物理机；并更新重启次数，直到确定主设备侧的物理机仍然异常，且重启次数达到所述预设阈值时，确定重启截止。

进一步可选地，本实施例的控制装置中还包括接收模块、该接收模块接收物理机上的代理设备广播的心跳消息。监控模块20具体用于在预设时间段内接收模块未接收到物理机上的代理设备广播的心跳消息时，确定物理机发生异常，在预设时间段内接收模块接收到物理机上的代理设备广播的心跳消息时，物理机正常。该代理设备设置在主设备侧的物理机上的VMM上。

本实施例的控制装置，通过采用上述模块实现异常处理的实现机制与上述相关方法实施例的实现机制相同，详细可以参考上述相关方法实施例的记载，在此不再赘述。

本实施例的控制装置，通过采用上述模块能够克服现有技术中无法对虚拟机所在的物理机的异常进行处理的缺陷，采用本实施例的技术方案，能够实现对虚拟机所在的物理机的异常进行处理，因此，本实施例的异常处理方案在实现虚拟机的HA过程中，灵活性较高。另外，物理机为主设备侧的物理机时，本实施例中的控制装置监控到主设备的物理机发生异常时，根据配置策略消息对主设备侧的物理机进行下电处理，并向备设备的物理机发送拉起被监控对象的消息，使得在主设备侧的物理机发生异常时，能够及时地启用备设备侧的物理机，从而可以为用户提供连续的服务；另外，当控制装置监控到主设备的物理机发生异常时，控制设备重启被监控对象，若重启后恢复正常，则无需向备设备侧发送拉起被监控对象的消息，从而节约了通信开销；再次，当控制装置监控到主设备的物理机发生异常时，控制设备重启被监控对象，若重启次数达到预设阈值，且被监控对象仍然异常，则向备设备侧的代理设备发送拉起重启被监控对象，从而能够提供连续的服务，保证能够向用户提供不间断的服务；上述实施例的控制装置，通过采用上述技术方案对虚拟机所在物理机进行的监控，能够有效地保证对异常的监控的效率，从而能够在虚拟机所在物理机发生异常时，对异常进行及时处理，从而保证了虚拟机所在物理机的HA。

图10为本发明一实施例提供的异常处理系统的结构示意图，如图10所示，本实施例的异常处理系统，可以包括主设备侧物理机30、备设备侧物理机40和控制装置50，主设备侧物理机30和备设备侧物理机40互为主备机，主设备侧物理机30上设置有虚拟机监控装置301、备设备侧物理机40上设置有虚拟机监控装置401；主设备侧物理机30上运行有至少一个虚拟机302，且至少一个虚拟机302中的每个虚拟机302上能够运行至少一个应用或应用组。备设备物理机40作为主设备物理机30的备用机，在主设备物理机30出现异常时，能够升级为主设备物理机，因此备设备侧物理机40上能运行至少一个虚拟机402，各虚拟机402中能够运行至少一个应用或者应用组。至少一个虚拟机402以及每一个虚拟机402中的至少一个应用或者应用组，均作为至少一个虚拟机302以及每一个虚拟机302中的至少一个应用或者应用组的备份。虚拟机监控装置301中设置有代理设备303；代理设备303能够对主物理机30中的虚拟机302进行监控。虚拟机监控装置401中设置有代理设备403；代理设备403能够对备物理机40中的虚拟机402进行监控。具体地代理设备303和代理设备403具体可以采用上述图8所示实施例的代理设备来实现，详细可以参考上述实施例的记载，在此不再赘述。图10中以主备设备侧物理机30上能运行的一个虚拟机302，备设备侧物理机40上运行的一个虚拟机402为例来介绍本发明的技术方案。

本实施例中控制装置50分别与代理设备303和代理设备403相通信，且代理设备303和代理设备403也能够互相通信。本实施例中的虚拟机监控装置301和虚拟机监控装置401具体可以为采用VMM来实现。

主设备侧物理机30上的代理设备303用于检测主设备侧的物理机上运行的虚拟机上的应用或者应用组或者虚拟机，并当主设备侧的物理机上运行的虚拟机上的应用或者应用组或者虚拟机出现异常时，向控制装置50发送主设备侧的物理机上运行的虚拟机上的应用或者应用组或者虚拟机异常的消息，控制装置50接收到主设备侧的物理机上运行的虚拟机上的应用或者应用组或者虚拟机异常的消息之后，将控制装置50中该虚拟机上的应用或者应用组或者虚拟机的状态更新为异常状态；并向主设备侧的代理设备303发送的配置策略消息；主设备侧的代理设备303接收控制装置50发送的配置策略消息，并根据配置策略消息进行异常处理；详细可以参考上述相关实施例的记载，在此不再赘述。

本实施例的异常处理系统，通过采用上述技术方案，能够克服现有技术中仅能对虚拟机的异常进行处理，而无法对虚拟机中的应用或者应用组的异常进行处理的缺陷，采用本实施例的技术方案，不仅可以对虚拟机的异常进行处理，还能够对虚拟机中的应用或者应用组的异常进行处理，因此，本实施例的异常处理方案在实现应用、应用组或者虚拟机的HA过程中，灵活性较高。

图11为本发明另一实施例提供的异常处理系统的结构示意图，如图11所示，本实施例的异常处理系统，包括主设备侧物理机60、备设备侧物理机70和控制装置80，主设备侧物理机60和备设备侧物理机70互为主备机；控制装置80控具体可以采用上述图9所示实施例的控制装置来实现，详细可以参考上述实施例的记载，在此不再赘述。

本实施例的异常处理系统中，主设备侧物理机60和备设备侧物理机70分别与控制装置80相通信。

本实施例的异常处理系统中，控制装置80用于监控正在运行的主设备侧物理机60是否异常；主设备侧物理机60上运行至少一个虚拟机，且各虚拟机上运行有至少一个应用；当主设备侧物理机60异常时，控制装置80将主设备侧物理机60上存储的至少一个虚拟机中每一个虚拟机的状态信息、以及至少一个虚拟机中每一个虚拟机上的至少一个应用中的每一个应用的状态信息更新为异常状态信息；并根据预设的配置策略消息进行异常处理；详细可以参考上述相关实施例的记载，在此不再赘述。

本实施例的异常处理系统，通过采用上述技术方案，能够克服现有技术中无法对虚拟机所在的物理机的异常进行处理的缺陷，采用本实施例的技术方案，能够对虚拟机所在的物理机的异常进行处理，实现虚拟机所在物理机的HA，灵活性较高。

本领域普通技术人员可以理解：实现上述各方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成。前述的程序可以存储于一计算机可读取存储介质中。该程序在执行时，执行包括上述各方法实施例的步骤；而前述的存储介质包括：ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质。

以上所描述的装置实施例仅仅是示意性的，其中作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到至少两个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性的劳动的情况下，即可以理解并实施。

最后应说明的是：以上各实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述各实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的范围。

Claims (9)

1.一种异常处理方法，其特征在于，包括：

控制装置监控物理机是否发生异常，其中，所述物理机上运行至少一个虚拟机，所述至少一个虚拟机中每一个虚拟机上运行至少一个应用；

当所述物理机发生异常时，所述控制装置将自身存储的所述物理机上每一个虚拟机的状态信息、以及所述每一个虚拟机中每一个应用的状态信息更新为异常状态信息；

所述控制装置根据预设的配置策略消息进行异常处理。

2.根据权利要求1所述的方法，其特征在于，所述物理机为主设备侧的物理机；

则，所述控制装置根据预设的配置策略消息进行异常处理，包括：

所述控制装置对所述主设备侧的物理机进行下电处理；

所述控制装置向备设备侧的物理机发送拉起所述主设备侧的物理机上运行的每一个虚拟机以及所述每一个虚拟机上运行的每一个应用的消息；

进一步地，所述方法还包括：

在所述备设备侧的物理机成功拉起所述主设备侧的物理机上运行的每一个虚拟机，以及所述每一个虚拟机上运行的每一个应用之后，所述控制装置将自身存储的所述主设备侧的物理机上的每一个虚拟机的状态信息、以及所述每一个虚拟机中每一个应用的状态信息更新为正常状态信息。

3.根据权利要求2所述的方法，其特征在于，在所述控制装置对所述主设备侧的物理机进行下电处理之前，所述方法还包括：

所述控制装置重启所述主设备侧的物理机；并更新重启次数；

所述控制装置判断所述主设备侧的物理机是否恢复正常；以及判断所述重启次数是否达到预设阈值；

当判断所述主设备侧的物理机未恢复正常，且所述重启次数未达到预设阈值时，则所述控制装置再次重启所述主设备侧的物理机，并更新所述重启次数，直到确定所述主设备侧的物理机仍然异常，且所述重启次数达到所述预设阈值时，确定重启截止。

4.根据权利要求2或3所述的方法，其特征在于，所述控制装置监控主设备侧的物理机是否发生异常，包括：

若所述控制装置在预设时间段内未接收到所述主设备侧的物理机上的代理设备广播的心跳消息时，则所述控制装置确定所述主设备侧的物理机发生异常，否则，所述控制装置确定所述主设备侧的物理机正常。

5.一种控制装置，其特征在于，包括：

监控模块，用于监控物理机是否发生异常，其中，所述物理机上运行至少一个虚拟机，所述至少一个虚拟机中每一个虚拟机上运行至少一个应用；

更新模块，用于当所述物理机异常时，将自身存储的所述物理机上每一个虚拟机的状态信息、以及所述每一个所述虚拟机中每一个应用的状态信息更新为异常状态信息；

异常处理模块，用于根据预设的配置策略消息进行异常处理。

6.根据权利要求5所述的装置，其特征在于，所述物理机为主设备侧的物理机；所述异常处理模块具体用于根据所述配置策略消息，对所述主设备侧的物理机进行下电处理，向备设备侧的物理机发送拉起所述主设备侧的物理机上运行的每一个虚拟机以及所述每一个虚拟机上运行的每一个应用的消息；

所述更新模块，还用于在所述备设备侧的物理机成功拉起所述主设备侧的物理机上运行的每一个虚拟机，以及所述每一个虚拟机上运行的每一个应用之后，将自身存储的所述主设备侧的物理机上的每一个虚拟机的状态信息、以及所述每一个虚拟机中每一个应用的状态信息更新为正常状态信息。

7.根据权利要求6所述的装置，其特征在于，所述异常处理模块，还用于根据所述配置策略消息，重启所述主设备侧的物理机；并更新重启次数；判断所述主设备侧的物理机是否恢复正常；以及判断所述重启次数是否达到预设阈值；当确定所述主设备侧的物理机未恢复正常，且所述重启次数未达到预设阈值时，再次重启所述主设备侧的物理机；并更新所述重启次数，直到确定所述主设备侧的物理机仍然异常，且所述重启次数达到所述预设阈值时，确定重启截止。

8.根据权利要求6或7任一所述的装置，其特征在于，所述装置还包括接收模块；

所述接收模块，用于接收所述主设备侧的物理机上的代理设备广播的心跳消息；

则，所述监控模块具体用于在预设时间段内所述接收模块未接收到所述主设备侧的物理机上的代理设备广播的心跳消息时，确定所述主设备侧的物理机发生异常，在预设时间段内所述接收模块接收到所述主设备侧的物理机上的代理设备广播的心跳消息时，确定所述主设备侧的物理机正常。

9.一种异常处理系统，其特征在于，包括主设备侧物理机、备设备侧物理机和控制装置，所述主设备侧物理机和所述备设备侧物理机互为主备机；所述控制装置采用如上权利要求5-8中任一所述的控制装置，所述主设备侧物理机和所述备设备侧物理机分别与所述控制装置相通信。