CN114048057A - 超融合系统的测试方法及装置、存储介质 - Google Patents

Abstract

本申请提供一种超融合系统的测试方法及装置、存储介质。超融合系统的测试方法，包括：从预设的多个故障模型中确定出超融合系统的故障检测模型；在所述超融合系统中运行所述故障检测模型，以在所述超融合系统中引发所述故障检测模型对应的故障；检测引发所述故障检测模型对应的故障后的超融合系统的故障处理结果，并记录所述故障处理结果。该测试方法用以实现超融合系统的长期且有效的测试。

Description

超融合系统的测试方法及装置、存储介质

技术领域

本申请涉及自动化测试技术领域，具体而言，涉及一种超融合系统的测试方法及装置、存储介质。

背景技术

超融合系统，是一种新兴的集成系统，将虚拟化计算、分布式存储和网络虚拟化整合到同一个节点或系统平台。

由于超融合系统(即超融合系统)通过网络整合多台物理服务器的所有物理硬件资源，从而经常会发生因为网络或硬件故障等因素导致的各类影响集群稳定性的问题，集群越大，节点越多，网络越复杂，发生故障的几率就越大。因此，需要对超融合系统进行有效且持续的测试。

现有技术中，采用人为制造故障，然后测试超融合系统的恢复能力的测试方式。这种测试方式，花费时间长，且需要测试人员操作，无法实现超融合系统的长期且有效的测试。

发明内容

本申请实施例的目的在于提供一种超融合系统的测试方法及装置、存储介质，用以实现超融合系统的长期且有效的测试。

第一方面，本申请实施例提供一种超融合系统的测试方法，包括：从预设的多个故障模型中确定出超融合系统的故障检测模型；在所述超融合系统中运行所述故障检测模型，以在所述超融合系统中引发所述故障检测模型对应的故障；检测引发所述故障检测模型对应的故障后的超融合系统的故障处理结果，并记录所述故障处理结果。

在本申请实施例中，与现有技术相比，预设多个故障模型，在需要对超融合系统进行测试时，从中确定出故障检测模型，然后在超融合系统中运行该故障检测模型以引发对应的故障，检测引发故障后的超融合系统的故障处理结果，并记录故障处理结果。可以理解，故障处理结果可以表征超融合系统的稳定性和可靠性，例如：故障处理失败，则代表稳定性可能下降，因此，通过这种测试方式，无需人工制造故障，能够实现超融合系统的有效测试。并且，在超融合系统的运行过程中，随时都可以按照该方法对其进行测试，这是一个可持续的过程，因此，能够实现超融合系统的长期测试。

作为一种可能的实现方式，所述多个故障模型包括：分别与不同的环境信息对应的故障模型，所述多个故障模型具有不同的故障等级；所述从预设的多个故障模型中确定出超融合系统的故障检测模型，包括：确定所述超融合系统需要引发的故障的故障等级；确定所述超融合系统对应的环境信息；根据所述需要引发的故障的故障等级和所述超融合系统对应的环境信息从所述多个故障模型中确定出所述超融合系统的故障检测模型。

在本申请实施例中，多个故障模型可以对应不同的环境信息，以及具有不同的故障等级；进而，分别确定故障等级和环境信息，利用故障等级和环境信息便可有效且准确的确定出对应的故障检测模型。

作为一种可能的实现方式，所述故障模型包括第一故障模型和第二故障模型，所述第一故障模型所引发的故障的故障等级低于所述第二故障模型所引发的故障的故障等级；所述第一故障模型所引发的故障包括：断电、断网、磁盘故障、内存故障、cpu故障、系统故障；所述第二故障模型引发的故障包括：网络丢包、时延，磁盘慢盘、坏盘，缓存故障。

在本申请实施例中，通过第一故障模型，可引发故障等级较低的故障；通过第二故障模型，可引发故障等级较高的故障；实现不同故障等级的故障的有效引发。

作为一种可能的实现方式，所述测试方法还包括：确定所述故障处理结果为故障处理失败；确定所述故障检测模型对应的故障恢复模型；在所述超融合系统中运行所述故障恢复模型，以使所述超融合系统恢复正常状态。

