Data recovery test method and device, electronic equipment and readable storage medium

Abstract

The invention discloses a data recovery test method, which comprises the following steps of: performing fault injection on a storage system to enable the storage system to enter a recovery state; determining a target test scene in the recovery state, and performing a performance recovery test on the storage system in the target test scene; estimating a target duration for the storage system to enter a stable state in the performance recovery test process; after waiting for the target duration, collecting target performance data of the storage system for verification, and determining a test result of the target test scene according to a verification result; and determining a data recovery test result according to the test result of each target test scene. By applying the technical scheme provided by the invention, more efficient and accurate data recovery performance testing can be realized for the storage system. The invention also discloses a data recovery test device, electronic equipment and a computer readable storage medium, which also have the above technical effects.

Description

Technical Field

[0001] The present application relates to the field of storage technology, and in particular to a data recovery test method, and also to a data recovery test device, an electronic device, and a computer-readable storage medium. Background Art

[0002] Storage is divided into centralized storage and distributed storage. Both have a data recovery process, that is, the storage system recovers its stored data when a node or hard disk fails. The data recovery performance of the storage system is an important aspect of measuring the performance of the storage system. However, the related technology mainly adopts the implementation method of manual testing, which has the problems of low test efficiency and low test accuracy.

[0003] Therefore, how to implement a more efficient and accurate data recovery performance test on a storage system is an urgent problem to be solved by those skilled in the art. Summary of the invention

[0004] The purpose of the present application is to provide a data recovery test method, which can achieve more efficient and accurate data recovery performance testing for a storage system; another purpose of the present application is to provide a data recovery test device, an electronic device, a computer-readable storage medium, and a computer program product, all of which have the above-mentioned beneficial effects.

[0005] In a first aspect, the present application provides a data recovery test method, comprising:

[0006] Performing fault injection on the storage system to put the storage system into a recovery state;

[0007] Determining a target test scenario in the recovery state, and performing a performance recovery test on the storage system in the target test scenario;

[0008] Estimate the target time for the storage system to enter a stable state during the performance recovery test;

[0009] After waiting for the target time, collecting target performance data of the storage system for verification, and determining the test result of the target test scenario according to the verification result;

[0010] The data recovery test result is determined according to the test results of each of the target test scenarios.

[0011] Optionally, determining the data recovery test result according to the test result of each target test scenario includes:

[0012] Performing real-time monitoring on the system status of the storage system;

[0013] When it is monitored that the system state enters a balanced state from the recovery state, returning to the step of injecting a fault into the storage system to make the storage system enter a recovery state, until test results of all the target test scenarios are obtained in the recovery state;

[0014] The data recovery test result is determined according to the test results of each of the target test scenarios.

[0015] Optionally, collecting target performance data of the storage system for verification, and determining a test result of the target test scenario according to the verification result, includes:

[0016] Collecting a plurality of target performance data of the storage system within a preset time, and calculating and obtaining a mean value of each target performance data;

[0017] Determining whether the mean value exceeds the standard value corresponding to the target performance data;

[0018] If the mean value does not exceed the standard value, the verification result is determined to be passed;

[0019] If the mean value exceeds the standard value, then counting the target number of target performance data exceeding the standard value;

[0020] Calculate the excess value ratio according to the target quantity and the total quantity of the target performance data;

[0021] Determine whether the excess value ratio exceeds a preset ratio;

[0022] When the excess value ratio does not exceed the preset ratio, the verification result is determined to be verification passed;

[0023] When the excess value ratio exceeds the preset ratio, the verification result is determined to be verification failure;

[0024] When the verification result is that the verification is passed, determining that the test result of the target test scenario is that the test is passed;

[0025] When the verification result is that the verification fails, it is determined that the test result of the target test scenario is that the test fails.

[0026] Optionally, estimating a target time for the storage system to enter a stable state during the performance recovery test includes:

[0027] Acquiring system configuration information of the storage system, and determining a performance recovery rate of the storage system during the performance recovery test;

[0028] An estimate is made based on the system configuration information and the performance recovery rate to obtain a target duration for the storage system to enter the stable state during the performance recovery test.

[0029] Optionally, injecting a fault into the storage system so that the storage system enters a recovery state includes:

[0030] A target storage disk of the storage system is made to fail to achieve the fault injection, so that the storage system enters the recovery state.

[0031] Optionally, before injecting a fault into the storage system so that the storage system enters a recovery state, the method further includes:

[0032] Performing an initialization operation on the storage system to put the storage system into a healthy state;

[0033] Accordingly, injecting a fault into the storage system so that the storage system enters a recovery state includes:

[0034] A fault is injected into the storage system in the healthy state, so that the storage system enters the recovery state.

