故障检测方法、评估装置、系统、设备及计算机存储介质

技术领域

本申请实施例涉及但不限于电子与信息技术领域，尤其涉及一种故障检测方法、评估装置、系统、设备及计算机存储介质。

背景技术

在云计算基础设施即服务(Infrastructure-as-a-Service，IaaS)中，为了业务持续稳定，保证底层服务不被中断，通常云计算服务商需要提供高可用服务，将软硬件故障或人为因素等原因导致的业务中断降至最低。然而，如何准确地确定云计算中目标节点是否故障，是本领域一直以来关注的问题。

发明内容

本申请实施例提供一种故障检测方法、评估装置、系统、设备及计算机存储介质。

第一方面，本申请实施例提供一种故障检测方法，应用于评估装置，包括：

接收负载均衡装置发送的至少一个检测装置的标识；所述检测装置用于检测对应的目标节点的故障状态；其中，不同的评估装置接收的检测装置的标识不重叠；

基于所述至少一个检测装置的标识，向至少一个检测装置中的每一检测装置发送状态请求信息；所述状态请求信息用于请求所述检测装置对应的所述目标节点是否故障的状态信息；

在接收到所述每一检测装置发送的状态信息的情况下，确定所述每一检测装置对应的目标节点是否故障。

在一些实施例中，所述在接收到所述每一检测装置发送的状态信息的情况下，确定所述每一检测装置对应的目标节点是否故障，包括：

在接收到所述至少一个检测装置中目标检测装置发送的状态信息，指示所述目标检测装置对应的目标节点故障的情况下，确定所述目标检测装置对应的目标节点故障。

在一些实施例中，所述基于所述至少一个检测装置的标识，向至少一个检测装置中的每一检测装置发送状态请求信息，包括：

基于所述至少一个检测装置的标识，每隔设定时长向所述每一检测装置发送所述状态请求信息。

在一些实施例中，所述在接收到所述至少一个检测装置中目标检测装置发送的状态信息，指示所述目标检测装置对应的目标节点故障的情况下，确定所述目标检测装置对应的目标节点故障，包括：

在接收到所述目标检测装置连续至少两次发送的状态信息，均指示所述目标检测装置对应的目标节点故障的情况下，确定所述目标检测装置对应的目标节点故障。

在一些实施例中，所述确定所述目标检测装置对应的目标节点故障之后，所述方法还包括：

输出指示所述目标检测装置对应的目标节点故障的告警信息。

在一些实施例中，所述输出指示所述目标检测装置对应的目标节点故障的告警信息，包括：

在确定所述目标检测装置发送的状态信息包括的故障类型信息，为不可通过服务引擎恢复的故障类型信息的情况下，输出指示所述目标检测装置对应的目标节点故障的所述告警信息。

在一些实施例中，所述确定所述目标检测装置对应的目标节点故障之后，所述方法还包括：

在确定所述目标检测装置发送的状态信息包括的故障类型信息，为可通过服务引擎恢复的故障类型信息的情况下，向所述服务引擎发送故障恢复请求；所述故障恢复请求用于请求所述服务引擎对所述目标检测装置对应的目标节点进行故障恢复。

在一些实施例中，所述方法还包括：

在没有接收到所述至少一个检测装置中特定检测装置发送的状态信息，且检测到所述特定检测装置对应的目标节点掉电的情况下，向控制节点发送指示信息；所述指示信息指示所述控制节点将所述特定检测装置对应的目标节点中的虚拟机转移到未掉电的目标节点中。

在一些实施例中，所述方法还包括：

在没有接收到所述至少一个检测装置中特定检测装置发送的状态信息，且检测到所述特定检测装置对应的目标节点没有掉电的情况下，确定所述特定检测装置对应的目标节点故障。

在一些实施例中，所述确定所述特定检测装置对应的目标节点故障，包括：

输出指示所述特定检测装置对应的目标节点故障的告警信息。

在一些实施例中，所述方法还包括：

接收所述负载均衡装置发送的一个或多个检测装置的标识；所述一个或多个检测装置的标识与所述至少一个检测装置的标识不同；

基于所述一个或多个检测装置的标识，向所述一个或多个检测装置中的每个检测装置发送状态请求信息；

在接收到所述每个检测装置发送的状态信息的情况下，确定所述每个检测装置对应的目标节点是否故障；

其中，所述一个或多个检测装置的标识是所述负载均衡装置，在确定故障检测系统中存在M个检测装置增加、M个检测装置减少、N个评估装置增加、N个评估装置减少的至少之一的情况下，向所述N个评估装置分别发送的；M和N均为大于或等于1的整数。

第二方面，本申请实施例提供一种评估装置，包括：

接收单元，用于接收负载均衡装置发送的至少一个检测装置的标识；所述检测装置用于检测对应的目标节点的故障状态；其中，不同的评估装置接收的检测装置的标识不重叠；

发送单元，用于基于所述至少一个检测装置的标识，向至少一个检测装置中的每一检测装置发送状态请求信息；所述状态请求信息用于请求所述检测装置对应的所述目标节点是否故障的状态信息；

确定单元，用于在接收到所述每一检测装置发送的状态信息的情况下，确定所述每一检测装置对应的目标节点是否故障。

第三方面，本申请实施例提供一种故障检测系统，包括：负载均衡装置、N个评估装置以及M个检测节点；每一所述节点包括目标节点和用于检测得到对应的目标节点是否故障的状态信息的检测装置；M和N均为大于或等于1的整数；

所述负载均衡装置用于基于M个检测装置的标识，向所述N个评估装置中的每个评估装置发送至少一个检测装置的标识；其中，向不同的评估装置发送的检测装置的标识不重叠；

所述每个评估装置，用于基于所述至少一个检测装置的标识，向至少一个检测装置中的每一检测装置发送状态请求信息；在接收到所述每一检测装置发送的状态信息的情况下，确定所述每一检测装置对应的目标节点是否故障。

在一些实施例中，所述负载均衡装置，还用于以下至少之一：

