Disk array test method, storage medium, electronic equipment and program product

Abstract

The invention discloses a disk array testing method, a storage medium, electronic equipment and a program product, and relates to the technical field of computers. Firstly, disk testing data corresponding to a disk testing set is acquired; determining disk arrays corresponding to different disk types in the disk test set and fault injection data corresponding to different disk arrays according to the disk test data; and finally, testing the different disk arrays according to the fault injection data corresponding to the different disk arrays, and obtaining test results corresponding to the different disk arrays. Compared with the prior art, the method has the advantages that the fault injection data corresponding to different disk arrays can be acquired according to the disk test data, and the fault injection data are utilized to perform fault injection test on the different disk arrays, so that automatic test of the plurality of disk arrays is realized; according to the invention, independent configuration and test operation are not required to be carried out on the to-be-tested disk arrays one by one, so that the test workload is reduced, and the test efficiency is effectively improved.

Description

Technical Field

[0001] The present disclosure relates to the field of computer technologies, and in particular, to a method for testing a disk array, a storage medium, an electronic device, and a program product. Background Art

[0002] Redundant Arrays of Independent Disks (RAID) is a technology that combines multiple physical hard disks into one or more logical units to improve the performance, reliability, and capacity of a data storage system, and is used to provide various data protection and performance enhancement services.

[0003] In related technologies, the disk redundant array (disk array) to be tested is usually configured and tested separately, and multiple disk arrays cannot be tested, which increases the test workload and reduces the test efficiency. Summary of the Invention

[0004] The present disclosure provides a method for testing a disk array, a storage medium, an electronic device, and a program product. Its main purpose is to solve the problem that in related technologies, the disk array to be tested is usually configured and tested separately, and multiple disk arrays cannot be tested, which increases the test workload and reduces the test efficiency.

[0005] In a first aspect, the present application provides a method for testing a disk array, including: Obtaining disk test data corresponding to a disk test set; Determining, according to the disk test data, disk arrays corresponding to different disk types in the disk test set, and fault injection data corresponding to different disk arrays; Testing different disk arrays according to the fault injection data corresponding to different disk arrays, and obtaining test results corresponding to different disk arrays.

[0006] In a second aspect, the present application provides a device for testing a disk array, including: An obtaining module, configured to obtain disk test data corresponding to a disk test set; A determining module, configured to determine, according to the disk test data, disk arrays corresponding to different disk types in the disk test set, and fault injection data corresponding to different disk arrays; An obtaining module, configured to test different disk arrays according to the fault injection data corresponding to different disk arrays, and obtain test results corresponding to different disk arrays.

[0007] In a third aspect, the present application provides a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, the method of the first aspect is implemented.

[0008] In a fourth aspect, the present application provides an electronic device, including a storage medium, a processor, and a computer program stored on the storage medium and executable on the processor, and when the processor executes the computer program, the method of the first aspect is implemented.

[0009] In a fifth aspect, the present application provides a computer program product, on which a computer program is stored, and when the computer program is executed by a processor, the method of the first aspect is implemented.

[0010] The disk array testing method, storage medium, electronic device, and program product provided by the present disclosure, wherein the method includes: first, obtaining disk test data corresponding to a disk test set; then, according to the disk test data, determining disk arrays corresponding to different disk types in the disk test set, and fault injection data corresponding to different disk arrays; and finally, testing different disk arrays according to the fault injection data corresponding to different disk arrays, and obtaining test results corresponding to different disk arrays. Compared with the current existing technologies, the present application can first obtain the disk test data of a disk test set preset by a user, determine different disk types to be tested by parsing the disk test data, determine the disk arrays to be tested according to different disk types, obtain the fault injection data corresponding to different disk arrays according to the disk test data, and perform fault injection testing on different disk arrays by using the fault injection data, realizing the automated testing of multiple disk arrays, without performing separate configuration and testing operations on each of the multiple disk arrays to be tested one by one, reducing the testing workload, and effectively improving the testing efficiency.

[0011] It should be understood that the content described in this part is not intended to identify the key or important features of the embodiments of the present application, nor is it used to limit the scope of the present application. Other features of the present application will become easily understood through the following description. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] To illustrate the embodiments of the present application more clearly, the following will briefly introduce the drawings required for the embodiments. Obviously, the drawings in the following description are only some embodiments of the present application, and those of ordinary skill in the art can also obtain other drawings based on these drawings without creative efforts.

[0013] Figure 1 It shows a schematic flowchart of a disk array testing method provided by an embodiment of the present application; Figure 2 It shows a schematic flowchart of another disk array testing method provided by an embodiment of the present application; Figure 3 A schematic diagram showing an example provided by an embodiment of the present application; Figure 4 A schematic structural diagram of a disk array test device provided by an embodiment of the present application. Detailed implementation manners

[0014] Next, the technical solutions in the embodiments of the present application will be clearly and completely described in conjunction with the accompanying drawings in the embodiments of the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without making creative efforts belong to the protection scope of the present application.

[0015] It should be noted that in the description of the present application, the terms "include", "comprise" or any other variant thereof are intended to cover a non-exclusive inclusion, so that a process, method, article or device including a series of elements not only includes those elements, but also includes other elements not expressly listed, or further includes elements inherent to such process, method, article or device. The terms "first", "second", etc. in the present application are used to distinguish similar objects, rather than to describe a specific order or sequence.

[0016] A disk array is composed of many independent disks, combined into a disk group with a huge capacity. By using the additive effect generated by individual disks to provide data, the performance of the entire disk system is improved. Using this technology, data can be cut into many segments and stored on each hard disk respectively. When a member disk fails, data can still be read and written. When there is a hot spare disk or a hot spare area, data reconstruction can be performed, and the data can be recalculated and rewritten into a new hard disk or a hot spare area. The RAID technology is a very core technology for storage, which can not only provide data storage, but also provide important data reliability. When a member disk of the RAID fails or is restored, various background tasks of the RAID will be triggered, such as reconstruction and backcopy. Therefore, the key test scenario for the RAID technology is to ensure that the customer's read and write operations are not affected when a member disk fails.

