Verification method and device of quota balance mechanism, storage medium and program product

Abstract

The invention discloses a verification method and device of a quota balancing mechanism, a storage medium and a program product, and relates to the technical field of storage, the method comprises the steps that a test set with a plurality of test combinations is acquired, and the test combinations comprise a plurality of tenant use scenes used for triggering the quota balancing mechanism; a plurality of tenant usage scenarios can be obtained by traversing to-be-tested test combinations in a test set. Tenant behaviors are simulated in a storage system supporting multiple tenants, and tenant use scenes are simulated in different quota inspection periods, so that a quota balancing mechanism is triggered to execute automatic quota balancing. And finally, obtaining an equalization result, and performing standard verification on the quota equalization mechanism based on the equalization result. The method has the technical effects that the quota balancing mechanism can be triggered to execute automatic quota balancing by automatically simulating different tenant use scenes, and then the quota balancing mechanism is subjected to standard verification on the basis of the obtained balancing result.

Description

Technical Field

[0001] The present application relates to the field of storage technology, and in particular to a verification method, device, storage medium, and program product for a quota balancing mechanism. Background Art

[0002] For storage systems supporting multiple tenants, a quota balancing mechanism automatically scales quotas across multiple tenants based on demand. This allows for rapid quota allocation without administrator oversight, ensuring business continuity. Therefore, the proper functioning of the quota balancing mechanism is crucial. However, existing verification methods only validate single functional points, failing to ensure proper performance in complex and diverse scenarios.

[0003] How to verify whether the quota balancing mechanism meets expectations is a technical problem that technicians in this field urgently need to solve. Summary of the Invention

[0004] This application provides a verification method, device, storage medium, and program product for a quota balancing mechanism, which can effectively verify whether the quota balancing mechanism meets expectations.

[0005] This application provides a verification method for a quota balancing mechanism, including:

[0006] Get a test set with several test combinations;

[0007] Traversing the test combinations to be tested in the test set to obtain several tenant usage scenarios for triggering the quota balancing mechanism;

[0008] Simulating tenant behavior in a storage system that supports multiple tenants to simulate the tenant usage scenarios in different quota inspection cycles;

[0009] When the quota balancing mechanism is triggered to perform automatic quota balancing, obtaining a balancing result;

[0010] The balancing result is used to verify whether the quota balancing mechanism meets the standards.

[0011] This application also provides a verification device, including:

[0012] A test set acquisition module, used to acquire a test set having several test combinations;

[0013] Tenant usage scenarios, used to traverse the test combinations to be tested in the test set to obtain several tenant usage scenarios for triggering the quota balancing mechanism;

[0014] A scenario simulation module is used to simulate tenant behavior in a storage system that supports multiple tenants, so as to simulate the tenant usage scenarios in different quota inspection cycles;

[0015] A balancing result acquisition module, configured to acquire a balancing result when the quota balancing mechanism is triggered to perform automatic quota balancing;

[0016] A verification module is used to verify that the quota balancing mechanism meets the requirements using the balancing result.

[0017] The present application also provides an electronic device, comprising: a memory for storing a computer program; and a processor for implementing the steps of any one of the above-mentioned verification methods when executing the computer program.

[0018] The present application also provides a computer-readable storage medium, in which a computer program is stored. When the computer program is executed by a processor, the steps of any of the above-mentioned verification methods are implemented.

[0019] The present application also provides a computer program product, including a computer program, which implements the steps of any of the above verification methods when executed by a processor.

[0020] Through this application, a test set with several groups of test combinations can be obtained, in which there are several tenant usage scenarios for triggering the quota balancing mechanism. Therefore, by traversing the test combinations to be tested in the test set, several tenant usage scenarios can be obtained. Then, tenant behavior is simulated in a storage system that supports multiple tenants. In this way, tenant usage scenarios can be simulated separately in different quota inspection cycles; because tenant usage scenarios will trigger the quota balancing mechanism. Therefore, after simulating tenant behavior and simulating the corresponding tenant usage scenarios, automatic quota balancing will be performed when the quota balancing mechanism is triggered. Then, the balancing result is obtained, and the quota balancing mechanism can be verified to be up to standard based on the balancing result.

[0021] That is to say, in this application, different tenant usage scenarios can be automatically simulated to trigger the quota balancing mechanism to perform automatic quota balancing, and then based on the obtained balancing results, the quota balancing mechanism can be verified to be up to standard. BRIEF DESCRIPTION OF THE DRAWINGS

[0022] In order to more clearly illustrate the embodiments of the present application, the following is a brief introduction to the drawings required for use in the embodiments. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0023] Figure 1 A flowchart of a verification method for a quota balancing mechanism provided in an embodiment of the present application;

[0024] Figure 2A schematic diagram of a specific implementation method of a quota balancing mechanism provided in an embodiment of the present application;

[0025] Figure 3 A schematic diagram of the structure of a verification device provided in an embodiment of the present application;

[0026] Figure 4 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application;

[0027] Figure 5 A schematic diagram of the specific structure of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0028] The following will be combined with the accompanying drawings in the embodiments of this application to clearly and completely describe the technical solutions in the embodiments of this application. Obviously, the embodiments described are only part of the embodiments of this application, not all of them. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0029] It should be noted that, in the description of this application, the terms "comprises," "includes," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or device comprising a series of elements includes not only those elements, but also other elements not explicitly listed, or elements inherent to such process, method, article, or device. The terms "first," "second," etc., in this application are used to distinguish similar objects, and are not used to describe a particular order or sequence.

[0030] Below, relevant technical terms are explained.

[0031] Multi-tenancy: Multi-tenancy technology, also known as multi-tenancy technology, is a software architecture technology that enables multiple users to share the same system or program components while still ensuring data isolation between users.