在确定向所述M个检测节点增加检测节点和/或删除所述M个检测节点中的检测节点，得到P个检测节点的情况下，基于P个检测装置的标识，向所述N个评估装置中的每个评估装置发送至少一个检测装置的标识；

在确定向所述N个评估装置增加评估装置和/或删除所述N个评估装置中的评估装置，得到Q个评估装置的情况下，基于所述M个检测装置的标识，向所述Q个评估装置中的每个评估装置发送至少一个检测装置的标识。

第四方面，本申请实施例提供一种故障检测设备，包括：存储器和处理器，

所述存储器存储有可在所述处理器上运行的计算机程序，

所述处理器执行所述计算机程序时实现上述方法中的步骤。

第五方面，本申请实施例提供一种计算机存储介质，所述计算机存储介质存储有一个或者多个程序，所述一个或者多个程序可被一个或者多个处理器执行，以实现上述方法中的步骤。

在本申请实施例中，由于基于负载均衡装置发送的至少一个检测装置的标识，向至少一个检测装置中的每一检测装置发送状态请求信息，接收每一检测装置发送的状态信息，而不同的评估装置接收的检测装置的标识不重叠，从而每个评估装置能够确定对应的至少一个目标节点的故障状态，提高了确定系统中目标节点的故障状态的有效性；另外，由于接收到每一检测装置发送的状态信息，从而能够准确地确定与至少一个检测装置一一对应的目标节点是否故障。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。

图1为本申请实施例提供的一种故障检测方法的实现流程示意图；

图2为本申请实施例提供的另一种故障检测方法的实现流程示意图；

图3为本申请实施例提供的又一种故障检测方法的实现流程示意图；

图4为本申请实施例提供的再一种故障检测方法的实现流程示意图；

图5为本申请另一实施例提供的一种故障检测方法的实现流程示意图；

图6为本申请实施例提供的一种评估装置的组成结构示意图；

图7为本申请实施例提供的一种故障检测系统的架构示意图；

图8为本申请实施例提供的另一种故障检测系统的架构示意图；

图9为本申请实施例提供的一种评估装置的工作流程示意图；

图10为本申请实施例提供的一种故障检测设备的硬件实体示意图。

具体实施方式

下面将通过实施例并结合附图具体地对本申请的技术方案进行详细说明。下面这几个具体的实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例中不再赘述。

需要说明的是：在本申请实例中，“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。

另外，本申请实施例所记载的技术方案之间，在不冲突的情况下，可以任意组合。在本申请的描述中，“多个”的含义是两个或两个以上，除非另有明确具体的限定。

Masakari是OpenStack开源社区的一个子项目，主要用于为OpenStack集群提供虚拟机高可用服务，其支持从故障事件中恢复基于内核的虚拟机(Kernel-based VirtualMachine，KVM)，实现故障自愈。Masakari具有应用程序接口(Application ProgrammingInterface，API)、Engine两个控制点服务及多个部署于计算节点的检测(monitor)服务，包括实例检测(instance-monitor)、进程检测(process-monitor)、节点检测(host-monitor)，实例检测、进程检测以及节点检测分别从虚拟机自身进程故障、nova-compute服务故障、计算节点物理机故障3个维度，支持虚拟机的高可用(High Availability，HA)功能。其中，pacemaker-remote使用Pacemaker/Corosync实现心跳检测机制和集群控制。本申请实施例中检测也可以理解为监控。

通过控制节点中的pacemaker，实时地向各计算节点中的pacemaker-remote发送虚拟机是否正常运行信息，如果规定的时间内，控制节点中的pacemaker收到计算节点中pacemaker-remote的反馈信息，表示此计算节点中虚拟机在正常运行，如果规定的时间内，控制节点中的pacemaker没有收到计算节点中pacemaker-remote的反馈信息，表示此计算节点中虚拟机出现了故障。

除了通过上述的控制节点中的pacemaker来监控各计算节点中的pacemaker-remote来判断各计算节点中虚拟机是否正常运行之外，控制节点中的pacemaker还可以通过监控各计算节点中的nova-compute、neurton-ovs-agent以及libvirt等进程，甚至可以通过在各计算节点上启动虚拟机来，进而得到各计算节点中虚拟机是否正常运行。

在确定发生故障事件后，monitor通过发送通知(notification)消息通知API，Masakari通过API服务监听来自monitor的notification请求，并通过消息队列通知Engine服务进行对应的故障恢复。

然而，相关技术中Masakari架构中，Pacemaker心跳检测机制依赖Pacemaker和Corosync，在节点数量较少的情况下，Pacemaker/Corosync框架可以用于进行心跳检测；而在大规模集群中，由于节点数量较多，Pacemaker/Corosync框架的可能存在以下几个问题：

性能降低：pacemaker remote进行集群加入节点/删除节点等操作响应过慢。

负载升高：通过监控系统发现，节点的管理网络带宽、中央处理器(CentralProcessing Unit，CPU)负载均明显升高，可能会影响节点上虚拟机业务和Nova等底层服务。

稳定性差：判断准确性明显下降，多次出现误判，反复出现大批量节点心跳失联的情况，而这些节点实际上没有问题。

另外，当故障事件发生后，monitor通过调用API通知Engine进行处理，这种处理方式过于单一和片面，无法满足实际生产环境的需求，例如：

当节点只是管理网络存在波动的情况，业务网络及存储网络均正常，不影响虚拟机业务的使用，这种情况下的节点心跳失联并无必要进行疏散。进行疏散的一种实施方式可以是通过控制节点将点心跳失联的节点中的虚拟机转移到未掉电的节点中。以及，缺乏连续故障检测机制，一般仅当连续检测到节点故障时才会触发节点故障后的虚拟机高可用事件，host-monitor缺乏这种机制。

本申请实施例提供一种故障检测方法、评估装置、系统、设备及计算机存储介质，可以用来解决上述至少之一的问题。