[0017] In some embodiments, there are various types of RAID composed of multiple hard disks, such as RAID5 and RAID6. The main difference lies in the different redundancy levels of the RAID. That is, when the redundancy level is N, N member disks can fail simultaneously, ensuring that the RAID remains online and the business is not interrupted, and the lost data can be reconstructed through other online member disks. With the continuous improvement of current technologies and the increasing requirements for reliability in storage services, the number of simultaneously failed member disks has increased, so the requirements for the redundancy level of the RAID have also increased. Currently, the common redundancy levels of RAID are 1 or 2, and the redundancy level of new RAID types can reach 3. In the future, it is very likely that even higher redundancy levels will be required.

[0018] Specifically, because the redundancy levels of each disk array are different, the number of member disks that can fail in the RAID is different. However, the test points for different RAID types are basically the same, and the test steps and expected results are basically the same. Therefore, a general method can be used to implement the failure simulation test for different RAID types, which is implemented in an automated way. This can not only automatically execute to release human resources and improve the utilization rate of test equipment, but also reuse this method to execute the test even if a new RAID type is added in the future, and execute the test efficiently and quickly.

[0019] Currently, in the related art, for the RAID to be tested, automated tests are performed through a specific configuration and specific operations. Exemplarily, the automation of a certain fixed test scenario can be achieved through a scripting language. For example, a simulation test for the failure of 1 disk in RAID5 and a test for the failure of 1 disk in RAID6 can be performed. However, this method requires script adjustment for the RAID to be tested. When changing the test object, such as adding or reducing a RAID type, the automated script must be modified to adapt. It fails to implement multiple test scenarios through a single script tool and cannot cover the testing of multiple RAID types. Secondly, the automated scripts constructed in the related art cover a single test point. To ensure the test coverage rate, multiple automated scripts need to be executed sequentially. The cycle of a single failure simulation injection is long due to the long reconstruction and copy-back times, resulting in a long test time for the disk array.

[0020] In order to improve the technical problems in the current related art that when usually performing separate configuration and test operations on the disk array to be tested, it is impossible to test multiple disk arrays, which increases the test workload and reduces the test efficiency.

[0021] This embodiment provides a disk array test method, as Figure 1 shown. This method includes the following steps: Step 101, obtain the disk test data corresponding to the disk test set.

[0022] In some embodiments, a preset script can be used to customize the disk test data corresponding to the disk test set to be tested. The preset script can be used to receive at least one disk type preset by the user and the fault injection data corresponding to different disk types. The disk test set can include at least one disk array. Specifically, it can include the disk arrays that have been created in the current storage system, or can also include the disk arrays that need to be newly created. The disk test data can include, but is not limited to, the disk types preset by the user, the fault injection data corresponding to each disk type, etc. When a new disk array needs to be created, the disk creation information of the at least one newly created disk array can be configured in the disk test data to automatically create the disk, and then perform the test after creation, so as to meet various user requirements. The disk creation information can include the newly created RAID type, array width, stripe width, number of hot spares, number of newly created RAIDs, etc.

[0023] Step 102: According to the disk test data, determine the disk arrays corresponding to different disk types in the disk test set, and the fault injection data corresponding to different disk arrays.

[0024] In some embodiments, the disk test data preset by the user can be parsed, and then different disk types to be tested can be extracted from it. Different disk arrays to be tested can be determined through different disk types, and the fault injection data corresponding to each disk type can be determined according to the corresponding relationship of the configuration information in the script. In this way, the test data corresponding to all disk arrays to be tested can be obtained, without the need to build multiple scripts to configure multiple disk arrays one by one, reducing the configuration time of the disk test data.

[0025] Correspondingly, if the disk array to be tested is a newly created disk array, the disk type can be obtained based on the disk creation information configured during creation, as well as the fault injection data corresponding to the newly created disk array. The fault injection data can include the preset number of faulty disks corresponding to each disk array, which can be used to simulate faults for the member disks with the preset number of faulty disks in the disk array to make them offline, and then detect the usage of the disk array.

[0026] Step 103: According to the fault injection data corresponding to different disk arrays, test different disk arrays and obtain the test results corresponding to different disk arrays.

[0027] In some embodiments, after configuring multiple disk types to be tested and fault injection data using a preset script, the fault injection data can be applied to perform fault injection operations on different disk arrays respectively, simulate faults for multiple disk arrays, detect the data processing situation after they fail, and implement parallel fault injection testing for multiple disk arrays. There is no need to test multiple disk arrays one by one, reducing the testing time for sequential testing of multiple disk arrays, thereby improving the testing efficiency of disk arrays and achieving testing of different disk arrays.

[0028] Compared with the current existing technologies, in this embodiment, the disk test data corresponding to the disk test set preset by the user can be obtained first. By analyzing the disk test data, different disk types to be tested are determined. Disk arrays to be tested are determined according to different disk types, and the fault injection data corresponding to different disk arrays is obtained according to the disk test data. Fault injection testing is performed on different disk arrays using the fault injection data, realizing automated testing of multiple disk arrays. There is no need to perform separate configuration and testing operations on multiple disk arrays to be tested one by one, reducing the testing workload and effectively improving the testing efficiency.

[0029] To further illustrate the specific implementation process of the method in this embodiment, this embodiment provides a specific method as shown in Figure 2 and the method includes: Step 201, obtain the disk test data corresponding to the disk test set.

[0030] Optionally, the method in this embodiment may further include: obtaining the preset test cycle and preset cycle interval of the disk test set; performing multiple tests on the disk test set according to the test cycle and preset cycle interval.

[0031] Exemplarily, the disk test data defined by the user may include disk creation information, disk attribute information, preset test cycle, preset cycle interval, etc.

