CN117992264A - 宿主机故障修复方法及装置、系统、电子设备和存储介质 - Google Patents

Abstract

本公开公开了宿主机故障修复方法及装置、电子设备和存储介质，在接收到被控节点发送的异常信息后，或在预设发送周期未接收到被控节点发送的心跳包后，根据故障判断规则对被控节点对应的宿主机进行至少一个故障的判定；将至少一个故障的集合确定为目标故障集；从预先配置的故障集与处理方式集之间的映射关系，确定目标故障集对应的目标处理方式；将目标处理方式发送至被控节点，以便被控节点根据目标处理方式对被控节点对应的宿主机进行修复。本公开提供的宿主机故障修复方法，增加了宿主机故障判定的全面性和可配置性，有效提升了宿主机故障判定的准确率，减少漏判，有效提升了宿主机故障判定的灵活性和可扩展性，提升了云计算服务的可用性。

Description

宿主机故障修复方法及装置、系统、电子设备和存储介质

技术领域

本公开涉及云计算技术领域，尤其涉及一种宿主机故障修复方法及装置、系统、电子设备和存储介质。

背景技术

随着云计算技术的迅速发展，越来越多的企业都在积极推动传统业务应用迁移上云，即把原来部署在物理服务器上的业务系统改为部署到云服务器上，因此，云计算服务的可用性在一定程度上决定着客户业务的可用性。云计算服务通常运行在数量众多的物理服务器(即宿主机)上，由于宿主机数量基数大以及云计算本身的复杂性，常常因软硬件的各种故障导致宿主机出现整体或局部性的故障。而宿主机上，通常运行着多个承载客户业务的云主机，宿主机的故障将导致云主机无法正常运行，从而影响云计算服务的可用性。因此，开发出一种检测和修复宿主机故障的方法对于提升云计算服务的可用性十分必要。

相关的云计算宿主机故障修复技术，一般通过智能平台管理接口(IntelligentPlatform Management Interface，IPMI)协议，采集宿主机电源状态、CPU状态、内存状态和网卡状态的性能数据，并将上述性能数据与预设的性能数据指标进行比较来判断对应的宿主机是否需要进行疏散处理，对故障的判定不够全面且具有漏判的可能性，例如，在实际判定情况中，也可能是电源、CPU、内存和网卡等硬件都正常，但提供云主机服务的宿主机的软件层面发生夯死故障，导致宿主机上的云主机不可用，从而影响客户业务；并且宿主机故障判定的逻辑比较固化，不具备可配置性和可扩展性。

因此，相关的云计算技术中，由于宿主机故障判定的方面不够全面以及故障判定的逻辑固化的问题，进而导致降低云计算服务的可用性。

发明内容

本公开提供了一种宿主机故障修复方法及装置、系统、电子设备和存储介质。其主要目的在于解决宿主机故障判定的方面不够全面以及故障判定的逻辑固化导致的云计算服务可用性降低的问题。

根据本公开的第一方面，提供了一种宿主机故障修复方法，所述方法应用于控制节点，包括：

在接收到被控节点发送的异常信息后，或在预设发送周期未接收到所述被控节点发送的心跳包后，根据故障判断规则对所述被控节点对应的宿主机进行至少一个故障的判定，所述故障判断规则包含预设判断顺序及判断逻辑；

将所述至少一个故障的集合确定为目标故障集；

从预先配置的故障集与处理方式集之间的映射关系，确定所述目标故障集对应的目标处理方式；

将所述目标处理方式发送至所述被控节点，以便所述被控节点根据所述目标处理方式对所述被控节点对应的宿主机进行修复。

可选地，所述根据故障判断规则对所述被控节点进行至少一个故障的判定包括：

确定所述故障判断规则中的预设判断顺序为依次执行硬件状态步骤、网络状态步骤、不同核心服务状态步骤的顺序；一个步骤对应一个判断逻辑；

根据所述执行步骤及对应的判断逻辑对所述被控节点对应的宿主机进行至少一个故障的判定。

可选地，所述根据所述执行步骤及对应的预设判断顺序对所述被控节点对应的宿主机进行至少一个故障的判定包括：

对所述被控节点对应的宿主机的所述电源状态进行检查，所述硬件状态包括电源状态；

在确定所述电源状态存在异常的情况下，则确定所述电源状态故障；

在确定所述电源状态正常的情况下，对所述被控节点对应的宿主机的所述网络状态进行检查，所述网络状态包括管理网连接及存储网连接；

在确定所述管理网连接异常的情况下，且确定所述存储网连接异常的情况下，则确定所述网络状态故障；

在确定所述存储网连接正常，和/或所述管理网连接正常的情况下，确定所述网络状态正常；

对所述不同核心服务状态进行检查，并确定存在故障的核心服务。

可选地，所述预设判断顺序及所述判断逻辑存储于有向无环图对应的配置文件中；

所述确定所述异常判断规则中的判断顺序为依次执行硬件状态步骤、网络状态步骤、不同核心服务状态步骤的顺序包括：

读取所述有向无环图对应的配置文件；

根据所述配置文件生成包含所述判断顺序及所述判断逻辑的有向无环图；

基于所述有向无环图确定所述故障判断规则中的判断顺序。

可选地，所述根据所述配置文件生成包含所述预设判断顺序及所述判断逻辑的有向无环图还包括：

在所述有向无环图对应的配置文件中新增判断顺序及对应的判断逻辑；

或，在所述有向无环图对应的配置文件中删除所述判断顺序及所述判断逻辑。

可选地，所述从预先配置的故障集与处理方式集之间的映射关系，确定所述目标故障集对应的目标处理方式，包括：

基于所述预先配置的故障集与处理方式集之间的映射关系，分别确定所述目标故障集中的故障或故障组合对应的多个处理方式，所述不同的处理方式对应不同的优先级；

根据优先级的排序结果从所述多个处理方式中确定目标处理方式。

可选地，在根据故障判断规则对所述被控节点对应的宿主机进行至少一个故障的判定前，所述方法包括：