本申请实施例中的故障检测方法可以应用于评估装置，评估装置可以是服务器、评估平台等设备，或者，评估装置可以是处理器或芯片。

图1为本申请实施例提供的一种故障检测方法的实现流程示意图，如图1所示，该方法应用于评估装置，该方法包括：

S101、接收负载均衡装置发送的至少一个检测装置的标识；所述检测装置用于检测对应的目标节点的故障状态；其中，不同的评估装置接收的检测装置的标识不重叠。

系统中可以包括负载均衡装置、M个评估装置以及N个目标节点。M和N均为大于或等于1的整数，N一般大于或等于M。在一些实施例中，M和N可以均为大于或等于2的整数。例如，M可以为2、3、4、5等等，N可以为2、3、4、5、6等等。N个目标节点可以一一对应N个检测装置。

负载均衡装置可以得到N个检测装置的标识，并通过一致性哈希(hash)算法向M个评估装置分配这N个检测装置的标识，从而使得每一个评估装置均可以负责负载均衡装置分配的至少一个检测装置。

在一些实施例中，评估装置可以接收负载均衡装置发送的至少一个目标节点的标识，评估装置可以确定与至少一个目标节点的标识一一对应的至少一个检测装置的标识。

接收负载均衡装置发送的至少一个检测装置的标识可以包括：接收负载均衡装置通过一致性哈希算法发送的至少一个检测装置的标识。

检测装置的标识可以为检测装置的API标识。检测装置可以包括以下至少之一的检测模块：实例检测模块、进程检测模块、节点检测模块等。其中，实例检测模块用于提供实例检测服务、进程检测模块用于提供进程检测服务、节点检测模块用于提供节点检测服务。实例检测模块、进程检测模块、节点检测模块中的任一个检测模块在检测到故障的情况下，生成指示故障的状态信息，故障信息还可以包括故障类型，将状态信息存放在检测装置的API接口，以使评估装置从测装置的API接口读取。

在一些实施例中，检测装置可以每隔设定时长检测一次目标节点是否故障。例如，实例检测模块可以每隔设定时长检测一次虚拟机自身进程故障；进程检测模块可以每隔设定时长检测一次nova-compute服务故障；节点检测模块可以每隔设定时长检测一次计算节点物理机故障，在这种方式下，检测装置提前检测到目标节点的状态信息，从而能够使得评估装置快速地得到检测装置检测的状态信息。在另一些实施例中，检测装置可以在接收到评估装置发送的状态请求信息的情况下，检测一次目标节点是否故障。

目标节点可以是以下至少之一：计算节点(Compute Node)、服务节点、控制节点、存储节点。在一些实施例中，系统中的N个目标节点均可以为计算节点。在另一些实施例中，系统中的N个目标节点均可以是上述列举的其它某个节点，或者系统中的N个目标节点包括上述列举的至少两个节点。

系统可以是分布式系统。在一些实施例中，系统可以为OpenStack系统。在一些实施例中，系统可以为OpenStack系统下的高可用组件Masakari。

针对某一个检测装置来说，在检测装置进行一次检测，确定对应的目标节点发生故障的情况下，可以生成指示目标节点故障的状态信息，这样，状态信息可以包括故障类型信息；在检测装置进行一次检测，确定对应的目标节点未发生故障的情况下，可以生就指示目标节点未故障(或正常)的状态信息。

S102、基于所述至少一个检测装置的标识，向至少一个检测装置中的每一检测装置发送状态请求信息；所述状态请求信息用于请求所述检测装置对应的所述目标节点是否故障的状态信息。

针对一个评估装置，在该评估装置接收到负载均衡装置发送的检测装置的标识分别为检测装置1、检测装置3和检测装置4的情况下，向检测装置1、检测装置3和检测装置4中的每个检测装置发送状态请求信息。

在系统中，由于不同的评估装置接收的检测装置的标识不重叠，从而不同的评估装置负责各自对应的检测装置，从而能够使得服务之间负载均衡。

S103、在接收到所述每一检测装置发送的状态信息的情况下，确定所述每一检测装置对应的目标节点是否故障。

针对一个评估装置，该评估装置可以接收到检测装置1、检测装置3和检测装置4分别发送的状态信息，从而基于检测装置1、检测装置3和检测装置4中的每个检测装置发送的状态信息，确定每个检测装置对应的目标节点是否故障。

在一些实施例中，S104可以包括：在接收到所述至少一个检测装置中目标检测装置发送的状态信息，指示所述目标检测装置对应的目标节点故障的情况下，确定所述目标检测装置对应的目标节点故障。

这样，每个评估装置都可以得到负载均衡装置向其分配的检测装置对应的目标节点是否故障的状态信息，从而在某个目标节点的发生故障的情况下，与该目标节点对应的评估装置就可以检测到该目标节点故障，从而通过系统中的M个评估装置，可以实现对系统中的N个目标节点的故障状态进行不断的检测，从而能够及时得到每个目标节点的状态信息，进而能够及时的针对故障的目标节点作出相应的响应，以提高系统的高可用。

在本申请实施例中，由于基于负载均衡装置发送的至少一个检测装置的标识，向至少一个检测装置中的每一检测装置发送状态请求信息，接收每一检测装置发送的状态信息，而不同的评估装置接收的检测装置的标识不重叠，从而每个评估装置能够确定对应的至少一个目标节点的故障状态，提高了确定系统中目标节点的故障状态的有效性；另外，由于接收到每一检测装置发送的状态信息，从而能够准确地确定与至少一个检测装置一一对应的目标节点是否故障。

图2为本申请实施例提供的另一种故障检测方法的实现流程示意图，如图2所示，该方法应用于评估装置，该方法包括：

S201、接收负载均衡装置发送的至少一个检测装置的标识；所述检测装置用于检测对应的目标节点的故障状态；其中，不同的评估装置接收的检测装置的标识不重叠。

S202、基于所述至少一个检测装置的标识，每隔设定时长向所述每一检测装置发送所述状态请求信息。

