CN111309515B - 一种容灾控制方法、装置及*** - Google Patents

Abstract

一种容灾控制方法、装置及***，用以解决主站点中同一服务的所有实例全部故障时，主站点和备站点均不能继续为客户提供该服务的问题。该方法包括：针对主站点提供的第一服务，确定所述第一服务在所述主站点中的多个虚拟机中的每个实例的工作状态。当所述主站点中所述第一服务的所有实例中工作状态为故障的实例的数量满足故障策略时，确定第一决策结果，所述第一决策结果为指示备站点接管所述主站点的业务。向备站点发送所述第一决策结果。

Description

一种容灾控制方法、装置及***

技术领域

本申请涉及计算机技术领域，尤其涉及一种容灾控制方法、装置及***。

背景技术

随着云计算的发展，软件***在往服务化方向演进，客户的大型软件***往往由若干个服务或组件构成，如数据库、消息中间件、业务应用等。在数据中心、私有云或者公有云环境中，站点中针对服务部署的实例故障时会导致业务停机，而业务停机都会给客户带来巨大的经济损失和声誉影响。

目前常用的站点容灾方案为建立两个站点，两个站点是对等的，其中一个站点作为主站点为客户提供服务，另一个站点为备站点为主站点提供备份能力。备站点通过监控与主站点之间的心跳消息来监控主站点是否故障。当主站点发生地震、火灾、网络断链等灾难受到破坏时主站点与备站点之间的心跳消息中断，从而备站点在监控到与主站点之间的心跳消息中断时可以接管主站点的业务，继续为客户提供服务。

但是当主站点中针对某一服务部署的所有实例全部故障导致业务中断时，主站点与备站点之间的心跳消息仍然是正常的，因此主站点以及备站点均无法为客户提供该服务。

发明内容

本申请提供一种容灾控制方法、装置及***，用以解决主站点中同一服务的所有实例全部故障时，主站点和备站点均不能继续为客户提供该服务的问题。

第一方面，本申请提供了一种容灾控制方法，该方法包括：针对主站点提供的第一服务，确定所述第一服务在所述主站点中的多个虚拟机中的每个实例的工作状态。当所述主站点中所述第一服务的所有实例中工作状态为故障的实例的数量满足故障策略时，确定第一决策结果，所述第一决策结果为指示备站点接管所述主站点的业务。向备站点发送所述第一决策结果。本申请实施例中主站点可以监控第一服务在所述主站点中的多个虚拟机中每个实例的工作状态，然后可以根据每个实例的工作状态确实是否将业务切换到备站点，例如，主站点在监测到某服务的实例全部故障时，指示备站点接管该主站点的业务，从而可以由备站点继续为客户提供服务，进而降低客户的经济损失和声誉影响。

一种可能的设计中，该故障策略为针对第一服务制定的。

一种可能的设计中，确定所述第一服务在所述主站点中的多个虚拟机中的每个实例的工作状态时，可以针对所述第一服务在所述主站点中的多个虚拟机中的每个实例，确定所述实例的故障开始时间。之后，根据所述故障开始时间确定故障持续时间。若所述故障持续时间大于故障时间阈值，则确定所述实例的工作状态为故障。若所述故障持续时间小于或等于所述故障时间阈值，则确定所述实例的工作状态为未故障。上述设计中，通过实例的故障持续时间可以比较准确的判断实例是否故障，从而可以提高决策结果的准确性。

一种可能的设计中，确定所述实例的故障开始时间时，可以接收并记录所述实例的应用健康情况。若接收的所述实例的应用健康情况为异常，且最近一次记录的所述实例的应用健康情况为正常或者没有所述实例的应用健康情况的记录，确定所述实例的故障开始时间为当前时间。在实例的应用健康情况由正常跳变为异常时可以确定该跳变时刻为该实例的故障开始的时间，因此，通过上述设计可以得到比较准确的故障开始时间，从而可以提高决策结果的准确性。

一种可能的设计中，确定所述实例的故障开始时间时，若未接收到第一虚拟机上报的所述实例的应用健康情况，则可以确定所述实例的故障开始时间为当前时间，所述第一虚拟机为所述主站点中部署所述实例的虚拟机。若未接收到第一虚拟机上报的所述实例的应用健康情况，可以认为第一虚拟机出现故障，因此可以认为第一虚拟机上所述实例出现故障，因此，通过上述设计可以及时的确定实例的故障开始时间，从而可以提高决策结果的准确性。

一种可能的设计中，确定所述第一服务在所述主站点中的多个虚拟机中的每个实例的工作状态时，还可以针对所述第一服务在所述主站点中的多个虚拟机中的每个实例，确定最近一次接收所述实例的应用健康情况的时间。根据所述最近一次接收所述实例的应用健康情况的时间确定中断时间。若所述中断时间大于故障时间阈值，则确定所述实例的工作状态为故障。若所述中断时间小于或等于故障时间阈值，则确定所述实例的工作状态为未故障。若长时间未接收到第一虚拟机上报的所述实例的应用健康情况，可以认为第一虚拟机出现故障，因此可以认为第一虚拟机上所述实例出现故障，因此，第一虚拟机上报的中断时间可以认为是虚拟机的故障持续时间，也就是第一虚拟机上的实例至少故障了该中断时间，因此根据该中断时间也可以及时的确定实例的工作状态是否故障，从而可以提高决策结果的准确性。

一种可能的设计中，主站点可以通过解析故障策略确定故障时间阈值。

一种可能的设计中，在确定所述第一服务在所述主站点中的多个虚拟机中的每个实例的工作状态之后，若所述主站点中所述第一服务的所有实例中工作状态为故障的实例的数量不满足所述故障策略，则可以确定第二决策结果，所述第二决策结果为不指示所述备站点接管所述主站点的业务。上述设计中，若第一服务的实例不满足故障策略，可以确定不指示备站点接管主站点的业务，从而可以由主站点继续为客户提供服务。

一种可能的设计中，所述向备站点发送所述第一决策结果时，可以通过仲裁服务向所述备站点发送所述第一决策结果。上述设计中，备站点在与主站点之间的心跳网络中断时可以比较准确的获取主站点的决策结果，从而可以及时的接管主站点的业务，进而可以业务停机的风险。