[0035] Optionally, injecting a fault into the storage system in the healthy state so that the storage system enters the recovery state includes:

[0036] Performing fault injection on the storage system in the healthy state so that the storage system enters a waiting-for-recovery state;

[0037] After waiting for a preset period of time in the waiting-for-recovery state, it is determined that the storage system enters the recovery state.

[0038] In a second aspect, the present application also discloses a data recovery test device, comprising:

[0039] An injection module, used for injecting a fault into the storage system so as to put the storage system into a recovery state;

[0040] A testing module, used to determine a target test scenario in the recovery state, and perform a performance recovery test on the storage system in the target test scenario;

[0041] An estimation module, used to estimate the target time for the storage system to enter a stable state during the performance recovery test;

[0042] A verification module, used to collect target performance data of the storage system for verification after waiting for the target time, and determine the test result of the target test scenario according to the verification result;

[0043] The determination module is used to determine the data recovery test result according to the test result of each target test scenario.

[0044] In a third aspect, the present application further discloses an electronic device, comprising:

[0045] Memory for storing computer programs;

[0046] A processor is used to implement the steps of any one of the data recovery test methods described above when executing the computer program.

[0047] In a fourth aspect, the present application further discloses a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, the steps of any one of the data recovery test methods described above are implemented.

[0048] In a fifth aspect, the present invention further discloses a computer program product, including a computer program / instruction, which implements the steps of any one of the data recovery test methods described above when executed by a processor.

[0049] The present application provides a data recovery test method, comprising: injecting a fault into a storage system to put the storage system into a recovery state; determining a target test scenario in the recovery state, and performing a performance recovery test on the storage system under the target test scenario; estimating a target time for the storage system to enter a stable state during the performance recovery test; after waiting for the target time, collecting target performance data of the storage system for verification, and determining a test result of the target test scenario based on the verification result; and determining a data recovery test result based on the test results of each of the target test scenarios.

[0050] By applying the technical solution provided by the present application, the data recovery performance test of the storage system is realized by script automation. For the storage system to be tested, a fault is first injected into it to make it enter a fault recovery state, so as to realize the performance recovery test of different test scenarios in this state. In each test scenario, the target time for the storage system to enter a stable state during the performance recovery test can be estimated, and the performance data of the storage system is verified after waiting for the target time to obtain the test result in the test scenario. Thus, the final data recovery test result can be obtained according to the test results of each test scenario. It can be seen that the present technical solution realizes the data recovery performance test of the storage system based on script automation, which can effectively reduce manpower time consumption and has high test efficiency and test accuracy.

[0051] In one embodiment of the present application, since the final data recovery test result needs to be determined based on the test results of each test scenario, it is necessary to perform a performance recovery test for each test scenario. During this process, the system status of the storage system can be monitored in real time. Once the system status of the storage system enters a balanced state, a fault is re-injected into the storage system to keep it in a recovery state. In other words, the storage system is ensured to be in a recovery state at all times to complete the performance recovery test of each test scenario, thereby effectively ensuring the accuracy of the data recovery test results.

[0052] The data recovery test device, electronic device, computer-readable storage medium and computer program product provided in this application also have the above-mentioned technical effects, which will not be described in detail in this application. BRIEF DESCRIPTION OF THE DRAWINGS

[0053] In order to more clearly illustrate the technical solutions in the prior art and the embodiments of the present application, the drawings required for use in the description of the prior art and the embodiments of the present application are briefly introduced below. Of course, the drawings described below in relation to the embodiments of the present application are only part of the embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on the provided drawings without creative work, and the obtained other drawings also belong to the protection scope of the present application.

[0054] Figure 1 A flowchart of a data recovery test method provided by this application;

[0055] Figure 2 A data recovery test system architecture diagram provided by this application;

[0056] Figure 3 A flowchart of another data recovery test method provided by this application;

[0057] Figure 4 A schematic diagram of the structure of a data recovery test device provided in this application;

[0058] Figure 5 A schematic diagram of the structure of an electronic device provided in this application. DETAILED DESCRIPTION

[0059] The core of the present application is to provide a data recovery test method, which can achieve more efficient and accurate data recovery performance testing for the storage system; another core of the present application is to provide a data recovery test device, electronic device, computer-readable storage medium and computer program product, all of which have the above-mentioned beneficial effects.

[0060] In order to describe the technical solutions in the embodiments of the present application more clearly and completely, the technical solutions in the embodiments of the present application will be introduced below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of this application.

[0061] An embodiment of the present application provides a data recovery test method.

[0062] Please refer to Figure 1 , Figure 1 This is a flow chart of a data recovery test method provided in the present application. The data recovery test method may include the following S101 to S104.

