一种集群的测试方法与流程

文档序号:11929974阅读:394来源:国知局
一种集群的测试方法与流程

本发明涉及集群领域,具体来说,涉及一种集群的测试方法。



背景技术:

当前存储技术正在从以盘阵为代表的纵向扩展技术向以集群为代表的横向扩展技术发展,而这种横向扩展的主体则是运行类UNIX操作系统、Linux操作系统的存储服务器节点,因此,在对集群的可用性和可靠性测试时,需要对整个集群注入一定故障,包括电源故障、硬盘故障、节点故障、网络故障、RAID控制器故障、RAID卷故障等复杂的故障,但是,一般情况下,这些故障注入都是由人对机器进行物理操作来注入故障,比如插拔电源线、插拔网线等物理操作来进行故障注入,上述故障注入方法虽然真实,但这个方法不具有时效性、准确性和可重复性,不便于发现系统漏洞后追查问题,而且由每个人负责的测试脚本也易出现浪费工作量、故障注入方法不统一、增加复现程序漏洞的交流成本、脚本碎片化严重等问题,且由于碎片化的问题,难以用一套标准的方法加入自动化测试框架中使用,因此,需要引入一种比较有效率的测试方法,以便在测试初期可以自动化的进行故障注入,缩短代码测试周期,增加测试效率。

针对相关技术中的问题,目前尚未提出有效的解决方案。



技术实现要素:

针对相关技术中的问题,本发明提出一种集群的测试方法,能够使故障注入的方法标准化,保证故障注入动作具有时效性,同时使故障注入行为具有时间上和频率上的可重复性。

本发明的技术方案是这样实现的:

根据本发明的一个方面,提供了一种集群的测试方法。

该集群的测试方法包括:步骤S1,设置待注入故障节点的系统类型;步骤S2,将第一软件包注入待注入故障节点,以构建软件的可运行环境;步骤S3,判断步骤S1和步骤S2是否执行成功,若成功,则执行步骤S4,若不成功,则执行步骤S5;步骤S4,向待注入故障节点注入故障;步骤S5,清除待注入故障节点的操作系统的修改。

根据本发明的一个实施例,系统类型包括至少以下系统之一:Linux操作系统、类UNIX操作系统。

根据本发明的一个实施例,进一步包括:步骤S1,设置多个待注入故障节点的类UNIX系统类型;步骤S2,将多种第一软件包分别注入多个待注入故障节点,以构建多个软件的可运行环境;步骤S3,判断步骤S1和步骤S2是否执行成功,若成功,则执行步骤S4,若不成功,则执行步骤S5;步骤S4,向多个待注入故障节点同时注入多个故障;步骤S5,清除待注入故障节点的操作系统的设置。

根据本发明的一个实施例,通过第二软件包设置故障节点的系统类型。

根据本发明的一个实施例,第二软件包括以下至少之一:Solaris系统的配置软件包、FreeBSD系统配置软件包、RHEL系统配置软件包、SLES系统配置软件包。

根据权利要求1的测试方法,其特征在于,第一软件包包括以下至少之一:SAS控制器的命令行工具、RAID控制器的命令行控制工具、RAID卷的配置函数。

根据本发明的一个实施例,注入故障包括以下至少之一:电源故障、硬盘故障、节点故障、网络故障、磁盘阵列的卷故障、磁盘阵列的控制器故障。

本发明的有益技术效果在于:

本发明通过设置待注入故障节点的系统类型,随后将第一软件包注入待注入故障节点,以构建软件的可运行环境,随后向待注入故障节点注入故障,基于该测试方案,从而能够使故障注入的方法标准化,保证故障注入动作具有时效性,同时使故障注入行为具有时间上和频率上的可重复性。

附图说明

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

图1是根据本发明实施例的集群的测试方法的流程图;

图2是根据本发明具体实施例的集群的测试方法的流程图。

具体实施方式

下面将结合本发明实施例中的附图,对本发明实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本发明一部分实施例,而不是全部的实施例。基于本发明中的实施例,本领域普通技术人员所获得的所有其他实施例,都属于本发明保护的范围。

根据本发明的实施例,提供了一种集群的测试方法。

如图1所示,根据本发明实施例的集群的测试方法包括:

步骤S101,设置待注入故障节点的系统类型;

步骤S103,将第一软件包注入待注入故障节点,以构建软件的可运行环境;

步骤S105,判断步骤S101和步骤S103是否执行成功,若成功,则执行步骤S107,若不成功,则执行步骤S109;

步骤S107,向待注入故障节点注入故障;

步骤S109,清除待注入故障节点的操作系统的修改。

通过本发明的上述方案,能够通过设置待注入故障节点的系统类型,随后将第一软件包注入待注入故障节点,以构建软件的可运行环境,随后向待注入故障节点注入故障,基于该测试方案,从而能够使故障注入的方法标准化,保证故障注入动作具有时效性,同时使故障注入行为具有时间上和频率上的可重复性。

根据本发明的一个实施例,系统类型包括至少以下系统之一:Linux操作系统、类UNIX操作系统。

