Method, device, storage medium and program product for verifying quota balancing mechanism

Abstract

The application discloses a quota balancing mechanism verification method and device, a storage medium and a program product, relates to the technical field of storage, and comprises the following steps: obtaining a test set with a plurality of test combinations, wherein the test combinations have a plurality of tenant use scenarios for triggering the quota balancing mechanism. By traversing the test combinations to be tested in the test set, a plurality of tenant use scenarios can be obtained. In a storage system supporting multi-tenancy, tenant behavior is simulated, and tenant use scenarios are simulated in different quota inspection periods to trigger the quota balancing mechanism to perform automatic quota balancing. Finally, the balancing result is obtained, and the quota balancing mechanism can be verified based on the balancing result. The technical effect of the application is that different tenant use scenarios can be automatically simulated to trigger the quota balancing mechanism to perform automatic quota balancing, and then the quota balancing mechanism is verified based on the obtained balancing result.

Description

TECHNICAL FIELD

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

[0002] For a storage system supporting multi-tenancy, a quota balancing mechanism can automatically expand the quota according to the needs of a large number of tenants, quickly obtain the quota without the presence of an administrator, and does not delay the use of the business. That is, the normal execution of the quota balancing mechanism is crucial. In related verification methods, only a single function point can be verified, and it cannot be determined whether the quota balancing mechanism is still normally executed in complex and variable use scenarios in actual application processes.

[0003] How to verify whether the quota balancing mechanism meets the expectations is a technical problem that needs to be solved by those skilled in the art. SUMMARY

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

[0005] The present application provides a quota balancing mechanism verification method, comprising:

[0006] obtaining a test set having a plurality of test combinations;

[0007] traversing the test combinations to be tested in the test set to obtain a plurality of tenant use scenarios for triggering the quota balancing mechanism;

[0008] simulating tenant behavior in a storage system supporting multi-tenancy to simulate the tenant use scenarios in different quota inspection periods, respectively;

[0009] obtaining a balancing result in the case of triggering the quota balancing mechanism to perform quota automatic balancing;

[0010] verifying the quota balancing mechanism using the balancing result.

[0011] The present application also provides a verification device, comprising:

[0012] a test set obtaining module for obtaining a test set having a plurality of test combinations;

[0013] a tenant use scenario for traversing the test combinations to be tested in the test set to obtain a plurality of tenant use scenarios for triggering the quota balancing mechanism;

[0014] a scenario simulation module for simulating tenant behavior in a storage system supporting multi-tenancy to simulate the tenant use scenarios in different quota inspection periods, respectively;

[0015] obtaining a balancing result when the quota balancing mechanism is triggered to perform automatic quota balancing;

[0016] verifying the quota balancing mechanism based on the balancing result.

[0017] The application further provides an electronic device, comprising a memory for storing a computer program and a processor for executing the computer program to implement the steps of the verification method.

[0018] The application further provides a computer readable storage medium, which stores a computer program, and the computer program is executed by a processor to implement the steps of the verification method.

[0019] The application further provides a computer program product, which comprises a computer program, and the computer program is executed by a processor to implement the steps of the verification method.

[0020] According to the application, a test set with a plurality of test combinations can be obtained, and the test combinations comprise a plurality of tenant use scenarios for triggering the quota balancing mechanism. Therefore, the test combinations in the test set are traversed to obtain a plurality of tenant use scenarios. Then, the tenant behaviors are simulated in the multi-tenant storage system, so that the tenant use scenarios can be simulated in different quota inspection periods. Since the tenant use scenarios can trigger the quota balancing mechanism, when the tenant behaviors are simulated and the corresponding tenant use scenarios are simulated, the quota balancing mechanism is triggered to perform automatic quota balancing. Then, the balancing result is obtained, and the quota balancing mechanism can be verified based on the balancing result.

[0021] That is, in the application, different tenant use scenarios can be simulated automatically to trigger the quota balancing mechanism to perform automatic quota balancing, and then the balancing result is obtained, and the quota balancing mechanism can be verified based on the balancing result. BRIEF DESCRIPTION OF DRAWINGS

[0022] In order to more clearly illustrate the embodiments of the application, the drawings needed in the embodiments will be briefly introduced. Obviously, the drawings in the following description are only some embodiments of the application, and other drawings can be obtained by those skilled in the art without creative labor.

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

[0024] Figure 2A specific implementation schematic diagram of a verification method of a quota balancing mechanism provided by an embodiment of the present application is provided.

[0025] Figure 3 A structural schematic diagram of a verification device provided by an embodiment of the present application is provided.

[0026] Figure 4 A structural schematic diagram of an electronic device provided by an embodiment of the present application is provided.

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

[0028] The technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, rather than all the embodiments of the present application. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative work fall within the protection scope of the present application.