[0032] In some embodiments, the preset test cycle and preset cycle interval of the disk test set can be configured using a preset script for performing multi-round tests on the disk test set scenarios, improving the accuracy of test results, and thus realizing loop iteration testing. Exemplarily, the number of times of cycle execution can be set to n, and the interval time of each cycle can be set to i. By detecting whether the number of tests reaches n, it is determined whether to end all loop operations.

[0033] Optionally, the method in this embodiment further includes: configuring the disk test data preset by the user using a preset script and performing legality detection on the disk test data.

[0034] Exemplarily, the preset script can be a general test script for building a disk test set, eliminating the need for multiple scripts to test each disk array separately and reducing configuration operations. The corresponding legality detection can include detection contents such as validity, mutual exclusivity, optional and mandatory.

[0035] By detecting and blocking illegal inputs in advance, it helps to ensure that the input data conforms to the expected format and range, avoid program crashes or other serious errors caused by invalid data, ensure the system continues to run normally, and reduce the overall impact.

[0036] Step 202: Create disk arrays of different disk types according to the disk creation information in the disk test data; and / or, select disk arrays of different disk types from the created disk arrays according to the disk attribute information in the disk test data.

[0037] Among them, the disk creation information can include, for the newly created disk arrays, the attribute information configured for the newly created disk arrays, such as: preset new type, array width, stripe width, hot spare quantity, number of newly created RAID, number of member disk failures (number of failed disks), etc., for creating multiple disk arrays; the disk attribute information can include, for the created disk arrays, the attribute information configured for the disk arrays to be tested, such as: ID, name, preset type, redundancy, preset number of failed disks, etc., for selecting disk arrays from the created disk arrays.

[0038] In some embodiments, in order to flexibly implement a custom test set, during testing, the disk creation information in the disk test data can be configured using the preset script, multiple different or the same type of RAID can be created, and then the fault injection operation can be performed on the newly created RAID respectively. Correspondingly, the disk arrays already created in the storage system can also be tested, some or all of the created disk arrays can be selected for testing, and then the fault injection operation can be performed on the selected RAID respectively.

[0039] In this way, the fault injection operation can be performed on the existing RAID in the storage system, and new RAID can also be created and operated on the newly created RAID, thereby improving the flexibility and scalability of disk testing.

[0040] Exemplarily, the specific configuration of the disk creation information is as follows: The new type (--create_RAID_level) can be used to configure the disk types corresponding to the newly created RAID respectively, and can be set as a mandatory parameter that cannot be omitted. The setting format can be expressed as: --create_RAID_level=RAID1R:RAID2R:RAID1R, indicating that 3 disk arrays are created, and the disk types are RAID1R, RAID2R, and RAID1R respectively; The hot spare quantity (--spare_count) can be used to configure the number of hot spare areas corresponding to the newly created RAID. If it is not specified, it can be set according to the minimum hot spare quantity of the disk array (such as 1). The setting format can be expressed as: --spare_count=1:2:1, indicating that the hot spare quantities corresponding to the disk types of the newly created RAID are 1, 2, and 1 respectively; The array width (--drive_count) can be used to configure the number of member disks of the newly created RAID. It can be set as a required parameter and cannot be omitted. The setting format can be expressed as: --drive_count=7:8:10, indicating that the numbers of member disks corresponding to the disk types of the newly created RAID are 7, 8, and 10 respectively; The stripe width (--strip_wIDth) can be used to configure the stripe width of the newly created RAID. If it is not specified, it can be set according to the minimum stripe width. The setting format can be expressed as: --strip_wIDth=6:8:10, indicating that the stripe widths corresponding to the disk types of the newly created RAID are 6, 8, and 10 respectively; The fault configuration parameter (--offline_disk_count) can be used to configure the number of faulty disks of the newly created RAID as fault injection data. If it is not specified, it is set according to the maximum redundancy corresponding to the RAID type.

[0041] Exemplarily, the specific configuration of the disk attribute information is as follows: The test type parameter (--op_RAID_level), this parameter can be used to configure the RAID type to be tested. The setting format of this parameter can be expressed as: --op_RAID_level=RAID1R:RAID2R:RAID3R. Multiple RAID types can be configured in this format; The fault configuration parameter (--offline_disk_count), this parameter can be used to configure the number of faulty member disks in the disk array to be tested. The setting format of this parameter can be expressed as: --offline_disk_count=1:2:3. The preset number of faulty disks corresponding to multiple RAID types can be configured in this format, that is, for the disk array with the preset type of RAID1R, its preset number of faulty disks is configured to be 1.

[0042] In this way, the unified configuration of the disk attribute information of multiple disk arrays is realized, eliminating the need for users to configure multiple disk arrays separately using multiple scripts, reducing the configuration time, and improving the test efficiency.

[0043] Optionally, according to the disk attribute information in the disk test data, select disk arrays of different disk types from the created disk arrays. Specifically, it may include: determining whether the type configuration field in the disk attribute information is default; if the type configuration field is default, use the created disk array as the selected disk array; if the type configuration field is not default, select the disk array corresponding to the preset type according to the preset type corresponding to the type configuration field from the created disk arrays.

[0044] Among them, the preset type can be at least one same or different disk type defined by the user.

[0045] In some embodiments, the user can configure multiple RAID types to be tested by customizing the test type parameter (--op_RAID_level) in the disk attribute information. The configuration format of the test type parameter can be expressed as: --op_RAID_level=RAID1R:RAID2R:RAID3R. Exemplarily, after the configuration is completed, it can be detected whether the type configuration field corresponding to this parameter is default. If it is default, that is, this parameter is not configured, all the created disk arrays can be determined as the disk arrays to be tested; if it is not default, the corresponding disk arrays are determined one by one from the created disk arrays according to the preset type corresponding to the type configuration field. For example, select the disk arrays with disk types RAID1R, RAID2R, and RAID3R respectively from the created disk arrays to achieve automatic selection of multiple disk arrays to be tested and avoid test interruption caused by the default of the type configuration field.