在一些实施例中，设定时长可以是用户通过系统接口(例如Masakari API)配置的时长。在另一些实施例中，设定时长可以是系统自适应调整的时长，或者是系统通过系统运行的相关参数确定的时长。

在一些实施例中，设定时长可以是不变的时长。在另一些实施例中，设定时长是可以变化的时长。在系统的业务繁忙程度较高的情况下，对系统的高可用性的要求就越高，则可以将设定时长设置的较短，相反地，在系统的业务繁忙程度较低的情况下，则可以将设定时长设置的较长。再例如，当系统运行在预定时间范围之内的情况下，可以将设定时长设置的较短，在系统运行在预定时间范围之外的情况下，可以将设定时长设置的较长；预定时长范围例如可以是一天中的8：00至24：00或是其它范围，本申请实施例对此不作限定。

在一些实施例中，设定时长可以是评估装置确定的。在另一些实施例中，设定时长可以是系统的控制节点确定的，系统的控制节点可以将确定的设定时长发送至评估装置。

在一些实施例中，每个检测装置也可以每隔设定时长检测一次对应目标节点的故障状态。例如，每个检测装置可以接收系统的控制节点发送的设定时长，或者，每个检测装置可以预先配置有设定时长。在一些实施例中，检测装置对目标节点进行故障检测所对应的周期，可以小于等于评估装置发送状态请求的周期。在另一些实施例中，检测装置对目标节点进行故障检测所对应的周期，可以小于评估装置发送状态请求的周期。通过这种方式，能够使得评估装置每次都能获取到最新的目标节点的状态信息。

不同的评估装置可以采用相同或不同的周期，来发送状态请求信息。

S203、在接收到所述至少一个检测装置中目标检测装置发送的状态信息，指示所述目标检测装置对应的目标节点故障的情况下，确定所述目标检测装置对应的目标节点故障。

评估装置可以每次向至少一个检测装置发送状态请求信息的情况下，都可以接收每个检测装置发送的状态信息，从而基于状态信息确定每一目标节点是否故障。

评估装置在每次向检测装置发送状态请求信息之后，可以确定是否能在预设时长内接收到状态信息，如果在预设时长内检测到状态信息，则确定接收到检测装置发送的状态信息，如果在预设时长内没有检测到状态信息，则确定没有接收到检测装置发送的状态信息。

举例而言，在第一时刻，评估装置分别向检测装置1、检测装置3和检测装置4发送状态请求信息，然后评估装置在预设时长内均接收到检测装置1、检测装置3和检测装置4发送的状态信息，且这三个状态信息均指示对应的目标节点正常，则继续下一轮的检测，即在第二时刻评估装置分别向检测装置1、检测装置3和检测装置4发送状态请求信息，然后评估装置在预设时长内均接收到检测装置1、检测装置3和检测装置4发送的状态信息，且检测装置1、检测装置3发送的状态信息指示对应的目标节点正常，检测装置4发送的状态信息指示对应的目标节点故障，则可以确定检测装置4对应的目标节点故障。

在一些实施例中，S203可以包括：在接收到所述目标检测装置连续至少两次发送的状态信息，均指示所述目标检测装置对应的目标节点故障的情况下，确定所述目标检测装置对应的目标节点故障。

例如，在评估装置连续至少两次(例如，两次、三次、四次或五次等)接收到检测装置4发送的状态信息，均指示检测装置4对应的目标节点故障的情况下，才确定检测装置4对应的目标节点故障。

在一些实施例中，还可以执行S204的步骤。

S204、输出指示所述目标检测装置对应的目标节点故障的告警信息。

在一些实施例中，评估装置在确定到目标检测装置对应的目标节点故障的情况下，就输出告警信息，无论目标检测装置发送的状态信息中包括的故障类型信息，是否为可通过服务引擎恢复的故障类型信息。

在另一些实施例中，评估装置可以在目标检测装置发送的状态信息中包括的故障类型信息，为可通过服务引擎恢复的故障类型信息的情况下，不输出告警信息。而在在目标检测装置发送的状态信息中包括的故障类型信息，为不可通过服务引擎恢复的故障类型信息的情况下，输出告警信息。

例如，在确定所述目标检测装置发送的状态信息包括的故障类型信息，为不可通过服务引擎恢复的故障类型信息的情况下，输出指示所述目标检测装置对应的目标节点故障的所述告警信息。

通过这种方式，在故障类型信息为可通过服务引擎恢复的故障类型信息的情况下，评估装置可以调用服务引擎进行故障恢复，不会对用户进行打扰。而在故障类型信息为不可通过服务引擎恢复的故障类型信息的情况下，评估装置无法通过调用服务引擎进行故障恢复，从而可以发出告警信息，以使相关人员(例如运维人员)看到告警信息的时候可以基于故障类型信息，对目标检测装置对应的目标节点进行检查。

在有一些实施例中，评估装置可以在目标检测装置发送的状态信息中包括的故障类型信息，为可通过服务引擎恢复的故障类型信息的情况下，输出第一告警信息。而在目标检测装置发送的状态信息中包括的故障类型信息，为不可通过服务引擎恢复的故障类型信息的情况下，输出第二告警信息。

第一告警信息和第二告警信息是不同的告警信息。第一告警信息可以指示该故障系统可以自行恢复，系统正在尝试进行恢复的信息，或者，第一告警信息可以指示该故障系统可以自行恢复，并提供是否对该故障进行恢复的选项信息，在用户选择是的情况下，评估装置可以调用服务引擎进行故障恢复。第二告警信息可以指示该故障系统不可以自行恢复。第二告警信息还可以指示用户如何检查目标检测装置对应的目标节点，以便于相关人员容易的确认故障和恢复故障。

评估装置在目标检测装置发送的状态信息中包括的故障类型信息，为可通过服务引擎恢复的故障类型信息的情况下，输出告警信息后，如果评估装置调用服务引擎对所述目标检测装置对应的目标节点进行故障恢复，在服务引擎对该故障恢复完成后，评估装置可以通过接收目标检测装置发送的状态信息，确定目标检测装置对应的目标节点正常，则可以输出故障恢复完成的信息，或者，停止输出告警信息。