[0032] System tenants: System tenants are not ordinary tenants. System tenant users have administrator privileges and can manage ordinary tenants, allocate resources to ordinary tenants, modify tenants, and perform other operations.

[0033] SAN Quota: The amount of space available for data storage in unified storage. The total space across all storage pools in the storage system constitutes the total quota. Quotas are allocated to tenants according to specified sizes, and tenants then have exclusive use of these quotas for storing business data. Specifically, a management mechanism for storage resources in a SAN (Storage Area Network) environment controls storage space usage by specific entities (such as hosts, LUNs, users, or business departments) by setting usage caps. This ensures optimal resource allocation and prevents misuse or overuse.

[0034] Shared quota: It is a quota shared by the storage system and not exclusive to tenants. It is controlled by the system administrator.

[0035] Logical volume (volume): Get any space of different capacities from the storage pool to create a logical volume. After mapping it to the customer's host, the customer can use it as a disk to store data and perform read and write operations.

[0036] Tenant users: Multi-tenants are independent user groups and roles in the storage system. First, create a tenant user group, then create a tenant to belong to this tenant user group. Then, create a tenant user and bind it to this tenant. Then, log in to the storage system using this tenant user to access the tenant's resources.

[0037] In order to enable those skilled in the art to better understand the present application, the present application is further described in detail below with reference to the accompanying drawings and specific implementation methods.

[0038] Please refer to Figure 1 , the specific implementation steps of this method are as follows.

[0039] S101. Obtain a test set having several test combinations.

[0040] In the embodiments of the present application, a quota balancing mechanism in a storage system with a multi-tenant architecture is verified.

[0041] A multi-tenant architecture is a software architecture pattern that allows services to be provided to multiple tenants within a single instance or system. Each tenant typically represents an independent customer or business unit. They share the same hardware and software resources, but their data and configurations are isolated. In storage, a multi-tenant architecture means that the data of multiple tenants is stored on the same physical storage device, but logically isolated to ensure data security and privacy. This requires cloud storage systems to have strong data management capabilities, including data access control, data encryption, and data backup and recovery.

[0042] SAN multi-tenancy creates multiple virtual storage systems within a single physical storage device, providing flexibility, ease of management, and lower deployment costs for multiple tenants without compromising data security and privacy. Resources under multiple tenants are relatively independent and cannot be seen or used by other tenants. This logical isolation ensures tenants' business and network security.

[0043] In unified storage, after the system administrator creates multiple tenants, they allocate resources to them, including SAN quotas, or storage space. Each tenant's quota information includes the total SAN quota, the remaining available SAN quota, and the used SAN quota.

[0044] In this embodiment, the quota balancing mechanism is a management mechanism used to achieve reasonable allocation of storage resources among multiple tenants and maintain system or environmental balance. By setting and adjusting quotas, we can avoid overuse or uneven resource allocation, ensuring stable system operation or achieving specific goals. Appropriate balancing rules and adjustment logic can be designed based on specific application scenarios.

[0045] The quota balancing mechanism in SAN storage automatically expands quotas across multiple tenants based on their needs. This allows for quick quota allocation without administrator oversight, preventing disruption to business operations. SAN quota resources represent storage pool capacity. Once a tenant has allocated a quota, they can create their own logical volumes for data storage. However, quotas are allocated by the system administrator and cannot be allocated by tenants themselves.

[0046] In this embodiment, the test set refers to a set of several test combinations that need to be verified in this verification. A test combination corresponds to a specific tenant usage scenario. There can be one or more tenant use cases in a tenant usage scenario, and the tenant use cases can be the same or different.

[0047] In this embodiment, for the convenience of testing, a tenant use case can be specifically a tenant with a specified tenant level, a specific quota, and whether the quota is sufficient. For example, a tenant use case can correspond to a tenant level of normal and a sufficient quota.

[0048] In a specific implementation of the present application, obtaining a test set having several test combinations includes: obtaining several tenant instances; combining the tenant instances to obtain candidate combinations; selecting a test combination from the candidate combinations, and adding the test combination to the test set.

[0049] The obtaining of several tenant instances includes: obtaining tenant configuration of the storage system; and obtaining several tenant instances by combining tenant levels, whether quotas are sufficient, and whether expansion is allowed in the tenant configuration.

[0050] The tenant instances are combined to obtain a candidate combination, including: obtaining the number of tenants required for simulation for verification; and selecting one or more tenant instances from a plurality of tenant instances for combination according to the number of tenants to obtain a candidate combination.

[0051] The following uses the example of dividing tenants into three levels to explain how to obtain a test set.

[0052] Tenants are divided into three levels: very important tenants, important tenants, and general tenants. This classification can be based on the importance of each tenant's business. Of course, in actual applications, the user-level storage system can be customized.

[0053] For very important tenants: the quota cannot be reduced, and the quota can be increased first. When the idle quota of a very important tenant is less than 20%, the quota needs to be expanded and allocated from the system shared quota. Important tenants: the quota cannot be reduced, and increasing the quota has the second highest priority. When the quota idle rate is less than 20%, it is written that the quota needs to be expanded, but the quota can only be applied from the system shared quota. If the shared quota is insufficient, the application will be abandoned. General tenants: The quota can be automatically reduced according to the current usage rate. When the quota idle rate is less than 20%, the quota needs to be expanded, but the quota can only be applied from the system shared quota. If the shared quota is insufficient, the expansion fails.