[0046] Optionally, select the disk array corresponding to the preset type from the created disk arrays according to the preset type corresponding to the type configuration field. Specifically, it may include: if the created disk arrays do not include the disk array corresponding to the preset type, generate a disk type error warning.

[0047] Correspondingly, it can be checked whether the created disk types in the storage system include the preset types configured by the user. If the created disk types do not include the preset types configured by the user, the program exits with failure and generates a disk type error warning, which can be used to prompt the user to reconfigure the preset type. Exemplarily, the error message prompted in the warning can be: The RAID type to be operated does not exist in the system.

[0048] Step 203: Determine the fault injection data corresponding to the disk arrays of different disk types.

[0049] Optionally, step 203 may specifically include: obtaining the fault configuration information corresponding to the disk arrays of different disk types from the disk creation information and / or the disk attribute information; determining the fault injection data corresponding to the different disk arrays according to the fault configuration information.

[0050] In some embodiments, the failure configuration information corresponding to multiple disk arrays in the disk test data can be configured using a preset script to obtain the failure injection data corresponding to each disk array. For a disk array to be newly created, the failure configuration information corresponding to each disk array can be configured in the disk creation information; for an already created disk array, the failure configuration information corresponding to each disk array can be configured in the disk attribute information. Among them, the failure configuration information can include, but is not limited to, the preset number of failed disks.

[0051] Optionally, according to the failure configuration information in the disk test data, determining the failure injection data corresponding to disk arrays of different disk types respectively includes: determining whether the failure configuration field in the failure configuration information is default; if the failure configuration field is default, then determining the failure injection data corresponding to different disk arrays respectively according to the redundancy of different disk arrays; if the failure configuration field is not default, then determining the failure injection data corresponding to different disk arrays respectively according to the preset number of failed disks corresponding to the failure configuration field.

[0052] Among them, the preset number of failed disks can be the number of failed disks corresponding to at least one disk array customized by the user.

[0053] In some embodiments, the user can configure the failure injection data corresponding to multiple RAID to be tested by customizing the failure configuration parameter (--offline_disk_count) corresponding to the failure configuration information. The configuration format of the failure configuration parameter can be expressed as: --offline_disk_count=1:2:3. Exemplarily, after the configuration is completed, the failure configuration field corresponding to the parameter can be parsed to determine whether the failure configuration field is default. If the failure configuration field is default, that is, the parameter is not configured, then the redundancy of the corresponding RAID type, that is, the maximum redundancy number, can be assigned to the failure configuration parameter. That is, if it is default, the same number of disk failures will be injected according to the maximum redundancy number; if the failure configuration field is not default, then the failure injection data corresponding to different disk arrays respectively can be determined according to the preset number of failed disks corresponding to the failure configuration field, so as to facilitate the failure injection of multiple disk arrays to be tested and avoid test interruption caused by the default of the failure configuration field.

[0054] Optionally, determining the failure injection data corresponding to different disk arrays respectively according to the redundancy of different disk arrays can specifically include: obtaining the redundancy corresponding to different disk arrays according to the disk attribute information, and the redundancy is updated according to the number of member disk failures of the disk array; determining the redundancy as the failure injection data corresponding to different disk arrays respectively.

[0055] In some embodiments, if a member disk of an existing RAID operation object has failed before, its redundancy may be reduced. The redundancy of each disk array can be obtained according to the attribute values of the existing RAID through a storage system command, which can detect the redundancy in real time, improve the accuracy of the redundancy, and there is no need to set it in a preset script, reducing the configuration operation of disk test data.

[0056] Exemplarily, if the redundancy of an existing RAID is 3 itself, but there is 1 failed disk, its redundancy should be 2. The redundancy can be obtained in real time according to the disk attribute information by using a storage system command; if a new RAID type is added, the redundancy corresponding to the new type can also be obtained according to the disk attribute information by using a storage system command, thus reducing the configuration operation of disk test data.

[0057] Optionally, the fault injection data corresponding to different disk arrays is determined according to the preset number of failed disks corresponding to the fault configuration field, which may specifically include: determining whether the preset number of failed disks of the disk array is greater than the redundancy of the disk array; if the preset number of failed disks of the disk array is greater than the redundancy of the disk array, a fault injection data reset prompt is generated; if the preset number of failed disks of the disk array is less than or equal to the redundancy of the disk array, the preset number of failed disks corresponding to the disk array is determined as the fault injection data corresponding to the disk array.

[0058] Exemplarily, the preset number of failed disks of each disk array can be verified. If it is detected that the preset number of failed disks of the disk array is greater than the redundancy of the disk array, a fault injection data reset prompt can be generated, and all the obtained information is discarded and a failure is returned. Exemplarily, the reset prompt can be "The number of failed member disks exceeds the redundancy, which will cause service interruption. Please reset the number of faults"; if it is detected that the preset number of failed disks of the disk array is less than or equal to the redundancy of the disk array, the preset number of failed disks corresponding to the disk array can be determined as the fault injection data corresponding to the disk array for fault injection testing.

[0059] Step 204: Test different disk arrays according to the fault injection data corresponding to different disk arrays.

[0060] Optionally, before step 204, the method of this embodiment may further include: storing the disk creation information and / or disk attribute information into a preset disk test list.

[0061] Among them, the preset disk test list can be used to store test data corresponding to the disk array to be tested, such as: RAID ID, RAID name, RAID level, RAID type, RAID redundancy, number of failed disks, etc. Exemplarily, the preset disk test list can be a list of object information corresponding to a dictionary data structure variable (Op_RAID_info_dict).

[0062] Exemplarily, the input parameters corresponding to the disk test data can be parsed and the required information of the RAID to be operated on can be obtained from the storage system. Each RAID information is first temporarily stored in the key:value key-value pair data structure, and after judging its legality, it is stored in the dictionary list to obtain a valid RAID information. Then, it is stored as a list element in a list, so that all the RAID objects to be operated on can be stored in a list, and the RAID information is stored in the data structure of the dictionary list. Each RAID information is a dictionary element, and finally, each RAID information is saved in the form similar to a two-dimensional table information.