一种可能的设计中，通过仲裁服务向所述备站点发送所述第一决策结果，可以通过将第一决策结果写入所述主站点的仲裁服务的实例中实现，其中，所述仲裁服务的实例可以部署在主站点、备站点和仲裁站点中。上述设计中，主站点中仲裁服务的实例、备站点中仲裁服务的实例、仲裁站点中仲裁服务的实例组成了一个集群，因此主站点的仲裁服务的实例写入的第一决策结果可以在该集群内共享。因此，备站点可以通过查询的方式在该集群中获得所述第一决策结果。

第二方面，本申请提供了一种主站点，包括：多个虚拟机和部署于第一虚拟机中的工作状态单元、决策单元和发送单元。所述工作状态单元用于针对主站点提供的第一服务，确定所述第一服务在所述主站点中的多个虚拟机中的每个实例的工作状态。所述决策单元用于当所述主站点中所述第一服务在所述多个虚拟机中的所有实例中工作状态为故障的实例的数量满足故障策略时，确定第一决策结果，所述第一决策结果为指示备站点接管所述主站点的业务。所述发送单元用于向备站点发送所述第一决策结果。

一种可能的设计中，所述工作状态单元，可以具体用于：针对所述第一服务在所述主站点中的多个虚拟机中的每个实例，确定所述实例的故障开始时间；根据所述故障开始时间确定故障持续时间；若所述故障持续时间大于故障时间阈值，则确定所述实例的工作状态为故障；若所述故障持续时间小于或等于所述故障时间阈值，则确定所述实例的工作状态为未故障。

一种可能的设计中，所述工作状态单元，在确定所述实例的故障开始时间时，可以具体用于：接收并记录所述实例的应用健康情况；若接收的所述实例的应用健康情况为异常，且最近一次记录的所述实例的应用健康情况为正常或者没有所述实例的应用健康情况的记录，确定所述实例的故障开始时间为当前时间。

一种可能的设计中，所述工作状态单元，在确定所述实例的故障开始时间时，可以具体用于：若未接收到第一虚拟机上报的所述实例的应用健康情况，则确定所述实例的故障开始时间为当前时间，所述第一虚拟机为所述主站点中部署所述实例的虚拟机。

一种可能的设计中，所述工作状态单元，可以具体用于：针对所述第一服务在所述主站点中的多个虚拟机中的每个实例，确定最近一次接收所述实例的应用健康情况的时间；根据最近一次接收所述实例的应用健康情况的时间确定中断时间；若所述中断时间大于故障时间阈值，则确定所述实例的工作状态为故障；若所述中断时间小于或等于故障时间阈值，则确定所述实例的工作状态为未故障。

一种可能的设计中，所述决策单元，还可以用于：当所述第一服务的所有实例中工作状态为故障的实例的数量不满足所述故障策略时，确定第二决策结果，所述第二决策结果为不指示所述备站点接管所述主站点的业务。

一种可能的设计中，所述发送单元，可以具体用于：通过仲裁服务向所述备站点发送所述第一决策结果。

一种可能的设计中，所述第一虚拟机是所述多个虚拟机中的一个虚拟机，或者，所述第一虚拟机不是所述多个虚拟机中的一个虚拟机。

第三方面，本申请提供了一种主站点，所述主站点运行多个虚拟机，所述多个虚拟机包括第一服务的实例。所述主站点包括容灾服务模块。所述容灾服务模块，用于确定所述第一服务在所述多个虚拟机中的每个实例的工作状态；以及，若所述第一服务的所有实例中工作状态为故障的实例的数量满足故障策略，确定第一决策结果，所述第一决策结果为指示备站点接管所述主站点的业务；以及，向所述备站点发送所述第一决策结果。

一种可能的设计中，所述容灾服务模块，在确定所述第一服务在所述多个虚拟机中的每个实例的工作状态时，可以具体用于：针对所述第一服务在所述主站点中的多个虚拟机中的每个实例，确定所述实例的故障开始时间；根据所述故障开始时间确定故障持续时间；若所述故障持续时间大于故障时间阈值，则确定所述实例的工作状态为故障；若所述故障持续时间小于或等于所述故障时间阈值，则确定所述实例的工作状态为未故障。

一种可能的设计中，所述多个虚拟机上分别可以包括一个容灾代理模块，每个容灾代理模块用于向所述容灾服务模块上报所在虚拟机上所述第一服务的实例的应用健康情况。所述容灾服务模块，在确定所述实例的故障开始时间时，可以具体用于：接收并记录第一容灾代理模块上报的所述实例的应用健康情况，所述第一容灾代理模块为部署所述实例的虚拟机上所包括的容灾代理模块；若接收的所述实例的应用健康情况为异常，且最近一次记录的所述实例的应用健康情况为正常或者没有所述实例的应用健康情况的记录，确定所述实例的故障开始时间为当前时间。

一种可能的设计中，所述多个虚拟机上分别可以包括一个容灾代理模块，每个容灾代理模块用于向所述容灾服务模块上报所在虚拟机上所述第一服务的实例的应用健康情况；所述容灾服务模块，在确定所述实例的故障开始时间时，可以具体用于：若未接收到第一容灾代理模块上报的所述实例的应用健康情况，则确定所述实例的故障开始时间为当前时间，所述第一容灾代理模块为部署所述实例的虚拟机上所包括的容灾代理模块。

一种可能的设计中，所述多个虚拟机上分别可以包括一个容灾代理模块，每个容灾代理模块用于向所述容灾服务模块上报所在虚拟机上所述第一服务的实例的应用健康情况；所述容灾服务模块，在确定所述第一服务在所述多个虚拟机中的每个实例的工作状态时，可以具体用于：针对所述第一服务在所述主站点中的多个虚拟机中的每个实例，确定第一容灾代理模块最近一次上报所述实例的应用健康情况的时间，所述第一容灾代理模块为所述主站点中包括所述实例的虚拟机上所部署的容灾代理模块；根据所述第一容灾代理模块最近一次上报所述实例的应用健康情况的时间确定中断时间；若所述中断时间大于故障时间阈值，则确定所述实例的工作状态为故障；若所述中断时间小于或等于故障时间阈值，则确定所述实例的工作状态为未故障。

一种可能的设计中，所述主站点还可以包括心跳接口，所述心跳接口用于所述主站点与所述备站点之间收发心跳消息。所述容灾服务模块，在向所述备站点发送所述第一决策结果时，可以具体用于：通过所述心跳接口向所述备站点发送所述第一决策结果。

一种可能的设计中，所述容灾服务模块，还可以用于：若所述第一服务的所有实例中工作状态为故障的实例的数量不满足所述故障策略，确定第二决策结果，所述第二决策结果为不指示所述备站点接管所述主站点的业务。