向所述被控节点发送控制指令，所述控制指令用于指示所述被控节点采集所述被控节点对应宿主机的当前系统性能数据；以便所述被控节点执行所述控制指令，并将所述当前系统性能数据与预设系统性能数据指标的比对结果上传异常信息；

接收所述被控节点发送的所述异常信息；

监控所述被控节点是否按照所述预设发送周期发送心跳包。

根据本公开的第二方面，提供了一种宿主机故障修复装置，包括：

判定单元，用于在接收到被控节点发送的异常信息后，或在预设发送周期未接收到所述被控节点发送的心跳包后，根据故障判断规则对所述被控节点对应的宿主机进行至少一个故障的判定，所述故障判断规则包含预设判断顺序及判断逻辑；

第一确定单元，用于将所述至少一个故障的集合确定为目标故障集；

第二确定单元，用于从预先配置的故障集与处理方式集之间的映射关系，确定所述目标故障集对应的目标处理方式；

第一发送单元，用于将所述目标处理方式发送至所述被控节点，以便所述被控节点根据所述目标处理方式对所述被控节点对应的宿主机进行修复。

可选地，所述判定单元还用于：

确定所述故障判断规则中的预设判断顺序为依次执行硬件状态步骤、网络状态步骤、不同核心服务状态步骤的顺序；一个步骤对应一个判断逻辑；

根据所述执行步骤及对应的判断逻辑对所述被控节点对应的宿主机进行至少一个故障的判定。

可选地，所述判定单元包括：

第一检查模块，用于对所述被控节点对应的宿主机的所述电源状态进行检查，所述硬件状态包括电源状态；

第一确定模块，用于在确定所述电源状态存在异常的情况下，则确定所述电源状态故障；

第二检查模块，用于在确定所述电源状态正常的情况下，对所述被控节点对应的宿主机的所述网络状态进行检查，所述网络状态包括管理网连接及存储网连接；

第二确定模块，用于在确定所述管理网连接异常的情况下，且确定所述存储网连接异常的情况下，则确定所述网络状态故障；

第三确定模块，用于在确定所述存储网连接正常，和/或所述管理网连接正常的情况下，确定所述网络状态正常；

第三检查模块，用于对所述不同核心服务状态进行检查，并确定存在故障的核心服务。

可选地，所述预设判断顺序及所述判断逻辑存储于有向无环图对应的配置文件中；

可选地，所述判定单元还包括：

读取模块，用于读取所述有向无环图对应的配置文件；

生成模块，用于根据所述配置文件生成包含所述判断顺序及所述判断逻辑的有向无环图；

第四确定单元，用于基于所述有向无环图确定所述故障判断规则中的判断顺序。

可选地，所述生成模块还用于：

在所述有向无环图对应的配置文件中新增判断顺序及对应的判断逻辑；

或，在所述有向无环图对应的配置文件中删除所述判断顺序及所述判断逻辑。

可选地，所述第二确定单元包括：

第五确定模块，用于基于所述预先配置的故障集与处理方式集之间的映射关系，分别确定所述目标故障集中的故障或故障组合对应的多个处理方式，所述不同的处理方式对应不同的优先级；

第六确定模块，用于根据优先级的排序结果从所述多个处理方式中确定目标处理方式。

可选地，所述装置还包括：

第二发送单元，用于在根据异常判断规则对所述被控节点对应的宿主机进行至少一个故障的判定之前，向所述被控节点发送控制指令，所述控制指令用于指示所述被控节点采集所述被控节点对应宿主机的当前系统性能数据；以便所述被控节点执行所述控制指令；

上传单元，用于将所述当前系统性能数据与预设系统性能数据指标的比对结果上传异常信息；

接收单元，用于接收所述被控节点发送的所述异常信息；

监控单元，用于监控所述被控节点是否按照所述预设发送周期发送心跳包。

根据本公开的第三方面，提供了一种宿主机故障修复系统，其特征在于，所述系统包括第一宿主机及第二宿主机；

其中，所述第一宿主机中包括控制节点，所述控制节点包括前述的宿主机故障修复装置；

所述第二宿主机中包括被控节点，所述第一宿主机与所述第二宿主机相同或不同。

根据本公开的第四方面，提供了一种电子设备，包括：

至少一个处理器；以及

与所述至少一个处理器通信连接的存储器；其中，

所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行前述第一方面所述的方法。

根据本公开的第五方面，提供了一种存储有计算机指令的非瞬时计算机可读存储介质，其中，所述计算机指令用于使所述计算机执行前述第一方面所述的方法。

根据本公开的第六方面，提供了一种计算机程序产品，包括计算机程序，所述计算机程序在被处理器执行时实现如前述第一方面所述的方法。

本公开提供的宿主机故障修复方法及装置、系统、电子设备和存储介质，在接收到被控节点发送的异常信息后，或在预设发送周期未接收到所述被控节点发送的心跳包后，根据故障判断规则对所述被控节点对应的宿主机进行至少一个故障的判定，所述故障判断规则包含预设判断顺序及判断逻辑；将所述至少一个故障的集合确定为目标故障集；从预先配置的故障集与处理方式集之间的映射关系，确定所述目标故障集对应的目标处理方式；将所述目标处理方式发送至所述被控节点，以便所述被控节点根据所述目标处理方式对所述目标故障集进行处理。本公开提供的宿主机故障修复方法，与相关技术相比，基于所述故障判断规则包含的预设判断顺序及判断逻辑对宿主机故障进行判定并确定对应的目标处理方式，增加了宿主机故障判定的全面性和可配置性，有效提升了宿主机故障判定的准确率，减少漏判，有效提升了宿主机故障判定的灵活性和可扩展性，并且基于目标处理方式及时修复宿主机故障，提升了云计算服务的可用性。

应当理解，本部分所描述的内容并非旨在标识本申请的实施例的关键或重要特征，也不用于限制本申请的范围。本申请的其它特征将通过以下的说明书而变得容易理解。

附图说明

附图用于更好地理解本方案，不构成对本公开的限定。其中：

图1为本公开实施例所提供的一种宿主机故障修复方法的流程示意图；