在本申请实施例中，当故障处理结果为故障处理失败时，通过在超融合系统中运行故障恢复模型，使超融合系统恢复正常状态，进而保证超融合系统的正常运行，以及可以进行下一次的故障测试。

作为一种可能的实现方式，所述测试方法还包括：从所述预设的多个故障模型中确定出恢复正常状态后的超融合系统的新的故障检测模型；在所述恢复正常状态后的超融合系统中运行所述新的故障检测模型，以在所述恢复正常状态后的超融合系统中引发所述新的故障检测模型对应的故障；检测引发所述新的故障检测模型对应的故障后的超融合系统的新的故障处理结果，并记录所述新的故障处理结果。

在本申请实施例中，基于恢复正常状态后的超融合系统，可确定出新的故障检测模型，并继续对其进行故障测试，以实现超融合系统的长期且有效的测试。

作为一种可能的实现方式，所述从所述预设的多个故障模型中确定出恢复正常状态后的超融合系统的新的故障检测模型，包括：从所述预设的多个故障模型中确定出目标故障模型；所述目标故障模型对应的超融合系统的故障处理结果为故障处理失败的次数大于预设次数；从所述目标故障模型中确定出所述新的故障检测模型。

在本申请实施例中，在确定新的故障检测模型时，结合之前的故障模型对应的故障处理结果进行确定；将对应的故障处理结果为故障处理失败的次数大于预设次数的故障模型确定为目标故障模型，然后从中确定出新的故障检测模型；进而，实现超融合系统针对难以处理的故障的故障处理能力的不断测试。

作为一种可能的实现方式，所述超融合系统包括：多个主机节点和多个业务虚拟机；所述检测引发所述故障检测模型对应的故障后的超融合系统的故障处理结果，包括：检测所述多个主机节点的故障恢复情况，以及检测所述多个业务虚拟机的故障恢复情况；根据所述多个主机节点的故障恢复情况和所述多个业务虚拟机的故障恢复情况确定所述故障处理结果。

在本申请实施例中，超融合系统包括多个主机节点和多个业务虚拟机，通过检测多个主机节点的故障恢复情况，以及检测多个业务虚拟机的故障恢复情况，实现故障处理结果的有效确定。

作为一种可能的实现方式，所述多个主机节点的故障恢复情况用于表征各个所述主机的业务是否恢复，以及数据是否丢失；所述多个业务虚拟机的故障恢复情况用于表征各个所述业务虚拟机的业务数据和业务操作是否受到影响。

在本申请实施例中，通过上述的故障恢复情况的检测，实现超融合系统的可靠性和稳定性的有效测试。

第二方面，本申请实施例提供一种超融合系统的测试装置，包括：用于实现第一方面以及第一方面的任意一种可能的实现方式中所述的超融合系统的测试方法的各个功能模块。

第三方面，本申请实施例提供一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被计算机运行时，执行第一方面以及第一方面的任意一种可能的实现方式中所述的超融合系统的测试方法。

附图说明

为了更清楚地说明本申请实施例的技术方案，下面将对本申请实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本申请的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。

图1为本申请实施例提供的测试系统的结构示意图；

图2为本申请实施例提供的超融合系统的测试方法的流程图；

图3为本申请实施例提供的故障检测模型的调用示例图；

图4为本申请实施例提供的超融合系统的测试装置的结构示意图。

图标：400-超融合系统的测试装置；410-处理模块；420-检测模块。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行描述。

本申请实施例提供的超融合系统的测试方法应用于超融合系统，用于测试超融合系统的故障处理能力，通过测试故障处理能力，实现超融合系统的可靠性和稳定性的测试。举例来说，故障处理能力较强，则可靠性和稳定性也较高；故障处理能力较弱，则可靠性和稳定性也较差。

超融合系统，采用分布式存储，通过软件技术把多台服务器的物理磁盘通过网络融合为一个大的存储池，使用多副本的形式实现数据冗余，防止物理服务器、物理磁盘损坏导致数据丢失。多副本使用了多倍的存储空间，存放在不同的物理机器和物理磁盘。

通过结合虚拟化计算、网络虚拟化、多副本卷等特点，超融合系统上的业务虚拟机具有计算高可用、存储高可用、网络高可用等特性，即超融合系统内的节点允许在发生故障后做到业务数据不丢失，快速可恢复。