一种可能的设计中，所述主站点还可以包括仲裁服务模块，所述仲裁服务模块用于提供仲裁服务。所述容灾服务模块，在向备站点发送所述第一决策结果时，可以具体用于：通过所述仲裁服务模块提供的仲裁服务向所述备站点发送所述第一决策结果。

一种可能的设计中，所述主站点中容灾服务模块的数量可以为两个，其中一个容灾服务模块作为主服务，另一个容灾服务模块作为备服务。作为备服务的容灾服务模块，用于在作为主服务的容灾服务模块故障时接管作为主服务的容灾服务模块的业务。

第四方面，本申请提供一种站点，所述站点包括处理器、存储器、通信接口、总线，所述处理器、存储器和通信接口之间通过总线连接并完成相互间的通信，所述存储器中用于存储计算机执行指令，所述装置运行时，所述处理器执行所述存储器中的计算机执行指令以利用所述装置中的硬件资源执行第一方面或第一方面任一种可能实现方式中所述方法的操作步骤。

第五方面，本申请提供了一种容灾***，包括第二方面或者第二方面任一项设计中所述的主站点，以及备站点。

一种可能的设计中，容灾***还可以包括仲裁站点。所述仲裁站点用于为所述主站点以及所述备站点提供仲裁服务。

一种可能的设计中，所述主站点、所述备站点以及所述仲裁站点均包括仲裁服务模块。其中，所述仲裁站点的仲裁服务模块用于为所述主站点以及所述备站点提供仲裁服务；所述主站点的仲裁服务模块用于通过仲裁服务向所述备站点发送所述主站点的决策结果；所述备站点的仲裁服务模块用于通过仲裁服务获取所述主站点的决策结果。

第六方面，本申请提供一种计算机可读存储介质，所述计算机可读存储介质中存储有指令，当其在计算机上运行时，使得计算机执行第一方面或第一方面任一种可能实现方式中所述的方法。

第七方面，本申请提供了一种包含指令的计算机程序产品，当其在计算机上运行时，使得计算机执行第一方面或第一方面任一种可能实现方式中所述的方法。

本申请在上述各方面提供的实现方式的基础上，还可以进行进一步组合以提供更多实现方式。

附图说明

图1为本申请实施例提供的一种站点保护方案的示意图；

图2为本申请实施例提供的一种容灾保护方案的示意图；

图3为本申请实施例提供的一种容灾***的架构示意图；

图4为本申请实施例提供的一种主站点的架构示意图；

图5为本申请实施例提供的第一容灾服务模块更新第一实例的故障开始时间的流程示意图；

图6为本申请实施例提供的第一容灾服务模块检测第一实例的工作状态的流程示意图；

图7为本申请实施例提供的第一容灾服务模块进行容灾切换的流程示意图；

图8为本申请实施例提供的一种容灾控制方法的流程示意图；

图9为本申请实施例提供的一种容灾切换过程的示意图；

图10为本申请实施例提供的一种主站点的结构示意图；

图11为本申请实施例提供的一种主站点的结构示意图。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述。

随着云计算的发展，软件***在往服务化方向演进，客户的大型软件***往往由若干个服务或组件构成，如数据库、消息中间件、业务应用等。在数据中心、私有云或者公有云环境中，站点中针对服务部署的实例故障时会导致业务停机，而业务停机都会给客户带来巨大的经济损失和声誉影响。

针对实例故障时会导致业务停机的问题，可以采用单个站点保护方案。目前常用的单个站点保护方案有：

(1)集群方案：在站点中针对同一个服务部署多个实例组成一个集群。当部分实例故障时，该集群中的其他实例可以继续提供服务。例如参阅图1所示，针对应用A在站点中部署3个实例，当这3个实例中某个实例故障时，可以由另外两个实例来提供应用A的服务。

(2)双活(冷备)方案：在站点中针对同一个服务部署两个实例，其中，一个实例是运行状态，一个实例是停止状态。通过辅助监控手段，当运行的实例故障后，停止的实例被拉起，继续提供服务。例如参阅图1所示，针对Web服务器/反向代理服务器及电子邮件代理服务器(Engine x，Nginx)，在站点中部署2个Nginx，其中，一个Nginx为运行状态，另一个Nginx为停止状态，当运行状态的Nginx故障后，停止状态的Nginx被拉起，来提供Nginx的服务。

(3)双活(热备)方案：在站点中针对同一个服务部署两个实例，其中，两个实例都是运行状态，一个实例作为主服务，另一个实例作为备服务。当主服务实例故障后，备服务实例成为主服务，继续提供服务。例如参阅图1所示，针对数据库(database，DB)，在站点中部署2个DB，其中，一个DB为主服务，另一个DB为备服务，当作为主服务的DB故障后，作为备服务的DB成为主服务来继续提供服务。

单个站点保护方案解决的是单个站点内部的相同服务部分实例故障的问题。若单个站点内部的相同服务全部实例故障，业务就会中断，不能继续提供服务。

针对站点故障时会导致业务停机的问题，还可以采用容灾保护方案。容灾保护方案为：建立两个站点，两个站点是对等的，其中一个站点作为主站点为客户提供服务，另一个站点为备站点为主站点提供备份能力。备站点通过监控与主站点之间的心跳消息来监控主站点是否故障。当主站点发生地震、火灾、网络断链等灾难受到破坏时主站点与备站点之间的心跳消息中断，从而备站点在监控到与主站点之间的心跳消息中断时可以接管主站点的业务，继续为客户提供服务，如图2所示。容灾保护方案可分为异地容灾和同城容灾，其中，异地容灾指两个站点部署在不同的城市，同城容灾是两个站点部署在同一个城市的不同地方。

但是当主站点中针对某一服务部署的所有实例全部故障导致业务中断时，主站点与备站点之间的心跳消息仍然是正常的，因此主站点以及备站点均无法为客户提供该服务。

基于此，本申请实施例通过监控站点中每个实例的工作状态，然后可以根据每个实例的工作状态确实是否将业务切换到备站点，相比现有技术中整个主站点掉电或故障后切换到备站点，本申请实施例可以实现更小粒度的监控，从而可以在站点中某应用不能提供服务时可以切换到备站点，例如，当某服务的实例全部故障时可以切换到备站点，从而可以由备站点继续为客户提供服务，进而降低客户的经济损失和声誉影响。

本申请中所涉及的多个，是指两个或两个以上。本申请中所涉及的至少一个，是指一个，或一个以上，即包括一个、两个、三个及以上。