[0063] S101: injecting a fault into a storage system to put the storage system into a recovery state.

[0064] This step aims to inject faults into the storage system so that the system state of the storage system enters a recovery state, that is, by injecting faults into the storage system, the storage system enters a recovery state from a healthy state. It can be understood that the recovery state means that the storage system state is warning, there is a node failure, and data recovery is required; the healthy state means that the storage system state is healthy, there is no node failure, and data recovery is not required.

[0065] In one embodiment of the present application, injecting a fault into a storage system so that the storage system enters a recovery state may include: injecting a fault into a target storage disk of the storage system so that the storage system enters a recovery state.

[0066] The embodiment of the present application provides a method for injecting a fault into a storage system. It is understandable that, for a storage system, a general fault is a fault in one or more storage hard disks or disks inside the storage system, which requires data recovery. Based on this, for a storage system that requires a data recovery test, one of the storage disks (target storage disk) can be made faulty to inject a fault into the storage system, so that the system state of the storage system enters a recovery state.

[0067] Furthermore, before injecting a fault into the storage system to make the storage system enter a recovery state, the method may further include: performing an initialization operation on the storage system to make the storage system enter a healthy state;

[0068] Accordingly, injecting a fault into the storage system so that the storage system enters a recovery state may include: injecting a fault into a storage system in a healthy state so that the storage system enters a recovery state.

[0069] It should be pointed out that in order to effectively ensure the accuracy of the data recovery test results, it is necessary to ensure that the initial state of the storage system is in a healthy state, and then to make it enter a recovery state through fault injection. If the storage system itself is not in a healthy state at the beginning, it is easy to have an adverse effect on the data recovery test results. Based on this, before performing fault injection on the storage system, it can be initialized to ensure that it is in a healthy state, and then to make it enter a recovery state through fault injection.

[0070] Among them, injecting a fault into a storage system in a healthy state so that the storage system enters a recovery state may include: injecting a fault into a storage system in a healthy state so that the storage system enters a waiting-for-recovery state; and determining that the storage system enters a recovery state after waiting for a preset period of time in the waiting-for-recovery state.

[0071] It is understandable that for any storage system that was originally in a healthy state, when it fails and needs to recover data, there needs to be a waiting process to confirm that it has indeed failed, and then perform the data recovery operation. Based on this, after the fault injection is completed in the storage system, the system state that the storage system first enters is the waiting recovery state. Obviously, the waiting recovery state refers to the storage system status warning that there is a node failure, but no data recovery is performed; further, it is possible to wait in the waiting recovery state for a certain length of time, that is, after a preset length of time, and then determine that the storage system has entered the recovery state. Among them, the specific value of the preset time length does not affect the implementation of the present technical solution, and can be set according to the actual performance of the storage system, and this application does not limit this.

[0072] S102: Determine a target test scenario in the recovery state, and perform a performance recovery test on the storage system under the target test scenario.

[0073] This step is to implement performance recovery test of specific test scenarios for the storage system in recovery state. It should be noted that in actual application scenarios, the application scenario of the system changes in real time and may be in various application scenarios, such as read-only scenario, write-only scenario, read-write scenario, high-bandwidth scenario, low-bandwidth scenario, etc. Therefore, in order to effectively ensure the accuracy of the test results, the number of test scenarios is not unique, and performance recovery tests need to be performed on various pre-set test scenarios.

[0074] In the specific implementation process, a test scenario set containing multiple different test scenarios can be created in advance, and then the target test scenarios can be traversed from the set in turn to perform performance recovery testing. The performance recovery test process includes adjusting specific indicator parameters in the storage system, and the specific indicator parameters may include but are not limited to IOPS (Input / Output Operations Per Second, the number of read and write operations per second), bandwidth, etc.

[0075] S103: Estimate the target time for the storage system to enter a stable state during the performance recovery test.

[0076] This step aims to estimate the duration of the performance recovery test process. In essence, it estimates the duration for various index parameters of the storage system to continuously change and enter a stable state during the performance recovery test, that is, the above-mentioned target duration.

[0077] In the specific implementation process, it can be implemented according to the system configuration information of the storage system and the performance recovery rate of the storage system during the performance recovery test. Therefore, in one embodiment of the present application, estimating the target time for the storage system to enter a stable state during the performance recovery test can include: obtaining the system configuration information of the storage system, and determining the performance recovery rate of the storage system during the performance recovery test; estimating according to the system configuration information and the performance recovery rate, and obtaining the target time for the storage system to enter a stable state during the performance recovery test. Among them, the system configuration information of the storage system may include but is not limited to the size of the storage space, the preset maximum data storage capacity, etc.

[0078] S104: After waiting for a target time, target performance data of the storage system is collected for verification, and a test result of the target test scenario is determined according to the verification result.