物理硬件资源作为超融合的载体，本身就具有通用服务器的融合特性，会发生CPU(Central Processing Unit，中央处理器)、内存、磁盘、网络引起的各类故障。

在超融合系统中，具有发生故障的可能性，而各个业务虚拟机或者主机节点，也具有相应的故障处理(恢复)能力，如果故障处理能力下降，则系统的稳定性和可靠性便会受到影响。因此，需要对超融合系统进行长期且有效的测试，以保证系统的稳定性和可靠性。

为了便于理解，请参照图1，为本申请实施例提供的超融合系统的测试架构示意图，在图1中，包括：超融合系统(即图中的超融合集群)和自动化测试服务器；自动化测试服务器与超融合系统通信连接。在一些实施例中，自动化测试服务器可以独立在超融合系统之外，也可以作为超融合系统的一部分。

本申请实施例提供的技术方案的硬件运行环境为自动化测试服务器。

在超融合系统中，包括多个主机节点(Host1、Host2、…HostN)，这多个主机节点组成一个超融合系统；还包括多个业务虚拟机。

每个主机节点上都有cpu、内存等计算资源；ssd(Solid State Disk或SolidState Drive，固态硬盘)、hdd(Hard Disk Drive，硬盘驱动器)等存储资源。各个主机节点之间通过网络连接在一起，再通过集群管理平台对资源进行统一管理，由超融合逻辑存储池划分不同的多副本卷给不同的业务虚拟机，业务虚拟机使用多副本的逻辑卷运行在集群中。

用户业务虚拟机运行在主机节点之上，数据则通过多个副本机制存放不同主机节点不同磁盘上，如果超融合中有故障出现，可通过检测虚拟机上的业务等判断提供给虚拟机的资源是否出现问题，以达到检测目的。

为了实现本申请实施例所提供的技术方案，该超融合系统需要具备一些基础条件，因此，可以预先对超融合系统作一些配置。

具体的，先保证超融合平台部署完成，环境检查正常。然后，正常创建测试租户及租户资源；以及正常创建集群测试管理员，避免登录冲突。接着，创建虚拟机，虚拟机采用2副本和3副本若干台，可在虚拟机内部署业务系统；也可在虚拟机内部装上压力测试工具如fio、iozone、memtest等，根据压力需求设置参数后设置开机启动；也可复制静态校验文件及动态校验文件；同时确定检测机制，如检测虚拟机是否启动成功。

以及，如果需要VPC(Virtual PC，网络虚拟机)网络功能测试，超融合平台上可启动VPC功能，相关测试虚拟机使用VPC网络，或使用VPC的浮动ip或端口功能让外部可访问需要校验的虚拟机，确定检测业务机制。

最后，记录所有主机节点的IPMI(Intelligent Platform ManagementInterface，智能平台管理接口)/BMC(Baseboard Management Controller，基板管理控制器)地址，并可以正常登录，发送IPMI命令。

可以理解，上述的超融合系统的基础配置，均属于本领域的常规技术手段，因此，在本申请实施例中不作详细介绍。

基于上述应用场景的介绍，请参照图2，为本申请实施例提供的超融合系统的测试方法的流程图，该测试方法包括：

步骤210：从预设的多个故障模型中确定出超融合系统的故障检测模型。

步骤220：在超融合系统中运行所述故障检测模型，以在超融合系统中引发故障检测模型对应的故障。

步骤230：检测引发故障检测模型对应的故障后的超融合系统的故障处理结果，并记录故障处理结果。

在本申请实施例中，与现有技术相比，预设多个故障模型，在需要对超融合系统进行测试时，从中确定出故障检测模型，然后在超融合系统中运行该故障检测模型以引发对应的故障，检测引发故障后的超融合系统的故障处理结果，并记录故障处理结果。可以理解，故障处理结果可以表征超融合系统的稳定性和可靠性，例如：故障处理失败，则代表稳定性可能下降，因此，通过这种测试方式，无需人工制造故障，能够实现超融合系统的有效测试。并且，在超融合系统的运行过程中，随时都可以按照该方法对其进行测试，这是一个可持续的过程，因此，能够实现超融合系统的长期测试。

接下来对该测试方法的详细实施方式进行介绍。