[0054] For a single tenant, quota sufficiency and insufficiency are defined as two or three scenarios for each tenant level. This results in seven basic scenarios for each of the three tenant levels, or seven specific tenant instances. Refer to Table 1 for the following: Tenant Instance 1: Very Important Tenant with Sufficient Quota; Tenant Instance 2: Very Important Tenant with Insufficient Quota; Tenant Instance 3: Important Tenant with Sufficient Quota; Tenant Instance 4: Important Tenant with Insufficient Quota; Tenant Instance 5: General Tenant with Sufficient Quota (Can Be Scaled Down); Tenant Instance 6: General Tenant with Sufficient Quota (Cannot Be Scaled Down); Tenant Instance 7: General Tenant with Insufficient Quota. In practice, different tenant instances can be defined based on different tenant tier classification schemes and whether or not scaling is possible, so these will not be detailed here. Below, tenant instance numbers are used to refer to different tenant instances, such as 1, which corresponds to Tenant Instance 1: Very Important Tenant with Sufficient Quota. Furthermore, because different tenant instances are simulated during the verification process, a tenant instance can also be considered a single tenant behavior.

[0055] Table 1 is a schematic diagram of tenant instances

[0056]

[0057] Considering that there is not only one tenant in actual applications and the tenant situations are also different, in order to better simulate the actual tenant usage scenario, in this embodiment, the tenant instances can be combined to obtain a test combination.

[0058] Specifically, these tenant instances are combined in various combinations, including one, two, three, four, five, six, and seven tenant instance combinations. This allows for the combination of identical and different tenant instances between tenants of the same level and between tenants of different levels, simulating various real-world tenant usage scenarios. Each tenant instance can be a single tenant or multiple tenants, and can be configured and adjusted based on actual testing needs.

[0059] For example, a similar orthogonal combination method can be used to identify all possible combinations. These combinations can be recorded in seven behavioral combination test sets for storage. Seven behavioral combination test set tuples are defined, t1 to t7, for example, t1 = (1, 2, 3), t2 = (11, 12, 13), t3 = (123), etc. This allows for customized selection of one or more behavioral combinations for testing. However, only one behavioral combination can be executed during a quota automatic balancing inspection cycle, as executing multiple behavioral combinations will not guarantee that the final results meet expectations. Table 2 below provides a summary of some potential combinations.

[0060] Table 2 is a summary of some of the candidate combinations

[0061]

[0062] Then, one or more combination instances can be selected from the candidate combinations consisting of the seven tenant instances to form the test set for this test. For example, t1 and t2 are selected to form the test set A=[1,2,3,…,12,13,23,…].

[0063] In a specific implementation of the present application, obtaining a test set having several test combinations includes: obtaining several tenant instances; corresponding tenant instances to behavior information, the behavior information including preconditions, operation steps and expected results; storing the behavior information corresponding to the tenant instances in dictionaries respectively; combining the tenant instances to obtain candidate combinations, and storing the dictionaries corresponding to the same candidate combination in a dictionary list; selecting a test combination from the candidate combinations; adding the dictionary list corresponding to the test combination to the test set list to obtain a test set.

[0064] That is to say, each behavior information can be defined as a dictionary and saved, where each behavior information includes preconditions, operation steps, and expected results; each behavior combination can be defined as a dictionary list and saved; finally, after selecting the candidate combinations to form a test set, all the dictionary lists are reorganized into a test list and saved.

[0065] For example, each behavior information corresponds to a tenant instance, such as 1 = {Precondition: a, Operation: b, Expected Result: c}, 2 = {Precondition: aa, Operation: bb, Expected Result: cc}. 1 and 2 refer to tenant instances 1 and 2 above. Each test combination can be defined as a dictionary list, such as 1 = [{Precondition: a, Operation: b, Expected Result: c}], 12 = [{Precondition: a, Operation: b, Expected Result: c}], [{Precondition: aa, Operation: bb, Expected Result: cc}]. After the test combination is selected and the test set is obtained, a test set list is formed, such as A=[[{precondition: a, operation steps: b, expected result: c}],[{precondition: aa, operation steps: bb, expected result: cc}],[{precondition: a, operation steps: b, expected result: c}],[{precondition: aa, operation steps: bb, expected result: cc}],[…]], the test set list element is also a list.

[0066] S102: Traverse the test combinations to be tested in the test set to obtain several tenant usage scenarios for triggering the quota balancing mechanism.

[0067] In this embodiment, after the test set is obtained, the test combinations to be tested in the test set may be traversed to obtain several tenant usage scenarios for triggering the quota balancing mechanism.

[0068] Among them, one test combination corresponds to a tenant usage scenario, and a tenant usage scenario can have one tenant or multiple tenants.

[0069] S103: Simulate tenant behavior in a storage system that supports multiple tenants, so as to simulate tenant usage scenarios in different quota inspection cycles.

[0070] After determining tenant usage scenarios, you can simulate tenant behavior in a multi-tenant storage system, thereby simulating tenant usage scenarios during different quota inspection cycles. Specifically, simulate at most one tenant usage scenario during each quota inspection cycle to determine which tenant usage scenario the balancing result corresponds to.

[0071] In a specific embodiment of the present application, tenant behavior is simulated in a storage system that supports multiple tenants to simulate tenant usage scenarios in different quota inspection cycles, including: in a storage system that supports multiple tenants, tenants that match the tenant usage scenarios are established; if the tenant has sufficient quota in the tenant usage scenario, the capacity of the newly created volume of the tenant user is simulated to be less than the specified share under the tenant; if the tenant has insufficient quota in the tenant usage scenario, the capacity of the newly created volume of the tenant user is simulated to be greater than the specified share under the tenant.

[0072] In a storage system that supports multi-tenancy, establishing tenants that match tenant usage scenarios involves: obtaining tenant information from the tenant usage scenarios; determining the tenant level and number of tenants using the tenant information; establishing tenants that match the tenant level and number of tenants in the storage system, and allocating quotas to the created tenants. In other words, creating tenants and assigning quotas allows for subsequent matching of tenants with tenant usage scenarios by mimicking combined user behavior, thereby triggering a quota balancing mechanism.