[0029] It should be noted that, in the description of the present application, the terms “include”, “contain” or any other variants thereof are intended to cover non-exclusive inclusion, so that the process, method, article or device including a series of elements not only includes those elements, but also includes other elements not explicitly listed or inherent to such process, method, article or device. The terms “first”, “second” and the like in the present application are used to distinguish similar objects, and are not used to describe a specific order or sequence.

[0030] Next, related technical terms are explained and described.

[0031] Multi-tenancy: Multi-tenancy technology or multi-rental technology is a software architecture technology that can be implemented in a multi-user environment to share the same system or program component and still ensure the isolation of data between users.

[0032] System tenant: A system tenant is not a general tenant. The user of the system tenant has administrator permissions and can manage general tenants, allocate resources to general tenants, and modify tenants and the like.

[0033] SAN (SAN Quota) quota: The amount of space for storing data in a unified storage system. The total space of all storage pools in the storage system is the total quota. Quotas are allocated to tenants according to a specified size, and then each tenant exclusively uses these quotas for storing business data. In other words, for storage resources in a SAN (Storage Area Network) environment, a usage limit is set to control the use of storage space by specific objects (such as hosts, LUNs, users, or business units), thereby achieving a management mechanism for reasonable resource allocation and avoiding abuse or over-occupancy.

[0034] Shared quotas are quotas shared by the storage system, not quotas reserved for individual tenants, and are controlled by the system administrator.

[0035] Logical Volume (Volume): A logical volume is created by acquiring space of any different capacity from the storage pool. After being mapped to the client's host, the client can use it as a disk to store data and perform read and write operations.

[0036] Tenant users: In a storage system, a tenant is an independent user group and a separate role. First, a tenant user group is created, then a tenant is created belonging to this tenant user group; then a tenant user is created and bound to this tenant. Then, by logging into the storage system through this tenant user, one can control the resources of that tenant.

[0037] To enable those skilled in the art to better understand the present application, the present application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

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

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

[0040] This application embodiment verifies the quota balancing mechanism in a multi-tenant architecture storage system.

[0041] Multitenant architecture is a software architecture pattern that allows multiple tenants to serve a single instance or system. Each tenant typically represents an independent customer or business unit, sharing the same hardware and software resources, but their data and configurations are isolated. In storage, multitenant architecture means that multiple tenants' data are stored on the same physical storage device, but data security and privacy are ensured through logical isolation mechanisms. This requires cloud storage systems to have robust data management capabilities, including data access control, data encryption, data backup and recovery, etc.

[0042] SAN multi-tenancy allows multiple tenants to create multiple virtual storage systems within a single physical storage device. This provides flexibility, ease of management, lower deployment costs, and does not compromise data security and privacy. Resources within each tenant are relatively independent, invisible and unusable by other tenants, ensuring business and network security through logical isolation.

[0043] In unified storage, after a system administrator creates multiple tenants, they allocate resources to those tenants, including SAN quotas, which are storage spaces. Therefore, each tenant's quota information includes the total SAN quota, the remaining available SAN quota, and the SAN quota already used.

[0044] In this embodiment, the quota balancing mechanism is a management mechanism used to achieve reasonable allocation of multi-tenant storage resources and maintain system or environmental balance. By setting and allocating relevant quotas, it can prevent excessive resource use or uneven allocation, ensuring stable system operation or achieving specific goals. Corresponding balancing rules and adjustment logic can be designed according to specific application scenarios.

[0045] The quota balancing mechanism in SAN storage enables automatic quota expansion among a large number of tenants based on demand. It allows for rapid quota acquisition without administrator intervention, ensuring uninterrupted business operations. This SAN quota resource is essentially the storage pool space capacity. After acquiring a quota, tenants can create their own logical volumes for data storage. However, quotas are allocated by the system administrator; tenants cannot allocate them themselves.

[0046] In this embodiment, the test set refers to the set of several test combinations that need to be verified in this verification. One test combination corresponds to a specific tenant use case. In a tenant use case, there can be one or more tenant use cases. The tenant use cases can be the same or different.

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

[0048] In one specific embodiment of this application, obtaining a test set with several test combinations includes: obtaining several types of 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] This involves obtaining several types of tenant instances, including: obtaining the tenant configuration of the storage system; and combining them according to the tenant level, quota sufficiency, and expansion permission in the tenant configuration to obtain several types of tenant instances.

[0050] The process of combining tenant instances to obtain candidate combinations includes: obtaining the number of tenants to be simulated for verification; and selecting one or more types of tenant instances from several types to combine according to the number of tenants, thus obtaining candidate combinations.

[0051] The following example, which divides tenant levels into three tiers, illustrates how to obtain a test set.

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