另外，需要理解的是，在本申请的描述中，“第一”、“第二”等词汇，仅用于区分描述的目的，而不能理解为指示或暗示相对重要性，也不能理解为指示或暗示顺序。

本申请实施例提供的容灾控制方法可以应用于图3所示的容灾***中，其中，容灾***中可以包括主站点以及备站点，还可以包括仲裁站点，其中，主站点用于为客户提供服务。主站点还可以根据每个实例的工作状态确定决策结果，该决策结果为第一决策结果或者第二决策结果，第一决策结果为指示备站点接管主站点的业务，第二决策结果为不指示备站点接管主站点的业务。备站点用于在主站点的指示下接管主站点的业务。仲裁站点用于为主站点以及备站点提供仲裁服务，主站点还用于通过仲裁服务向备站点发送决策结果，备站点还用于通过仲裁服务获取主站点的决策结果。

一种实施方式中，如图4所示，主站点可以至少一个容灾代理模块以及第一容灾服务模块，其中，每个容灾代理模块独立部署在主站点运行的一个虚拟机上，第一容灾服务模块可以部署在主站点中的任一虚拟机上。应理解，图4仅是一种示例性说明，并不对主站点内包括的虚拟机、容灾代理模块、第一容灾服务模块的数量进行具体限定。

每个容灾代理模块，用于向第一容灾服务模块上报容灾代理模块所在虚拟机上每个实例的应用健康情况。

容灾代理模块可以通过步骤A1至A4上报容灾代理模块所在虚拟机上每个实例的应用健康情况：

A1，读取所在虚拟机上应用的部署信息。

A2，根据部署信息来确定所在虚拟机包括的实例，如关键业务管理服务、数据库、消息中间件等。

A3，采集所在虚拟机上每个实例的应用健康情况。示例性的，容灾代理模块可以采用类似巡检的方式采集所在虚拟机上每个实例的应用健康情况，例如容灾代理模块可以通过查询每个实例的进程、服务状态、保活接口等来采集每个实例的应用健康情况。

A4，向第一容灾服务模块上报每个实例的应用健康情况。示例性的，容灾代理模块可以通过调用第一容灾服务模块提供的接口上报应用的健康信息，例如，该接口可以为yaml定义的接口。

第一容灾服务模块，用于基于每个容灾代理模块上报的应用健康情况确定决策结果，并向备站点发送第一决策结果。

作为一种可能的实施方式，第一容灾服务模块可以通过步骤B1至B4确定决策结果：

B1，第一容灾服务模块解析故障策略配置文件。故障策略配置文件可以包括针对所有服务制定的故障策略，或者，故障策略配置文件也可以包括针对多个服务分别制定的故障策略，例如，故障策略配置文件可以包括针对第一服务定制的故障策略、针对第二服务制定的故障策略等等。

B2，第一容灾服务模块接收到容灾代理模块上报的应用健康情况，根据实例的应用健康情况更新缓存中应用的故障开始时间。

一种示例性说明，针对虚拟机上的每个实例，若接收的所述实例的应用健康情况为异常，且缓存中最近一次记录的所述实例的应用健康情况为正常或者没有所述实例的应用健康情况的记录，第一容灾服务模块在缓存中将所述实例的故障开始时间设置为当前时间。

若接收的所述实例的应用健康情况为正常，第一容灾服务模块可以在缓存中将该实例的应用健康情况设置为正常，还可以将所述实例的故障开始时间设置为0。

另一种示例性说明，若未接收到第一虚拟机上报的所述实例的应用健康情况，第一容灾服务模块可以认为第一虚拟机出现故障，即所述实例出现故障，因此可以在缓存中将所述实例的故障开始时间设置为当前时间。

为了更好地理解本申请实施例，以下结合具体应用场景，对步骤B2的过程进行具体详细描述。下面以第一实例为例进行描述，参阅图5所示，为第一容灾服务模块更新第一实例的故障开始时间的过程：

S501，第一容灾服务模块接收第一容灾代理模块所上报的第一实例的应用健康情况，第一容灾代理模块为第一实例所在虚拟机上部署的容灾代理模块。执行步骤S502。

S502，第一容灾服务模块确定缓存中是否存在第一实例的故障开始时间。若是，执行步骤S503；若否，执行步骤S507。

S503，第一容灾服务模块确定缓存中第一实例的应用健康情况是否为正常。若是，执行步骤S504；若否，执行步骤S511。

S504，第一容灾服务模块确定第一容灾代理模块上报的第一实例的应用健康情况是否为正常。若是，执行步骤S505，若否，执行步骤S506。

S505，第一容灾服务模块不更新缓存中第一实例的应用健康情况以及故障开始时间。

S506，第一容灾服务模块将缓存中第一实例的故障开始时间设置为当前时间。

S507，第一容灾服务模块在缓存中增加第一实例的记录。执行步骤S508。

S508，第一容灾服务模块确定第一容灾代理模块上报的第一实例的应用健康情况是否为正常。若是，执行步骤S509，若否，执行步骤S510。

S509，第一容灾服务模块在缓存中将第一实例的应用健康情况设置为正常，将第一实例的故障开始时间设置为0。

S510，第一容灾服务模块在缓存中将第一实例的故障开始时间设置为当前时间。

S511，第一容灾服务模块确定第一容灾代理模块上报的第一实例的应用健康情况是否为正常。若是，执行步骤S512，若否，执行步骤S513。

S512，第一容灾服务模块在缓存中将第一实例的应用健康情况设置为正常，将第一实例的故障开始时间更新为0。

S513，第一容灾服务模块不更新缓存中第一实例的应用健康情况以及故障开始时间。

B3，根据缓存中每个实例的故障开始时间周期性检测每个实例的工作状态。

一种实现方式中，针对每个实例，在缓存中存在该实例的故障开始时间时，若该实例的故障开始时间为0或者缓存中该实例的应用健康情况为正常，则可以确定所述实例的工作状态为未故障。若该实例的故障开始时间不为0或者缓存中该实例的应用健康情况不为正常，可以根据所述故障开始时间确定故障持续时间。示例性的，Δt1＝t1-t2，其中，Δt1为故障持续时间，t1为当前时间，t2为故障开始时间。当所述故障持续时间大于故障时间阈值时，可以确定所述实例的工作状态为故障。当所述故障持续时间小于或等于所述故障时间阈值时，可以确定所述实例的工作状态为未故障。