[0073] Allocating quotas to newly created tenants involves dividing the total storage system quota into shared quotas and tenant quotas, and then equally allocating the tenant quotas to the newly created tenants. This simplifies quota management and ensures that the shared quota is always sufficient from the start.

[0074] Simulating a tenant user to create a new volume with a capacity greater than the specified quota under the tenant includes: simulating the tenant user under the tenant, randomly determining a target volume size within a range of volume sizes; and continuously creating target volumes according to the target volume size so that the new volume capacity exceeds the specified quota. In other words, the creation of target volumes can be used to ensure that the tenant's used quota status matches the tenant's usage scenario.

[0075] Furthermore, while simulating tenant users creating new volumes under a tenant, a volume is also created under the system tenant to simulate changes in shared quotas. This means that by creating volumes under the system tenant, shared quotas are occupied, thereby achieving changes in shared quotas, fully simulating actual application scenarios.

[0076] In other words, based on the preconditions, operation steps, and expected results corresponding to the tenant instances in the test combination, the tenant usage scenario corresponding to the test combination can be simulated. Specifically, this can be achieved through a defined universal function method. During program execution, after obtaining the value of this dictionary element, the corresponding method program is executed to complete the corresponding operations in sequence. Each element in the test set can be sequentially selected, that is, each test combination is completed sequentially. A test combination is completed during a quota inspection cycle, simulating the implementation of different automatic balancing strategies for storage SAN quotas. If the behavior combination contains two or more behaviors, all operation steps are executed first, and then the expected results are checked after automatic quota balancing is triggered. Automatic quota balancing refers to the balancing operation of expanding or reducing the quota for the corresponding tenant when the current multi-tenant usage scenario triggers the automatic quota balancing conditions set in the quota automatic balancing mechanism (such as applying for expansion or reaching the used quota threshold, etc.).

[0077] Taking an example, the specific implementation steps are as follows.

[0078] Step 1: Based on each test behavior combination, the system administrator will first create a corresponding number of tenants and corresponding users. For example, if there are two behavior combinations, two tenants and two tenant users will be created. Tenant users log in to the storage cluster system through remote SSH and then issue storage operation commands in parallel or serially.

[0079] Step 2: The system administrator then assigns fixed quotas to tenants. Volumes are created under the system tenant to simulate changes in shared quotas, and volumes are created under non-system tenants to simulate changes in individual tenant quotas. For simplicity, the quotas assigned to tenants are fixed, regardless of whether there are one or more tenants. 50% of the shared quota is reserved, and the remaining 50% is evenly distributed among all tenants to ensure sufficient shared quota at the outset. Simulating sufficient shared quota requires no additional action. Simulating insufficient shared quota requires simply creating a volume of a specified capacity under the system tenant so that the available shared quota is less than the expansion quota. Simulating sufficient and insufficient tenant quotas is accomplished by creating logical volumes of a specified capacity. A sufficient quota is achieved when the newly created volume's capacity accounts for less than 80% of the tenant's total quota, while insufficient quota is achieved when the newly created volume's capacity accounts for more than or equal to 80% of the tenant's total quota. Using newly created volumes to control changes in used quota usage is both simple and accurate. The size of the created volumes is a random number within a range, ensuring that the data generated in each test is unique, simulating real customer behavior and improving coverage.

[0080] S104: When the quota balancing mechanism is triggered to perform automatic quota balancing, a balancing result is obtained.

[0081] When the quota balancing mechanism is triggered, automatic quota balancing can be performed. After the quota balancing is performed, the balancing result can be obtained. The balancing result can include the results corresponding to quota changes such as whether the tenant has expanded or reduced its capacity.

[0082] In a specific embodiment of the present application, when the quota balancing mechanism is triggered to perform automatic quota balancing, the balancing result is obtained, including: triggering the quota balancing mechanism to perform automatic quota balancing in a simulated tenant usage scenario; waiting for the quota balancing mechanism to perform automatic quota balancing for the required time, obtaining the storage audit log; and determining the balancing result based on the storage audit log. After the quota balancing mechanism is triggered, the automation program can determine whether the execution is successful or failed, and save the corresponding execution information to the audit log, and also save the quota information of all combinations obtained during the execution process. That is, the storage system will record the audit log for the success and failure of expansion and contraction, and by obtaining the audit log, the balancing result can be obtained by obtaining the audit log.

[0083] S105. Use the balancing result to verify that the quota balancing mechanism meets the standards.

[0084] Each test case in a test suite has a corresponding expected result, indicating whether the tenant's quota has been expanded or reduced. For example, if the shared quota is sufficient, then all tenants will successfully expand their quota even if their quota is insufficient. If the shared quota is insufficient, then the quota expansion failure will be reported. If all tenants have sufficient quota, no expansion is required. If the shared quota is insufficient, then expanding the tenant's quota will fail and trigger an expansion failure alarm. If a general tenant has a large quota, then the quota will be released to the shared quota by reducing their own quota.

[0085] Therefore, the quota balancing mechanism can be verified to be in compliance with the standards by comparing the balancing results with the expected results.

[0086] In a specific embodiment of the present application, after verifying the compliance of the quota balancing mechanism using the balancing result, if the current verification result is that the currently simulated tenant usage scenario has not passed, an error message can be output, and the specific details can be recorded, and the storage system can be initialized (such as deleting the tenant), and the next tenant usage scenario can be simulated until the verification results corresponding to all tenant usage scenarios to be tested are obtained. After all tests are completed, the error details are exported, and the quota balancing mechanism is optimized based on the error details (such as supplementing the configuration in the quota balancing mechanism), and the tenant usage scenario with the error is re-simulated until all tenant usage scenarios to be tested are verified. In this way, the quota balancing mechanism can be continuously optimized through verification, so that the quota balancing mechanism can ultimately have better performance under complex and changing tenant usage scenarios.