图2为本公开实施例提供的一种故障判断规则的流程示意图；

图3为本公开实施例提供的另一种故障判断规则的流程示意图

图4为本公开实施例提供的一种故障判断规则对应的有向无环图的示意图；

图5为本公开实施例提供的一种宿主机故障修复装置的结构示意图；

图6为本公开实施例提供的另一种宿主机故障修复装置的结构示意图；

图7为本公开实施例提供的示例电子设备400的示意性框图。

具体实施方式

以下结合附图对本公开的示范性实施例做出说明，其中包括本公开实施例的各种细节以助于理解，应当将它们认为仅仅是示范性的。因此，本领域普通技术人员应当认识到，可以对这里描述的实施例做出各种改变和修改，而不会背离本公开的范围和精神。同样，为了清楚和简明，以下的描述中省略了对公知功能和结构的描述。

下面参考附图描述本公开实施例的宿主机故障修复方法及装置、系统、电子设备和存储介质。

图1为本公开实施例所提供的一种宿主机故障修复方法的流程示意图。

如图1所示，该方法包含以下步骤：

步骤101，在接收到被控节点发送的异常信息后，或在预设发送周期未接收到所述被控节点发送的心跳包后，根据故障判断规则对所述被控节点对应的宿主机进行至少一个故障的判定，所述故障判断规则包含预设判断顺序及判断逻辑。

为了及时发现宿主机存在的故障以便于对所述宿主机进行故障修复，提升宿主机的可用性，需监控被控节点，并向被控节点发送控制指令，指示所述被控节点采集所述被控节点对应宿主机的当前系统性能数据；以便所述被控节点执行所述控制指令，并将所述当前系统性能数据与预设系统性能数据指标的比对结果上传异常信息。所述预设系统性能数据指标包括但不局限于内核态和用户态分别占用的CPU百分比、等待磁盘io的CPU占比、可用内存、系统盘可用空间。

为了确定被控节点状态正常，当被控节点的所述当前系统性能数据符合预设系统性能数据指标时，即所述被控节点当前状态正常，无需上传异常信息但需按照所述预设发送周期发送心跳包，所述心跳包为控制节点用来判断被控节点是否正常运行的一个自定义信息，按照一定的时间间隔发送，类似于心跳，所以叫做心跳包，如果在多个预设周期内未接收到所述心跳包，则判断被控节点已经离线，宿主机发生故障。

为了提升宿主机故障判定的准确率，减少漏判，避免因漏判故障而造成宿主机可用性降低，本申请提供了一种根据故障判断规则对所述被控节点对应的宿主机进行故障判定的方法，所述故障判定规则包含预设判断顺序及判断逻辑，按照预设判断顺序，根据判断逻辑对所述宿主机进行一次全面的判定，就能够找到所述宿主机的所有故障，可有效减少对所述宿主机故障的漏判。

在本申请实施例中，所述故障判断规则包含预设判断顺序及判断逻辑，所述预设判断顺序为依次执行硬件状态步骤、网络状态步骤、不同核心服务状态步骤的顺序，并且一个步骤对应一个判断逻辑，因此所述故障判定规则是可以灵活变动的，例如，当所述宿主机需要新增故障的判断逻辑时，可将所述新增故障的判断逻辑添加在所述预设判断顺序中，有效提升了宿主机故障判定的灵活性、可配置性和可扩展性。

步骤102，将所述至少一个故障的集合确定为目标故障集。

在对所述宿主机进行至少一个故障的判定后，收集所述硬件状态步骤、网络状态步骤、不同核心服务状态步骤对应的故障，并将所述至少一个故障的集合确定为目标故障集，所述目标故障集为对每一个步骤进行判定后得到的目标故障的集合。

步骤103，从预先配置的故障集与处理方式集之间的映射关系，确定所述目标故障集对应的目标处理方式。

为了确定所述目标故障集对应的目标处理方式以便于及时修复宿主机故障，在确定所述目标故障集后，通过预先配置的故障集与处理方式集之间的映射关系，找到所述目标故障集对应的目标处理方式。所述处理方式集中包括“跳过”、“告警”、“疏散”等处理方式，并且每种处理方式包括对应的优先级。

为了在所述目标故障集中存在多个故障的情况下确定所述目标处理方式并对所述宿主机进行正确的修复，提高宿主机的可用性，需基于所述预先配置的故障集与处理方式集之间的映射关系查找目标处理方式。为了更加准确的找到所述目标处理方式，所述预先配置的故障集与处理方式集之间的映射关系包括一个故障对应于一个处理方式的映射关系，也包括多个故障的组合对应于一个处理方式的映射关系，具体的故障集与处理方式集之间的映射关系本申请实施例不做限定。

步骤104，将所述目标处理方式发送至所述被控节点，以便所述被控节点根据所述目标处理方式对所述被控节点对应的宿主机进行修复。

在确定所述目标处理方式后，将所述目标处理方式发送至所述被控节点，所述控制节点根据所述目标处理方式对所述宿主机进行修复，以提升所述宿主机的可用性。

本公开提供的宿主机故障修复方法，在接收到被控节点发送的异常信息后，或在预设发送周期未接收到所述被控节点发送的心跳包后，根据故障判断规则对所述被控节点对应的宿主机进行至少一个故障的判定，所述故障判断规则包含预设判断顺序及判断逻辑；将所述至少一个故障的集合确定为目标故障集；从预先配置的故障集与处理方式集之间的映射关系，确定所述目标故障集对应的目标处理方式；将所述目标处理方式发送至所述被控节点，以便所述被控节点根据所述目标处理方式对所述目标故障集进行处理。本公开提供的宿主机故障修复方法，与相关技术相比，基于所述故障判断规则包含的预设判断顺序及判断逻辑对宿主机故障进行判定并确定对应的目标处理方式，增加了宿主机故障判定的全面性和可配置性，有效提升了宿主机故障判定的准确率，减少漏判，有效提升了宿主机故障判定的灵活性和可扩展性，并且基于目标处理方式及时修复宿主机故障，提升了云计算服务的可用性。