[0063] Assume that the RAID types with different redundancies are defined as RAID 1R (redundancy is 1), RAID 2R (redundancy is 2), RAID 3R (redundancy is 3). The RAID information to be saved can include: RAID_ID, RAID_name, RAID_level, RAID_redundancy, failed_disk_count, as shown in Table 1 specifically.

[0064] Table 1

[0065] In some embodiments, if the operation object to be tested is an existing RAID in the storage system, the RAID equal to the "test type parameter (op_RAID_level)" is obtained and filtered through the storage system command, and the required attribute values are obtained and assigned to the dictionary data structure variable Op_RAID_info_dict to be saved. The variable can include attribute information such as object ID (RAID_ID:x), object name (RAID_name:x), RAID type (RAID_level:x), RAID redundancy (RAID_redundancy:x), etc., and the number of member disk failures corresponding to each RAID type is obtained according to the failure configuration parameters.

[0066] Correspondingly, if the operation object to be tested is a newly created RAID, first parse the disk creation information to obtain all the parameters required for creating the RAID and the fault configuration parameters, and store them in the create disk list (create_RAID_dict_list) in the form of key: value key-value pairs. This list can include the fault configuration parameters corresponding to each RAID. Then, retrieve the information of the RAID to be created from the newly created disk list. First, create a storage pool to manage one or more RAIDs, execute the creation of the RAID, and store one type of RAID in each pool. Record the RAID_ID of the newly created RAID and the corresponding number of faulty disks, which can be stored in a new dictionary list (new_RAID_dict_list) for subsequent retrieval and operation of the newly created RAID.

[0067] Specifically, if the operation object is a newly created RAID, the disk array identifier (RAID_ID) corresponding to the newly created RAID can be obtained from the disk array identifier list (RAID_ID_list). Then, according to the RAID_ID, obtain the RAID information and the number of faulty disks from the storage system, and assign them to Op_RAID_info_dict, without the need to query and filter all RAID objects, thereby improving the test efficiency.

[0068] Optionally, step 204 may specifically include: determining the target member disks in different disk arrays according to the preset number of faulty disks; using the fault injection operation to make the target member disks in different disk arrays offline; and performing disk task tests on the different disk arrays after the target member disks are offline.

[0069] Among them, the target member disks can be the member disks with simulated faults determined according to the preset number of faulty disks.

[0070] In some embodiments, the RAID information to be tested can be obtained one by one from the object information list, and then the fault injection operation is started. The same number of member disk faults are injected through the storage system command to make them offline. After the member disks of a RAID are offline, the disk test tasks corresponding to the RAID can be checked, for example: whether the RAID is offline, whether the client's IO is interrupted, whether there is an abnormal alarm in the storage system health, and whether the reconstruction and copy-back tasks started by the RAID are normal, etc.

[0071] Step 205, obtain the test results corresponding to different disk arrays respectively.

[0072] Optionally, step 205 may specifically include: obtaining the number of tasks corresponding to the disk task test according to the disk array identifiers corresponding to different disk arrays; and determining the test results corresponding to different disk arrays respectively according to the number of tasks and the expected number of tasks of different disk arrays.

[0073] In some embodiments, according to the disk array identifier, the number and status of background tasks running are obtained through storage system commands, and the expected result judgment is performed on the running situation of the specified RAID. Exemplarily, when the number of available hot spares is greater than or equal to the number of failed disks, after a member disk fails and goes offline, check whether the storage system has started reconstruction tasks equal to the number of failed disks; when the number of available hot spares is less than the number of failed disks, after a member disk fails and goes offline, check whether the storage system has started reconstruction tasks equal to the number of failed disks. If it is detected that all reconstruction tasks can be successfully completed, then resume all failed and offline disks to go online again, and check whether the copy-back task can be successfully completed, then it can be determined that the RAID reconstruction and copy-back task startup situation is normal.

[0074] As a possible implementation, as Figure 3 shown, first, by inputting custom parameters, a custom test set can be flexibly implemented, and fault injection operations can be performed on the existing RAIDs in the storage system, or operations can be performed only on newly created RAIDs. Then, the input parameters are parsed, combined with the operation information required for the RAIDs obtained by querying, and each attribute and its value are stored in the form of a key:value key-value pair and added to the object information list. After that, the RAID information is obtained one by one from the object information list, and the corresponding number of member disk failures are injected; then, the test expected result is checked, including checking that the RAID is not offline, the client's IO is not interrupted, the storage system is healthy without abnormal alarms, and the reconstruction and copy-back tasks started by the RAID are running normally. Exemplarily, the specific steps may include: 1. First, script parameters can be configured, such as storage cluster login information, whether to use existing RAIDs, whether to create new RAIDs, and the number of periodic executions and intervals, etc. Specifically, the information of all nodes in the cluster and the current test environment can be configured into a configuration file that can be read by the automation platform or automation script. In this way, when executing the automation use case, the basic information of the cluster and nodes can be read, mainly including username, password, login port, IP, etc., so as to realize that the automation script can remotely log in to the test cluster or node, and then issue execution commands.

[0075] 2. If it is determined to use an existing RAID, then set its corresponding test RAID type and the number of member disk failures.

[0076] 3. In order to flexibly implement a custom test set, operations can also be performed on newly created RAIDs. If it is determined to operate on a newly created RAID, then the parameters required for the newly created RAID need to be set, such as the newly created RAID type, array width, stripe width, number of hot spares, number of newly created RAIDs, etc.