输出告警信息可以包括以下至少之一：向Masakari API发送告警信息，以使Masakari API向显示设备发送告警信息，显示设备可以是管理平台；和/或，以使MasakariAPI向相关人员的终端发送告警信息。

图3为本申请实施例提供的又一种故障检测方法的实现流程示意图，如图3所示，该方法应用于评估装置，该方法包括：

S301、接收负载均衡装置发送的至少一个检测装置的标识；所述检测装置用于检测对应的目标节点的故障状态；其中，不同的评估装置接收的检测装置的标识不重叠。

S302、基于所述至少一个检测装置的标识，向至少一个检测装置中的每一检测装置发送状态请求信息；所述状态请求信息用于请求所述检测装置对应的所述目标节点是否故障的状态信息。

S303、在接收到所述至少一个检测装置中目标检测装置发送的状态信息，指示所述目标检测装置对应的目标节点故障的情况下，确定所述目标检测装置对应的目标节点故障。

S304、在确定所述目标检测装置发送的状态信息包括的故障类型信息，为可通过服务引擎恢复的故障类型信息的情况下，向所述服务引擎发送故障恢复请求；所述故障恢复请求用于请求所述服务引擎对所述目标检测装置对应的目标节点进行故障恢复。

可通过服务引擎恢复的故障类型信息，例如可以是虚拟机故障和/或进程故障等。

故障恢复请求可以包括：目标检测装置对应的目标节点的标识，故障类型信息。故障恢复请求中还可以包括故障恢复所需要的配置信息。

评估装置可以将故障恢复请求存放在队列中，队列中依序可以存放至少一个故障恢复请求，至少一个故障恢复请求可以是按照故障产生的先后顺序进行排序。系统中可以包括至少一个服务引擎，服务引擎的类型可以相同或不同。至少一个服务引擎中的任一个服务引擎可以在空闲的情况下，从队列中读取最靠前的故障恢复请求，以基于读取到的故障恢复请求，恢复故障恢复请求所对应的目标节点故障。

图4为本申请实施例提供的再一种故障检测方法的实现流程示意图，如图4所示，该方法应用于评估装置，该方法包括：

S401、接收负载均衡装置发送的至少一个检测装置的标识；所述检测装置用于检测对应的目标节点的故障状态；其中，不同的评估装置接收的检测装置的标识不重叠。

S402、基于所述至少一个检测装置的标识，向至少一个检测装置中的每一检测装置发送状态请求信息；所述状态请求信息用于请求所述检测装置对应的所述目标节点是否故障的状态信息。

在S402之后，还可以执行S403、S404、S405中的至少之一：

S403、在接收到所述每一检测装置发送的状态信息的情况下，确定所述每一检测装置对应的目标节点是否故障。

S404、在没有接收到所述至少一个检测装置中特定检测装置发送的状态信息，且检测到所述特定检测装置对应的目标节点掉电的情况下，向控制节点发送指示信息；所述指示信息指示所述控制节点将所述特定检测装置对应的目标节点中的虚拟机转移到未掉电的目标节点中。

S405、在没有接收到所述至少一个检测装置中特定检测装置发送的状态信息，且检测到所述特定检测装置对应的目标节点没有掉电的情况下，确定所述特定检测装置对应的目标节点故障。

在一些实施例中，没有接收到所述至少一个检测装置中特定检测装置发送的状态信息，可以包括：存在一次没有接收到所述至少一个检测装置中特定检测装置发送的状态信息，或者，可以包括：存在连续至少两次没有接收到所述至少一个检测装置中特定检测装置发送的状态信息。相应地，检测所述特定检测装置对应的目标节点是否掉电，可以是在存在一次没有接收到特定检测装置发送的状态信息的情况下执行的，或者可以是在存在连续至少两次没有接收到特定检测装置发送的状态信息的情况下执行的。

在一些实施例中，S403、S404或者S405之后，还可以执行S406。

S406、输出指示所述特定检测装置对应的目标节点故障的告警信息。

图5为本申请另一实施例提供的一种故障检测方法的实现流程示意图，如图5所示，该方法应用于评估装置，该方法包括：

S501、接收负载均衡装置发送的至少一个检测装置的标识；所述检测装置用于检测对应的目标节点的故障状态；其中，不同的评估装置接收的检测装置的标识不重叠。

S502、基于所述至少一个检测装置的标识，向至少一个检测装置中的每一检测装置发送状态请求信息；所述状态请求信息用于请求所述检测装置对应的所述目标节点是否故障的状态信息。

S503、在接收到所述每一检测装置发送的状态信息的情况下，确定所述每一检测装置对应的目标节点是否故障。

S504、接收所述负载均衡装置发送的一个或多个检测装置的标识；所述一个或多个检测装置的标识与所述至少一个检测装置的标识不同。

其中，所述一个或多个检测装置的标识是所述负载均衡装置，在确定故障检测系统中存在M个检测装置增加、M个检测装置减少、N个评估装置增加、N个评估装置减少的至少之一的情况下，向所述N个评估装置分别发送的；M和N均为大于或等于1的整数。

在一些实施例中，用户可以通过Masakari API来配置检测装置的增减和/或配置评估装置的增减。Masakari API可以向负载均衡装置发送增减的检测装置的标识和/或增减的评估装置的标识，以使负载均衡装置可以得到系统当前的检测装置的标识和评估装置的标识，以采用一致性哈希算法重新向每个评估装置分配至少一个检测装置。

例如，在S504之前，某一个或多个评估装置获取到的至少一个检测装置的标识可以包括：检测装置1、检测装置3和检测装置4。在S504中，某一个或多个评估装置获取到的一个或多个检测装置的标识可以包括：检测装置2和检测装置3。

S505、基于所述一个或多个检测装置的标识，向所述一个或多个检测装置中的每个检测装置发送状态请求信息。