在本申请提供的一个实施例中，为了便于对所述根据所述执行步骤及对应的判断逻辑对所述被控节点对应的宿主机进行至少一个故障的判定进行更好的理解，以OpenStack集群为例，请参考图2，图2为本公开实施例提供的一种故障判断规则的流程示意图。

如图2所示，该故障判断规则包含以下步骤：

步骤201，对所述被控节点对应的宿主机的所述电源状态进行检查，所述硬件状态包括电源状态。

在本申请实施例中，对所述被控节点对应的宿主机的所述电源状态进行检查可以采用但不局限于，通过智能平台管理接口(Intelligent Platform ManagementInterface，IPMI)协议检查被控节点对应的宿主机的电源状态是否正常。

步骤202，在确定所述电源状态异常的情况下，则确定所述电源状态故障。

若确定所述电源状态正常，则按照所述预设判断顺序继续对所述宿主机的故障进行判定，若确定所述被控节点对应的宿主机的电源状态存在故障，例如发生断电异常，则结束对所述宿主机的判定。

步骤203，在确定所述电源状态正常的情况下，对所述被控节点对应的宿主机的所述网络状态进行检查，所述网络状态包括管理网连接及存储网连接。

在确定所述电源状态正常的情况下，可以采用但不局限于ping(Packet InternetGroper)检查所述宿主机的管理网连接状态，若所述管理网连接正常，则所述宿主机的网络状态正常。若确定所述管理网连接异常，则继续采用ping对所述宿主机的存储网连接状态进行检查，若确定所述存储网连接正常，则继续对所述宿主机的不同核心服务状态进行检查。

步骤204，在确定所述管理网连接异常的情况下，且确定所述存储网连接异常的情况下，则确定所述网络状态故障。

当确定所述管理网连接异常的情况下，并且确定所述存储网连接也出现异常，则确定所述网络状态故障，并结束对所述宿主机的判定。

步骤205，在确定所述存储网连接正常，和/或所述管理网连接正常的情况下，确定所述网络状态正常。

在确定所述管理网连接正常的情况下，或者所述管理网连接异常，但存储网连接异常的情况下，则确定所述宿主机的网络状态正常，并继续对所述宿主机进行检查。

步骤206，对所述不同核心服务状态进行检查，并确定存在故障的核心服务。

在确定所述宿主机的网络状态正常后，对所述宿主机的核心服务进行检查，所述核心服务包括但不局限于Nova-compute、libvirt、agent等核心服务，所述Nova-compute、libvirt、agent为OpenStack中的核心组件。其中，所述Nova-compute在被控节点上运行，负责管理节点上的实例。通常一个主机运行一个Nova-compute服务,一个实例部署在哪个可用的主机上取决于调度算法。OpenStack对实例的操作最后都是提交给Nova-compute来完成。Nova-compute可分为两类，一类是按照预设周期向OpenStack上报被控节点的状态，另一类是实现实例生命周期的管理，本申请实施例的Nova-compute显然为上述的第一类；所述l ibvirt是用于管理虚拟化平台的开源的应用程序编程接口(ApplicationProgramming Interface,API)，提供了一个方便的方式来管理虚拟机和其他虚拟化功能的软件的集合，如存储和网络接口管理。

在本申请实施例中，所述Nova-compute用于检查被控节点的心跳包是否按照预设周期发送。所述对所述宿主机的核心服务进行检查，可以采用但不局限于以下方法，例如，若libvirt端口在节点间开放，则向该计算节点的l ibvirt发送一个试探请求，确定所述试探性请求是否正常返回，若不正常返回则确定libvirt组件异常；或者，被控节点的agent组件发送一个试探性请求，确定所述试探性请求是否正常返回，若不正常返回则确定agent组件异常。

通过如图2所示的故障判断规则，按照所述预设判断顺序对所述宿主机的进行全面性的故障判定，有效提升所述宿主机故障判定的准确率，降低漏判率，提升宿主机的可用性。

为了对上述以OpenStack集群为例的故障判断规则进行进一步地说明，图3为本申请实施例提供的另一种故障判断规则的流程示意图。