[0077] 4. By setting the custom parameter —is_exist_RAID, it is possible to select whether the RAID for fault injection is an existing RAID or a newly created RAID. When the value is yes, there is no need to create a new RAID and operations can be directly performed on the existing RAID. When the parameter is missing, the default value is yes, and the parameter --op_RAID_level must be set to select the type of the existing RAID. When the value is no, fault injection operations are performed on the newly created RAID, and the parameters required for creating the new RAID, such as --create_RAID_level, must be set. And there is no need to set the parameter --op_RAID_level because the RAID type to be tested is the newly created RAID type.

[0078] 5. The program parses all the set script parameters and judges their legality.

[0079] 6. If there is no need to create a new RAID, that is, when —is_exist_RAID is set to yes, the --op_RAID_level parameter is parsed. First, all RAID types are obtained from the storage system, and it is judged whether the RAID type set in the --op_RAID_level parameter exists in the storage system. If the existing RAID types do not include the RAID type to be operated, the program exits with failure and prompts an error message: The RAID to be operated does not exist in the system.

[0080] 7. If the operation object is an existing RAID in the storage system, the RAID equal to the parameter "test RAID type (op_RAID_level)" is obtained and filtered through the storage system command, and the required attribute values are obtained and assigned to the dictionary data structure variable Op_RAID_info_dict to be saved, including the object ID (RAID_ID:x), object name (RAID_name:x), RAID type (RAID_level:x), redundancy of the RAID (RAID_redundancy:x), and the number of member disk failures corresponding to the RAID type is obtained from the input parameter (--offline_disk_count) (failed_disk_count:x). Exemplarily, the list structure can be expressed as: Op_RAID_info_dict = {"RAID_ID": 0, "RAID_name":"mdisk0", "RAID_level": "RAID1R", " RAID_redundancy ": "1", " failed_disk_count ": "1"}.

[0081] 8. If you want to create a new RAID, perform the RAID creation operation. First, parse all the parameters required for creating a RAID and the parameter --offline_disk_count, and store them in the new dictionary list create_RAID_dict_list in the form of key:value key-value pairs, including the number of member disks to fail for each RAID. Then, retrieve the information of the RAID to be created from the list. First, create a storage pool to manage one or more RAIDs, and perform the RAID creation. Each pool stores one type of RAID. Record the RAID_ID of the newly created RAID and the corresponding number of failed member disks in a new dictionary list new_RAID_dict_list for subsequent operations on the newly created RAID.

[0082] 9. If the operation object is a newly created RAID, obtain the ID of the newly created RAID from the RAID_ID_list list, and then obtain the RAID information and "failed_disk_count" from the storage system based on the RAID_ID, and assign them to the RAID information storage data structure Op_RAID_info_dict. There is no need to query and filter all RAID objects.

[0083] 10. When obtaining each RAID information, if it is determined that the number of failed member disks (failed_disk_count) is greater than the redundancy (RAID_redundancy), then discard all the obtained information and return failure, reporting an error "The number of failed member disks exceeds the redundancy, which will cause service interruption. Please reset the number of failures."

[0084] 11. Store each RAID information in a dictionary Op_RAID_info_dict in the form of key:value key-value pairs, and then store it as a list element in a dictionary list Op_RAID_info_list, so that all RAID objects to be operated can be stored in a list.

[0085] 12. Obtain the storage space of the RAID in the storage pool, create a volume, and map it to the client for reading and writing operations.

[0086] 13. Start performing the fault injection operation. Retrieve the RAID information one by one from the object information list Op_RAID_info_list, and then inject the same number of member disk failures through the storage system command to make them offline. After a member disk of a RAID goes offline, check that the RAID is not offline, the client's IO is not interrupted, the storage system is healthy without abnormal alarms, and the reconstruction and copy-back tasks started by the RAID are normal.

[0087] 14. Check whether the RAID reconstruction and copy-back tasks are started normally. According to the unique identifier RAID_ID, obtain the number and status of background tasks running through the storage system commands, and judge the expected results of the specified RAID operation situation.

[0088] 15. It can implement loop iteration testing and perform multi-round test execution for scenarios. Set the number of times of periodic loop execution -n and set the interval time -i for each period.

[0089] In this way, it can be applied to the unified RAID-related function automation testing. The core testing function of RAID is actually to trigger the reconstruction task after a member disk fails to ensure data integrity. During test execution, the same scenario operations will be performed for each type of RAID. Since the RAID test cycle is relatively long, this method can achieve automated testing at night or during device idle time without manual monitoring, releasing manpower and making full use of the device. And based on the custom parameter settings of the test set, it can customize the test to cover the fault injection test of one or more types of RAID according to the actual test scenario. Implement the test methods of different RAIDs through a general method. When adding or reducing a type of RAID, it can also be quickly reused and put into test execution without repeating the writing of test cases, which not only improves the test efficiency but also has strong scalability and customizability.

[0090] Compared with the prior art, in this embodiment, by customizing the disk test data of the disk test set, it is possible to perform fault injection operations on the existing RAIDs in the storage system, and it is also possible to create new RAIDs and test the newly created RAIDs. It can also detect the redundancy of each disk array in real time, rather than obtaining the redundancy through configuration parameters, and update it according to the fault situation of the disk array, thereby improving the accuracy of redundancy, and there is no need to set it in the preset script, reducing the configuration operation of disk test data.

[0091] The embodiment of the present application also provides a disk array testing device, as Figure 1 and Figure 2 shown in the method for specific implementation, as Figure 4 shown, the device includes: an acquisition module 31 and a determination module 32.

[0092] The acquisition module 31 is configured to acquire the disk test data corresponding to the disk test set; The determination module 32 is configured to determine the disk arrays corresponding to different disk types in the disk test set and the fault injection data corresponding to different disk arrays according to the disk test data; The acquisition module 31 is configured to test different disk arrays according to the fault injection data corresponding to different disk arrays respectively and obtain the test results corresponding to different disk arrays respectively.

[0093] In some examples of this embodiment, the determining module 32 is specifically configured to create disk arrays of different disk types according to the disk creation information in the disk test data; and / or, select disk arrays of different disk types from the created disk arrays according to the disk attribute information in the disk test data; determine the fault injection data corresponding to the disk arrays of different disk types respectively.