[0053] For critical tenants: Quota reduction is not allowed; quota increases are prioritized. When a critical tenant's idle quota is less than 20%, quota expansion is required, allocated from the system's shared quota. For important tenants: Quota reduction is not allowed; quota increases are the next priority. When the quota idle rate is less than 20%, quota expansion is required, but quota can only be requested from the system's shared quota. If the shared quota is insufficient, the request is abandoned. For general tenants: Quota reduction can be performed automatically based on current usage. When the quota idle rate is less than 20%, quota expansion is required, but quota can only be requested from the system's shared quota. If the shared quota is insufficient, the expansion fails.

[0054] For a single tenant, the quota sufficiency and insufficiency of each tenant level are defined as two or three scenarios, resulting in seven basic scenarios for a single tenant across the three levels, or seven specific tenant instances. Please refer to Table 1, which lists the following instances: 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. Of course, in practical applications, different tenant instances can be defined based on different tenant level classification schemes and whether scaling down is possible, which will not be elaborated upon here. Below, tenant instance numbers will be used to refer to different tenant instances, such as 1 corresponding to Tenant Instance 1: Very Important Tenant with Sufficient Quota. Furthermore, since different tenant instances will be simulated during the verification process, a single tenant instance can also be considered as a single tenant behavior.

[0055] Table 1 is a sample table of tenant instances.

[0056]

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

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

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

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

[0061]

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

[0063] In one specific embodiment of this application, obtaining a test set with several test combinations includes: obtaining several tenant instances; each tenant instance corresponds to behavioral information, which includes preconditions, operation steps, and expected results; storing the behavioral information corresponding to each tenant instance in a dictionary; combining the tenant instances to obtain candidate combinations, and storing the dictionary corresponding to the same candidate combination in a dictionary list; selecting a test combination from the candidate combinations; and adding the dictionary list corresponding to the test combination to the test set list to obtain the test set.

[0064] In other words, each behavioral information can be defined as a dictionary and stored, where each behavioral information includes preconditions, operation steps, and expected results; each combination of behaviors can be defined as a list of dictionaries and stored; finally, after selecting candidate combinations to form a test set, all the dictionary lists are combined again into a test list and stored.

[0065] For example, each behavioral information corresponds to a tenant instance, such as 1={precondition: a, operation step: b, expected result: c}, 2={precondition: aa, operation step: bb, expected result: cc}. Here, 1 and 2 refer to tenant instance 1 and tenant instance 2 mentioned above. For each test combination, it can be defined as a dictionary list to store, such as 1=[{precondition: a, operation step: b, expected result: c}], 12=[{precondition: a, operation step: b, expected result: c}],[{precondition: aa, operation step: bb, expected result: cc}]. Once the test combination is selected and the test set is obtained, it is formed into a test set list, such as A=[[{precondition: a, operation step: b, expected result: c}],[{precondition: aa, operation step: bb, expected result: cc}],[{precondition: a, operation step: b, expected result: c}],[{precondition: aa, operation step: bb, expected result: cc}],[…]], and the elements of the test set list are also a list.

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

[0067] In this embodiment, after obtaining the test set, the test combinations to be tested in the test set can be traversed to obtain several tenant use cases for triggering the quota balancing mechanism.

[0068] One test combination corresponds to one tenant use case. A tenant use case can have one tenant or multiple tenants.

[0069] S103. Simulate tenant behavior in a multi-tenant storage system to simulate tenant usage scenarios within different quota inspection cycles.

[0070] Once the tenant usage scenarios are determined, tenant behavior can be simulated in a multi-tenant storage system, allowing for the simulation of different tenant usage scenarios within different quota inspection cycles. Specifically, at most one tenant usage scenario can be simulated within a quota inspection cycle to determine which tenant usage scenario corresponds to the load balancing result.

[0071] In one specific embodiment of this application, tenant behavior is simulated in a multi-tenant storage system to simulate tenant usage scenarios in different quota inspection cycles. This includes: in the multi-tenant storage system, establishing tenants that match the tenant usage scenarios; if the tenant has sufficient quota in the tenant usage scenario, then simulating the tenant user creating a new volume with a capacity less than a specified share under the tenant; if the tenant has insufficient quota in the tenant usage scenario, then simulating the tenant user creating a new volume with a capacity greater than a specified share under the tenant.

[0072] In a multi-tenant storage system, creating tenants that match the tenant's usage scenario involves: obtaining tenant information from the tenant's usage scenario; using the tenant information to determine the tenant level and number of tenants; creating 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 allocating quotas allows for subsequent matching of tenants with their usage scenarios by mimicking combined user behaviors, thereby triggering a quota balancing mechanism.