[0087] In a specific implementation of the present application, the quota balancing mechanism is verified to be up to standard using the balancing result, including: judging whether the balancing result is consistent with the expected result of the currently simulated tenant usage scenario; if so, determining that the quota balancing mechanism is up to standard in the currently simulated tenant usage scenario; if not, determining that the quota balancing mechanism is not up to standard in the currently simulated tenant usage scenario. Specifically, the expected results can be divided into five categories: Expected 1: No quota expansion, Expected 2: No quota reduction, Expected 3: Quota expansion, Expected 4: Quota reduction, Expected 5: Failure to expand quota. Then the information of each behavior corresponds to the correct expected result, where there are one or more expected results. First, perform the operation of creating a volume to simulate quota changes, save the current used quotas and available shared quotas of all tenants, and after triggering the automatic balancing of storage quotas, check the storage audit logs and various quota values, and compare the expected results to see whether the quota expansion and quota reduction operations are completed, and whether the shared quotas and the quota values ​​corresponding to the tenants are the same as expected.

[0088] In a specific embodiment of the present application, tenant behavior is simulated in a storage system that supports multiple tenants, so as to simulate tenant usage scenarios in different quota inspection cycles, including: simulating tenant behavior in a tenant usage scenario in a single quota inspection cycle, until all tenant usage scenarios have been simulated, or determining that the quota balancing mechanism does not meet the standards in the currently simulated tenant usage scenario. That is to say, after completing a test combination, if the quota automatic balancing result meets expectations, the verification is successful, and then the next quota inspection cycle is entered, and then the next behavior combination test is executed until all tests in the test set are completed; otherwise, if the inspection result does not meet expectations, it fails and exits, and an error prompt message is given. The length of the storage quota inspection cycle can be flexibly set, and can be set to a shorter time to allow the test to be executed more quickly.

[0089] Through the description of the above implementation methods, those skilled in the art can clearly understand that the method according to the above embodiment can be implemented by means of software plus the necessary general hardware platform, and of course it can also be implemented by hardware, but in many cases the former is a better implementation method.

[0090] By applying the method provided in the embodiment of the present application, a test set with several groups of test combinations can be obtained, in which there are several tenant usage scenarios for triggering the quota balancing mechanism. Therefore, by traversing the test combinations to be tested in the test set, several tenant usage scenarios can be obtained. Then, tenant behavior is simulated in a storage system that supports multiple tenants. In this way, tenant usage scenarios can be simulated separately in different quota inspection cycles; because tenant usage scenarios will trigger the quota balancing mechanism. Therefore, after simulating tenant behavior and simulating the corresponding tenant usage scenarios, automatic quota balancing will be performed when the quota balancing mechanism is triggered. Then, the balancing result is obtained, and the quota balancing mechanism can be verified to be up to standard based on the balancing result.

[0091] That is to say, in this application, different tenant usage scenarios can be automatically simulated to trigger the quota balancing mechanism to perform automatic quota balancing, and then based on the obtained balancing results, the quota balancing mechanism can be verified to be up to standard.

[0092] To facilitate those skilled in the art to better understand and implement the verification method provided in the embodiments of the present application, the following detailed description is given in combination with details such as actual verification configuration.

[0093] Please refer to Figure 2 , you can configure the multi-tenant storage cluster and all node information in the current test environment into a configuration file that can be read by the automation platform or automation script. This allows the automation script to remotely log in to the test cluster or node and issue execution commands when executing the automation case.

[0094] In order to flexibly implement customized test sets, you can customize the test set for this test. The customized parameter is the test set (--test_set): it is used to specify which behavior combinations are selected for this test. You can select 1 or more. The setting format is such as -test_set=1:2:3, which means that the behavior combinations of this test are 1 behavior combination, 2 behavior combinations and 3 behavior combinations. The program will combine these three types of behavior combinations into a final test combination list; it can be set to -test_set=all, which means testing all behavior combinations. If it is not set by default, it will default to all.

[0095] Initialize the test set data structure. The test set tuples for the seven test behaviors and seven behavior combinations are t1 to t7. Because different quota configurations and expected results are required when the cluster's shared quota is sufficient or insufficient, the test sets are divided into two categories based on whether the shared quota is sufficient or insufficient.

[0096] Specifically, the test set can be divided into two categories based on whether the shared quota is sufficient or insufficient. The parameter -is_euf_quota can be set to either yes or no. "yes" indicates sufficient shared quota, while "no" indicates insufficient shared quota. By default, the value is yes. The parameter -is_euf_quota determines the test behaviors selected for this test and the resulting test set. The precondition for distinguishing between sufficient and insufficient shared quotas is to simulate the successful and failed tenant quota expansion scenarios. If the shared quota is sufficient, the tenant quota expansion succeeds; otherwise, it fails.

[0097] For each tenant level, quota sufficiency and insufficiency are defined as two or three scenarios, resulting in seven tenant instances for the three tenant levels. These tenant instances are combined into various combinations, including one, two, three, four, four, five, six, and seven tenant instances. This allows for the combination of identical and different tenant instances between tenants of the same level and between tenants of different levels, simulating the various tenant instances of real tenants.

[0098] Using a similar orthogonal combination method, we derive candidate combinations for all tenant instances and record these combinations in seven behavioral combination test sets. We define seven behavioral combination test set tuples, t1 to t7, for example, t1 = (1, 2, 3), t2 = (11, 12, 13), t3 = (123), etc. You can select one or more behavioral combinations for testing, but only one can be executed during a quota auto-balancing inspection cycle. Executing multiple behavioral combinations can make it impossible to determine whether the final results meet expectations.