[0094] In some examples of this embodiment, the determining module 32 is specifically configured to obtain the fault configuration information corresponding to the disk arrays of different disk types from the disk creation information and / or the disk attribute information; determine the fault injection data corresponding to the disk arrays of different disk types respectively according to the fault configuration information.

[0095] In some examples of this embodiment, the determining module 32 is specifically configured to determine whether the fault configuration field in the fault configuration information is default; if the fault configuration field is default, determine the fault injection data corresponding to the disk arrays of different disk types respectively according to the redundancy of the different disk arrays; if the fault configuration field is not default, determine the fault injection data corresponding to the disk arrays of different disk types respectively according to the preset number of faulty disks corresponding to the fault configuration field.

[0096] In some examples of this embodiment, the determining module 32 is specifically configured to obtain the redundancy corresponding to different disk arrays according to the disk attribute information, and the redundancy is updated according to the number of member disk failures of the disk array; determine the redundancy as the fault injection data corresponding to the disk arrays of different disk types respectively.

[0097] In some examples of this embodiment, the determining module 32 is specifically configured to determine whether the preset number of faulty disks of the disk array is greater than the redundancy of the disk array; if the preset number of faulty disks of the disk array is greater than the redundancy of the disk array, generate a prompt for resetting the fault injection data; if the preset number of faulty disks of the disk array is less than or equal to the redundancy of the disk array, determine the preset number of faulty disks corresponding to the disk array as the fault injection data corresponding to the disk array.

[0098] In some examples of this embodiment, the determining module 32 is specifically configured to determine the target member disks in different disk arrays according to the preset number of faulty disks; use the fault injection operation to make the target member disks in different disk arrays offline; perform disk task tests on the different disk arrays after the target member disks are offline.

[0099] In some examples of this embodiment, the obtaining module 31 is further specifically configured to obtain the number of tasks corresponding to the disk task test according to the disk array identifier corresponding to different disk arrays; determine the test results corresponding to the disk arrays of different disk types respectively according to the number of tasks and the expected number of tasks of different disk arrays.

[0100] In some examples of this embodiment, the obtaining module 31 is further specifically configured to store the disk creation information and / or the disk attribute information into a preset disk test list.

[0101] In some examples of this embodiment, the determining module 32 is specifically configured to determine whether the type configuration field in the disk attribute information is default; if the type configuration field is default, use the created disk array as the selected disk array; if the type configuration field is not default, select the disk array corresponding to the preset type from the created disk arrays according to the preset type corresponding to the type configuration field.

[0102] In some examples of this embodiment, the determining module 32 is specifically configured to generate a disk type error alarm if the created disk arrays do not include the disk array corresponding to the preset type.

[0103] In some examples of this embodiment, the obtaining module 31 is further specifically configured to obtain the preset test period and the preset period interval of the disk test set; perform multiple tests on the disk test set according to the test period and the preset period interval.

[0104] It should be noted that for other corresponding descriptions of the various functional units involved in the disk array test device provided in this embodiment, reference can be made to Figure 1 and Figure 2 the corresponding descriptions therein, which will not be elaborated here.

[0105] Based on the above methods as shown in Figure 1 and Figure 2 Accordingly, this embodiment further provides a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, the above methods as shown in Figure 1 and Figure 2 are implemented.

[0106] Based on the above methods as shown in Figure 1 and Figure 2 Accordingly, this embodiment further provides a computer program product, on which a computer program is stored, and when the computer program is executed by a processor, the above methods as shown in Figure 1 and Figure 2 are implemented.

[0107] Based on such an understanding, the technical solution of this application can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (which can be a CD-ROM, a USB flash drive, a mobile hard disk, etc.), and includes several instructions for causing a computer device (which can be a personal computer, a server, or a network device, etc.) to execute the methods of the various implementation scenarios of this application.

[0108] Based on the above asFigure 1 and Figure 2 the method shown in, and Figure 4 the virtual device embodiments shown in. To achieve the above object, an embodiment of the present application further provides an electronic device, such as a personal computer or a server, which includes a storage medium and a processor; the storage medium is used to store a computer program; the processor is used to execute the computer program to implement the methods shown in Figure 1 and Figure 2 above.

[0109] In some embodiments, the above-mentioned physical device may further include a user interface, a network interface, a camera, a radio frequency (RF) circuit, sensors, an audio circuit, a WI-FI module, and so on. The user interface may include a display screen (Display), an input unit such as a keyboard (Keyboard), etc. Optionally, the user interface may further include a USB interface, a card reader interface, etc. The network interface may include a standard wired interface, a wireless interface (such as a WI-FI interface), etc. in some embodiments.

[0110] Those skilled in the art can understand that the above-mentioned physical device structure provided by this embodiment does not limit the physical device, and it may include more or fewer components, or combine certain components, or have different component arrangements.

[0111] The storage medium may further include an operating system and a network communication module. The operating system is a program for managing the hardware and software resources of the above-mentioned physical device, and supports the operation of information processing programs and other software and / or programs. The network communication module is used to implement communication between components inside the storage medium, and communication between other hardware and software in the information processing physical device.

[0112] Through the description of the above embodiments, those skilled in the art can clearly understand that this application can be implemented by means of software plus a necessary general hardware platform, or can be implemented by hardware. By applying the solution of this embodiment, compared with the current existing technologies, this embodiment can first obtain the disk test data of the disk test set preset by the user, determine different disk types by parsing the disk test data, determine the disk arrays to be tested according to different disk types, and obtain the fault injection data corresponding to different disk arrays according to the disk test data. Then, use the fault injection data to test different disk arrays respectively. It can configure the types and fault injection data of different disk arrays by using the disk test data, and perform fault injection tests on different types of disk arrays in the disk test set respectively, realizing the automated test of multiple disk arrays, without the need to perform separate configuration and test operations on each of the multiple disk arrays to be tested one by one, reducing the test workload and effectively improving the test efficiency. In addition, by customizing the disk test data of the disk test set, it is possible to perform fault injection operations on the existing RAID in the storage system, and also to create a new RAID and test the newly created RAID. It can also detect the redundancy of each disk array in real time, rather than obtaining the redundancy through configuration parameters, and update it according to the fault situation of the disk array, thereby improving the accuracy of the redundancy, and there is no need to set it in the preset script, reducing the configuration operation of the disk test data.