在步骤210中，从预设的多个故障模型中确定出超融合系统的故障检测模型，代表当前需要对超融合系统进行故障测试。

在一些实施例中，步骤210的执行可以是有条件的，即，故障测试具有对应的触发条件。

作为一种可选的实施方式，步骤210包括：在接收到测试指令时，从预设的多个故障模型中确定出超融合系统的故障检测模型。

在这种实施方式中，可以由研发人员或者系统发起测试指令，然后触发超融合系统的测试流程。

作为另一种可选的实施方式，步骤210包括：在当前时间到达预设的测试周期时，从预设的多个故障模型中确定出超融合系统的故障检测模型。

在这种实施方式中，超融合系统的测试可以是周期性的，例如：每隔1小时进行一次测试；那么，当检测到当前时间到达预设的测试周期时，便可触发超融合系统的测试流程。

除了上述的两种实施方式，在实际应用时，也可以结合具体的应用场景设置其他的测试触发条件，在本申请实施例中不作限定。

在步骤210中，所确定出的故障检测模型可以为一个，也可以为多个，通常情况来说为多个。在为多个的情况下，每个故障检测模型均会按照步骤220-步骤230的流程进行测试，并且，在各个故障检测模型之间，如果前一个故障检测模型对应的故障处理结果为故障处理失败，需要先对系统进行恢复之后，再继续进行下一个故障检测模型的测试；当然，如果前一个故障检测模型对应的故障处理结果为故障处理成功，则可直接进行下一个故障检测模型的测试。

预设的多个故障模型，用于在超融合系统中引发故障，可以理解为一种故障的触发程序，可以由研发人员根据超融合系统的特点进行预设。

作为一种可选的实施方式，多个故障模型包括：分别与不同的环境信息对应的故障模型，多个故障模型具有不同的故障等级。

其中，环境信息指的是超融合系统的环境信息，例如：不同的集群的服务器数量不一样，硬盘数量不一样，网络不一样等。多个故障模型具有的故障等级，可以是一部分故障模型对应一种故障等级，另一部分故障模型对应另一种故障等级，这两种故障等级不相同。

作为一种可选的实施方式，故障模型包括第一故障模型和第二故障模型，第一故障模型所引发的故障的故障等级低于第二故障模型所引发的故障的故障等级。

在这种实施方式中，第一故障模型为较为基础的故障模型，可引发低故障等级的故障；第二故障模型为较为高级的故障模型，可引发故障等级较高的故障。

具体的，第一故障模型所引发的故障可以包括：断电、断网、磁盘故障、内存故障、cpu故障、系统故障。第二故障模型引发的故障可以包括：网络丢包、时延，磁盘慢盘、坏盘，缓存故障。

在本申请实施例中，通过第一故障模型，可引发故障等级较低的故障；通过第二故障模型，可引发故障等级较高的故障；实现不同故障等级的故障的有效引发。

基于上述故障模型的实施方式的介绍，作为一种可选的实施方式，步骤210包括：确定超融合系统需要引发的故障的故障等级；确定超融合系统对应的环境信息；根据需要引发的故障的故障等级和超融合系统对应的环境信息从多个故障模型中确定出超融合系统的故障检测模型。

在这种实施方式中，可根据超融合系统的历史故障处理结果确定需要引发的故障的故障等级。举例来说，假设超融合系统的历史故障处理结果大部分都是处理成功，说明超融合系统已经可以较好的处理较为简单的故障，则可将需要引发的故障的故障等级确定为较高的故障等级。假设超融合系统的历史故障处理结果大部分都是处理失败，说明超融合系统对较为简单的故障的处理能力也较弱，需要继续训练处理简单的故障的能力，则可将需要引发的故障的故障等级确定为较低的故障等级。

在确定超融合系统对应的环境信息时，可以将超融合系统的实际环境与预设的各个环境信息进行比对，将与超融合系统的实际环境较为匹配的环境信息确定为超融合系统对应的环境信息。

在分别确定需要引发的故障的故障等级和超融合系统对应的环境信息之后，将预设的多个故障模型中，与需要引发的故障的故障等级和超融合系统对应的环境信息对应的故障模型确定为超融合系统的故障检测模型。