若缓存中不存在该实例的故障开始时间，且从未接收到该实例的应用健康情况的时间，则可以确定该实例的故障开始时间为当前时间，并将该实例的故障开始时间记录在缓存中。

另一种实现方式中，确定最近一次接收所述实例的应用健康情况的时间。根据所述最近一次接收所述实例的应用健康情况的时间确定中断时间。示例性的，Δt2＝t1-t3，其中，Δt2为故障持续时间，t1为当前时间，t3为最近一次接收所述实例的应用健康情况的时间。若所述中断时间大于故障时间阈值，则可以确定所述实例的工作状态为故障。若所述中断时间小于或等于故障时间阈值，则可以确定所述实例的工作状态为未故障。

示例性的，故障时间阈值可以配置在故障策略中。因此第一容灾服务模块可以通过步骤B1，解析故障策略配置文件来确定故障时间阈值。

为了更好地理解本申请实施例，以下结合具体应用场景，对步骤B3的过程进行具体详细描述。第一容灾服务模块遍历每个实例，检测每个实例的工作状态。下面以第一实例为例进行描述，其中第一实例属于第一服务，参阅图6所示，为第一容灾服务模块检测第一实例的工作状态的过程：

S601，第一容灾服务模块确定是否接收到过来自第一容灾代理模块的第一实例的应用健康情况。若是，执行步骤S602。若否，执行步骤S608。

S602，第一容灾服务模块确定第一实例的中断时间，其中，第一实例的中断时间为当前时间以及最近一次接收来自第一容灾服务模块的第一实例的应用健康情况的时间之间的差值。执行步骤S603。

S603，第一容灾服务模块确定第一实例的中断时间是否大于第一服务对应故障策略中的故障时间阈值。若是，执行步骤S604。若否，执行步骤S605。

S604，第一容灾服务模块确定第一实例的工作状态为故障。

S605，第一容灾服务模块确定第一实例的故障持续时间，其中，第一实例的故障持续时间为当前时间以及第一实例的故障开始时间之间的差值。执行步骤S606。

S606，第一容灾服务模块确定第一实例的故障持续时间是否大于第一服务对应故障策略中的故障时间阈值。若是，执行步骤S604。若否，执行步骤S607。

S607，第一容灾服务模块确定第一实例的工作状态为未故障。

S608，第一容灾服务模块确定缓存中是否存在第一实例的故障开始时间。若是，执行步骤S605。若否，执行步骤S609。

S609，第一容灾服务模块在缓存中将第一实例的故障开始时间设置为当前时间。

B4，针对每个服务，确定该服务的所有实例中工作状态为故障的实例的数量是否满足故障策略。若是，则确定第一决策结果，即指示备站点接管主站点的业务。若否，则确定第二决策结果，则不指示备站点接管主站点的业务。

示例性的，故障策略可以包括故障实例的数量阈值，因此在该服务的工作状态为故障的实例的数量大于该数量阈值时，可以确定满足故障策略，反之，则可以确定不满足故障策略。例如，故障策略为故障实例数量阈值为4，因此可以在确定该服务的工作状态为故障的实例的数量大于4时，确定满足故障策略，反之，则确定不满足故障策略。

或者，故障策略也可以包括故障实例占的比重阈值，因此在该服务的工作状态为故障的实例占该服务的所有实例的比重大于该比重阈值时，可以确定满足故障策略，反之，则可以确定不满足故障策略。例如，故障策略为工作状态为故障的实例超过一半，因此可以在确定该服务的工作状态为故障的实例占该服务的所有实例的比重大于50％时，可以确定满足故障策略，反之，则确定不满足故障策略。又例如，故障策略为实例全部故障，因此可以在确定该服务的实例全部故障时，可以确定满足故障策略，反之，则确定不满足故障策略。

其中，若故障策略配置文件包括针对所有服务制定的故障策略，则确定该服务的所有实例中工作状态为故障的实例的数量是否满足该故障策略。若故障策略配置文件包括针对多个服务分别制定的故障策略，则确定该服务的所有实例中工作状态为故障的实例的数量是否满足针对该服务制定的故障策略。

主站点还可以还包括第二容灾服务模块，所述第二容灾服务模块部署主站点中的任一虚拟机。所述第二容灾服务模块，用于在所述第一容灾服务模块故障时接管所述第一容灾服务模块的业务。在第一容灾服务模块运行时，第二容灾服务模块可以处于停止状态也可以处于运行状态，本申请实施例不做具体限定。

一种实现方式中，所述主站点还可以包括心跳接口，所述心跳接口用于所述主站点与所述备站点之间收发心跳消息。

一种示例性说明中，所述第一容灾服务模块，在向所述备站点发送所述第一决策结果时，可以通过所述心跳接口向所述备站点发送所述第一决策结果。

主站点还可以包括仲裁服务模块，该仲裁服务模块可以部署在主站点的任一虚拟机上，所述仲裁服务模块用于存储决策结果。所述第一容灾服务模块，还用于在确定决策结果之后，将所述决策结果写入所述仲裁服务模块。

备站点以及仲裁站点中也可以包括仲裁服务模块。主站点中的仲裁服务模块、备站点中的仲裁服务模块以及仲裁站点中的仲裁服务模块可以组成一个集群，主站点的仲裁服务模块写入决策结果后可以在该集群内共享决策结果，从而备站点可以通过查询的方式获得所述决策结果。

另一种示例性说明中，所述第一容灾服务模块，在向所述备站点发送所述第一决策结果时，还可以将第一决策结果保存在仲裁服务模块，从而通过仲裁服务向所述备站点发送所述第一决策结果。

其中，主站点中可以包括两个仲裁服务模块，其中，一个仲裁服务模块作为主服务来提供仲裁服务，另一个仲裁服务模块作为备服务，当作为主服务的仲裁服务模块故障后，作为备服务的仲裁服务模块成为主服务来继续仲裁服务。其中，在作为主服务的仲裁服务模块运行时，作为备服务的仲裁服务模块可以为停止状态也可以为运行状态，本申请不做具体限定。

为了更好地理解本申请实施例，以下结合具体应用场景，对第一容灾服务模块进行容灾切换的过程进行具体详细描述。参阅图7所示：

S701，第一容灾服务模块遍历每个服务，确定是否每个服务是否均满足对应的故障策略。若是，执行步骤S702。若否，执行步骤S703。

S702，第一容灾服务模块得到第二决策结果。执行步骤S707。

S703，第一容灾服务模块得到第一决策结果。执行步骤S704。

S704，第一容灾服务模块确定所在站点是否为主站点。若是，执行步骤S705。若否，则结束。