[0113] It should be noted that in this article, relational terms such as "first" and "second" are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any actual relationship or order between these entities or operations. Moreover, the term "comprising", "including" or any other variant thereof is intended to cover a non-exclusive inclusion, so that a process, method, article or device including a series of elements not only includes those elements, but also includes other elements not expressly listed, or further includes elements inherent to such process, method, article or device. Without further limitation, an element defined by the statement "including a..." does not exclude the existence of additional identical elements in the process, method, article or device including the element.

[0114] The above are only the specific embodiments of this application, enabling those skilled in the art to understand or implement this application. Various modifications to these embodiments will be obvious to those skilled in the art, and the general principles defined herein can be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application will not be limited to these embodiments herein, but will be accorded the widest scope consistent with the principles and novel features claimed herein.

Claims

1. A disk array testing method, characterized in that: include: Get the disk test data corresponding to the disk test set; Determine, according to the disk test data, disk arrays corresponding to different disk types in the disk test set, and fault injection data corresponding to different disk arrays; According to the fault injection data respectively corresponding to the different disk arrays, the different disk arrays are tested, and the test results respectively corresponding to the different disk arrays are obtained.

2. The method according to claim 1, characterized in that Determining, based on the disk test data, disk arrays corresponding to different disk types in the disk test set and fault injection data corresponding to different disk arrays, respectively, includes: Creating disk arrays of different disk types according to the disk creation information in the disk test data; and / or, According to the disk attribute information in the disk test data, selecting disk arrays of different disk types from the created disk arrays; Determine the fault injection data corresponding to disk arrays of different disk types.

3. The method according to claim 2, characterized in that The determining of the fault injection data corresponding to the disk arrays of different disk types respectively includes: Acquire fault configuration information corresponding to disk arrays of different disk types from the disk creation information and / or the disk attribute information; According to the fault configuration information, fault injection data corresponding to different disk arrays are determined.

4. The method according to claim 3, characterized in that The determining, according to the fault configuration information, fault injection data corresponding to different disk arrays respectively includes: Determine whether the fault configuration field in the fault configuration information is default; If the fault configuration field is default, determining the fault injection data corresponding to different disk arrays respectively according to the redundancy of different disk arrays; If the fault configuration field is not defaulted, the fault injection data corresponding to different disk arrays are determined according to the preset number of fault disks corresponding to the fault configuration field.

5. The method according to claim 4, characterized in that The method of determining the fault injection data corresponding to different disk arrays according to the redundancy of different disk arrays includes: According to the disk attribute information, the redundancy corresponding to different disk arrays is obtained, and the redundancy is updated according to the number of member disk failures of the disk array; The redundancy is determined as fault injection data corresponding to different disk arrays respectively.

6. The method according to claim 5, characterized in that The determining of the fault injection data corresponding to different disk arrays according to the preset number of fault disks corresponding to the fault configuration field includes: Determine whether the number of preset failed disks of the disk array is greater than the redundancy of the disk array; If the number of preset faulty disks in the disk array is greater than the redundancy of the disk array, a fault injection data reset prompt is generated; If the preset number of faulty disks of the disk array is less than or equal to the redundancy of the disk array, the preset number of faulty disks corresponding to the disk array is determined as the fault injection data corresponding to the disk array.

7. The method according to claim 6, characterized in that The testing of the different disk arrays according to the fault injection data respectively corresponding to the different disk arrays includes: According to the preset number of failed disks, determining target member disks in different disk arrays; Using fault injection operations, target member disks in different disk arrays are made offline; Perform disk task tests on different disk arrays after the target member disk is offline.

8. The method according to claim 7, characterized in that The obtaining of the test results corresponding to the different disk arrays respectively includes: According to the disk array identifiers corresponding to the different disk arrays, obtaining the task quantity corresponding to the disk task test; According to the number of tasks and the expected number of tasks of the different disk arrays, test results corresponding to the different disk arrays are determined.

9. The method according to claim 8, characterized in that Before testing the different disk arrays according to the fault injection data respectively corresponding to the different disk arrays, the method further includes: The disk creation information and / or the disk attribute information is stored in a preset disk test list.

10. The method according to claim 2, characterized in that The step of selecting disk arrays of different disk types from the created disk arrays according to the disk attribute information in the disk test data includes: Determine whether the type configuration field in the disk attribute information is default; If the type configuration field is default, the created disk array is used as the selected disk array; If the type configuration field is not defaulted, then according to the preset type corresponding to the type configuration field, a disk array corresponding to the preset type is selected from the created disk arrays.

11. The method according to claim 10, characterized in that The selecting, according to the preset type corresponding to the type configuration field, from the created disk arrays, a disk array corresponding to the preset type, comprises: If the created disk array does not include a disk array corresponding to the preset type, a disk type error alarm is generated.

12. The method according to claim 1, characterized in that The method further comprises: Obtaining a preset test cycle and a preset cycle interval of the disk test set; The disk test set is tested multiple times according to the test cycle and the preset cycle interval.

13. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the method according to any one of claims 1 to 12 is implemented.

14. An electronic device comprising a storage medium, a processor, and a computer program stored in the storage medium and executable on the processor, characterized in that: When the processor executes the computer program, the method according to any one of claims 1 to 12 is implemented.

15. A computer program product having a computer program stored thereon, characterized in that: When the computer program product is executed by a processor, the method according to any one of claims 1 to 12 is implemented.

Images