例如：假设确定超融合系统需要引发的故障的故障等级为较高的故障等级，则从第二故障模型中确定出与超融合系统的环境信息匹配的故障模型，作为超融合系统的故障检测模型。

在本申请实施例中，多个故障模型可以对应不同的环境信息，以及具有不同的故障等级；进而，分别确定故障等级和环境信息，利用故障等级和环境信息便可有效且准确的确定出对应的故障检测模型。

在步骤210中确定出故障检测模型之后，在步骤220中，在超融合系统中运行故障检测模型，以在超融合系统中引发故障检测模型对应的故障。

对于该步骤来说，只需在超融合系统中运行故障检测模型即可，例如：在业务虚拟机上执行故障检测模型中的故障任务1，以及在主机节点上执行故障检测模型中的故障任务2。

在执行步骤220之后，便会在超融合系统中引发故障检测模型对应的故障，然后再执行步骤230，检测引发故障检测模型对应的故障后的超融合系统的故障处理结果，并记录故障处理结果。

结合前述关于超融合系统的介绍，作为一种可选的实施方式，步骤230包括：检测多个主机节点的故障恢复情况，以及检测多个业务虚拟机的故障恢复情况；根据多个主机节点的故障恢复情况和多个业务虚拟机的故障恢复情况确定故障处理结果。

其中，多个主机节点的故障恢复情况用于表征各个主机的业务是否恢复，以及数据是否丢失；多个业务虚拟机的故障恢复情况用于表征各个业务虚拟机的业务数据和业务操作是否受到影响。

业务虚拟机的业务操作包括：增加快照、删除快照等。

在本申请实施例中，通过上述的故障恢复情况的检测，实现超融合系统的可靠性和稳定性的有效测试。

通过上述的故障恢复情况的检测，可确定故障处理结果。作为一种可选的实施方式，当故障恢复情况中，存在数据丢失，业务未恢复，业务数据受到影响，业务操作受到影响中的至少一项时，确定故障处理结果为故障处理失败，并将对应的未恢复项作为故障处理结果中的失败原因。当故障恢复情况中，不存在上述的各项时，则确定故障处理结果为故障处理成功。

在本申请实施例中，超融合系统包括多个主机节点和多个业务虚拟机，通过检测多个主机节点的故障恢复情况，以及检测多个业务虚拟机的故障恢复情况，实现故障处理结果的有效确定。

在确定故障处理结果之后，可将故障处理结果进行记录。参照前述实施例的介绍可知，如果当前的故障检测模型的故障处理结果为故障处理失败，则可先对超融合系统进行恢复，然后再继续下一个故障检测模型的测试。

以及，如果当前的故障检测模型的故障处理结果为故障处理成功，则可继续下一个故障检测模型的测试。

因此，作为一种可选的实施方式，在步骤230之后，该测试方法还包括：确定故障处理结果为故障处理失败；确定故障检测模型对应的故障恢复模型；在超融合系统中运行故障恢复模型，以使超融合系统恢复正常状态。

与故障检测模型类似，开发人员可以预设不同的故障检测模型对应的故障恢复模型，故障恢复模型可以理解为故障恢复程序或者故障恢复算法，通过在超融合系统中运行故障恢复模型，可以使超融合系统恢复正常状态。

在本申请实施例中，当故障处理结果为故障处理失败时，通过在超融合系统中运行故障恢复模型，使超融合系统恢复正常状态，进而保证超融合系统的正常运行，以及可以进行下一次的故障测试。

进一步地，在超融合系统恢复正常状态之后，该测试方法还包括：从预设的多个故障模型中确定出恢复正常状态后的超融合系统的新的故障检测模型；在恢复正常状态后的超融合系统中运行新的故障检测模型，以在恢复正常状态后的超融合系统中引发新的故障检测模型对应的故障；检测引发新的故障检测模型对应的故障后的超融合系统的新的故障处理结果，并记录新的故障处理结果。

在这种实施方式中，按照步骤210-步骤230的流程，再次对超融合系统进行测试。其中，新的故障检测模型可以与之前采用的故障检测模型不相同，当然，也可以相同，在此不作限定。以及，上述的测试流程中各个步骤的实施方式参照步骤210-步骤230的实施方式，在此不再重复介绍。