[0079] This step is intended to determine the test results of the target test scenario. Specifically, after estimating the target time for the storage system to enter a stable state during the performance recovery test, you can wait for the target time, and then collect certain performance data (target performance data) in the storage system for verification, so that you can determine the test results of the storage system in the target test scenario based on the verification results of the target performance data. Obviously, when the verification result of the target performance data is passed, the test result of the storage system in the target test scenario is also passed; when the verification result of the target performance data is failed, the test result of the storage system in the target test scenario is also failed. Among them, the target performance data may include but is not limited to the above-mentioned IOPS, bandwidth, etc.

[0080] In one embodiment of the present application, collecting target performance data of the storage system for verification, and determining the test result of the target test scenario according to the verification result may include:

[0081] Collect multiple target performance data of the storage system within a preset time, and calculate the average value of each target performance data;

[0082] Determine whether the mean value exceeds the standard value corresponding to the target performance data;

[0083] If the mean value does not exceed the standard value, the verification result is determined to be passed;

[0084] If the mean value exceeds the standard value, the target number of target performance data exceeding the standard value is counted;

[0085] Calculate the excess value ratio based on the total number of target numbers and target performance data;

[0086] Determine whether the excess value ratio exceeds the preset ratio;

[0087] When the excess value ratio does not exceed the preset ratio, the verification result is determined to be passed;

[0088] When the excess value ratio exceeds the preset ratio, the verification result is determined to be verification failure;

[0089] When the verification result is verification passed, the test result of the target test scenario is determined to be test passed;

[0090] When the verification result is verification failure, it is determined that the test result of the target test scenario is test failure.

[0091] The embodiment of the present application provides an implementation method for verifying target performance data. Specifically, after waiting for the target time, multiple target performance data of the storage system within a preset time can be collected, such as collecting IOPS values ​​within one hour, and then calculating the average of multiple target performance data, so that it can be determined whether the target data verification has passed according to the value of the average: if the average is ≤ the standard value, the target indicator data verification has passed; if the average is > the standard value, the verification continues. When continuing to verify, the number of target performance data with values ​​exceeding the standard value is counted among all target performance data. If the proportion of such target performance data is too high (that is, the proportion of excess values ​​exceeds the preset ratio), the target indicator data verification fails, otherwise the verification passes. Of course, the specific values ​​of the preset time and the preset ratio do not affect the implementation of the present technical solution, and can be set by technical personnel according to actual conditions, and the present application does not limit this.

[0092] S105: Determine the data recovery test result according to the test result of each target test scenario.

[0093] This step aims to determine the final data recovery test results based on the test results of each target test scenario. In the specific implementation process, a data recovery test report on the storage system can be directly generated and output based on the test results of each target test scenario. Furthermore, after obtaining the data recovery test results of the storage system, the fault recovery function module can be called to recover the injected fault of the storage system to restore it to a healthy state.

[0094] In one embodiment of the present application, determining the data recovery test result according to the test results of each target test scenario may include:

[0095] Real-time monitoring of the system status of the storage system;

[0096] When it is monitored that the system state changes from the recovery state to the balance state, return to the step of injecting a fault into the storage system to make the storage system enter the recovery state, until the test results of all target test scenarios are obtained in the recovery state;

[0097] The data recovery test results are determined based on the test results of each target test scenario.

[0098] The embodiment of the present application provides a method for determining the data recovery test result according to the test results of each target test scenario. In the embodiment of the present application, it is ensured that the performance recovery test under each target test scenario of the storage system is always in the recovery state. Once the system state of the storage system is monitored to be in a balanced state, the fault injection is performed again to keep it in the recovery state. It can be understood that the balanced state means that the storage system is in a healthy state, there are node failures, but no data recovery is performed.

[0099] It should be noted that re-injecting a fault into the storage system may specifically include: searching for a new target storage disk in the storage system to perform a fault so as to implement re-injection of the fault. That is, each time a fault injection is performed, a different storage disk is selected in the storage system to perform a fault, so as to effectively ensure balance and the accuracy of the data recovery test result.

[0100] It can be seen that in the embodiments of the present application, since the final data recovery test result needs to be determined based on the test results of each test scenario, it is necessary to perform a performance recovery test for each test scenario. During this process, the system status of the storage system can be monitored in real time. Once the system status of the storage system enters a balanced state, a fault is re-injected into the storage system to keep it in a recovery state. In other words, the storage system is ensured to be in a recovery state at all times to complete the performance recovery test of each test scenario, thereby effectively ensuring the accuracy of the data recovery test results.