[0073] This involves allocating quotas to the created tenants, including dividing the total quota of the storage system into shared quotas and tenant quotas; and distributing the tenant quotas equally among the created tenants. This simplifies quota management and ensures that the shared quota is initially sufficient.

[0074] Specifically, simulating a tenant user creating a volume with a capacity greater than a specified share includes: simulating a tenant user under the tenant, randomly determining the target volume size within a range of volume size values; and continuously creating target volumes according to the target volume size to ensure that the newly created volume capacity exceeds the specified share. In other words, by creating target volumes, the tenant's used quota status can be matched with the tenant's usage scenario.

[0075] Furthermore, during the process of simulating tenant users creating new volumes under a tenant, volumes are also created under the system tenant to simulate changes in shared quotas. That is, by creating volumes under the system tenant to occupy shared quotas, changes in shared quotas are realized, thus fully simulating real-world 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 general function method. When the program executes, after obtaining the value of this dictionary element, the corresponding method program is executed to complete the corresponding operation in sequence. Each element can be retrieved sequentially from the test set, that is, each test combination is completed sequentially. One test combination is completed in one quota inspection cycle, simulating the implementation of different strategies for automatic balancing of SAN quotas. If the behavior combination has two or more behaviors, all operation steps are executed first, and then the expected result check is performed after automatic quota balancing is triggered. Here, automatic quota balancing refers to the balancing operation of expanding or shrinking the quota for the corresponding tenant after the current multi-tenant usage scenario triggers the conditions set in the automatic quota balancing mechanism (such as applying for expansion, or the used quota reaching the threshold, etc., pre-set conditions).

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

[0078] Step 1: Based on each combination of test behaviors, the system administrator will first create a corresponding number of tenants and users. For example, if it is a combination of two behaviors, two tenants and two tenant users will be created. The tenant users log in to the storage cluster system remotely via SSH, and then issue and execute storage operation commands in parallel or serially.

[0079] Step Two: The system administrator then assigns fixed quotas to tenants. Volumes are created under system tenants to simulate changes in shared quotas, and volumes are created under non-system tenants to simulate changes in quotas for each tenant. For simplicity, the quotas assigned to tenants are fixed, regardless of whether there is one or more. 50% of the shared quota is reserved, and the remaining 50% is evenly distributed among all tenants, ensuring sufficient shared quotas initially. Simulating sufficient shared quotas requires no further action. Simulating insufficient shared quotas involves creating volumes of a specified capacity under system tenants so that the available shared quota is less than the expansion quota. Both simulating sufficient and insufficient tenant quotas are achieved by creating logical volumes of a specified capacity. Sufficient quota means the new volume capacity is less than 80% of the tenant's total quota; insufficient quota means the new volume capacity is greater than or equal to 80%. Using new volumes controls changes in the used quota, achieving a simple and accurate result. The volume size is set to a random number within a certain range, ensuring different data for each test, simulating real customer behavior and improving coverage.

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

[0081] When the quota balancing mechanism is triggered, automatic quota balancing can be performed. After automatic quota balancing is performed, the balancing results can be obtained. The balancing results may include information on whether the tenant has undergone quota changes such as expansion or contraction.

[0082] In one specific embodiment of this application, when the quota balancing mechanism is triggered to perform automatic quota balancing, obtaining the balancing result includes: triggering the quota balancing mechanism to perform automatic quota balancing under a simulated tenant usage scenario; waiting for the required time for the quota balancing mechanism to perform automatic quota balancing, and then obtaining the storage audit log; and determining the balancing result based on the storage audit log. After the quota balancing mechanism is triggered, the automated program can determine whether the execution was successful or failed, and save the corresponding execution information to the audit log, while also saving all combined quota information obtained during the execution process. That is, for both expansion and contraction execution success and failure, the storage system records the audit log, and the balancing result can be obtained by obtaining the audit log.

[0083] S105. Verify the compliance of the quota balancing mechanism using the balancing results.

[0084] Because each test case in a test suite has a corresponding expected result, the expected result is whether the tenant has expanded or reduced their quota. For example, if the shared quota is sufficient, all tenants will successfully expand their quotas if their quotas are insufficient. If the shared quota is insufficient, the expansion of quotas will fail. If all tenants have sufficient quotas, no expansion is needed. If the shared quota is insufficient, the expansion of tenant quotas will fail and trigger an expansion failure alarm. If a general tenant has a large quota space, it will release its quota into the shared quota by reducing its own quota.

[0085] Therefore, the quota balancing mechanism can be verified by comparing the equilibrium results with the expected results.