为了更好地表达所述故障判断规则，更方便地对所述故障判断规则进行调整，在一些实施例中，可将图2所示的故障判断规则的流程图转换为图3所示的可配置的有向无环图，具体的实施方法包括：将所述预设判断顺序及所述判断逻辑存储于有向无环图对应的配置文件中，该有向无环图的配置文件格式可以使用YAML(Ain't a Markup Language)文件的形式；读取所述有向无环图对应的配置文件；根据所述配置文件生成包含所述判断顺序及所述判断逻辑的有向无环图；基于所述有向无环图确定所述异常故障判断规则中的判断顺序。当需要对所述宿主机增加新的故障的判定逻辑，可在所述有向无环图对应的配置文件中新增判断顺序及所述判断逻辑；或者，当需要对所述宿主机已有的故障的判定逻辑进行删除时，可直接在所述有向无环图对应的配置文件中删除所述判断顺序及所述判断逻辑。

在一些实施例中，在获取所述有向无环图之后，还可使用深度优先搜索算法对所述有向无环图进行检查。深度优先搜索算法(Depth First Search，DFS)是一种用于搜索树或图的算法。

为了对所述有向无环图进行更好的理解，请参考图3，如图3所示，图3为本申请实施例提供的一种故障判断规则对应的有向无环图的示意图。

如图3所示，该故障判断规则对应的有向无环图具有以下几个规则：

规则1、所述有向无环图的顶点分为检查顶点和异常顶点。所述检查顶点用于根据实际的判断逻辑对所述宿主机进行检查，所述异常顶点用来代表某一个故障。

规则2、检查顶点的出度边具有条件，用于和检查顶点所查出的结果做相等性判断，相等则在深度优先搜索时沿着该出度边继续搜索。

规则3、检查顶点可以指向另一个检查顶点，也可以指向异常顶点。

规则4、异常顶点只能有一条入度边和一条出度边，出度边不能有条件。

规则5、一个异常顶点不能指向另一个异常顶点。

规则6、入度为0的顶点只能有一个，且此顶点是检查顶点。

在一些实施例中，在得到所述有向无环图之后，在实际进行深度优先搜索时，以入度为0的顶点为起始，若顶点为检查顶点，则执行其附带的判断逻辑，将判断逻辑的结果与其出度边所带的条件进行比较，相等则选择该出度边继续搜索。若顶点为异常顶点，则将该异常顶点所对应的故障存入目标故障集中，直至没有顶点可以搜索为止，就得到了对所述宿主机进行故障判定所能找到的所有故障。

在一些实施例中，还可以将所述有向无环图具象化，绘制出所述有向无环图的实际图片，将所述预设判断顺序及判断逻辑具象化。

通过将所述故障判定规则通过配置文件转换为有向无环图的方法，有效提升了故障判定的可配置性和可扩展性，使所述故障判断规则更加直观。

在一些实施例中，为了确定目标处理方式，需从预先配置的故障集与处理方式集之间的映射关系，确定所述目标异常事件故障集对应的目标处理方式，具体的实施方法包括：基于所述预先配置的异常事件故障集与处理方式集之间的映射关系，分别确定所述目标故障集中的故障或故障组合对应的多个处理方式，不同的处理方式对应不同的优先级；根据优先级的排序结果从所述多个处理方式中确定目标处理方式。

所述预先配置的故障集与处理方式集之间的映射关系包括一个故障对应于一个处理方式的映射关系，也包括多个故障的组合对应于一个处理方式的映射关系，在确定所述目标处理方式的过程中，所述目标故障集中可能包含多个故障，例如故障集为{E1,E2,E3}，处理方式集为{H1,H2}，则可以配置映射关系为:E1+E2+E3对应H1。因此，允许将所述目标故障集中的多个故障组合在一起，查找所述映射关系中所述故障组合对应的处理方式。当同时查找到多种处理方式时，需对处理方式对应的优先级进行排序。例如，所述处理方式集中有3种处理方式：跳过、告警、疏散，则将其优先级分别设为1、3、5，即“疏散”为优先级最大的处理方式，并将优先级最大的处理方式确定为目标处理方式。例如，针对上述图2所提供的实施例，确定需要疏散的故障组合为:(1)断电异常(2)管理网异常+存储网异常(3)nova-compute心跳异常+libvirt异常+agent异常。

通过上述的方法，在确定所述宿主机的目标故障集后，可迅速查找到对应的目标处理方式并发送至被控节点，以便于所述被控节点根据所述目标处理方式对所述被控节点对应的宿主机进行修复。

为了能够监控所述宿主机状态，以便于及时修复所述宿主机的故障，在一些实施例中，通过向所述被控节点发送控制指令，指示所述被控节点采集所述被控节点对应宿主机的当前系统性能数据；并将所述当前系统性能数据与预设系统性能数据指标进行比对以确定异常信息，并将所述异常信息上传至控制节点。

为了便于对所述异常信息进行更好的理解，表1为本申请实施例提供的一种预设系统性能数据指标。

根据上述表1提供的预设系统性能指标确定所述异常信息，并将所述异常信息发送至所述控制节点。

在一些实施例中，若确定所述当前系统性能数据符合所述预设系统性能指标，即宿主机状态正常，则所述被控节点按照所述预设发送周期发送心跳包至控制节点，便于所述控制节点确定所述被控节点状态正常。

通过上述被控节点与控制节点之间发送异常信息或心跳包的方法，对所述宿主机的状态进行监控，以便于及时发现故障。

综上所述，本公开实施例能达到以下效果：

1.按照所述预设判断顺序对所述宿主机的进行全面性的故障判定，有效提升所述宿主机故障判定的准确率，降低漏判率，提升宿主机的可用性。

2.通过将所述故障判定规则通过配置文件转换为有向无环图的方法，有效提升了故障判定的可配置性和可扩展性，使所述故障判断规则更加直观。

3.通过预先配置的异常事件故障集与处理方式集之间的映射关系，确定所述目标异常事件故障集对应的目标处理方式，可迅速查找到对应的目标处理方式并发送至被控节点，以便于所述被控节点根据所述目标处理方式对所述被控节点对应的宿主机进行修复。

4.通过上述被控节点与控制节点之间发送异常信息或心跳包的方法，对所述宿主机的状态进行监控，以便于及时发现故障。

与上述的宿主机故障修复方法相对应，本发明还提出一种宿主机故障修复装置。由于本发明的装置实施例与上述的方法实施例相对应，对于装置实施例中未披露的细节可参照上述的方法实施例，本发明中不再进行赘述。

图5为本公开实施例提供的一种宿主机故障修复装置的结构示意图，如图5所示，包括：判定单元31、第一确定单元32、第二确定单元33和发送单元34。

判定单元31，用于在接收到被控节点发送的异常信息后，或在预设发送周期未接收到所述被控节点发送的心跳包后，根据故障判断规则对所述被控节点对应的宿主机进行至少一个故障的判定，所述故障判断规则包含预设判断顺序及判断逻辑；

第一确定单元32，用于将所述至少一个故障的集合确定为目标故障集；

第二确定单元33，用于从预先配置的故障集与处理方式集之间的映射关系，确定所述目标故障集对应的目标处理方式；

发送单元34，用于将所述目标处理方式发送至所述被控节点，以便所述被控节点根据所述目标处理方式对所述被控节点对应的宿主机进行修复。

本公开提供的宿主机故障修复装置，在接收到被控节点发送的异常信息后，或在预设发送周期未接收到所述被控节点发送的心跳包后，根据故障判断规则对所述被控节点对应的宿主机进行至少一个故障的判定，所述故障判断规则包含预设判断顺序及判断逻辑；将所述至少一个故障的集合确定为目标故障集；从预先配置的故障集与处理方式集之间的映射关系，确定所述目标故障集对应的目标处理方式；将所述目标处理方式发送至所述被控节点，以便所述被控节点根据所述目标处理方式对所述目标故障集进行处理。本公开提供的宿主机故障修复方法，与相关技术相比，基于所述故障判断规则包含的预设判断顺序及判断逻辑对宿主机故障进行判定并确定对应的目标处理方式，增加了宿主机故障判定的全面性和可配置性，有效提升了宿主机故障判定的准确率，减少漏判，有效提升了宿主机故障判定的灵活性和可扩展性，并且基于目标处理方式及时修复宿主机故障，提升了云计算服务的可用性。

进一步地，在本实施例一种可能的实现方式中，所述判定单元31还用于：

确定所述异常判断规则中的判断顺序为依次执行硬件状态步骤、网络状态步骤、不同核心服务状态步骤的顺序；一个步骤对应一个判断逻辑；

根据所述执行步骤及对应的判断逻辑顺序对所述被控节点对应的宿主机进行至少一个故障的判定。

进一步地，在本实施例一种可能的实现方式中，如图6所示，所述判定单元31包括：

第一检查模块311，用于对所述被控节点对应的宿主机的所述电源状态进行检查，所述硬件状态包括电源状态；

第一确定模块312，用于在确定所述电源状态异常的情况下，则确定所述电源状态故障；

第二检查模块313，用于在确定所述电源状态正常的情况下，对所述被控节点对应的宿主机的所述网络状态进行检查，所述网络状态包括管理网连接及存储网连接；

第二确定模块314，用于在确定所述管理网连接异常的情况下，且确定所述存储网连接异常的情况下，则确定所述网络状态故障；

第三确定模块315，用于在确定所述存储网连接正常，和/或所述管理网连接正常的情况下，确定所述网络状态正常；

第三检查模块316，用于对所述不同核心服务状态进行检查，并确定存在故障的核心服务。

进一步地，在本实施例一种可能的实现方式中，如图6所示，所述预设判断顺序及所述判断逻辑存储于有向无环图对应的配置文件中；

进一步地，在本实施例一种可能的实现方式中，如图6所示，所述判定单元31还包括：

读取模块317，用于读取所述有向无环图对应的配置文件；

生成模块318，用于根据所述配置文件生成包含所述预设判断顺序及所述判断逻辑的有向无环图；

第四确定模块319，用于基于所述有向无环图确定所述故障判断规则中的判断顺序。

进一步地，在本实施例一种可能的实现方式中，如图6所示，所述生成模块318还用于：

在所述有向无环图对应的配置文件中新增判断顺序及所述判断逻辑；

或，在所述有向无环图对应的配置文件中删除所述判断顺序及所述判断逻辑。

进一步地，在本实施例一种可能的实现方式中，如图6所示，所述第二确定单元33包括：

第五确定模块331，用于基于所述预先配置的故障集与处理方式集之间的映射关系，分别确定所述目标故障集中的故障或故障组合对应的多个处理方式，所述不同的处理方式对应不同的优先级；

第六确定模块332，用于根据优先级的排序结果从所述多个处理方式中确定目标处理方式。

进一步地，在本实施例一种可能的实现方式中，如图6所示，所述装置还包括：

第二发送单元35，用于在根据异常判断规则对所述被控节点对应的宿主机进行至少一个故障的判定之前，向所述被控节点发送控制指令，所述控制指令用于指示所述被控节点采集所述被控节点对应宿主机的当前系统性能数据；以便所述被控节点执行所述控制指令；

上传单元36，用于将所述当前系统性能数据与预设系统性能数据指标的比对结果上传异常信息；

接收单元37，用于接收所述被控节点发送的所述异常信息；

监控单元38，用于监控所述被控节点是否按照所述预设发送周期发送心跳包。

需要说明的是，前述对方法实施例的解释说明，也适用于本实施例的装置，原理相同，本实施例中不再限定。

与上述的宿主机故障修复方法相对应，本发明还提出一种宿主机故障修复系统。由于本发明的系统实施例与上述的方法实施例相对应，对于系统实施例中未披露的细节可参照上述的方法实施例，本发明中不再进行赘述。

根据本公开的实施例，本公开还提供了一种宿主机故障修复系统，所述系统包括第一宿主机及第二宿主机；

其中，所述第一宿主机中包括控制节点，所述控制节点包括所述的宿主机故障修复装置；

所述第二宿主机中包括被控节点，所述第一宿主机与所述第二宿主机相同或不同。

本公开提供的宿主机故障修复系统，在接收到被控节点发送的异常信息后，或在预设发送周期未接收到所述被控节点发送的心跳包后，根据故障判断规则对所述被控节点对应的宿主机进行至少一个故障的判定，所述故障判断规则包含预设判断顺序及判断逻辑；将所述至少一个故障的集合确定为目标故障集；从预先配置的故障集与处理方式集之间的映射关系，确定所述目标故障集对应的目标处理方式；将所述目标处理方式发送至所述被控节点，以便所述被控节点根据所述目标处理方式对所述目标故障集进行处理。本公开提供的宿主机故障修复方法，与相关技术相比，基于所述故障判断规则包含的预设判断顺序及判断逻辑对宿主机故障进行判定并确定对应的目标处理方式，增加了宿主机故障判定的全面性和可配置性，有效提升了宿主机故障判定的准确率，减少漏判，有效提升了宿主机故障判定的灵活性和可扩展性，并且基于目标处理方式及时修复宿主机故障，提升了云计算服务的可用性。

根据本公开的实施例，本公开还提供了一种电子设备、一种可读存储介质和一种计算机程序产品。

图7示出了可以用来实施本公开的实施例的示例电子设备400的示意性框图。电子设备旨在表示各种形式的数字计算机，诸如，膝上型计算机、台式计算机、工作台、个人数字助理、服务器、刀片式服务器、大型计算机、和其它适合的计算机。电子设备还可以表示各种形式的移动装置，诸如，个人数字处理、蜂窝电话、智能电话、可穿戴设备和其它类似的计算装置。本文所示的部件、它们的连接和关系、以及它们的功能仅仅作为示例，并且不意在限制本文中描述的和/或者要求的本公开的实现。

如图7所示，设备400包括计算单元401，其可以根据存储在ROM(Read-OnlyMemory，只读存储器)402中的计算机程序或者从存储单元408加载到RAM(Random AccessMemory，随机访问/存取存储器)403中的计算机程序，来执行各种适当的动作和处理。在RAM403中，还可存储设备400操作所需的各种程序和数据。计算单元401、ROM 402以及RAM 403通过总线404彼此相连。I/O(Input/Output，输入/输出)接口405也连接至总线404。

设备400中的多个部件连接至I/O接口405，包括：输入单元406，例如键盘、鼠标等；输出单元407，例如各种类型的显示器、扬声器等；存储单元408，例如磁盘、光盘等；以及通信单元409，例如网卡、调制解调器、无线通信收发机等。通信单元409允许设备400通过诸如因特网的计算机网络和/或各种电信网络与其他设备交换信息/数据。

计算单元401可以是各种具有处理和计算能力的通用和/或专用处理组件。计算单元401的一些示例包括但不限于CPU(Central Processing Unit，中央处理单元)、GPU(Graphic Processing Units，图形处理单元)、各种专用的AI(Artificial Intelligence，人工智能)计算芯片、各种运行机器学习模型算法的计算单元、DSP(DigitalSignal Processor，数字信号处理器)、以及任何适当的处理器、控制器、微控制器等。计算单元401执行上文所描述的各个方法和处理，例如宿主机故障修复方法。例如，在一些实施例中，宿主机故障修复方法可被实现为计算机软件程序，其被有形地包含于机器可读介质，例如存储单元408。在一些实施例中，计算机程序的部分或者全部可以经由ROM 402和/或通信单元409而被载入和/或安装到设备400上。当计算机程序加载到RAM 403并由计算单元401执行时，可以执行上文描述的方法的一个或多个步骤。备选地，在其他实施例中，计算单元401可以通过其他任何适当的方式(例如，借助于固件)而被配置为执行前述宿主机故障修复方法。

本文中以上描述的系统和技术的各种实施方式可以在数字电子电路系统、集成电路系统、FPGA(Field Programmable Gate Array，现场可编程门阵列)、ASIC(Application-Specific Integrated Circuit，专用集成电路)、ASSP(Application Specific StandardProduct，专用标准产品)、SOC(System On Chip，芯片上系统的系统)、CPLD(ComplexProgrammable Logic Device，复杂可编程逻辑设备)、计算机硬件、固件、软件、和/或它们的组合中实现。这些各种实施方式可以包括：实施在一个或者多个计算机程序中，该一个或者多个计算机程序可在包括至少一个可编程处理器的可编程系统上执行和/或解释，该可编程处理器可以是专用或者通用可编程处理器，可以从存储系统、至少一个输入装置、和至少一个输出装置接收数据和指令，并且将数据和指令传输至该存储系统、该至少一个输入装置、和该至少一个输出装置。

用于实施本公开的方法的程序代码可以采用一个或多个编程语言的任何组合来编写。这些程序代码可以提供给通用计算机、专用计算机或其他可编程数据处理装置的处理器或控制器，使得程序代码当由处理器或控制器执行时使流程图和/或框图中所规定的功能/操作被实施。程序代码可以完全在机器上执行、部分地在机器上执行，作为独立软件包部分地在机器上执行且部分地在远程机器上执行或完全在远程机器或服务器上执行。

在本公开的上下文中，机器可读介质可以是有形的介质，其可以包含或存储以供指令执行系统、装置或设备使用或与指令执行系统、装置或设备结合地使用的程序。机器可读介质可以是机器可读信号介质或机器可读储存介质。机器可读介质可以包括但不限于电子的、磁性的、光学的、电磁的、红外的、或半导体系统、装置或设备，或者上述内容的任何合适组合。机器可读存储介质的更具体示例会包括基于一个或多个线的电气连接、便携式计算机盘、硬盘、RAM、ROM、EPROM(Electrically Programmable Read-Only-Memory，可擦除可编程只读存储器)或快闪存储器、光纤、CD-ROM(Compact Disc Read-Only Memory，便捷式紧凑盘只读存储器)、光学储存设备、磁储存设备、或上述内容的任何合适组合。

为了提供与用户的交互，可以在计算机上实施此处描述的系统和技术，该计算机具有：用于向用户显示信息的显示装置(例如，CRT(Cathode-Ray Tube，阴极射线管)或者LCD(Liquid Crystal Display，液晶显示器)监视器)；以及键盘和指向装置(例如，鼠标或者轨迹球)，用户可以通过该键盘和该指向装置来将输入提供给计算机。其它种类的装置还可以用于提供与用户的交互；例如，提供给用户的反馈可以是任何形式的传感反馈(例如，视觉反馈、听觉反馈、或者触觉反馈)；并且可以用任何形式(包括声输入、语音输入或者、触觉输入)来接收来自用户的输入。

可以将此处描述的系统和技术实施在包括后台部件的计算系统(例如，作为数据服务器)、或者包括中间件部件的计算系统(例如，应用服务器)、或者包括前端部件的计算系统(例如，具有图形用户界面或者网络浏览器的用户计算机，用户可以通过该图形用户界面或者该网络浏览器来与此处描述的系统和技术的实施方式交互)、或者包括这种后台部件、中间件部件、或者前端部件的任何组合的计算系统中。可以通过任何形式或者介质的数字数据通信(例如，通信网络)来将系统的部件相互连接。通信网络的示例包括：LAN(LocalArea Network，局域网)、WAN(Wide Area Network，广域网)、互联网和区块链网络。

计算机系统可以包括客户端和服务器。客户端和服务器一般远离彼此并且通常通过通信网络进行交互。通过在相应的计算机上运行并且彼此具有客户端-服务器关系的计算机程序来产生客户端和服务器的关系。服务器可以是云服务器，又称为云计算服务器或云主机，是云计算服务体系中的一项主机产品，以解决了传统物理主机与VPS服务("Virtual Private Server"，或简称"VPS")中，存在的管理难度大，业务扩展性弱的缺陷。服务器也可以为分布式系统的服务器，或者是结合了区块链的服务器。

其中，需要说明的是，人工智能是研究使计算机来模拟人的某些思维过程和智能行为(如学习、推理、思考、规划等)的学科，既有硬件层面的技术也有软件层面的技术。人工智能硬件技术一般包括如传感器、专用人工智能芯片、云计算、分布式存储、大数据处理等技术；人工智能软件技术主要包括计算机视觉技术、语音识别技术、自然语言处理技术以及机器学习/深度学习、大数据处理技术、知识图谱技术等几大方向。

应该理解，可以使用上面所示的各种形式的流程，重新排序、增加或删除步骤。例如，本公开中记载的各步骤可以并行地执行也可以顺序地执行也可以不同的次序执行，只要能够实现本公开公开的技术方案所期望的结果，本文在此不进行限制。

上述具体实施方式，并不构成对本公开保护范围的限制。本领域技术人员应该明白的是，根据设计要求和其他因素，可以进行各种修改、组合、子组合和替代。任何在本公开的精神和原则之内所作的修改、等同替换和改进等，均应包含在本公开保护范围之内。

Claims (10)

1.一种宿主机故障修复方法，其特征在于，所述方法应用于控制节点，包括：

在接收到被控节点发送的异常信息后，或在预设发送周期未接收到所述被控节点发送的心跳包后，根据故障判断规则对所述被控节点对应的宿主机进行至少一个故障的判定，所述故障判断规则包含预设判断顺序及判断逻辑；

将所述至少一个故障的集合确定为目标故障集；

从预先配置的故障集与处理方式集之间的映射关系，确定所述目标故障集对应的目标处理方式；

将所述目标处理方式发送至所述被控节点，以便所述被控节点根据所述目标处理方式对所述被控节点对应的宿主机进行修复。

2.根据权利要求1所述的方法，其特征在于，所述根据故障判断规则对所述被控节点进行至少一个故障的判定包括：

确定所述故障判断规则中的预设判断顺序为依次执行硬件状态步骤、网络状态步骤、不同核心服务状态步骤的顺序；一个步骤对应一个判断逻辑；

根据所述执行步骤及对应的判断逻辑对所述被控节点对应的宿主机进行至少一个故障的判定。

3.根据权利要求2所述的方法，其特征在于，所述根据所述执行步骤及对应的预设判断顺序对所述被控节点对应的宿主机进行至少一个故障的判定包括：

对所述被控节点对应的宿主机的所述电源状态进行检查，所述硬件状态包括电源状态；

在确定所述电源状态异常的情况下，则确定所述电源状态故障；

在确定所述电源状态正常的情况下，对所述被控节点对应的宿主机的所述网络状态进行检查，所述网络状态包括管理网连接及存储网连接；

在确定所述管理网连接异常的情况下，且确定所述存储网连接异常的情况下，则确定所述网络状态故障；

在确定所述存储网连接正常，和/或所述管理网连接正常的情况下，确定所述网络状态正常；

对所述不同核心服务状态进行检查，并确定存在故障的核心服务。

4.根据权利要求3所述的方法，其特征在于，所述预设判断顺序及所述判断逻辑存储于有向无环图对应的配置文件中；

所述确定所述故障判断规则中的预设判断顺序为依次执行硬件状态步骤、网络状态步骤、不同核心服务状态步骤的顺序包括：

读取所述有向无环图对应的配置文件；

根据所述配置文件生成包含所述预设判断顺序及所述判断逻辑的有向无环图；

基于所述有向无环图确定所述故障判断规则中的判断顺序。

5.根据权利要求4所述的方法，其特征在于，所述根据所述配置文件生成包含所述预设判断顺序及所述判断逻辑的有向无环图还包括：

在所述有向无环图对应的配置文件中新增判断顺序及对应的判断逻辑；

或，在所述有向无环图对应的配置文件中删除所述判断顺序及所述判断逻辑。

6.根据权利要求1所述的方法，其特征在于，所述从预先配置的故障集与处理方式集之间的映射关系，确定所述目标故障集对应的目标处理方式，包括：

基于所述预先配置的故障集与处理方式集之间的映射关系，分别确定所述目标故障集中的故障或故障组合对应的多个处理方式，所述不同的处理方式对应不同的优先级；

根据优先级的排序结果从所述多个处理方式中确定目标处理方式。

7.根据权利要求1所述的方法，其特征在于，在根据故障判断规则对所述被控节点对应的宿主机进行至少一个故障的判定前，所述方法包括：

向所述被控节点发送控制指令，所述控制指令用于指示所述被控节点采集所述被控节点对应宿主机的当前系统性能数据；以便所述被控节点执行所述控制指令，并将所述当前系统性能数据与预设系统性能数据指标的比对结果上传异常信息；

接收所述被控节点发送的所述异常信息；

监控所述被控节点是否按照所述预设发送周期发送心跳包。

8.一种宿主机故障修复装置，其特征在于，所述装置应用于控制节点，包括：

判定单元，用于在接收到被控节点发送的异常信息后，或在预设发送周期未接收到所述被控节点发送的心跳包后，根据故障判断规则对所述被控节点对应的宿主机进行至少一个故障的判定，所述故障判断规则包含预设判断顺序及判断逻辑；

第一确定单元，用于将所述至少一个故障的集合确定为目标故障集；

第二确定单元，用于从预先配置的故障集与处理方式集之间的映射关系，确定所述目标故障集对应的目标处理方式；

第一发送单元，用于将所述目标处理方式发送至所述被控节点，以便所述被控节点根据所述目标处理方式对所述被控节点对应的宿主机进行修复。

9.一种宿主机故障修复系统，其特征在于，所述系统包括第一宿主机及第二宿主机；

其中，所述第一宿主机中包括控制节点，所述控制节点包括如权利要求7所述的宿主机故障修复装置；

所述第二宿主机中包括被控节点，所述第一宿主机与所述第二宿主机相同或不同。

10.一种电子设备，其特征在于，包括：

至少一个处理器；以及

与所述至少一个处理器通信连接的存储器；其中，

所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行权利要求1-7中任一项所述的方法。