在本申请实施例中，基于恢复正常状态后的超融合系统，可确定出新的故障检测模型，并继续对其进行故障测试，以实现超融合系统的长期且有效的测试。

在实际应用时，本申请实施例可采用一轮多故障检测模型的方式对超融合系统进行故障测试，举例来说，在一轮中，设置5个故障检测模型，然后分别利用这5个故障检测模型对超融合系统进行故障测试。在完成每轮的故障测试之后，记录每轮中每个故障检测模型对应的故障处理结果，进而，可以根据记录的信息确定每个故障模型对应的故障处理结果为故障处理失败的次数。

在后续确定超融合系统的故障检测模型时，可以依据上述记录的信息确定。因此，作为一种可选的实施方式，从预设的多个故障模型中确定出恢复正常状态后的超融合系统的新的故障检测模型，包括：从预设的多个故障模型中确定出目标故障模型；目标故障模型对应的超融合系统的故障处理结果为故障处理失败的次数大于预设次数；从目标故障模型中确定出新的故障检测模型。

在这种实施方式中，将故障处理结果为故障处理失败的次数大于预设次数的故障模型作为新的故障检测模型，以对问题频繁的故障模型进行重复测试，以达到问题验证的目的。

其中，预设次数可以结合实际的情况进行设置，在此不作限定。

在本申请实施例中，在确定新的故障检测模型时，结合之前的故障模型对应的故障处理结果进行确定；将对应的故障处理结果为故障处理失败的次数大于预设次数的故障模型确定为目标故障模型，然后从中确定出新的故障检测模型；进而，实现超融合系统针对难以处理的故障的故障处理能力的不断测试。

在本申请实施例中，如果一轮的故障检测模型对应的故障处理结果均为失败，或者说连续几个故障检测模型对应的故障处理结果均为失败，此时，可以执行重新测试流程。具体的，再次通过这些失败的故障检测模型对超融合系统进行测试。

以及，在执行重新测试流程之后，将这个情况反映给开发人员，由开发人员来定位故障，或者对故障进行修复等。

在本申请实施例中，在运行故障检测模型之后，除了引发故障检测模型对应的故障之外，可能还会引发其他连锁的故障，此时，可以基于这部分的故障生成新的故障检测模型，并加入到预设的故障模型中，实现预设的故障模型的更新。

此外，在步骤230中记录故障处理结果之后，开发人员可以随时对故障处理结果进行查阅，以根据故障处理结果对超融合系统进行维护。

为了便于更清楚的理解本申请实施例所提供的技术方案，接下来对该技术方案在实际应用时的自动化测试流程进行举例介绍。

具体的，一个自动化测试的完整流程可以包括：

1.程序运行时会检查平台状态，节点状态，虚拟机状态，卷状态等。

2.通过自动化测试脚本调取模型中的故障任务1(即故障检测模型1，后续的故障任务同理)。

3.检查租户下的所有业务虚拟机是否都启动正常，故障后是否都恢复。

4.通过自动化测试脚本调取模型中的恢复任务1(即故障恢复模型1，后续的恢复任务同理)。

5.检查平台状态，节点状态，虚拟机状态，卷状态等，如果都正常刚下一步。

6.通过自动化测试脚本调取模型中的故障任务2。

7.检查租户下的所有业务虚拟机是否都启动正常，故障后是否都恢复。

8.通过自动化测试脚本调取模型中的恢复任务2。

9.检查平台状态，节点状态，虚拟机状态，卷状态等，如果都正常刚下一步。

10.通过自动化测试脚本调模型中的故障任务3。

11.检查租户下的所有业务虚拟机是否都启动正常，故障后是否都恢复。

12.通过自动化测试脚本调取模型中的恢复任务3。

13.检查平台状态，节点状态，虚拟机状态，卷状态等，如果都正常刚下一步。

14.通过自动化测试脚本调取模型中的故障任务N。

15.第一轮基础模型库调用完成之后，第二轮调用会同时增加环境模型库，即基础模型库和环境模型库整合到一起，第三轮调用会再次增加高级模型库，每次有新故障任务类型，下一轮调用就会增加。