根据本发明的一个实施例,进一步包括:步骤S1,设置多个待注入故障节点的类UNIX系统类型;步骤S2,将多种第一软件包分别注入多个待注入故障节点,以构建多个软件的可运行环境;步骤S3,判断步骤S1和步骤S2是否执行成功,若成功,则执行步骤S4,若不成功,则执行步骤S5;步骤S4,向多个待注入故障节点同时注入多个故障;步骤S5,清除待注入故障节点的操作系统的设置。

根据本发明的一个实施例,通过第二软件包设置故障节点的系统类型。

根据本发明的一个实施例,第二软件包括以下至少之一:Solaris系统的配置软件包、FreeBSD系统配置软件包、RHEL系统配置软件包、SLES系统配置软件包。

根据权利要求1的测试方法,其特征在于,第一软件包包括以下至少之一:SAS控制器的命令行工具、RAID控制器的命令行控制工具、RAID卷的配置函数。

根据本发明的一个实施例,注入故障包括以下至少之一:电源故障、硬盘故障、节点故障、网络故障、磁盘阵列的卷故障、磁盘阵列的控制器故障。

为了更好的描述本发明,下面通过具体的实施例进行详细的描述。

本发明采用Linux下Python编程语言和Shell脚本实现故障注入行为,同时,采用C语言配合RAID控制器、SAS控制器厂商的官方库函数以及POSIX标准函数实现故障注入方法,从而通过软件的形式实现本专利的方法,将软件打包成1个压缩包,并且采用2级目录结构,同时,根目录下存放3个主脚本和5个文件夹,其中,3个主脚本包括:

Failure_Inject:按照此脚本跟随的参数,注入参数所描述的故障行为;

Sys_Set:用于完成软件包及其依赖包的配置,不同操作系统的环境配置,厂商库函数源码的安装等;

Clean:用于清除此软件对操作系统进行的所有更改。

5个文件目录包括:

include:内含4个压缩包,sol.tar.gz、bsd.tar.gz、rhel.tar.gz、suse.tar.gz,用于存放针对不同操作系统定制的系统配置脚本和可执行文件,其中,sol.tar.gz存放Solaris操作系统可用的文件,bsd.tar.gz存放FreeBSD操作系统可用的文件,rhel.tar.gz存放RHEL操作系统可用的文件,sles.tar.gz存放SLES操作系统可用的文件;

source:存放软件运行过程中需要使用的库函数或依赖包的压缩包,其包括sas3ircu、sas2ircu、megacli、storcli、storlib等用于操作和监控RAID控制器及硬盘、SAS控制器及硬盘的工具包和库函数;

src:存放针对不同硬件故障注入的子脚本,包括NAS_CTL、POWER_CTL、PACKED_CTL、BOND_CTL、ETH_CTL、SAS_SATA_CTL、RAID_VOL_CTL等脚本,其分别是针对集群NAS、节点电源、网口网络包、bond网口、物理网口、SAS控制器上物理盘、RAID控制器上逻辑卷的故障注入脚本;

Logs:存放日志文件,其针对不同硬件注入的故障,会记录在独立的文件中,便于追溯故障注入的过程;

Tmp:存放临时数据。

表1

1级目录下存放主脚本作为程序入口,调用src下脚本协同工作,文件目录结构如表1所示。

进一步,本发明的集群的测试方法如图2所示,具体地:

步骤1,调用Sys_Set程序,使用include目录中的相应软件包设置待注入故障节点的操作系统,使其符合Failure_Inject程序的要求,同时将配置过程的日志写入logs目录;

步骤2:调用Sys_Set程序,使用source目录中的软件包配置待注入故障节点,构建Failure_Inject可运行的软件环境,同时将配置过程的日志写入logs目录;

步骤3:判断步骤1和步骤2是否成功,若成功则进入步骤4,若失败则进入步骤5;

步骤4:步骤1和步骤2执行成功,使用Failure_Inject程序按照设定的参数向预定的节点注入故障,同时将故障注入的log写入到logs目录,然后退出;

步骤5:步骤1和步骤2执行失败,使用Clean程序清除对节点操作系统的修改,然后通知使用者检查问题并退出。

综上所述,借助于本发明的上述技术方案,通过该集群测试方法,在Linux操作系统下对集群中的节点进行配置和自动故障注入,并自动记录便于回溯,同时,兼容类UNIX操作系统,如RHEL系统、CentOS系统、SLES系统、Solaris系统等,还支持包括NAS业务网、节点电源故障、节点网口丢包故障、bonding网口故障、物理网管故障、SAS控制器上硬盘故障、RAID逻辑卷故障等故障内容,此外,通过该集群测试方法,还可以在研发测试阶段节约大量测试人力,实现故障自动化注入,加速分布式存储系统软件开发进度。

以上所述仅为本发明的较佳实施例而已,并不用以限制本发明,凡在本发明的精神和原则之内,所作的任何修改、等同替换、改进等,均应包含在本发明的保护范围之内。

当前第1页1 2 3 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1