S705，第一容灾服务模块确定与备站点之间的心跳是否正常。若是，执行步骤S706。若否，执行步骤S707。

S706，第一容灾服务模块通过心跳接口向备站点发送第一决策结果，以指示备站点升为主站点。备站点升为主站点后接管原主站点的业务。执行步骤S707。

S707，第一容灾服务模块将第一决策结果写入仲裁服务模块。

另一种实施方式中，图3所示容灾***中的备站点、仲裁站点的结构可以参阅图4所示主站点的结构，这里不再重复赘述。

其中，备站点中的第一容灾服务模块，还可以用于通过备站点的心跳接口收到来自主站点的第一决策结果，并执行接管主站点业务的处理。

备站点的第一容灾服务模块，还可以用于通过仲裁服务获取主站点的决策结果，若获取的决策结果为第一决策结果，则执行接管主站点业务的处理。示例性的，备站点的第一容灾服务模块可以周期性查询备站点中的仲裁服务模块以获取主站点的决策结果。

一种实施方式中，备站点的第一容灾服务模块在通过备站点的心跳接口收到来自主站点的第一决策结果之后，通过仲裁服务获取的决策结果为第一决策结果，则只对第一决策结果进行一次处理。

下面结合如图3所示的容灾***，进一步介绍本申请实施例提供的容灾控制方法。参见图8，为本申请提供的容灾控制方法的方法流程图。该方法可以由图3中主站点、备站点实施，该方法可包括以下步骤：

S801，主站点针对主站点提供的第一服务，确定所述第一服务在所述主站点中的多个虚拟机中的每个实例的工作状态。其中，第一服务可以主站点所提供的任一服务，或者，第一服务也可以为主站点中的关键服务，如数据库、关键业务管理服务等等。

一种实施方式中，主站点确定所述第一服务在所述主站点中的多个虚拟机中的每个实例的工作状态，可以通过步骤C1至C4实现：

C1，针对所述第一服务在所述主站点中的多个虚拟机中的每个实例，主站点确定所述实例的故障开始时间。

一种示例性说明，主站点可以接收并记录所述实例的应用健康情况。若接收的所述实例的应用健康情况为异常，且最近一次记录的所述实例的应用健康情况为正常或者没有所述实例的应用健康情况的记录，确定所述实例的故障开始时间为当前时间。其中，所述实例的应用健康情况可以由第一虚拟机上报的，所述第一虚拟机为所述主站点中部署所述实例的虚拟机。进一步的，第一虚拟机可以周期性上报所述实例的应用健康情况。

另一种示例性说明，主站点若未接收到第一虚拟机上报的所述实例的应用健康情况，可以认为第一虚拟机出现故障，即所述实例出现故障，因此可以确定所述实例的故障开始时间为当前时间。

C2，主站点根据所述故障开始时间确定故障持续时间。示例性的，Δt1＝t1-t2，其中，Δt1为故障持续时间，t1为当前时间，t2为故障开始时间。

C3，若所述故障持续时间大于故障时间阈值，则主站点确定所述实例的工作状态为故障。

C4，若所述故障持续时间小于或等于所述故障时间阈值，则主站点确定所述实例的工作状态为未故障。

另一种实施方式中，主站点确定所述第一服务在所述主站点中的多个虚拟机中的每个实例的工作状态，还可以通过步骤D1至D4实现：

D1，针对所述第一服务在所述主站点中的多个虚拟机中的每个实例，确定最近一次接收所述实例的应用健康情况的时间；

D2，根据所述最近一次接收所述实例的应用健康情况的时间确定中断时间。示例性的，Δt2＝t1-t3，其中，Δt2为故障持续时间，t1为当前时间，t3为最近一次接收所述实例的应用健康情况的时间。

D3，若所述中断时间大于故障时间阈值，则确定所述实例的工作状态为故障。

D4，若所述中断时间小于或等于故障时间阈值，则确定所述实例的工作状态为未故障。

在实施中，可以由所述第一服务在所述主站点中的多个虚拟机中的容灾代理模块向主站点的第一容灾服务模块上报第一服务的每个实例的应用健康情况。然后，第一容灾服务模块可以基于第一服务的每个实例的应用健康情况确定第一服务的每个实例的工作状态。

其中，所述第一服务在所述主站点中的多个虚拟机中的容灾代理模块向主站点的第一容灾服务模块上报第一服务的每个实例的应用健康情况的过程，可以参阅上述步骤A1～A4，这里不再重复赘述。第一容灾服务模块确定第一服务的每个实例的工作状态的过程，可以参阅上述步骤B3，这里不再重复赘述。

S802，当所述主站点中所述第一服务的所有实例中工作状态为故障的实例的数量满足故障策略时，主站点确定第一决策结果，所述第一决策结果为指示备站点接管所述主站点的业务。

或者，若所述主站点中所述第一服务的所有实例中工作状态为故障的实例的数量不满足所述故障策略，则主站点可以确定第二决策结果，所述第二决策结果为不指示所述备站点接管所述主站点的业务。

示例性的，故障策略可以包括故障实例的数量阈值，因此在该服务的工作状态为故障的实例的数量大于该数量阈值时，可以确定满足故障策略，反之，则可以确定不满足故障策略。例如，故障策略为故障实例数量阈值为4，因此可以在确定该服务的工作状态为故障的实例的数量大于4时，确定满足故障策略，反之，则确定不满足故障策略。

或者，故障策略也可以包括故障实例占的比重阈值，因此在该服务的工作状态为故障的实例占该服务的所有实例的比重大于该比重阈值时，可以确定满足故障策略，反之，则可以确定不满足故障策略。例如，故障策略为工作状态为故障的实例超过一半，因此可以在确定该服务的工作状态为故障的实例占该服务的所有实例的比重大于50％时，可以确定满足故障策略，反之，则确定不满足故障策略。又例如，故障策略为实例全部故障，因此可以在确定该服务的实例全部故障时，可以确定满足故障策略，反之，则确定不满足故障策略。

具体的，该故障策略可以为针对第一服务制定的策略，或者，该故障策略也可以为针对所有服务制定的策略，本申请不做具体限定。

在实施中，步骤S802可以由主站点中的第一容灾服务模块执行。其中，第一容灾服务模块确定决策结果的过程，可以参阅上述步骤B4，这里不再重复赘述。

S803，主站点向备站点发送所述第一决策结果。

一种实现方式中，主站点可以直接向备站点发送第一决策结果。示例性的，主站点可以通过与备站点之间的心跳网络向备站点发送第一决策结果。