基础故障模型任务说明：故障模型中的故障任务可随机，即根据不同故障类型不同节点或不同节点功能进行组合；也可按顺序，即所有节点都故障一遍之后再从节点1循环，不断重复，每一步的检查如果不通过都增加重试，并等待测试人员介入定位故障。

同时把这次失败任务记录到故障测试模型当中。下次再次调用模型任务时可根据失败或成功的记录，进行自动化测试算法调整，对出问题频繁的任务重点调用，以达到问题验证目的。遇到基础模型中未曾学习到的故障任务类型，则需要加入到模型中，完善高级特性。

基础模型库：假设只有5种故障任务类型，都调用完成之后，只有一种任务导致出问题，则模型库进行记录执行结果。

第二次模型库调用前就会先判断失败任务次数，当失败任务次数超过3时，调用权重加1，则增加一次调用，当失败任务次数超过6时，调用权重加1，如此类推。

具体的，可以参见如图3所示，记录每次任务的成功或者失败次数，然后在下次调用时，结合记录的信息进行调用。

环境模型库：基础模型库中的任务类型可根据不同环境进行增加，如不同的集群的服务器数量不一样，硬盘数量不一样，网络不一样，每个超融合系统都有部分特有的环境信息，当环境中有使用固态硬盘作为缓存时，增加缓存故障任务类型，从而更新环境模型库。

高级模型库：当产生一项故障任务时，往往会引起超融合系统程序各种检测处理机制，即程序某个故障处理机制的触发是根据另外一种错误提示决定的(如虚拟机的崩溃可能是由系统盘读取出错导致的)，所以会在上面的两种模型库运行过程中不断学习到关联的细分故障类型或新故障，从而加入到高级模型库中，从而实时更新高级模型库。

通过前述实施例的介绍，可以看出，采用本申请实施例所提供的测试方案，可以实现测试的自动化，人工干预少。并且，还可以实现对引发故障后的集群是否可正常恢复，业务是否恢复，数据是否丢失的长期(7*24)有效测试机制，从而应对生产环境中突发的故障处理机制，保证超融合产品的稳定性。

基于同一发明构思，请参照图4，本申请实施例中还提供一种超融合系统的测试装置400，包括：处理模块410和检测模块420。

处理模块410，用于：从预设的多个故障模型中确定出超融合系统的故障检测模型；在所述超融合系统中运行所述故障检测模型，以在所述超融合系统中引发所述故障检测模型对应的故障。检测模块420，用于检测引发所述故障检测模型对应的故障后的超融合系统的故障处理结果，并记录所述故障处理结果。

在本申请实施例中，处理模块410具体用于：确定所述超融合系统需要引发的故障的故障等级；确定所述超融合系统对应的环境信息；根据所述需要引发的故障的故障等级和所述超融合系统对应的环境信息从所述多个故障模型中确定出所述超融合系统的故障检测模型。

在本申请实施例中，处理模块410还用于：确定所述故障处理结果为故障处理失败；确定所述故障检测模型对应的故障恢复模型；在所述超融合系统中运行所述故障恢复模型，以使所述超融合系统恢复正常状态。

在本申请实施例中，处理模块410还用于：从所述预设的多个故障模型中确定出恢复正常状态后的超融合系统的新的故障检测模型；在所述恢复正常状态后的超融合系统中运行所述新的故障检测模型，以在所述恢复正常状态后的超融合系统中引发所述新的故障检测模型对应的故障；检测模块420还用于：检测引发所述新的故障检测模型对应的故障后的超融合系统的新的故障处理结果，并记录所述新的故障处理结果。

在本申请实施例中，处理模块410具体用于：从所述预设的多个故障模型中确定出目标故障模型；所述目标故障模型对应的超融合系统的故障处理结果为故障处理失败的次数大于预设次数；从所述目标故障模型中确定出所述新的故障检测模型。

在本申请实施例中，检测模块420具体用于：检测所述多个主机节点的故障恢复情况，以及检测所述多个业务虚拟机的故障恢复情况；根据所述多个主机节点的故障恢复情况和所述多个业务虚拟机的故障恢复情况确定所述故障处理结果。

超融合系统的测试装置400与前述的测试方法对应，各个功能模块也与各个步骤对应，因此，各个功能模块的实施方式参照前述实施例中的介绍，在此不再重复介绍。