[0101] It can be seen that the data recovery test method provided in the embodiment of the present application realizes the data recovery performance test of the storage system by means of script automation. For the storage system to be tested, a fault is first injected into it to make it enter a fault recovery state, so as to realize the performance recovery test of different test scenarios in this state. In each test scenario, the target time for the storage system to enter a stable state during the performance recovery test can be estimated, and the performance data of the storage system can be verified after waiting for the target time to obtain the test result under the test scenario. Thus, the final data recovery test result can be obtained according to the test results of each test scenario. It can be seen that the technical solution realizes the data recovery performance test of the storage system based on script automation, which can effectively reduce manpower time consumption and has high test efficiency and test accuracy.

[0102] Based on the above embodiments, the embodiment of the present application takes a distributed storage system as an example to provide another data recovery test method.

[0103] First, please refer to Figure 2 , Figure 2 This is a data recovery test system architecture diagram provided by this application. The data recovery test system mainly includes a data recovery management module, a parameter configuration module, a cluster fault processing module, a data analysis module, and a monitoring module. The functions of each module are implemented as follows:

[0104] 1. The parameter configuration module is used to configure test-related information, including but not limited to storage information, test scenarios, limited parameters such as IOPS value / bandwidth value, effective time, etc.

[0105] 2. The data recovery management module is responsible for unified scheduling of the cluster fault handling module, data analysis module, and monitoring module.

[0106] 3. The cluster fault handling module is used to manage the status of the cluster system, including the healthy status, waiting for recovery status, recovery status, and rebalancing status; and, according to the needs of the test process and the set fault strategy, implement fault injection operations or health recovery operations.

[0107] The fault strategy may be: if the cluster system data is restored but the test scenario is not completed, the cluster system is faulted again and enters the recovery state. A different disk or node is selected for each fault injection.

[0108] 4. The data analysis module is used to analyze the comparison between the cluster recovery performance and the set performance indicators during the data recovery process using the set analysis strategy, and to analyze whether the cluster recovery performance meets the set indicators based on the comparison results.

[0109] Among them, the analysis strategy can be: after the data stabilizes, first sample multiple groups of indicator values ​​to be tested within a certain period of time, and then calculate the average value to analyze whether it exceeds the set indicator value (standard value). If it does not exceed, the verification is passed; if it exceeds, the number of times the set indicator value is exceeded is counted. If it exceeds a preset ratio (such as 5%, which is adjustable and may be less than 1% in harsh environments), the verification fails; otherwise, it is still considered to have passed the verification.

[0110] 5. The monitoring module is used to count and display the progress of the current cluster recovery, and optimize the test waiting time between different test scenarios and the time required for verification of each test scenario through the set time calculation strategy, so as to ensure that as many test cases as possible are executed and the test results are more accurate by reasonably controlling the time.

[0111] Among them, the time calculation strategy can be: based on the set cache size, indicator recovery speed, etc., calculate the approximate time required to reach the newly set indicators of the current test scenario, that is, calculate the time it takes for the parameters to stably recover to the set values ​​after setting.

[0112] Further, based on the above data recovery test system, please refer to Figure 3 , Figure 3 This is a flow chart of another data recovery test method provided by this application, and its implementation process is as follows:

[0113] 1. Ensure that the storage cluster is in a healthy state initially, with no node failures or single disk failures.

[0114] 2. Set the cluster information, test scenarios, and related parameters in the parameter configuration module.

[0115] 3. Use the data recovery management module to write a certain amount of data into the storage pool according to the parameter information set in step 2. Note that the written data is a mixed block of large and small blocks to simulate real data as much as possible; the amount of data is at least 60% of the capacity to ensure that the single cluster data recovery time is as long as possible.

[0116] 4. Call the cluster fault handling module, select any node or disk in the storage pool fault domain and make it fail, so that the cluster changes from the healthy state to the waiting for recovery state, and waits for the cluster to recover according to the set waiting for recovery time.

[0117] 5. After the waiting time is over and the data recovery management module detects that the cluster has entered the recovery state, it calls the test scenario in the parameter configuration module to perform a recovery performance test. The test includes adjusting indicator parameters such as IOPS or bandwidth during the recovery process.

[0118] 6. It takes a stabilization process for the cluster to go from the default performance indicators to the adjusted performance indicators. At this time, the time calculation strategy in the monitoring module is called to estimate the time required for the cluster performance to stabilize to the set value (target event) and wait for stabilization.

[0119] 7. After the performance data stabilizes, sample the performance data for a period of time, and then call the analysis strategy in the data analysis module to analyze whether the current performance data meets the set performance indicators.

[0120] 8. In step 7, if the performance after sampling meets the set value, the scenario test is considered to have passed and the next scenario test is continued.

[0121] 9. If the cluster has recovered to a balanced state during the testing of a scenario, it needs to be handled according to the fault strategy, and then repeat step 4 to restart the scenario test.