[0099] Generate the test set: From the test sets obtained from the seven tenant use cases, select one or more behavior combinations to form the test set for this test. For example, select t1 and t2 to form the test set A = [1, 2, 3, …, 12, 13, 23, …]. Define each behavior information as a dictionary, where each behavior information includes preconditions, operation steps, and expected results. Then define each behavior combination as a dictionary list. Finally, after selecting the behavior combinations to form the test set, combine all the dictionary lists into a test list and save it.

[0100] When verifying operations, you sequentially select each element from the test set, completing each action combination sequentially. Each test combination completes within a quota inspection cycle, simulating the implementation of different strategies for automatic balancing of storage SAN quotas. If a test combination contains two or more actions, complete all the steps first, then trigger automatic quota balancing before checking the expected results. The specific implementation includes the following steps.

[0101] Step 1: Based on each test behavior combination, the system administrator will first create a corresponding number of tenants and corresponding users. For example, if there are two behavior combinations, two tenants and two tenant users will be created. Tenant users log in to the storage cluster system through remote SSH and then issue storage operation commands in parallel or serially.

[0102] Step 2: The system administrator then assigns fixed quotas to tenants. Volumes are created under the system tenant to simulate changes in the shared quota, and volumes are created under non-system tenants to simulate changes in each tenant's quota. For simplicity, all tenants are assigned fixed quotas. Regardless of whether they are single or multiple, 50% of the shared quota is reserved for each tenant, and the remaining 50% is evenly distributed among all tenants to ensure sufficient shared quota at the outset. Simulating sufficient shared quota requires no additional action. Simulating insufficient shared quota requires creating a volume of a specified capacity under the system tenant so that the available shared quota is less than the expansion quota. Simulating sufficient and insufficient tenant quotas is accomplished by creating a logical volume of a specified capacity. A sufficient quota is achieved when the newly created volume's capacity accounts for less than 80% of the tenant's total quota, while insufficient quota is achieved when the newly created volume's capacity accounts for more than or equal to 80% of the tenant's total quota. (Of course, this specified portion can be set and adjusted based on the actual quota automatic balancing mechanism.) Using newly created volumes to control changes in used quota usage is simple and accurate. In addition, the size of the created volume is a random number that fits the range, so that the data for each test can be different, which can simulate the real behavior of customers and improve coverage.

[0103] Step 3: Each tenant instance in a test combination has a corresponding expected result. The expected result indicates whether the tenant's quota has been expanded or reduced. This includes: if the shared quota is sufficient, all tenants will successfully expand their quota even if their quota is insufficient. If the shared quota is insufficient, the quota expansion failure message will be displayed. If all tenants have sufficient quota, no expansion is required. If the shared quota is insufficient, the tenant's quota expansion will fail and an expansion failure alarm will be triggered. If a general tenant has sufficient quota space, the tenant's quota will be reduced to release quota to the shared quota. Each action information then corresponds to the correct expected result, which can be one or more.

[0104] You can first create a volume to simulate quota changes, save the current used quotas and available shared quotas for all tenants, and after triggering automatic storage quota balancing, check the storage audit logs and various quota values ​​to compare the expected results to see whether the quota expansion and reduction operations are completed, and whether the shared quotas and the quota values ​​corresponding to the tenants are the same as expected. The storage has audit logs for the success and failure of expansion and reduction. By verifying the audit logs, the automated program determines whether the execution succeeded or failed, and saves the corresponding execution information to the log. At the same time, the quota information of all combinations obtained during the execution process is also saved for test record keeping.

[0105] Step 4: After completing a behavior combination test, if the quota automatic balancing result meets expectations, the test is successful, and the next quota inspection cycle is entered, and then the next behavior combination test is executed until the tests in all test sets are completed; otherwise, if the inspection result does not meet expectations, the test fails and exits with an error prompt message.

[0106] It can be seen that the verification method provided in the embodiment of the present application is applied to the automated testing of multi-tenant related functions of unified storage products. The full test set is quickly obtained through the automated program, which can simulate a large number of different tenant behavior combinations. A very simple operation method is used to simulate the quota changes triggered by the behavior of multiple tenant users; and general operations are abstracted to achieve the same type of operations and the same type of expected results through public function methods, thereby realizing automated testing of a large number of different behavior combinations. Ultimately, a combination of the same and different behaviors between tenants of the same level and between tenants of different levels is achieved, simulating various different behaviors of real tenants. Comprehensively cover the different operation combinations when multiple tenant users use quotas, and simulate the automatic quota balancing function of the storage system under various combined quota changes. Not only is the test speed improved, but also the test coverage is improved.

[0107] Corresponding to the above method embodiment, the embodiment of the present application further provides a verification device. The verification device described below and the verification method described above can refer to each other.

[0108] Please refer to Figure 3 , the device comprises:

[0109] A test set acquisition module 101 is used to acquire a test set having a plurality of test combinations;

[0110] Tenant usage scenarios 102, used to traverse the test combinations to be tested in the test set to obtain a number of tenant usage scenarios for triggering the quota balancing mechanism;

[0111] A scenario simulation module 103 is used to simulate tenant behavior in a storage system that supports multiple tenants, so as to simulate tenant usage scenarios in different quota inspection cycles;

[0112] The balancing result acquisition module 104 is used to obtain the balancing result when the quota balancing mechanism is triggered to perform automatic quota balancing;

[0113] The verification module 105 is used to verify whether the quota balancing mechanism meets the standards by using the balancing result.