基于同一发明构思，本申请实施例还提供一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序，该计算机程序被计算机运行时，执行前述实施例中所述的超融合系统的测试方法。

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

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

再者，在本申请各个实施例中的各功能模块可以集成在一起形成一个独立的部分，也可以是各个模块单独存在，也可以两个或两个以上模块集成形成一个独立的部分。

在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。

以上所述仅为本申请的实施例而已，并不用于限制本申请的保护范围，对于本领域的技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。

Claims (10)

1.一种超融合系统的测试方法，其特征在于，包括：

从预设的多个故障模型中确定出超融合系统的故障检测模型；

在所述超融合系统中运行所述故障检测模型，以在所述超融合系统中引发所述故障检测模型对应的故障；

检测引发所述故障检测模型对应的故障后的超融合系统的故障处理结果，并记录所述故障处理结果。

2.根据权利要求1所述的测试方法，其特征在于，所述多个故障模型包括：分别与不同的环境信息对应的故障模型，所述多个故障模型具有不同的故障等级；所述从预设的多个故障模型中确定出超融合系统的故障检测模型，包括：

确定所述超融合系统需要引发的故障的故障等级；

确定所述超融合系统对应的环境信息；

根据所述需要引发的故障的故障等级和所述超融合系统对应的环境信息从所述多个故障模型中确定出所述超融合系统的故障检测模型。

3.根据权利要求2所述的测试方法，其特征在于，所述故障模型包括第一故障模型和第二故障模型，所述第一故障模型所引发的故障的故障等级低于所述第二故障模型所引发的故障的故障等级；所述第一故障模型所引发的故障包括：断电、断网、磁盘故障、内存故障、cpu故障、系统故障；所述第二故障模型引发的故障包括：网络丢包、时延，磁盘慢盘、坏盘，缓存故障。

4.根据权利要求1所述的测试方法，其特征在于，所述测试方法还包括：

确定所述故障处理结果为故障处理失败；

确定所述故障检测模型对应的故障恢复模型；

在所述超融合系统中运行所述故障恢复模型，以使所述超融合系统恢复正常状态。

5.根据权利要求4所述的测试方法，其特征在于，所述测试方法还包括：

从所述预设的多个故障模型中确定出恢复正常状态后的超融合系统的新的故障检测模型；

在所述恢复正常状态后的超融合系统中运行所述新的故障检测模型，以在所述恢复正常状态后的超融合系统中引发所述新的故障检测模型对应的故障；

检测引发所述新的故障检测模型对应的故障后的超融合系统的新的故障处理结果，并记录所述新的故障处理结果。

6.根据权利要求5所述的测试方法，其特征在于，所述从所述预设的多个故障模型中确定出恢复正常状态后的超融合系统的新的故障检测模型，包括：

从所述预设的多个故障模型中确定出目标故障模型；所述目标故障模型对应的超融合系统的故障处理结果为故障处理失败的次数大于预设次数；

从所述目标故障模型中确定出所述新的故障检测模型。

7.根据权利要求1所述的测试方法，其特征在于，所述超融合系统包括：多个主机节点和多个业务虚拟机；所述检测引发所述故障检测模型对应的故障后的超融合系统的故障处理结果，包括：

检测所述多个主机节点的故障恢复情况，以及检测所述多个业务虚拟机的故障恢复情况；

根据所述多个主机节点的故障恢复情况和所述多个业务虚拟机的故障恢复情况确定所述故障处理结果。

8.根据权利要求7所述的测试方法，其特征在于，所述多个主机节点的故障恢复情况用于表征各个所述主机的业务是否恢复，以及数据是否丢失；所述多个业务虚拟机的故障恢复情况用于表征各个所述业务虚拟机的业务数据和业务操作是否受到影响。

9.一种超融合系统的测试装置，其特征在于，包括：

处理模块，用于：

从预设的多个故障模型中确定出超融合系统的故障检测模型；

在所述超融合系统中运行所述故障检测模型，以在所述超融合系统中引发所述故障检测模型对应的故障；

检测模块，用于检测引发所述故障检测模型对应的故障后的超融合系统的故障处理结果，并记录所述故障处理结果。

10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被计算机运行时，执行如权利要求1-8任一项所述的超融合系统的测试方法。

Images