例如，某一个或多个评估装置可以向检测装置2和检测装置3，分别发送状态请求信息。

S506、在接收到所述每个检测装置发送的状态信息的情况下，确定所述每个检测装置对应的目标节点是否故障。

例如，某一个评估装置可以在接收到检测装置2和检测装置3分别发送的状态信息的情况下，确定检测装置2和检测装置3分别对应的目标节点是否故障。

基于前述的实施例，本申请实施例提供一种评估装置，该装置包括所包括的各单元、以及各单元所包括的各模块，可以通过评估装置中的处理器来实现；当然也可通过具体的逻辑电路实现。

图6为本申请实施例提供的一种评估装置的组成结构示意图，如图6所示，评估装置600包括：

接收单元601，用于接收负载均衡装置发送的至少一个检测装置的标识；所述检测装置用于检测对应的目标节点的故障状态；其中，不同的评估装置接收的检测装置的标识不重叠；

发送单元602，用于基于所述至少一个检测装置的标识，向至少一个检测装置中的每一检测装置发送状态请求信息；所述状态请求信息用于请求所述检测装置对应的所述目标节点是否故障的状态信息；

确定单元603，用于在接收到所述每一检测装置发送的状态信息的情况下，确定所述每一检测装置对应的目标节点是否故障。

在一些实施例中，确定单元603，还用于在接收到所述至少一个检测装置中目标检测装置发送的状态信息，指示所述目标检测装置对应的目标节点故障的情况下，确定所述目标检测装置对应的目标节点故障。

在一些实施例中，发送单元602，还用于基于所述至少一个检测装置的标识，每隔设定时长向所述每一检测装置发送所述状态请求信息。

在一些实施例中，确定单元603，还用于在接收到所述目标检测装置连续至少两次发送的状态信息，均指示所述目标检测装置对应的目标节点故障的情况下，确定所述目标检测装置对应的目标节点故障。

在一些实施例中，发送单元602，还用于输出指示所述目标检测装置对应的目标节点故障的告警信息。

在一些实施例中，发送单元602，还用于在确定所述目标检测装置发送的状态信息包括的故障类型信息，为不可通过服务引擎恢复的故障类型信息的情况下，输出指示所述目标检测装置对应的目标节点故障的所述告警信息。

在一些实施例中，发送单元602，还用于在确定所述目标检测装置发送的状态信息包括的故障类型信息，为可通过服务引擎恢复的故障类型信息的情况下，向所述服务引擎发送故障恢复请求；所述故障恢复请求用于请求所述服务引擎对所述目标检测装置对应的目标节点进行故障恢复。

在一些实施例中，发送单元602，还用于在没有接收到所述至少一个检测装置中特定检测装置发送的状态信息，且检测到所述特定检测装置对应的目标节点掉电的情况下，向控制节点发送指示信息；所述指示信息指示所述控制节点将所述特定检测装置对应的目标节点中的虚拟机转移到未掉电的目标节点中。

在一些实施例中，发送单元602，还用于在没有接收到所述至少一个检测装置中特定检测装置发送的状态信息，且检测到所述特定检测装置对应的目标节点没有掉电的情况下，确定所述特定检测装置对应的目标节点故障。

在一些实施例中，发送单元602，还用于输出指示所述特定检测装置对应的目标节点故障的告警信息。

在一些实施例中，接收单元601，还用于接收所述负载均衡装置发送的一个或多个检测装置的标识；所述一个或多个检测装置的标识与所述至少一个检测装置的标识不同；

发送单元602，还用于基于所述一个或多个检测装置的标识，向所述一个或多个检测装置中的每个检测装置发送状态请求信息；

确定单元603，还用于在接收到所述每个检测装置发送的状态信息的情况下，确定所述每个检测装置对应的目标节点是否故障；

其中，所述一个或多个检测装置的标识是所述负载均衡装置，在确定故障检测系统中存在M个检测装置增加、M个检测装置减少、N个评估装置增加、N个评估装置减少的至少之一的情况下，向所述N个评估装置中的目标评估装置发送的；M和N均为大于或等于1的整数。

图7为本申请实施例提供的一种故障检测系统的架构示意图，如图7所示，故障检测系统700包括：负载均衡装置701、N个评估装置702以及M个检测节点703；M个检测节点703一一对应M个目标节点704。每一所述节点包括目标节点704和用于检测得到对应的目标节点704是否故障的状态信息的检测装置；M和N均为大于或等于1的整数。

所述负载均衡装置701用于基于M个检测装置的标识，向所述N个评估装置702中的每个评估装置702发送至少一个检测装置的标识；其中，向不同的评估装置702发送的检测装置的标识不重叠。

例如，负载均衡装置701在向评估装置A发送了检测装置1的情况下，就不会向系统中除评估装置A之外的其它评估装置702发送检测装置1。

所述每个评估装置702，用于基于所述至少一个检测装置的标识，向至少一个检测装置中的每一检测装置发送状态请求信息；在接收到所述每一检测装置发送的状态信息的情况下，确定所述每一检测装置对应的目标节点704是否故障。

在一些实施例中，所述负载均衡装置701，还用于以下至少之一：

在确定向所述M个检测节点703增加检测节点703和/或删除所述M个检测节点703中的检测节点703，得到P个检测节点703的情况下，基于P个检测装置的标识，向所述N个评估装置702中的每个评估装置702发送至少一个检测装置的标识；

在确定向所述N个评估装置702增加评估装置702和/或删除所述N个评估装置702中的评估装置702，得到Q个评估装置702的情况下，基于所述M个检测装置的标识，向所述Q个评估装置702中的每个评估装置702发送至少一个检测装置的标识。

本申请实施例提供了一种针Masakari高可用故障检测方案，可以包括以下几个内容：

重构了计算节点host-monitor服务，使其成为节点故障检测的代理服务，同时开放RESTful-API接口(对应上述的检测装置的API接口)，返回故障检测结果。