[0122] 10. After testing all scenarios, call the cluster fault handling module and restore the cluster to its original healthy state according to the fault strategy in the module.

[0123] 11. After the test is completed, a test report is generated.

[0124] It can be seen that the data recovery test method provided in the embodiment of the present application realizes the data recovery performance test of the storage system by means of script automation. For the storage system to be tested, a fault is first injected into it to make it enter a fault recovery state, so as to realize the performance recovery test of different test scenarios in this state. In each test scenario, the target time for the storage system to enter a stable state during the performance recovery test can be estimated, and the performance data of the storage system can be verified after waiting for the target time to obtain the test result under the test scenario. Thus, the final data recovery test result can be obtained according to the test results of each test scenario. It can be seen that the technical solution realizes the data recovery performance test of the storage system based on script automation, which can effectively reduce manpower time consumption and has high test efficiency and test accuracy.

[0125] An embodiment of the present application provides a data recovery test device.

[0126] Please refer to Figure 4 , Figure 4 This is a structural schematic diagram of a data recovery test device provided by the present application, and the data recovery test device may include:

[0127] The injection module 1 is used to inject a fault into the storage system so as to put the storage system into a recovery state;

[0128] Test module 2, used to determine a target test scenario in a recovery state, and perform a performance recovery test on the storage system under the target test scenario;

[0129] An estimation module 3 is used to estimate the target time for the storage system to enter a stable state during the performance recovery test;

[0130] Verification module 4, used to collect target performance data of the storage system for verification after waiting for the target time, and determine the test result of the target test scenario according to the verification result;

[0131] The determination module 5 is used to determine the data recovery test result according to the test result of each target test scenario.

[0132] It can be seen that the data recovery test device provided in the embodiment of the present application realizes the data recovery performance test of the storage system by means of script automation. For the storage system to be tested, a fault is first injected into it to make it enter a fault recovery state, so as to realize the performance recovery test of different test scenarios in this state. In each test scenario, the target time for the storage system to enter a stable state during the performance recovery test can be estimated, and the performance data of the storage system can be verified after waiting for the target time to obtain the test result in the test scenario. Thus, the final data recovery test result can be obtained according to the test results of each test scenario. It can be seen that the technical solution realizes the data recovery performance test of the storage system based on script automation, which can effectively reduce manpower time consumption and has high test efficiency and test accuracy.

[0133] In one embodiment of the present application, the above-mentioned determination module 5 can be specifically used to monitor the system status of the storage system in real time; when it is monitored that the system status enters the balanced state from the recovery state, return to the step of injecting faults into the storage system to make the storage system enter the recovery state, until the test results of all target test scenarios are obtained in the recovery state; determine the data recovery test results according to the test results of each target test scenario.

[0134] In one embodiment of the present application, the above-mentioned verification module 4 can be specifically used to collect multiple target performance data of the storage system within a preset time, and calculate the mean of each target performance data; determine whether the mean exceeds the standard value corresponding to the target performance data; if the mean does not exceed the standard value, determine that the verification result is verified; if the mean exceeds the standard value, count the target number of target performance data that exceeds the standard value; calculate the excess value ratio based on the target number and the total number of target performance data; determine whether the excess value ratio exceeds the preset ratio; when the excess value ratio does not exceed the preset ratio, determine that the verification result is verified; when the excess value ratio exceeds the preset ratio, determine that the verification result is verified failed; when the verification result is verified passed, determine that the test result of the target test scenario is tested passed; when the verification result is verified failed, determine that the test result of the target test scenario is tested failed.

[0135] In one embodiment of the present application, the above-mentioned estimation module 3 can be specifically used to obtain system configuration information of the storage system and determine the performance recovery rate of the storage system during the performance recovery test; make an estimate based on the system configuration information and the performance recovery rate to obtain the target time for the storage system to enter a stable state during the performance recovery test.

[0136] In one embodiment of the present application, the injection module 1 can be specifically used to cause a target storage disk of the storage system to fail to achieve fault injection, so that the storage system enters a recovery state.

[0137] In one embodiment of the present application, the data recovery test device may further include an initialization module, which is used to perform an initialization operation on the storage system so that the storage system enters a healthy state before the above-mentioned fault injection is performed on the storage system so that the storage system enters a recovery state;

[0138] Accordingly, the injection module 1 can be specifically used to perform fault injection on a storage system in a healthy state, so as to enable the storage system to enter a recovery state.

[0139] In one embodiment of the present application, the injection module 1 may include:

[0140] The injection unit is used to inject faults into the storage system in a healthy state so as to put the storage system into a waiting-for-recovery state;