另一种实现方式中，主站点向备站点发送所述第一决策结果时，可以通过仲裁服务向所述备站点发送所述第一决策结果。实例性的，主站点可以将第一决策结果写入所述主站点的仲裁服务的实例中，其中，所述仲裁服务的实例可以部署在主站点、备站点和仲裁站点中。主站点中仲裁服务的实例、备站点中仲裁服务的实例、仲裁站点中仲裁服务的实例组成了一个集群，因此主站点的仲裁服务的实例写入的第一决策结果可以在该集群内共享。因此，备站点可以通过查询的方式在该集群中获得所述第一决策结果。

在实施中，步骤S803可以由主站点的第一容灾服务模块执行。

S804，备站点在接收到第一决策结果之后接管主站点的业务。备站点可以接管主站点的所有业务。或者，备站点也可以接管主站点的第一服务。本申请不做具体限定。

在实施中，步骤S804可以由备站点的第一容灾服务模块执行。

本申请实施例中主站点可以监控每个实例的工作状态，然后可以根据每个实例的工作状态确实是否将业务切换到备站点，例如，主站点在监测到某服务的实例全部故障时，指示备站点接管该主站点的业务，从而可以由备站点继续为客户提供服务，进而降低客户的经济损失和声誉影响。

为了更好地理解本申请实施例，以下结合图4所示的容灾***，对容灾切换的过程进行具体详细描述。容灾切换的过程参阅图9所示：

S901，主站点的容灾代理模块采集所在虚拟机上各个实例的应用健康情况。

示例性的，容灾代理模块采集所在虚拟机上各个实例的应用健康情况，可以参阅上述步骤A1至A3，这里不再重复赘述。

S902，主站点的容灾代理模块向主站点的第一容灾服务模块上报所采集的应用健康情况。

S903，主站点的第一容灾服务模块解析故障策略配置文件。

S904，主站点的第一容灾服务模块汇总主站点的容灾代理模块上报的应用健康情况，做出决策结果。

示例性的，第一容灾服务模块汇总主站点的容灾代理模块上报的应用健康情况，做出决策结果的过程，可以参阅上述步骤B2至B4，这里不再重复赘述。

S905，主站点的第一容灾服务模块将决策结果写入主站点的仲裁服务模块。

S906，若主站点的第一容灾服务模块做出的决策结果为指示备站点接管主站点的业务，且主站点与备站点之间的心跳正常，则主站点的第一容灾服务模块调用主站点的心跳接口通过主站点与备站点之间的心跳网络发送该决策结果。

S907，备站点的第一容灾服务模块接收到指示备站点接管主站点的业务的决策结果后，执行接管主站点业务的操作。

S908，备站点的第一容灾服务模块定时在备站点的仲裁服务模块中查询主站点的决策结果。

S909，若在备站点的仲裁服务模块中查询到的决策结果为指示备站点接管主站点的业务，则备站点的第一容灾服务模块执行接管主站点业务的操作。

一种实现方式中，若在步骤S909之前，备站点的第一容灾服务模块接收到来自主站点的指示备站点接管主站点业务的决策结果，则备站点的第一容灾服务模块在备站点的仲裁服务模块中查询到的决策结果为指示备站点接管主站点的业务时，不再进行重复执行接管主站点业务的操作。

基于与上述实施例相同的发明构思，本发明实施例提供一种主站点100，具体用于实现图8所述的实施例描述的方法。主站点100上运行多个虚拟机，所述多个虚拟机上可以运行第一服务的实例。主站点运行的第一虚拟机上部署工作状态单元101、决策单元102以及发送单元103，其中，所述第一虚拟机可以是所述多个虚拟机中的一个虚拟机，或者，所述第一虚拟机也可以不是所述多个虚拟机中的一个虚拟机。以第一虚拟机不是所述多个虚拟机中的一个虚拟机为例，主站点100的结构可以如图10所示。应理解，图10仅是主站点结构的一种示例性说明，并不对主站点包括的虚拟机的数量、主站点所提供服务的数量及类型、第一虚拟机与所述多个虚拟机的关系等进行具体限定。

其中，所述工作状态单元101用于针对主站点提供的第一服务，确定所述第一服务在所述主站点中的多个虚拟机中的每个实例的工作状态。所述决策单元102用于当所述主站点中所述第一服务在所述多个虚拟机中的所有实例中工作状态为故障的实例的数量满足故障策略时，确定第一决策结果，所述第一决策结果为指示备站点接管所述主站点的业务。所述发送单元103用于向备站点发送所述第一决策结果。

一种实现方式中，所述工作状态单元101，可以具体用于：针对所述第一服务在所述主站点中的多个虚拟机中的每个实例，确定所述实例的故障开始时间；根据所述故障开始时间确定故障持续时间；若所述故障持续时间大于故障时间阈值，则确定所述实例的工作状态为故障；若所述故障持续时间小于或等于所述故障时间阈值，则确定所述实例的工作状态为未故障。

一种示例性说明，所述工作状态单元101，在确定所述实例的故障开始时间时，可以具体用于：接收并记录所述实例的应用健康情况；若接收的所述实例的应用健康情况为异常，且最近一次记录的所述实例的应用健康情况为正常或者没有所述实例的应用健康情况的记录，确定所述实例的故障开始时间为当前时间。

另一种示例性说明，所述工作状态单元101，在确定所述实例的故障开始时间时，还可以具体用于：若未接收到第一虚拟机上报的所述实例的应用健康情况，则确定所述实例的故障开始时间为当前时间，所述第一虚拟机为所述主站点中部署所述实例的虚拟机。

另一种实现方式中，所述工作状态单元101，还可以具体用于：针对所述第一服务在所述主站点中的多个虚拟机中的每个实例，确定最近一次接收所述实例的应用健康情况的时间；根据最近一次接收所述实例的应用健康情况的时间确定中断时间；若所述中断时间大于故障时间阈值，则确定所述实例的工作状态为故障；若所述中断时间小于或等于故障时间阈值，则确定所述实例的工作状态为未故障。

所述决策单元102，还可以用于：当所述第一服务的所有实例中工作状态为故障的实例的数量不满足所述故障策略时，确定第二决策结果，所述第二决策结果为不指示所述备站点接管所述主站点的业务。

一种可能的实施中，所述发送单元103，可以具体用于：通过仲裁服务向所述备站点发送所述第一决策结果。