设计了一种全新的心跳检测机制，在控制节点新增Masakari-Evaluator(对应上述的评估装置)高可用评估服务，周期性访问host-monitor的API接口(对应上述的检测装置的API接口)，获取节点当前健康状态(对应上述的状态信息)，采取多重确认的方式，故障判断更为准确。

解决了服务扩展性问题，服务设计采取分而治之的思想，多个Evaluator可通过一致性Hash完成计算节点的分配，每个服务负责一部分计算节点的状态评估。

图8为本申请实施例提供的另一种故障检测系统的架构示意图，如图8所示，故障检测系统800包括：

负载均衡装置801、评估装置802、检测节点803、目标节点804、Masakari API 805、服务引擎806以及控制节点807。

Masakari API 805可以包括在HA代理(proxy)中。

评估装置802可以是Masakari-Evaluator，检测节点803可以是host-monitor或者host-monitor API，目标节点804可以是Compute Node，服务引擎806可以是Masakari-Engine，控制节点807可以是OpenStack-Nova。

host-monitor组件可以为计算节点的故障采集代理服务，能够对计算点存储网、业务网、智能平台管理接口(Intelligent Platform Management Interface，IPMI)网络工作及负载情况进行检测，同时能够监控计算节点的CPU、内存、磁盘状态，并通过API接口输出节点检查结果，等待Evaluator周期性轮询。

Evaluator评估服务负责对整个集群计算点进行健康检查，周期性调用host-monitor的API获取数据，查询节点其他基础信息的情况，同时进行心跳检测(进行心跳检测即Evaluator向host-monitor API发送状态请求信息，以接收host-monitor API发送的状态信息)。若有节点心跳失联，Evaluator还将通过IPMI进行反向检查，探测节点是否掉电，与host-monitor依赖pacemaker实现心跳检测相比，判断更加准确。

在故障检测方面，Evaluator还支持故障多次重复确认机制，对于连续周期内多次发生的故障，将会通过远程过程调用协议(Remote Procedure Call Protocol，RPC)的方式，调用Engine服务执行故障恢复。同时，Evaluator还集成了告警功能，若节点相关指标异常，将会发送告警。

考虑到大规模集群下，单个Evaluator服务可能无法负载全部节点的评估工作，Evaluator借助Tooz一致性哈希环设计了负载均衡器(对应上述的负载均衡装置)，实现了多Evaluator服务之间的负载均衡与高可用。Tooz是OpenStack社区用于分布式协同的开源框架，Evaluator服务之间通过Tooz组成一个群组，每个服务通过负载均衡器进行协同工作，均衡器会给每个Evaluator分配一部分节点，Evaluator服务只负责这部分计算节点的故障评估。每当有Evaluator服务down或者扩展了新的Evaluator服务，均衡器会重新进行分配，保证服务之间负载均衡。

而当集群扩容之后，只需要扩展更多的Evaluator服务即可完成扩容，理论上不存在性能瓶颈，因此可以对超大规模集群进行故障监控，且不会影响服务性能。

Masakari API 805为Masakari控制点服务，可以通过Masakari API 805接口对Masakari集群进行查询、节点加入/退出等操作。

Engine服务以异步的方式高级消息队列协议(Advanced Message QueuingProtocol，AMQP)接收从Masakari API 805收到的请求，并执行各类故障恢复操作。

本申请实施例提出的大规模集群故障监控的高可用系统，重新设计了心跳检测机制，摆脱了对第三方组件Pacemaker的依赖，能够纳管更多的计算节点，提升系统处理上限。除了正向获取心跳数据之外，同时还补充了IPMI探测进行故障确认，检测准确性更高，受网络波动影响更小。作为集群的故障自愈系统，该系统能够有效保障OpenStack虚拟机的HA功能，有效降低运维压力。

为了有效提升Evaluator服务的处理性能，增强系统的横向扩展能力，本申请实施例通过Tooz将多个Evaluator服务组成一个组串联起来，通过一致性哈希负载均衡器协同工作，理论上Evaluator服务可无限扩展，即使是监控大规模OpenStack集群，也丝毫不影响系统的处理性能，实时性和有效性都能够得到保证。

本申请实施例重构host-monitor服务，基于Restful-API重新设计host-monitor，支持通过API获取节点工作状态和系统信息，另外，(2)新增Evaluator评估服务，包括主动式故障发现评估、支持故障重复确认、支持故障告警、支持多节点负载均衡及高可用、以及高可扩展性，支持大规模节点的故障评估。

本申请实施例的效果在于：提出一种能够适用于大规模OpenStack集群的故障检测系统，重新设计了故障检测方案，重构了故障检测代理服务host-monitor，并新增了一个高可扩展的故障评估服务。该系统在丰富了原先Masakari的功能、提高判断的准确性的同时，保证了故障检测、故障自愈及告警的实时性，并且具有横向扩展能力，有效提升了集群自动化运维的效率，降低运维人员的压力。

图9为本申请实施例提供的一种评估装置的工作流程示意图，如图9所示，该方法应用于评估装置，该方法包括：

S901、服务启动。

S902、加入Tooz群组。

S903、通过HashRing(哈希环)获取需要监控的节点列表。

节点列表中包括至少一个检测装置的标识或者目标节点的标识。

S904、调用host-monitor API获取检测指标。

检测指标可以是上述的状态信息。

S905、确定是否获取成功。

在是的情况下，执行S906，在否的情况下，执行S910。

S906、解析检测指标。

S907、确定指标是否异常。

在是的情况下，执行S908，在否的情况下，执行S909。

S908、发送告警信息。

S909、等待下个周期。

在S909之后，可以执行903。

S910、通过IPMI查看目标节点的电源。

S911、确定电源是否正常。

在是的情况下，执行S908，在否的情况下，执行S912。

S912、调用Nova执行疏散。

图10为本申请实施例提供的一种故障检测设备的硬件实体示意图，如图10所示，该故障检测设备1000的硬件实体包括：处理器1001和存储器1002，其中，存储器1002存储有可在处理器1001上运行的计算机程序，处理器1001执行程序时实现上述任一实施例的方法中的步骤。