[0141] The waiting unit is used to determine that the storage system enters the recovery state after waiting for a preset time in the recovery state.

[0142] For an introduction to the device provided in the embodiments of the present application, please refer to the above method embodiments, and the present application will not elaborate on them here.

[0143] An embodiment of the present application provides an electronic device.

[0144] Please refer to Figure 5 , Figure 5 This is a schematic diagram of the structure of an electronic device provided in this application, and the electronic device may include:

[0145] A memory 11, used for storing computer programs;

[0146] The processor 10 can implement the steps of any one of the above-mentioned data recovery test methods when executing a computer program.

[0147] like Figure 5 , which is a schematic diagram of the composition structure of an electronic device, the electronic device may include: a processor 10, a memory 11, a communication interface 12 and a communication bus 13. The processor 10, the memory 11 and the communication interface 12 all communicate with each other through the communication bus 13.

[0148] In the embodiment of the present application, the processor 10 may be a central processing unit (CPU), an application specific integrated circuit, a digital signal processor, a field programmable gate array or other programmable logic devices, etc.

[0149] The processor 10 may call a program stored in the memory 11. Specifically, the processor 10 may execute operations in the embodiment of the data recovery test method.

[0150] The memory 11 is used to store one or more programs, which may include program codes, and the program codes include computer operation instructions. In the embodiment of the present application, the memory 11 at least stores programs for implementing the following functions:

[0151] Perform fault injection on the storage system to put the storage system into a recovery state;

[0152] Determine the target test scenario in the recovery state, and perform performance recovery test on the storage system under the target test scenario;

[0153] Estimate the target time it takes for the storage system to enter a stable state during the performance recovery test;

[0154] After waiting for the target time, collect the target performance data of the storage system for verification, and determine the test result of the target test scenario based on the verification result;

[0155] The data recovery test results are determined based on the test results of each target test scenario.

[0156] In a possible implementation, the memory 11 may include a program storage area and a data storage area, wherein the program storage area may store an operating system and an application required for at least one function, etc.; the data storage area may store data created during use.

[0157] In addition, the memory 11 may include a high-speed random access memory, and may also include a non-volatile memory, such as at least one disk storage device or other volatile solid-state storage device.

[0158] The communication interface 12 may be an interface of a communication module, and is used to connect to other devices or systems.

[0159] Of course, it should be noted that Figure 5 The structure shown does not constitute a limitation on the electronic device in the embodiment of the present application. In actual applications, the electronic device may include Figure 5 More or fewer components than shown, or combinations of certain components.

[0160] An embodiment of the present application provides a computer-readable storage medium.

[0161] The computer-readable storage medium provided in the embodiment of the present application stores a computer program, and when the computer program is executed by a processor, the steps of any one of the above-mentioned data recovery test methods can be implemented.

[0162] Among them, the computer-readable storage medium can be any available medium that can be stored in a computer or a data storage device such as a server or data center that includes one or more available media integrated. For example, it can be a magnetic medium (such as a floppy disk, hard disk, magnetic tape, etc.), an optical medium (such as a DVD) or a semiconductor medium (such as a solid-state hard disk) and other media that can store computer program codes.

[0163] For an introduction to the computer-readable storage medium provided in the embodiments of the present application, please refer to the above method embodiments, and the present application will not elaborate on them here.

[0164] An embodiment of the present application provides a computer program product.

[0165] The computer program product provided in the embodiments of the present application includes a computer program / instruction, and when the computer program / instruction is executed by a processor, the steps of any of the above-mentioned data recovery test methods can be implemented.

[0166] Specifically, in the above embodiments, all or part of them can be implemented by software, hardware, firmware or any combination thereof. When implemented by software, all or part of them can be implemented in the form of a computer program product.

[0167] Among them, the computer program product may include one or more computer programs / instructions, and when the computer program / instructions are loaded and executed on a computer, the process or function described in the embodiment of the present application may be generated in whole or in part. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. Computer instructions may be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, computer instructions may be transmitted from one website site, computer, server or data center to another website site, computer, server or data center by wired (e.g., coaxial cable, optical fiber, digital subscriber line, etc.) or wireless (e.g., infrared, wireless, microwave, etc.) means.

[0168] For an introduction to the computer program product provided in the embodiments of the present application, please refer to the above method embodiments, and the present application will not elaborate on them here.

[0169] The various embodiments in the specification are described in a progressive manner, and each embodiment focuses on the differences from other embodiments. The same or similar parts between the various embodiments can be referred to each other. For the device disclosed in the embodiment, since it corresponds to the method disclosed in the embodiment, the description is relatively simple, and the relevant parts can be referred to the method part description.

[0170] Professionals may further appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the composition and steps of each example have been generally described in the above description according to function. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professionals and technicians may use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application.