[0086] In one specific implementation of this application, after verifying the compliance of the quota balancing mechanism using the balancing results, if the current verification result is that the current simulated tenant usage scenario fails, an error message can be output, and the specific details can be recorded. The storage system can then be initialized (e.g., deleting a tenant), and the simulation of the next tenant usage scenario can continue until the verification results for all tested tenant usage scenarios are obtained. After completing all tests, the error details are exported, and the quota balancing mechanism is optimized based on these details (e.g., supplementing the configuration in the quota balancing mechanism). The failed tenant usage scenarios are then re-simulated until all tested tenant usage scenarios pass verification. In this way, the quota balancing mechanism can be continuously optimized through verification, ultimately enabling it to achieve better performance under complex and varied tenant usage scenarios.

[0087] In one specific embodiment of this application, the quota balancing mechanism is validated using the balancing results, including: determining whether the balancing results are consistent with the expected results of the current simulated tenant usage scenario; if yes, the quota balancing mechanism is deemed to have met the requirements in the current simulated tenant usage scenario; if no, the quota balancing mechanism is deemed to have failed to meet the requirements in the current simulated tenant usage scenario. Specifically, the expected results can be divided into five categories: Expectation 1: No quota expansion, Expectation 2: No quota reduction, Expectation 3: Quota expansion, Expectation 4: Quota reduction, and Expectation 5: Quota expansion failure. Each behavior's information corresponds to a correct expected result, where one or more expected results are possible. First, a volume creation simulation quota change operation is executed, saving all tenants' current used quotas and available shared quotas. After automatic quota balancing of storage is triggered, the storage audit logs and various quota values ​​are checked to compare whether the expected results have completed the quota expansion and reduction operations, and whether the shared quota and the quota values ​​corresponding to the tenants are equal to the expectations.

[0088] In one specific embodiment of this application, tenant behavior is simulated in a multi-tenant storage system to simulate tenant usage scenarios within different quota inspection cycles. This includes simulating tenant behavior under a single tenant usage scenario within a single quota inspection cycle until all tenant usage scenarios have been simulated, or until it is determined that the quota balancing mechanism fails to meet the standards in the currently simulated tenant usage scenario. In other words, after completing a test combination, if the automatic quota balancing result meets expectations, the verification is successful, and the next quota inspection cycle begins. Then, the next behavior combination test is executed until all tests in the test set are completed; otherwise, if the check result does not meet expectations, the system fails and exits with an error message. The length of the storage quota inspection cycle can be flexibly set, and can be set to a shorter time to allow for faster test execution.

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

[0090] By applying the method provided in this application, a test set with several test combinations can be obtained, containing several tenant usage scenarios that trigger the quota balancing mechanism. Therefore, by traversing the test combinations to be tested in the test set, several tenant usage scenarios are obtained. Then, tenant behavior is simulated in a multi-tenant storage system, allowing for the simulation of tenant usage scenarios within different quota inspection cycles. Since tenant usage scenarios trigger the quota balancing mechanism, after simulating tenant behavior and corresponding tenant usage scenarios, automatic quota balancing is executed upon triggering the quota balancing mechanism. Then, the balancing result is obtained, and based on this result, the compliance verification of the quota balancing mechanism can be performed.

[0091] In other words, in this application, different tenant usage scenarios can be automatically simulated to trigger the quota balancing mechanism to perform automatic quota balancing. Then, based on the obtained balancing results, the quota balancing mechanism can be verified to meet the standards.

[0092] To facilitate those skilled in the art to better understand and implement the verification methods provided in the embodiments of this application, detailed descriptions are provided below in conjunction with actual verification configurations and other details.

[0093] Please refer to Figure 2 This allows configuring multi-tenant storage clusters and all node information in the current test environment into a configuration file readable by the automation platform or automation scripts. When executing automated test cases, basic cluster and node information, including username, password, login port, and IP address, can be read, enabling automation scripts to remotely log in to the test cluster or nodes and issue execution commands.

[0094] To flexibly implement custom test sets, a custom test set can be defined for this test. The custom parameter is test set (--test_set): it specifies which behavior combinations to select for this test. You can select one or more, and the format is as follows: --test_set=1:2:3, which means that the behavior combinations for 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 also default to all.

[0095] The initial test set data structure is set up with tuples t1 to t7 for 7 test behaviors and 7 behavior combinations. Since different quota configurations and different expected result judgments are required when the cluster's shared quota is sufficient or insufficient, the test sets are divided into two major categories based on whether the shared quota is sufficient or insufficient.

[0096] In practice, the test sets can be divided into two main categories based on whether the shared quota is sufficient or insufficient. The parameter `--is_euf_quota` can be set, with values ​​of `yes` and `no`. `yes` indicates sufficient shared quota, and `no` indicates insufficient shared quota. The default value is `yes`. The `--is_euf_quota` parameter determines the selected test behaviors and the final test set. The prerequisite for this test is whether the shared quota is sufficient or insufficient, mainly to simulate two scenarios: successful and unsuccessful expansion of tenant quotas. If the shared quota is sufficient, the expansion of the tenant quota will succeed; otherwise, it will fail.