存储器1002存储有可在处理器上运行的计算机程序，存储器1002配置为存储由处理器1001可执行的指令和应用，还可以缓存待处理器1001以及故障检测设备1000中各模块待处理或已经处理的数据(例如，图像数据、音频数据、语音通信数据和视频通信数据)，可以通过闪存(FLASH)或随机访问存储器(Random Access Memory，RAM)实现。

处理器1001执行程序时实现上述任一项的故障检测方法的步骤。处理器1001通常控制故障检测设备1000的总体操作。

本申请实施例提供一种计算机存储介质，计算机存储介质存储有一个或者多个程序，该一个或者多个程序可被一个或者多个处理器执行，以实现如上任一实施例的故障检测方法的步骤。

以上装置、系统、设备、计算机存储介质实施例的描述，与上述方法实施例的描述是类似的，具有同方法实施例相似的有益效果。对于本申请装置、系统、设备、计算机存储介质实施例中未披露的技术细节，请参照本申请方法实施例的描述而理解。

需要说明的是，本申请实施例中，如果以软件功能模块的形式实现上述的故障检测方法，并作为独立的产品销售或使用时，也可以存储在一个计算机存储介质中。基于这样的理解，本申请实施例的技术方案本质上或者说对相关技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台评估装置执行本申请各个实施例所述方法的全部或部分。

上述评估装置、芯片或处理器可以包括以下任一个或多个的集成：特定用途集成电路(Application Specific Integrated Circuit，ASIC)、数字信号处理器(DigitalSignal Processor，DSP)、数字信号处理装置(Digital Signal Processing Device，DSPD)、可编程逻辑装置(Programmable Logic Device，PLD)、现场可编程门阵列(FieldProgrammable Gate Array，FPGA)、中央处理器、图形处理器(Graphics Processing Unit，GPU)、嵌入式神经网络处理器(neural-network processing units，NPU)、控制器、微控制器、微处理器、可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以理解地，实现上述处理器功能的电子器件还可以为其它，本申请实施例不作具体限定。

上述计算机存储介质/存储器可以是只读存储器(Read Only Memory，ROM)、可编程只读存储器(Programmable Read-Only Memory，PROM)、可擦除可编程只读存储器(Erasable Programmable Read-Only Memory，EPROM)、电可擦除可编程只读存储器(Electrically Erasable Programmable Read-Only Memory，EEPROM)、磁性随机存取存储器(Ferromagnetic Random Access Memory，FRAM)、快闪存储器(Flash Memory)、磁表面存储器、光盘、或只读光盘(Compact Disc Read-Only Memory，CD-ROM)等存储器。

应理解，说明书通篇中提到的“一个实施例”或“一实施例”或“本申请实施例”或“前述实施例”或“一些实施方式”或“一些实施例”意味着与实施例有关的特定特征、结构或特性包括在本申请的至少一个实施例中。因此，在整个说明书各处出现的“在一个实施例中”或“在一实施例中”或“本申请实施例”或“前述实施例”或“一些实施方式”或“一些实施例”未必一定指相同的实施例。此外，这些特定的特征、结构或特性可以任意适合的方式结合在一个或多个实施例中。应理解，在本申请的各种实施例中，上述各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。上述本申请实施例序号仅仅为了描述，不代表实施例的优劣。

在未做特殊说明的情况下，评估装置执行本申请实施例中的任一步骤，可以是评估装置的处理器执行该步骤。除非特殊说明，本申请实施例并不限定评估装置执行下述步骤的先后顺序。另外，不同实施例中对数据进行处理所采用的方式可以是相同的方法或不同的方法。还需说明的是，本申请实施例中的任一步骤是评估装置可以独立执行的，即评估装置执行上述实施例中的任一步骤时，可以不依赖于其它步骤的执行。

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

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

另外，在本申请各实施例中的各功能单元可以全部集成在一个处理单元中，也可以是各单元分别单独作为一个单元，也可以两个或两个以上单元集成在一个单元中；上述集成的单元既可以采用硬件的形式实现，也可以采用硬件加软件功能单元的形式实现。

本申请所提供的几个方法实施例中所揭露的方法，在不冲突的情况下可以任意组合，得到新的方法实施例。本申请所提供的几个产品实施例中所揭露的特征，在不冲突的情况下可以任意组合，得到新的产品实施例。本申请所提供的几个方法或设备实施例中所揭露的特征，在不冲突的情况下可以任意组合，得到新的方法实施例或设备实施例。

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

或者，本申请上述集成的单元如果以软件功能模块的形式实现并作为独立的产品销售或使用时，也可以存储在一个计算机存储介质中。基于这样的理解，本申请实施例的技术方案本质上或者说对相关技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机、服务器、或者网络设备等)执行本申请各个实施例所述方法的全部或部分。而前述的存储介质包括：移动存储设备、ROM、磁碟或者光盘等各种可以存储程序代码的介质。

在本申请实施例中，不同实施例中相同步骤和相同内容的说明，可以互相参照。在本申请实施例中，术语“并”不对步骤的先后顺序造成影响，例如，评估装置执行A，并执行B，可以是评估装置先执行A，再执行B，或者是评估装置先执行B，再执行A，或者是评估装置执行A的同时执行B。

值得注意的是，本申请实施例中的附图只是为了说明各个器件在评估装置上的示意位置，并不代表在评估装置中的真实位置，各器件或各个区域的真实位置可根据实际情况(例如，评估装置的结构)作出相应改变或偏移，并且，图中的评估装置中不同部分的比例并不代表真实的比例。

在本申请实施例和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。

应当理解，本文中使用的术语“和/或”仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。另外，本文中字符“/”，一般表示前后关联对象是一种“或”的关系。

需要说明的是，本申请所涉及的各个实施例中，可以执行全部的步骤或者可以执行部分的步骤，只要能够形成一个完整的技术方案即可。

以上所述，仅为本申请的实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以所述权利要求的保护范围为准。