主站点100可以是与图3或图4对应的实施例中的主站点，用于执行与图5-图9对应的实施例中的主站点所执行的操作。主站点100中的工作状态单元101、决策单元102以及发送单元103可以是图4所示的第一容灾服务模块中的软件单元。

本申请实施例中对模块的划分是示意性的，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，另外，在本申请各个实施例中的各功能模块可以集成在一个处理器中，也可以是单独物理存在，也可以两个或两个以上模块集成在一个模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。

其中，集成的模块既可以采用硬件的形式实现时，如图11所示，主站点可以包括处理器802。处理器802上可以运行多个虚拟机。上述模块对应的实体的硬件可以为处理器802。处理器802，可以是一个中央处理模块(central processing unit，CPU)，或者为数字处理模块等等。主站点还可以包括通信接口801A、801B，处理器802可以通过通信接口801A与备站点之间收发消息，其中，通信接口801A可以为心跳接口。处理器802可以通过通信接口801B与仲裁站点之间收发消息。该主站点还包括：存储器803，用于存储处理器802执行的程序。存储器803可以是非易失性存储器，比如硬盘(hard disk drive，HDD)或固态硬盘(solid-state drive，SSD)等，还可以是易失性存储器(volatile memory)，例如随机存取存储器(random-access memory，RAM)。存储器803是能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质，但不限于此。

处理器802用于执行存储器803存储的程序代码，具体用于执行容灾代理模块以及第一容灾处理模块的相应功能。

本申请实施例中不限定上述通信接口801A、通信接口801B、处理器802以及存储器803之间的具体连接介质。本申请实施例在图11中以存储器803、处理器802以及通信接口801A、通信接口801B之间通过总线804连接，总线在图11中以粗线表示，其它部件之间的连接方式，仅是进行示意性说明，并不引以为限。所述总线可以分为地址总线、数据总线、控制总线等。为便于表示，图11中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。

图11所示的主站点可以是与图3或图4对应的实施例中的主站点。主站点中的处理器802执行存储器803中的计算机可读指令，可以使主站点执行与图5-图9对应的实施例中的主站点所执行的操作。存储器803中存储有基于Linux、Unix或者Windows的操作***，以及用于在所述操作***上生成虚拟机的虚拟机软件指令。基于所述操作***，处理器802执行所述虚拟机软件指令，可以在图11所示的主站点上得到如图4或图10所示的包括多台虚拟机主站点。

本发明实施例还提供了一种计算机可读存储介质，用于存储为执行上述处理器所需执行的计算机软件指令，其包含用于执行上述处理器所需执行的程序。

上述实施例，可以全部或部分地通过软件、硬件、固件或其他任意组合来实现。当使用软件实现时，上述实施例可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令。在计算机上加载或执行所述计算机程序指令时，全部或部分地产生按照本申请实施例所述的流程或功能。所述计算机可以为通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集合的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质(例如，软盘、硬盘、磁带)、光介质(例如，DVD)、或者半导体介质。半导体介质可以是固态硬盘(solid state drive，SSD)。

本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的***、装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

在本申请所提供的几个实施例中，应该理解到，所揭露的***、装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个***，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

Claims (9)

1.一种容灾控制方法，其特征在于，所述方法包括：

针对主站点提供的第一服务，确定所述第一服务在所述主站点中的多个虚拟机中的每个实例的工作状态；

当所述主站点中所述第一服务在所述多个虚拟机中的所有实例中工作状态为故障的实例的数量满足故障策略时，确定第一决策结果，所述第一决策结果为指示备站点接管所述主站点的业务；

向备站点发送所述第一决策结果；

其中，确定所述第一服务在所述主站点中的多个虚拟机中的每个实例的工作状态，包括：

针对所述第一服务在所述主站点中的多个虚拟机中的每个实例，确定最近一次接收所述实例的应用健康情况的时间；

根据所述最近一次接收所述实例的应用健康情况的时间确定中断时间；

若所述中断时间大于故障时间阈值，则确定所述实例的工作状态为故障；

若所述中断时间小于或等于故障时间阈值，则确定所述实例的工作状态为未故障。

2.如权利要求1所述的方法，其特征在于，在确定所述第一服务在所述主站点中的多个虚拟机中的每个实例的工作状态之后，所述方法还包括：

若所述主站点中所述第一服务的所有实例中工作状态为故障的实例的数量不满足所述故障策略，则确定第二决策结果，所述第二决策结果为不指示所述备站点接管所述主站点的业务。

3.如权利要求1所述的方法，其特征在于，所述向备站点发送所述第一决策结果，包括：

通过仲裁服务向所述备站点发送所述第一决策结果。

4.一种主站点，其特征在于，包括：多个虚拟机和部署于第一虚拟机中的工作状态单元、决策单元和发送单元，其中

所述工作状态单元用于针对主站点提供的第一服务，确定所述第一服务在所述主站点中的多个虚拟机中的每个实例的工作状态；

所述决策单元用于当所述主站点中所述第一服务在所述多个虚拟机中的所有实例中工作状态为故障的实例的数量满足故障策略时，确定第一决策结果，所述第一决策结果为指示备站点接管所述主站点的业务；

所述发送单元用于向备站点发送所述第一决策结果；

其中，所述工作状态单元，具体用于：

针对所述第一服务在所述主站点中的多个虚拟机中的每个实例，确定最近一次接收所述实例的应用健康情况的时间；

根据最近一次接收所述实例的应用健康情况的时间确定中断时间；

若所述中断时间大于故障时间阈值，则确定所述实例的工作状态为故障；

若所述中断时间小于或等于故障时间阈值，则确定所述实例的工作状态为未故障。

5.如权利要求4所述的主站点，其特征在于，所述决策单元，还用于：

当所述第一服务的所有实例中工作状态为故障的实例的数量不满足所述故障策略时，确定第二决策结果，所述第二决策结果为不指示所述备站点接管所述主站点的业务。

6.如权利要求4所述的主站点，其特征在于，所述发送单元，具体用于：

通过仲裁服务向所述备站点发送所述第一决策结果。

7.如权利要求4所述的主站点，其特征在于，所述第一虚拟机是所述多个虚拟机中的一个虚拟机，或者，所述第一虚拟机不是所述多个虚拟机中的一个虚拟机。

8.一种容灾***，其特征在于，包括如权利要求4至7任一项所述的主站点，以及备站点。

9.如权利要求8所述的容灾***，其特征在于，还包括仲裁站点；

其中，所述仲裁站点用于为所述主站点以及所述备站点提供仲裁服务。