[0114] By applying the device provided in the embodiment of the present application, a test set with several groups of test combinations can be obtained, in which there are several tenant usage scenarios for triggering the quota balancing mechanism. Therefore, by traversing the test combinations to be tested in the test set, several tenant usage scenarios can be obtained. Then, tenant behavior is simulated in a storage system that supports multiple tenants. In this way, tenant usage scenarios can be simulated separately in different quota inspection cycles; because tenant usage scenarios will trigger the quota balancing mechanism. Therefore, after simulating tenant behavior and simulating the corresponding tenant usage scenarios, automatic quota balancing will be performed when the quota balancing mechanism is triggered. Then, the balancing result is obtained, and the quota balancing mechanism can be verified to be up to standard based on the balancing result.

[0115] That is to say, in this application, different tenant usage scenarios can be automatically simulated to trigger the quota balancing mechanism to perform automatic quota balancing, and then based on the obtained balancing results, the quota balancing mechanism can be verified to be up to standard.

[0116] In a specific embodiment of the present application, the scenario simulation module is specifically used to establish a tenant that matches the tenant usage scenario in a storage system that supports multiple tenants; if the tenant has sufficient quota in the tenant usage scenario, the capacity of the newly created volume of the tenant user is simulated to be less than the specified share under the tenant; if the tenant has insufficient quota in the tenant usage scenario, the capacity of the newly created volume of the tenant user is simulated to be greater than the specified share under the tenant.

[0117] In a specific embodiment of the present application, the scenario simulation module is specifically used to obtain tenant information from the tenant usage scenario; use the tenant information to determine the tenant level and the number of tenants; establish tenants that match the tenant level and the number of tenants in the storage system, and allocate quotas to the created tenants.

[0118] In a specific implementation of the present application, the scenario simulation module is specifically configured to divide the total quota of the storage system into a shared quota and a tenant quota; and distribute the tenant quota equally to the created tenants.

[0119] In a specific implementation of the present application, the scenario simulation module is specifically used to simulate a tenant user under a tenant, randomly determine the target volume size within the range of volume size values; and continuously create target volumes according to the target volume size so that the newly created volume capacity is greater than the specified share.

[0120] In a specific implementation of the present application, the scenario simulation module is specifically used to create a volume under the system tenant in the process of simulating a tenant user creating a new volume under the tenant to simulate the change of the shared quota.

[0121] In a specific implementation of the present application, a test set acquisition module is specifically used to obtain several tenant instances; the tenant instances correspond to behavior information, and the behavior information includes preconditions, operation steps and expected results; the behavior information corresponding to the tenant instances is stored in a dictionary respectively; the tenant instances are combined to obtain candidate combinations, and the dictionaries corresponding to the same candidate combination are stored in a dictionary list; a test combination is selected from the candidate combinations; the dictionary list corresponding to the test combination is added to the test set list to obtain a test set.

[0122] In a specific implementation of the present application, the test set acquisition module is specifically used to obtain several tenant instances; combine the tenant instances to obtain candidate combinations; select a test combination from the candidate combinations, and add the test combination to the test set.

[0123] In a specific implementation of the present application, the test set acquisition module is specifically used to obtain the tenant configuration of the storage system; and obtain several tenant instances by combining the tenant level, whether the quota is sufficient, and whether expansion is allowed in the tenant configuration.

[0124] In a specific implementation of the present application, the test set acquisition module is specifically used to obtain the number of tenants required for simulation for verification; according to the number of tenants, one or more tenant instances are selected for combination to obtain a candidate combination.

[0125] In a specific implementation of the present application, the balancing result acquisition module is specifically used to determine whether the balancing result is consistent with the expected result of the currently simulated tenant usage scenario; if so, it is determined that the quota balancing mechanism meets the standards in the currently simulated tenant usage scenario; if not, it is determined that the quota balancing mechanism does not meet the standards in the currently simulated tenant usage scenario.

[0126] In a specific embodiment of the present application, the scenario simulation module is specifically used to simulate tenant behavior in a tenant usage scenario within a single quota inspection cycle until all tenant usage scenarios have been simulated, or it is determined that the quota balancing mechanism does not meet the requirements in the currently simulated tenant usage scenario.

[0127] In a specific implementation of the present application, the balancing result acquisition module is specifically used to trigger the quota balancing mechanism to perform automatic quota balancing under the condition of simulating tenant usage scenarios; after waiting for the quota balancing mechanism to perform automatic quota balancing for the required time, obtain the storage audit log; and determine the balancing result based on the storage audit log.

[0128] For the description of the features in the embodiment corresponding to the verification device, please refer to the relevant description of the embodiment corresponding to the verification method, and no further details will be given here.

[0129] Corresponding to the above method embodiment, an embodiment of the present application further provides an electronic device. The electronic device described below and the verification method described above can refer to each other.

[0130] See also Figure 4 As shown, the electronic device includes:

[0131] Memory 332, for storing computer programs;

[0132] The processor 322 is configured to implement the steps of the verification method of the above method embodiment when executing a computer program.

[0133] For details, please refer to Figure 5 , Figure 5 This is a schematic diagram of the specific structure of an electronic device provided in this embodiment. This electronic device may vary significantly due to different configurations or performance. It may include one or more central processing units (CPUs) (for example, one or more processors) and memory 332. The memory 332 stores one or more computer programs 342 or data 344. The memory 332 may be temporary storage or permanent storage. The program stored in the memory 332 may include one or more modules (not shown), each of which may include a series of instruction operations in the data processing device. Furthermore, the processor 322 may be configured to communicate with the memory 332 to execute the series of instruction operations in the memory 332 on the electronic device 301.

[0134] The electronic device 301 may further include one or more power supplies 326 , one or more wired or wireless network interfaces 350 , one or more input / output interfaces 358 , and / or one or more operating systems 341 .

[0135] The steps in the verification method described above can be implemented by the structure of an electronic device.