[0097] Each tenant tier's quota sufficiency and insufficiency are defined as two or three scenarios, resulting in seven tenant instances across the three tiers. These tenant instances are then combined in various ways, including combinations of one, two, three, four, five, six, and seven tenant instances, to simulate the combinations of identical and different tenant instances between tenants of the same tier and between tenants of different tiers, thus mimicking the diverse tenant instances found in real-world tenant scenarios.

[0098] Using a method similar to orthogonal combination, candidate combinations for all tenant instances are derived. These combinations are then recorded in seven behavior combination test sets, defined as tuples t1 to t7, for example, t1=(1,2,3), t2=(11,12,13), t3=(123), ... . Users can customize and select one or more behavior combinations for testing; however, only one behavior combination can be executed within a single quota automatic balancing inspection cycle, as executing multiple behavior combinations will not guarantee that the final result will 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 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 again into a test list and save it.

[0100] During verification, each element can be sequentially retrieved from the test set, meaning each combination of actions is completed sequentially. One test combination is completed within a quota inspection cycle, simulating the implementation of different strategies for automatic balancing of SAN quotas. If a test combination has two or more actions, all operation steps are executed first, and then the expected result check is performed after automatic quota balancing is triggered. The specific implementation includes the following steps.

[0101] Step 1: Based on each combination of test behaviors, the system administrator will first create a corresponding number of tenants and users. For example, if it is a combination of two behaviors, two tenants and two tenant users will be created. The tenant users log in to the storage cluster system remotely via SSH, and then issue and execute storage operation commands in parallel or serially.

[0102] Step Two: The system administrator then assigns fixed quotas to tenants. Volumes are created under system tenants to simulate changes in shared quotas, and volumes are created under non-system tenants to simulate changes in each tenant's quota. For simplicity, the quotas assigned to tenants are fixed, regardless of whether there is one or multiple tenants. 50% of the shared quota is reserved, and the remaining 50% is evenly distributed among all tenants, ensuring sufficient shared quotas initially. No further action is needed to simulate sufficient shared quotas. If shared quotas are insufficient, volumes of a specified capacity are created under system tenants so that the available shared quota is less than the expansion quota. Simulating sufficient or insufficient tenant quotas is achieved by creating logical volumes of a specified capacity. Sufficient quotas mean the newly created volume capacity is less than 80% of the tenant's total quota; insufficient quotas mean the newly created volume capacity is greater than or equal to 80% of the tenant's total quota (this specified share can be set and adjusted according to the actual quota automatic balancing mechanism). Using newly created volumes to control changes in the used quota is simple and accurate. In addition, the size of the volume is set to a random number within a certain range, so that the data for each test is different, which can simulate real customer behavior and improve coverage.

[0103] Step 3: Each tenant instance in a test suite will have a corresponding expected result. The expected result is whether the tenant has expanded or reduced its quota. This mainly includes: if the shared quota is sufficient, all tenants will successfully expand their quotas even if their quotas are insufficient; if the shared quota is insufficient, expansion will fail; if all tenants have sufficient quotas, expansion is unnecessary; if the shared quota is insufficient, expansion will fail and trigger an expansion failure alarm; if a typical tenant has ample quota space, it will release its quota into the shared quota by reducing its own quota. Then, the information for each behavior corresponds to the correct expected result, where one or more expected results may be generated.

[0104] First, a volume creation simulation of quota changes can be performed, saving the current used quotas and available shared quotas for all tenants. After automatic quota balancing of the storage is triggered, the storage audit logs and various quota values ​​are checked to compare the expected results with those of the quota expansion and contraction operations, and whether the shared quotas and the quota values ​​corresponding to the tenants are equal to the expectations. The storage has audit logs for both successful and failed expansion and contraction operations. By verifying the audit logs, an automated program determines whether the execution was successful or failed and saves the corresponding execution information to the log. Simultaneously, all combined quota information acquired during the execution process is also saved for test record storage.

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

[0106] As can be seen, applying the verification method provided in this application to the automated testing of multi-tenant related functions of unified storage products allows for the rapid generation of a full test set through automated programs, simulating a large number of different combinations of tenant behaviors. A very simple operation method simulates quota changes triggered by the behaviors of multiple tenant users; and a general operation is abstracted to achieve the same type of operation and the same type of expected result through common function methods, enabling automated testing of a large number of different behavior combinations. Ultimately, it achieves combinations of the same and different behaviors between tenants of the same level and between tenants of different levels, simulating various different behaviors of real tenants. It comprehensively covers different operation combinations when multiple tenant users use quotas, simulating the automatic quota balancing function of the storage system triggered under various combined quota change scenarios. This not only improves testing speed but also increases test coverage.