[0171] The steps of the method or algorithm described in conjunction with the embodiments disclosed herein may be implemented directly using hardware, a software module executed by a processor, or a combination of the two. The software module may be placed in a random access memory (RAM), a memory, a read-only memory (ROM), an electrically programmable ROM, an electrically erasable programmable ROM, a register, a hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art.

[0172] The technical solution provided by the present application is described in detail above. The principle and implementation method of the present application are described in detail using specific examples herein, and the description of the above embodiments is only used to help understand the method and core idea of ​​the present application. It should be pointed out that for ordinary technicians in this technical field, without departing from the principle of the present application, several improvements and modifications can be made to the present application, and these improvements and modifications also fall within the scope of protection of the present application.

Claims

1. A data recovery test method, characterized in that: include: Performing fault injection on the storage system to put the storage system into a recovery state; Determining a target test scenario in the recovery state, and performing a performance recovery test on the storage system in the target test scenario; Estimate the target time for the storage system to enter a stable state during the performance recovery test; After waiting for the target time, collecting target performance data of the storage system for verification, and determining the test result of the target test scenario according to the verification result; The data recovery test result is determined according to the test results of each of the target test scenarios.

2. The data recovery test method according to claim 1, characterized in that: Determining data recovery test results according to the test results of each of the target test scenarios includes: Performing real-time monitoring on the system status of the storage system; When it is monitored that the system state enters a balanced state from the recovery state, returning to the step of injecting a fault into the storage system to make the storage system enter a recovery state, until test results of all the target test scenarios are obtained in the recovery state; The data recovery test result is determined according to the test results of each of the target test scenarios.

3. The data recovery test method according to claim 1, characterized in that: Collecting target performance data of the storage system for verification, and determining the test result of the target test scenario according to the verification result, including: Collecting a plurality of target performance data of the storage system within a preset time, and calculating and obtaining a mean value of each target performance data; Determining whether the mean value exceeds the standard value corresponding to the target performance data; If the mean value does not exceed the standard value, the verification result is determined to be passed; If the mean value exceeds the standard value, then counting the target number of target performance data exceeding the standard value; Calculate the excess value ratio according to the target quantity and the total quantity of the target performance data; Determine whether the excess value ratio exceeds a preset ratio; When the excess value ratio does not exceed the preset ratio, the verification result is determined to be verification passed; When the excess value ratio exceeds the preset ratio, the verification result is determined to be verification failure; When the verification result is that the verification is passed, determining that the test result of the target test scenario is that the test is passed; When the verification result is that the verification fails, it is determined that the test result of the target test scenario is that the test fails.

4. The data recovery test method according to claim 1, characterized in that: Estimating the target time for the storage system to enter a stable state during the performance recovery test, including: Acquiring system configuration information of the storage system, and determining a performance recovery rate of the storage system during the performance recovery test; An estimate is made based on the system configuration information and the performance recovery rate to obtain a target duration for the storage system to enter the stable state during the performance recovery test.

5. The data recovery test method according to claim 1, characterized in that: Injecting a fault into a storage system so that the storage system enters a recovery state includes: A target storage disk of the storage system is made to fail to achieve the fault injection, so that the storage system enters the recovery state.

6. The data recovery test method according to claim 1, characterized in that: Before injecting a fault into the storage system so that the storage system enters a recovery state, the method further includes: Performing an initialization operation on the storage system to put the storage system into a healthy state; Accordingly, injecting a fault into the storage system so that the storage system enters a recovery state includes: A fault is injected into the storage system in the healthy state, so that the storage system enters the recovery state.

7. The data recovery test method according to claim 6, characterized in that: Performing a fault injection on the storage system in the healthy state so that the storage system enters the recovery state includes: Performing fault injection on the storage system in the healthy state so that the storage system enters a waiting-for-recovery state; After waiting for a preset period of time in the waiting-for-recovery state, it is determined that the storage system enters the recovery state.

8. A data recovery test device, characterized in that: include: An injection module, used for injecting a fault into the storage system so as to put the storage system into a recovery state; A testing module, used to determine a target test scenario in the recovery state, and perform a performance recovery test on the storage system in the target test scenario; An estimation module, used to estimate the target time for the storage system to enter a stable state during the performance recovery test; A verification module, used to collect target performance data of the storage system for verification after waiting for the target time, and determine the test result of the target test scenario according to the verification result; The determination module is used to determine the data recovery test result according to the test result of each target test scenario.

9. An electronic device, characterized in that: include: Memory for storing computer programs; A processor, configured to implement the steps of the data recovery test method according to any one of claims 1 to 7 when executing the computer program.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the steps of the data recovery test method according to any one of claims 1 to 7 are implemented.

Images