[0136] Corresponding to the above method embodiments, embodiments of the present application further provide a readable storage medium. The readable storage medium described below and the verification method described above can be referenced in correspondence with each other. Embodiments of the present application further provide a computer-readable storage medium having a computer program stored therein, wherein the computer program is configured to execute the steps of any of the above verification method embodiments when executed.

[0137] In an exemplary embodiment, the computer-readable storage medium may include, but is not limited to, various media that can store computer programs, such as a USB flash drive, a read-only memory (ROM), a random access memory (RAM), a mobile hard disk, a magnetic disk, or an optical disk.

[0138] An embodiment of the present application further provides a computer program product, which includes a computer program. When the computer program is executed by a processor, the steps in any one of the above verification method embodiments are implemented.

[0139] An embodiment of the present application further provides another computer program product, including a non-volatile computer-readable storage medium, wherein the non-volatile computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the steps in any of the above-mentioned verification method embodiments are implemented.

[0140] Those skilled in the art 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 above description has generally described the composition and steps of each example according to function. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art 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.

[0141] This document uses specific examples to illustrate the principles and implementation methods of this application. The description of the above examples is only intended to help understand the method and core ideas of this application. It should be noted that those skilled in the art may make several improvements and modifications to this application without departing from the principles of this application, and such improvements and modifications also fall within the scope of protection of this application.

Claims

1. A verification method for a quota balancing mechanism, characterized in that: include: Get a test set with several test combinations; Traversing the test combinations to be tested in the test set to obtain several tenant usage scenarios for triggering the quota balancing mechanism; Simulating tenant behavior in a storage system that supports multiple tenants to simulate the tenant usage scenarios in different quota inspection cycles; When the quota balancing mechanism is triggered to perform automatic quota balancing, obtaining a balancing result; The balancing result is used to verify whether the quota balancing mechanism meets the standards.

2. The method according to claim 1, characterized in that Simulate tenant behavior in a multi-tenant storage system to simulate tenant usage scenarios during different quota inspection cycles, including: In a storage system that supports multiple tenants, establishing tenants that match the tenant usage scenarios; If the tenant has sufficient quota in the tenant usage scenario, then the capacity of the newly created volume simulated by the tenant user under the tenant is less than the specified share; If the tenant has insufficient quota in the tenant usage scenario, a new volume capacity greater than the specified share is created by simulating the tenant user under the tenant.

3. The method according to claim 2, characterized in that In a storage system that supports multiple tenants, establishing tenants that match the tenant usage scenarios includes: Obtain tenant information from the tenant usage scenario; Determining the tenant level and the number of tenants using the tenant information; In the storage system, tenants matching the tenant level and the number of tenants are created, and quotas are allocated to the created tenants.

4. The method according to claim 3, characterized in that Allocate quotas for the created tenant, including: Dividing the total quota of the storage system into a shared quota and a tenant quota; The tenant quota is evenly distributed among the created tenants.

5. The method according to claim 2, characterized in that Simulate a tenant user under the tenant to create a new volume with a capacity larger than the specified quota, including: Simulating a tenant user under the tenant and randomly determining a target volume size within a range of volume sizes; Target volumes are continuously created according to the target volume size so that the newly created volume capacity is larger than the specified share.

6. The method according to claim 2, characterized in that The process of simulating a tenant user to create a new volume under the tenant also includes: Create volumes under the system tenant to simulate changes in share quotas.

7. The method according to claim 1, characterized in that Get a test suite with several test combinations, including: Get several tenant instances; Combining the tenant instances to obtain a candidate combination; A test combination is selected from candidate combinations and added to a test set.

8. The method according to claim 7, characterized in that Get several types of tenant instances, including: Obtaining tenant configuration for the storage system; According to the tenant level, whether the quota is sufficient, and whether expansion is allowed in the tenant configuration, several tenant instances are obtained.

9. The method according to claim 8, characterized in that The tenant instances are combined to obtain a candidate combination, including: Get the number of simulated tenants required for verification; According to the number of tenants, one or more tenant instances are selected and combined from the plurality of tenant instances to obtain the candidate combination.

10. The method according to claim 1, characterized in that Get a test suite with several test combinations, including: Obtaining several tenant instances; the tenant instances correspond to behavior information, the behavior information including preconditions, operation steps, and expected results; Storing the behavior information corresponding to the tenant instances in the dictionary respectively; Combine the tenant instances to obtain candidate combinations, and store the dictionaries corresponding to the same candidate combination into a dictionary list; Selecting a test combination from the candidate combinations; Add the dictionary list corresponding to the test combination to the test set list to obtain the test set.

11. The method according to claim 1, wherein The quota balancing mechanism is verified to be up to standard using the balancing result, including: Determining whether the balancing result is consistent with the expected result of the currently simulated tenant usage scenario; If yes, determining that the quota balancing mechanism meets the requirements in the currently simulated tenant usage scenario; If not, it is determined that the quota balancing mechanism does not meet the requirements in the currently simulated tenant usage scenario.

12. The method according to any one of claims 1 to 11, characterized in that When the quota balancing mechanism is triggered to perform automatic quota balancing, obtaining a balancing result includes: In the case of simulating the tenant usage scenario, triggering the quota balancing mechanism to perform automatic quota balancing; After waiting for the quota balancing mechanism to execute the automatic quota balancing for a required period of time, obtaining the storage audit log; The balancing result is determined based on the storage audit log.

13. An electronic device, characterized in that: include: memory for storing computer programs; A processor, configured to implement the steps of the verification method according to any one of claims 1 to 12 when executing the computer program.

14. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a computer program, wherein the computer program implements the steps of the verification method according to any one of claims 1 to 12 when executed by a processor.

15. A computer program product comprising a computer program, characterized in that When the computer program is executed by a processor, the steps of the verification method according to any one of claims 1 to 12 are implemented.

Images