[0107] Corresponding to the above method embodiments, this application also provides a verification device. The verification device described below and the verification method described above can be referred to each other.

[0108] Please refer to Figure 3 The device includes:

[0109] Test set acquisition module 101 is used to acquire a test set with several test combinations;

[0110] Tenant use case 102 is used to traverse the test combinations to be tested in the test set to obtain several tenant use cases for triggering the quota balancing mechanism.

[0111] The scenario simulation module 103 is used to simulate tenant behavior in a multi-tenant storage system to simulate tenant usage scenarios in different quota inspection cycles.

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

[0113] Verification module 105 is used to verify the compliance of the quota balancing mechanism using the balancing results.

[0114] Using the apparatus provided in this application, a test set with several test combinations can be obtained, containing several tenant usage scenarios that trigger the quota balancing mechanism. Therefore, by traversing the test combinations to be tested in the test set, several tenant usage scenarios are obtained. Then, tenant behavior is simulated in a multi-tenant storage system, thus simulating tenant usage scenarios within different quota inspection cycles. Since tenant usage scenarios trigger the quota balancing mechanism, after simulating tenant behavior and corresponding tenant usage scenarios, automatic quota balancing is executed upon triggering the quota balancing mechanism. Then, the balancing result is obtained, and based on this result, the compliance verification of the quota balancing mechanism can be performed.

[0115] In other words, in this application, different tenant usage scenarios can be automatically simulated to trigger the quota balancing mechanism to perform automatic quota balancing. Then, based on the obtained balancing results, the quota balancing mechanism can be verified to meet the standards.

[0116] In one specific embodiment of this application, the scenario simulation module is specifically used to establish tenants that match the tenant's usage scenario in a multi-tenant storage system; if the tenant has sufficient quota in the tenant's usage scenario, the simulated tenant user creates a volume with a capacity less than the specified share; if the tenant has insufficient quota in the tenant's usage scenario, the simulated tenant user creates a volume with a capacity greater than the specified share.

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

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

[0119] In one specific embodiment of this application, the scenario simulation module is specifically used to simulate tenant users 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 capacity of the newly created volumes is greater than the specified share.

[0120] In one specific embodiment of this application, the scenario simulation module is specifically used to create a volume under the system tenant during the process of simulating a tenant user creating a new volume under the tenant, so as to simulate the change of shared quota.

[0121] In one specific embodiment of this application, the test set acquisition module is specifically used to acquire several tenant instances; each tenant instance corresponds to behavioral information, which includes preconditions, operation steps, and expected results; the behavioral information corresponding to each tenant instance is stored in a dictionary; the tenant instances are combined to obtain candidate combinations, and the dictionary corresponding to the same candidate combination is 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 the test set.

[0122] In one specific embodiment of this application, the test set acquisition module is specifically used to acquire 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 one specific embodiment of this application, the test set acquisition module is specifically used to acquire the tenant configuration of the storage system; and to combine several tenant instances according to the tenant level, quota sufficiency, and expansion permission in the tenant configuration.

[0124] In one specific embodiment of this application, the test set acquisition module is specifically used to acquire the number of tenants to be simulated for verification; and to select one or more types of tenant instances from several types of tenant instances according to the number of tenants to obtain a candidate combination.

[0125] In one specific embodiment of this application, the balancing result acquisition module is specifically used to determine whether the balancing result is consistent with the expected result of the current simulated tenant usage scenario; if yes, it is determined that the quota balancing mechanism meets the standard in the current simulated tenant usage scenario; if no, it is determined that the quota balancing mechanism does not meet the standard in the current simulated tenant usage scenario.

[0126] In one specific embodiment of this application, the scenario simulation module is specifically used to simulate tenant behavior under 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 has not met the standards in the currently simulated tenant usage scenario.

[0127] In one specific embodiment of this 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 time required for the quota balancing mechanism to perform automatic quota balancing, acquire the storage audit log; and determine the balancing result based on the storage audit log.

[0128] For a 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, which will not be repeated here.

[0129] Corresponding to the above method embodiments, this application also provides an electronic device. The electronic device described below and the verification method described above can be referred to each other.

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

[0131] Memory 332 is used to store computer programs;

[0132] The processor 322 is used to implement the steps of the verification method in the above method embodiments 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. The electronic device can vary significantly due to differences in configuration or performance. It may include one or more central processing units (CPUs) (e.g., one or more processors) and a memory 332. The memory 332 stores one or more computer programs 342 or data 344. The memory 332 can be temporary or permanent storage. The program stored in the memory 332 may include one or more modules (not shown in the diagram), each module may include a series of instruction operations on the data processing device. Furthermore, the processor 322 may be configured to communicate with the memory 332 and execute the series of instruction operations stored in the memory 332 on the electronic device 301.

[0134] Electronic device 301 may also 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 the electronic device.

[0136] Corresponding to the above method embodiments, this application also provides a readable storage medium. The readable storage medium described below corresponds to the verification method described above. This application also provides a computer-readable storage medium storing a computer program, wherein the computer program is configured to execute the steps in any of the verification method embodiments described above when run.

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

[0138] Embodiments of this application also provide a computer program product, which includes a computer program that, when executed by a processor, implements the steps in any of the above verification method embodiments.

[0139] Embodiments of this application also provide another computer program product, including a non-volatile computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps in any of the above verification method embodiments.

[0140] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

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

Claims

1. A verification method for a quota balancing mechanism, characterized in that, include: Obtain a test set with several test combinations; Iterate through the test combinations to be tested in the test set to obtain several tenant use cases for triggering the quota balancing mechanism; In a multi-tenant storage system, tenant behavior is simulated to simulate the tenant usage scenarios under different quota inspection cycles. When the quota balancing mechanism is triggered to perform automatic quota balancing, the balancing result is obtained; The quota balancing mechanism is verified to meet the requirements using the balancing results. This includes obtaining a test set with several test combinations, including: Obtain several tenant instances; The tenant instances are combined to obtain candidate combinations; Select a test combination from the candidate combinations and add the test combination to the test set; This includes obtaining several types of tenant instances, including: Obtain the tenant configuration of the storage system; Several tenant instances are obtained by combining the tenant level, quota sufficiency, and expansion permission settings in the tenant configuration. Each tenant instance corresponds to a tenant with a specified tenant level, and the current quota sufficiency and expansion permission settings are configured accordingly. The tenant instances are combined to obtain candidate combinations, including: Obtain the number of tenants required for verification; Based on the number of tenants, one or more types of tenant instances are selected from several types of tenant instances and combined to obtain the candidate combination; Simulate tenant behavior in a multi-tenant storage system to simulate tenant usage scenarios within different quota inspection cycles, including: In a multi-tenant storage system, tenants are created that match the usage scenarios of the tenants. If the tenant has sufficient quota in the tenant's usage scenario, then the volume capacity created by the simulated tenant user under the tenant is less than the specified share; If the tenant's quota is insufficient in the tenant's usage scenario, then the simulated tenant user under the tenant will create a volume with a capacity greater than the specified share; In a multi-tenant storage system, tenants are created that match the user scenarios of the tenants, including: Obtain tenant information from the tenant's usage scenario; The tenant information is used to determine the tenant level and the number of tenants; In the storage system, tenants matching the tenant level and number of tenants are created, and quotas are assigned to the created tenants; Assign quotas to the created tenants, including: The total quota of the storage system is divided into shared quota and tenant quota; The tenant quota is evenly distributed among the created tenants.

2. The method according to claim 1, characterized in that, Simulating a tenant user creating a volume with a capacity greater than a specified share under the aforementioned tenant includes: Simulate tenant users under the tenant, and randomly determine the target volume size within the range of volume size values; Continuously create target volumes according to the target volume size, so that the capacity of the new volumes is greater than the specified share.

3. The method according to claim 1, characterized in that, The process of simulating a tenant user creating a new volume under the aforementioned tenant also includes: Create a volume under the system tenant to simulate changes in shared quotas.

4. The method according to claim 1, characterized in that, Obtain a test set with several test combinations, including: Several tenant instances are obtained; each tenant instance corresponds to behavioral information, which includes preconditions, operation steps, and expected results. Store the behavioral information corresponding to each tenant instance into a dictionary; The tenant instances are combined to obtain candidate combinations, and the dictionary corresponding to the same candidate combination is stored in the dictionary list. Select 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.

5. The method according to claim 1, characterized in that, The compliance verification of the quota balancing mechanism is performed using the balancing results, including: Determine whether the equilibrium result is consistent with the expected result of the current simulated tenant usage scenario; If so, then it is determined that the quota balancing mechanism meets the requirements in the current simulated tenant usage scenario; If not, then it is determined that the quota balancing mechanism does not meet the requirements in the current simulated tenant use case.

6. The method according to any one of claims 1 to 5, characterized in that, When the quota balancing mechanism is triggered to perform automatic quota balancing, the balancing result is obtained, including: In simulating the tenant's usage scenario, the quota balancing mechanism is triggered to perform automatic quota balancing; After waiting for the quota balancing mechanism to execute the automatic quota balancing, obtain the storage audit log; The load balancing result is determined based on the storage audit logs.

7. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor for executing the computer program to implement the steps of the verification method as described in any one of claims 1 to 6.

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

9. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the verification method as described in any one of claims 1 to 6.

Images