Storage service quality dynamic control method and device, electronic equipment and storage medium

Abstract

The application discloses a storage service quality dynamic control method and device, electronic equipment and a storage medium, relates to the technical field of storage, and applies for a quota for a service quality server through a service quality client according to the service quality domain identifier of an input / output request, and the service quality server dynamically allocates and broadcasts the quota. When the client detects that a high-priority request is out of limit, the speed is increased according to the service quality score value to guarantee the service, and the resource usage is reported in the next period. The service quality server collects global information accordingly, and realizes load balancing of the storage system by reducing the quota of a low-priority domain. The application realizes dynamic adjustment of the service quality of multiple volumes and hosts by combining the response of the client with the coordination of the server, ensures that critical business can obtain performance guarantee when input / output resources are tight, and improves the adaptability of the system to different business modes and load changes through the feedback mechanism of high-priority input / output.

Description

Technical Field

[0001] This application relates to the field of storage technology, and in particular to methods and apparatus for dynamic control of storage service quality, electronic devices, and storage media. Background Technology

[0002] Against the backdrop of accelerated digital transformation, distributed storage systems have become widely used. These systems comprise a master server, storage servers, and clients, offering high scalability and reliability. Block storage, which can be used like a physical hard drive, is suitable for most general scenarios and its application is increasingly widespread. Since the stability of storage services directly impacts front-end operations, the rational allocation of resources to "volumes," as the core unit of block storage, is becoming increasingly crucial.

[0003] In block storage, volumes host different services, making them prone to resource contention. High-throughput volumes can cause other services to lag. To avoid this problem, related technologies set Quality of Service (QoS) at the volume level. By configuring the maximum QoS of a logical volume, resource limits are set for services, and resources are allocated to ensure the order of basic services.

[0004] However, when there are many volumes, the relevant technologies require each volume to be identified and its services configured before QoS can be set. Furthermore, in virtualization scenarios, a host may be associated with multiple volumes, but host-level QoS hierarchical control is not possible, making it difficult to coordinate and manage host-level resource allocation. Summary of the Invention

[0005] This application provides a method, apparatus, electronic device, and storage medium for dynamic control of storage service quality, relating to the field of storage technology. It realizes dynamic QoS adjustment of multiple volumes and hosts, ensuring that critical services can still obtain sufficient performance guarantees when IO resources are scarce, and reclaiming QoS quotas after some hosts go offline to avoid waste of storage system resources. It provides cross-node host-level QoS control capabilities, and at the same time, it ensures the performance of critical services through a QoS priority customization method and improves the system's adaptability to different business modes and load changes through a high-priority IO feedback mechanism.

[0006] Firstly, this application provides a method for dynamic control of storage service quality, including: The service quality client requests the corresponding service quality quota from the service quality server based on the service quality domain identifier of the input and output requests; The Quality of Service (QoS) server dynamically calculates and allocates QoS quotas based on the current system resource allocation and usage status, and broadcasts the updated quota information to each QoS client. When a service quality client detects that the number of high-priority input / output requests exceeds the preset ratio of its current service quality quota, it increases the token generation rate of that service quality domain to a preset threshold based on the service quality score, and reports the adjusted high-priority resource usage to the service quality server in the next heartbeat cycle. The Quality of Service (QoS) server reduces the quota of a preset number of low-priority QoS domains based on the high-priority resource usage reported by each client, in order to maintain the load balance of the storage system.

[0007] Secondly, this application also provides a storage service quality dynamic control device, comprising: The application module is used by the service quality client to apply for the corresponding service quality quota from the service quality server based on the service quality domain identifier of the input and output requests. The allocation module is used by the service quality server to dynamically calculate and allocate service quality quotas based on the current system resource allocation status and resource usage status, and to send the updated quota information to each service quality client via broadcast. The upgrade module is used to increase the token generation rate of the service quality domain to a preset threshold based on the service quality score when the service quality client detects that the number of high-priority input and output requests exceeds the preset ratio of its current service quality quota, and to report the adjusted high-priority resource usage to the service quality server in the next heartbeat cycle. The downgrade module is used by the Quality of Service (QoS) server to reduce the quota of a preset number of low-priority QoS domains based on the high-priority resource usage reported by each client, in order to maintain the load balance of the storage system.

[0008] Thirdly, this application provides an electronic device, including at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform the storage service quality dynamic control method implementing the first aspect.

[0009] Fourthly, this application provides a non-transitory computer-readable storage medium storing computer instructions, which are used to cause a computer to execute the dynamic control method for storage service quality implementing the first aspect.

[0010] Fifthly, this application provides a computer program product on which a computer program is stored, and when the computer program is executed by a processor, it implements the dynamic control method for storage service quality of the first aspect.

[0011] The storage service quality dynamic control method, apparatus, electronic device, and storage medium provided in this application include: a service quality client applying for a corresponding service quality quota from a service quality server based on the service quality domain identifier to which the input / output request belongs; the service quality server dynamically calculating and allocating service quality quotas based on the current system resource allocation and usage status, and broadcasting the updated quota information to each service quality client; when a service quality client detects that the number of high-priority input / output requests exceeds a preset proportion of its current service quality quota, it increases the token generation rate of that service quality domain to a preset threshold based on the service quality score, and reports the adjusted high-priority resource usage to the service quality server in the next heartbeat cycle; the service quality server, based on the high-priority resource usage reported by each client, reduces the quota of a preset number of low-priority service quality domains to maintain the load balance of the storage system. It enables dynamic QoS adjustment across multiple volumes and hosts, ensuring sufficient performance for critical services even when IO resources are scarce. It also reclaims QoS quotas after some hosts go offline, preventing waste of storage system resources. It provides cross-node host-level QoS control capabilities and ensures the performance of critical services through QoS priority customization. Through the feedback mechanism of high-priority IO, it improves the system's adaptability to different business modes and load changes.

[0012] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of this application, nor is it intended to limit the scope of this application. Other features of this application will become readily apparent from the following description. Attached Figure Description

[0013] To more clearly illustrate the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0014] Figure 1 A flowchart illustrating a dynamic control method for storage service quality provided in this application embodiment; Figure 2 A flowchart illustrating another method for dynamic control of storage service quality provided in this application embodiment; Figure 3 A flowchart illustrating another method for dynamic control of storage service quality provided in this application embodiment; Figure 4 A flowchart illustrating another method for dynamic control of storage service quality provided in this application embodiment; Figure 5A flowchart illustrating another method for dynamic control of storage service quality provided in this application embodiment; Figure 6 This is a schematic diagram of a storage service quality dynamic control device provided in an embodiment of this application. Detailed Implementation

[0015] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the protection scope of this application.

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

[0017] Against the backdrop of accelerated digital transformation, distributed storage systems have become widely used. These systems comprise master servers, storage servers, and clients, offering high scalability and reliability. Block storage, which can be used like physical hard drives, is suitable for most general-purpose scenarios and its application is increasingly widespread. However, the stability of storage services directly impacts front-end services, making the rational allocation of resources for "volumes," as the core unit of block storage, increasingly crucial. In block storage, volumes carry different services, easily leading to resource contention; high-throughput volumes can cause other services to lag. To avoid this problem, related technologies set Quality of Service (QoS) at the volume level, configuring the maximum QoS for logical volumes to set resource limits for services and allocate resources to ensure the order of basic services. However, when there are many volumes, these technologies require identifying the services carried by each volume before setting QoS; furthermore, in virtualization scenarios, a host may be associated with multiple volumes, but host-level QoS hierarchical control is not possible, making it difficult to coordinate and manage host-level resource allocation.

[0018] In this context, a new solution is needed to address the quality of service (QoS) control issues in distributed storage systems. This solution should enable dynamic QoS adjustment across multiple volumes and hosts, ensuring sufficient performance for critical services even under I / O resource constraints, and reclaiming QoS quotas after some hosts go offline to avoid wasting storage resources. It should provide cross-node host-level QoS control capabilities, while ensuring the performance of critical services through customized QoS priorities and improving the system's adaptability to different business models and load changes through a high-priority I / O feedback mechanism.

[0019] To address these issues, this application provides a method, apparatus, electronic device, and storage medium for dynamic control of storage service quality.

[0020] 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.

[0021] Figure 1 A flowchart of a dynamic control method for storage service quality provided in this disclosure embodiment is shown below. Figure 1 As shown, the method includes the following steps: Step 101: The service quality client requests the corresponding service quality quota from the service quality server based on the service quality domain identifier to which the input and output requests belong.

[0022] In some embodiments, the Quality of Service (QoS) Client traverses the locally stored QoS configuration cache, which pre-stores the association information of the configured volume-level QoS domains and host-level QoS domains in the system. By parsing the service association parameters carried in the IO request, it determines whether the IO request belongs to a volume-level QoS domain or a host-level QoS domain. If the IO request does not belong to any volume-level or host-level QoS domain, the QoS Client directly allows the IO request without initiating a quota request. If the IO request clearly belongs to a volume-level or host-level QoS domain, a quota request process is triggered. The QoS Client uses the volume identifier and host identifier of the QoS domain to which the IO request belongs as core parameters and encapsulates them into a "quota request message" according to a preset communication protocol format. The message also carries the client's own identifier and the basic service type of the IO request. The QoS client sends the encapsulated quota request message to the QoS server through a pre-defined communication link, requesting the allocation of QoS quotas that match the QoS domain. If it is the first quota request for the QoS domain, the message will be marked with a "first request" flag so that the QoS server will prioritize the initial quota allocation.

[0023] Step 102: The Quality of Service (QoS) server dynamically calculates and allocates QoS quotas based on the current system resource allocation and usage status, and broadcasts the updated quota information to each QoS client.

[0024] In some embodiments, the Quality of Service (QoS) server collects core information in real time: system resource allocation status, i.e., the quota details currently allocated to each QoS client; and system resource usage status, i.e., real-time resource consumption data reported by each client and the total remaining resources in the storage system. This information is synchronized with the server's local monitoring module via periodic heartbeats from the QoS clients to form a global resource view.

[0025] The Quality of Service (QoS) server calculates quotas based on the global resource view and the alloc_qos allocation algorithm for different scenarios, ensuring the rationality and flexibility of resource allocation.

[0026] The server encapsulates the updated global quota details into a "quota synchronization message." This message includes the latest quota for each volume-level / host-level Quality of Service (QoS) domain, the corresponding client identifier, and the quota's effective date. If any QoS domain has its quota reduced, the "reason for adjustment" will be additionally marked. Global broadcast and client response: The server broadcasts the "quota synchronization message" through the global communication link, ensuring that all QoS clients can receive it. Upon receiving the message, the client immediately updates its local token bucket parameters, and subsequent IO requests are managed according to the new quota, achieving real-time synchronization of global quotas.

[0027] Step 103: When the service quality client detects that the number of high-priority input / output requests exceeds the preset ratio of its current service quality quota, it increases the token generation rate of the service quality domain to a preset threshold based on the service quality score, and reports the adjusted high-priority resource usage to the service quality server in the next heartbeat cycle.

[0028] In some embodiments, the Quality of Service (QoS) client continuously tracks the status of IO request queues belonging to each QoS domain through a local IO queue monitoring module. The QoS client prioritizes IO requests entering the queue according to preset QoS configurations. High-priority IO requests must meet preset business conditions and be bound to the priority configuration of their respective QoS domains. The QoS client periodically counts the number of high-priority IO requests queued under the current QoS domain and calculates the ratio with the currently allocated QoS quota for that domain. When the proportion of queued high-priority IO requests to the current quota exceeds 10%, the "token generation rate increase" condition is triggered.

[0029] When the rate increase condition is triggered, the service quality client calls the local QoS scoring module to calculate a score based on real-time service data of the current service quality domain using a formula. The service quality client then matches the calculated service quality score with the corresponding preset threshold for token generation rate. The service quality client directly modifies the "token generation rate" parameter in the local token bucket, increasing the rate according to the matched threshold to ensure that high-priority I / O can quickly consume tokens and pass through the queue. Simultaneously, it records the timestamp of the rate adjustment, the original rate, and the adjusted rate for subsequent reporting and backtracking.

[0030] The Service Quality (SQ) client integrates core information: the SQ domain identifier, token rate adjustment details, adjusted high-priority resource consumption data, and the overall resource utilization rate of the current SQ domain. This information is then encapsulated into a "High-Priority Resource Usage Reporting Message" according to a preset heartbeat protocol format. At the start of the next heartbeat cycle, the SQ client sends this encapsulated reporting message along with regular heartbeat data to the SQ server. This ensures the SQ server has real-time access to changes in high-priority domain resource usage, providing data support for subsequent reductions in low-priority domain quotas and maintaining system load balancing.

[0031] Step 104: The Quality of Service (QoS) server reduces the quota of a preset number of low-priority QoS domains based on the high-priority resource usage reported by each client, in order to maintain the load balance of the storage system.

[0032] In some embodiments, the Quality of Service (QoS) server receives "high-priority resource usage messages" reported by all clients in batches through a heartbeat interaction channel agreed upon with the clients. It extracts key information from these messages, including but not limited to: the identifier of the QoS domain to which the high-priority I / O belongs, the actual resource consumption after the client increases the token generation rate, changes in the number of high-priority I / O queues, and the current total quota occupancy rate of the high-priority domain. Based on the parsed valid data, the QoS server calculates the "resource gap" caused by the over-occupancy of high-priority domain resources in the current system. The QoS server then selects "low-priority domains" from the globally allocated QoS domains that require quota reduction. Based on the "resource gap" and the "low-priority candidate domain sorting results," the QoS server determines the amount and specific objects of quota reduction and performs targeted adjustments. The QoS server ensures the effectiveness of the adjustments and achieves system load balancing through broadcast synchronization and load monitoring.

[0033] Compared with related technologies, in this embodiment, the service quality client requests the corresponding service quality quota from the service quality server based on the service quality domain identifier to which the input / output request belongs. The service quality server dynamically calculates and allocates service quality quotas based on the current system resource allocation and usage status, and broadcasts the updated quota information to each service quality client. When a service quality client detects that the number of high-priority input / output requests exceeds a preset proportion of its current service quality quota, it increases the token generation rate of that service quality domain to a preset threshold based on the service quality score, and reports the adjusted high-priority resource usage to the service quality server in the next heartbeat cycle. Based on the high-priority resource usage reported by each client, the service quality server reduces the quota of a preset number of low-priority service quality domains to maintain the load balance of the storage system. This embodiment implements dynamic QoS adjustment across multiple volumes and hosts, ensuring that critical services can still obtain sufficient performance guarantees when IO resources are scarce. It also avoids wasting storage system resources by reclaiming QoS quotas after some hosts go offline. It provides cross-node host-level QoS control capabilities and ensures the performance of critical services through QoS priority customization. The feedback mechanism of high-priority IO improves the system's adaptability to different service modes and load changes.

[0034] Furthermore, based on the technical solutions disclosed in 101-104, in order to increase the token generation rate of the service quality domain to a preset threshold according to the service quality score, this embodiment can calculate the service quality score using the following formula: Service Quality Score = α·Normalized I / O operations per second + β·Normalized bandwidth + γ·Reciprocal of normalized latency The weighting coefficients α, β, and γ correspond to input / output operation-sensitive services, bandwidth-sensitive services, and latency-sensitive services, respectively.

[0035] In some embodiments, the real-time monitoring values ​​of IOPS, bandwidth, and latency are normalized: the real-time monitoring values ​​of IOPS, bandwidth, and latency are converted into standardized values ​​in the range [0,1]. Weighting coefficients: α corresponds to IOPS-sensitive services (such as database transaction processing), β corresponds to bandwidth-sensitive services (such as large file transfer), and γ corresponds to latency-sensitive services (such as real-time interactive services). The sum of the weights of the three is 1, and they are preset according to the service type of the service quality domain.

[0036] Figure 2 A flowchart of a dynamic control method for storage service quality proposed in this disclosure is further shown, including the following steps: Step 201: After receiving an input / output request, the QoS client traverses the local configuration cache to determine whether the request belongs to a volume-level or host-level QoS domain.

[0037] In some embodiments, the QoS client locally stores a "QoS configuration cache". This cache is a preset structured data storage unit used to record the core configuration information of the volume-level QoS domain and host-level QoS domain that have taken effect in the system, including: volume-level QoS domain configuration items, host-level QoS domain configuration items, and mapping relationship table.

[0038] The service quality client parses the parameters of the received IO requests and extracts core business parameters such as volume association parameters, host association parameters, and control switch parameters to determine the service quality domain affiliation.

[0039] The Quality of Service (QoS) client performs a line-by-line matching of local QoS configuration caches according to a preset traversal order of "volume-level first, then host-level" or "host-level first, then volume-level" (configurable by system, defaulting to "volume-level priority"). If an IO request simultaneously satisfies both "volume-level QoS domain matching success" and "host-level QoS domain matching success", the QoS client will make a final determination according to the system's preset "domain priority rules": if the system is configured with "host-level QoS domain priority higher than volume-level", then the IO request will be determined to belong to the host-level QoS domain, and subsequent management will be based on host-level quotas; if the system is configured with "volume-level QoS domain priority higher than host-level", then the IO request will be determined to belong to the volume-level QoS domain, and subsequent management will be based on volume-level quotas; if the system is configured with "dual-domain merged management", then the IO request will be associated with both volume-level and host-level domain identifiers, and subsequent quota requests will require both identifiers to be carried, with the QoS server allocating quotas according to the merged logic.

[0040] This disclosure can simultaneously identify the volume domain or host domain to which an IO request belongs by synchronously traversing "volume-level / host-level configuration items", supporting "volume-host dual domain association" scenarios and realizing "volume-host" dual-layer management and control coverage. The determination logic relies entirely on the "QoS configuration cache" pre-stored locally on the service quality client, without needing to initiate a query request to the service quality server. Compared with the traditional solution that needs to obtain domain ownership information through the network, it can reduce at least one cross-node communication, keeping the domain ownership determination latency of IO requests to the millisecond level, and directly improving the IO response speed of front-end services.

[0041] Step 202: If it belongs to the Quality of Service (QoS) domain, encapsulate the volume identifier and host identifier into a quota request message and send it to the QoS server.

[0042] In some embodiments, after determining whether the IO request belongs to the volume-level or host-level QoS domain, the QoS client extracts the core identification information: If the IO request belongs to the volume-level quality of service domain: extract the "volume unique identifier" and "logical unit number" corresponding to the volume, and associate them with the "host identifier" currently connected to the volume; If the IO request belongs to the host-level quality of service domain: extract the "host identifier" that initiated the IO request, and associate it with the "volume identifier" that the host is currently operating on.

[0043] The service quality client encapsulates the core identifier and auxiliary information into a "quota application message" according to the communication protocol format agreed upon with the service quality server.

[0044] The QoS client sends an encapsulated quota request message through a pre-defined dedicated communication link. After the message is sent, the QoS client enters a "waiting state for request result" until it receives the quota allocation result from the QoS server, and then executes the QoS control logic for subsequent IO requests.

[0045] This step ensures that both the volume-level and host-level domains of the IO domain carry both a "volume identifier" and a "host identifier" by associating identifiers. This avoids incorrect allocations caused by missing identifiers on the server, reduces unnecessary processing overhead on the server side, and improves the accuracy of quota allocation.

[0046] Step 203: The Quality of Service (QoS) server dynamically calculates and allocates QoS quotas based on the current system resource allocation and usage status, and broadcasts the updated quota information to each QoS client.

[0047] Step 204: When the service quality client detects that the number of high-priority input / output requests exceeds the preset ratio of its current service quality quota, it increases the token generation rate of the service quality domain to a preset threshold based on the service quality score, and reports the adjusted high-priority resource usage to the service quality server in the next heartbeat cycle.

[0048] Step 205: The Quality of Service (QoS) server reduces the quota of a preset number of low-priority QoS domains based on the high-priority resource usage reported by each client, in order to maintain the load balance of the storage system.

[0049] For a description of steps 203-205, please refer to the description of steps 102-104 in the above embodiment. This embodiment will not repeat these steps in detail.

[0050] Figure 3 A flowchart of a dynamic control method for storage service quality proposed in this disclosure is further shown, including the following steps: Step 301: The service quality client requests the corresponding service quality quota from the service quality server based on the service quality domain identifier to which the input and output requests belong.

[0051] For a description of step 301, please refer to the description of step 101 in the above embodiment. This embodiment will not repeat the description in detail.

[0052] Step 302: If the current remaining service quality resources are greater than the first preset threshold, then all or a first proportion of the remaining resources are allocated to the accessed service quality clients, and the updated quota information is broadcast to each service quality client.

[0053] In some embodiments, the Quality of Service (QoS) server first performs quantitative calculations and threshold determinations of remaining resources based on a "global resource view" (including total system resources and details of allocated resources) to ensure compliance with allocation prerequisites. Remaining resource calculation method: Remaining QoS resources = Total system QoS resources - Total resources allocated to each QoS domain (volume level / host level); Among them, "Quality of Service Resources" specifically refers to the core resources that the storage system can manage—the total pool of input / output operations per second (IOPS) and the total bandwidth pool (unit: MB / s), and the remaining amount of the two types of resources is calculated separately.

[0054] The first preset threshold is 10% of the total system service quality resources. The server needs to perform threshold verification on the remaining IOPS and bandwidth respectively: the subsequent "all or first proportion allocation" logic is triggered only when the remaining amount of both types of resources is greater than 10% of the corresponding total resources, or when the remaining amount of a single resource exceeds the threshold and the resource is the core requirement of the currently accessing client.

[0055] The service quality server selects either "allocate all remaining resources" or "allocate according to the first proportion" based on the business attributes of the accessing client to ensure that resources are adapted to business needs. If the service quality domain to which the accessing client belongs is making its first request, the server will directly allocate 90% of all remaining resources to that client, reserving 10% of the remaining resources to handle sudden requests from other clients; if the total amount of remaining resources is large, it will be allocated according to "90% remaining resources" to avoid a single client occupying too many idle resources.

[0056] If the accessing client is an existing client already connected to the system, and all accessing clients belong to the same service priority, the server will distribute all remaining resources equally among all accessing clients that require additional resources. The distribution formula is as follows: Single client replenishment quota = Total remaining resources ÷ Number of clients requiring replenishment; If the access client's service has a priority distinction, the server allocates the remaining resources according to the "first proportion": First, according to the QoS Score formula: QoS Score = α·Normalized number of input / output operations per second + β·Normalized bandwidth + γ·Reciprocal of normalized latency; Calculate the priority score for each access client; allocate the remaining resources according to the score percentage, i.e.: Single client supplemental quota = total remaining resources × (client priority score ÷ sum of priority scores of all accessing clients); After the Quality of Service (QoS) server completes resource allocation, it needs to encapsulate and distribute information according to the preset broadcast mechanism to ensure that all clients are synchronized with the latest quota.

[0057] Step 302, as a core scenario branch of "Dynamic Allocation of Quotas for Quality of Service Servers," follows the global resource scheduling requirements of Step 102, supporting subsequent client IO management and system load balancing. Through the logic of "active allocation when remaining resources > the first preset threshold (10% of total system resources)," idle resources are precisely allocated to clients with demand for quality of service. "Allocating remaining resources according to the first proportion (business priority weight)" allows IOPS-sensitive businesses (such as database transaction processing, where the α weight in the QoSScore is high) to obtain more remaining IOPS resources through priority proportion, ensuring their transaction processing efficiency. For bandwidth-sensitive businesses, remaining bandwidth resources can be obtained first, avoiding transmission bottlenecks. Compared to the traditional "average allocation" mode, this design increases the resource acquisition amount for critical businesses, ensuring performance guarantees for critical businesses when IO resources are scarce.

[0058] Step 303: If the remaining resources are less than the first preset threshold, check if there are any clients whose allocated quota exceeds the second preset threshold. If so, reclaim the second proportion quota and redistribute it. Otherwise, distribute the remaining resources equally to all clients and broadcast the updated quota information to each quality of service client.

[0059] In some embodiments, the Quality of Service (QoS) server, based on a "global resource view" (including total system resources and details of allocated resources), first performs accurate calculations of remaining resources and threshold comparisons. The remaining IOPS and bandwidth are calculated separately. Remaining QoS resources = Total system QoS resources (total IOPS pool + total bandwidth pool) - Total resources allocated to each QoS domain (volume level / host level); Threshold confirmation criteria: The first preset threshold is 10% of the total system resources. Only when the remaining IOPS is less than 10% of the total system IOPS resources or the remaining bandwidth is less than 10% of the total system bandwidth resources will the subsequent "quota check and recovery" or "remaining resource equal distribution" process officially begin.

[0060] The Quality of Service (QoS) server iterates through all client records with allocated quotas in the "Global Resource View," filters out clients exceeding the quota based on a second preset threshold, and performs quota reclamation and reallocation. The second preset threshold is set to 20% of the total QoS resources corresponding to the system.

[0061] The service quality server iterates through the IOPS and bandwidth quotas allocated to each client and compares them with 20% of the corresponding total resource pool. If any resource quota (IOPS or bandwidth) of a client exceeds the corresponding threshold, it is determined to be an "over-quota client that needs to have its quota reclaimed". If a client has both IOPS and bandwidth quotas exceeding the limit, the resource type with the largest remaining resource gap will be reclaimed first.

[0062] Reclaim 10% of the allocated quota for clients that have exceeded the limit (not 10% of the total system resources). When reclaiming, it must be ensured that the quota of the client after reclamation is not lower than the "minimum guaranteed quota" of its service quality domain.

[0063] The reclaimed quota is preferentially allocated to the client that currently initiated the quota request. If no new client requests a quota, it is allocated to the high-load clients that are already connected according to the "QoS Score priority". If, after traversing all clients, no client with an allocated quota exceeding the second preset threshold is found, the QoS server will allocate the remaining resources to all connected QoS clients according to the "average allocation" principle.

[0064] After the Quality of Service (QoS) server completes the "quota reclamation and redistribution" or "remaining resource equal distribution", it encapsulates the information and sends it out according to the preset broadcast mechanism to ensure that all clients are synchronized with the latest quota.

[0065] This step, serving as a "quota adjustment mechanism when remaining resources are insufficient," complements step 302 (allocation when resources are sufficient) and is a crucial step in ensuring system resource fairness and business continuity. A "minimum guaranteed quota" is introduced during both "quota recovery" and "equal allocation" to ensure uninterrupted basic services and prevent excessive lag in low-priority services; the mechanism of "broadcasting updated quotas" is continued to ensure global quota visibility. Figure 1 This is to avoid local resource conflicts.

[0066] Step 304: When the service quality client detects that the number of high-priority input / output requests exceeds the preset ratio of its current service quality quota, it increases the token generation rate of the service quality domain to a preset threshold based on the service quality score, and reports the adjusted high-priority resource usage to the service quality server in the next heartbeat cycle.

[0067] Step 305: The Quality of Service (QoS) server reduces the quota of a preset number of low-priority QoS domains based on the high-priority resource usage reported by each client, in order to maintain the load balance of the storage system.

[0068] For a description of steps 304-305, please refer to the description of steps 103-104 in the above embodiment. This embodiment will not repeat these steps in detail.

[0069] Figure 4 A flowchart of a dynamic control method for storage service quality proposed in this disclosure is further shown, including the following steps: Step 401: The service quality client requests the corresponding service quality quota from the service quality server based on the service quality domain identifier to which the input and output requests belong.

[0070] Step 402: The Quality of Service (QoS) server dynamically calculates and allocates QoS quotas based on the current system resource allocation and usage status, and broadcasts the updated quota information to each QoS client.

[0071] Step 403: When the service quality client detects that the number of high-priority input / output requests exceeds the preset ratio of its current service quality quota, it increases the token generation rate of the service quality domain to a preset threshold based on the service quality score, and reports the adjusted high-priority resource usage to the service quality server in the next heartbeat cycle.

[0072] Step 404: The Quality of Service (QoS) server reduces the quota of a preset number of low-priority QoS domains based on the high-priority resource usage reported by each client, in order to maintain the load balance of the storage system.

[0073] For a description of steps 401-404, please refer to the description of steps 101-104 in the above embodiment. This embodiment will not repeat them in detail.

[0074] Step 405: The service quality server detects the business activity status of each service quality client. If a service quality client has no input or output requests within a preset timeout period, its service quality quota is released and reallocated to other service quality clients.

[0075] In some embodiments, the client periodically (by default, once every 1 second) sends heartbeat information to the server. The information includes core fields such as "number of IO requests in the current cycle", "total IO processed", and "token bucket consumption". The server extracts these fields, and if "number of IO requests = 0" for multiple consecutive heartbeat cycles, the client is marked as "low activity state".

[0076] The server maintains a local "client IO request log" that records the timestamp, request type (read / write), and associated service quality domain identifier of each client's IO request in real time. If the difference between a client's "latest IO request timestamp" and the current time exceeds a preset threshold, its "low activity state" is further verified to avoid misjudging the client's state due to abnormal heartbeat information and ensure detection accuracy.

[0077] The default timeout is 6 seconds, but it can be configured according to business scenarios (e.g., it can be adjusted to 10 seconds for lightweight businesses and 3 seconds for high-frequency businesses). This timeout starts from the client's "latest IO request completion time", rather than the start of the heartbeat cycle, to ensure that the timing is strongly correlated with actual business activities. If the server detects that the client's "latest IO request timestamp" is greater than or equal to the preset timeout period (e.g., no IO requests within 6 seconds) and / or the client reports "IO request count = 0" for 5 consecutive heartbeat cycles (default 5 seconds), and the "token bucket remaining tokens" is consistently higher than 80% of the allocated quota, the quota will be released.

[0078] After the server re-includes the released quota into the "system allocable resource pool", it will prioritize allocating it to clients that need it, based on the "alloc_qos allocation algorithm" and "dynamic allocation" requirements.

[0079] The service quality server relies on a dual-dimensional approach of "heartbeat interaction + IO request recording" to accurately detect the status of client business activities. It sets a "business activity timeout threshold" and explicitly triggers quota release to convert idle quotas back into allocable resources, thereby improving system resource utilization in idle scenarios. At the same time, quota reclamation reduces the system's reliance on "reserved redundant resources" and lowers the hardware investment cost of the storage system.

[0080] Figure 5 A flowchart of a dynamic control method for storage service quality proposed in this disclosure is further shown, including the following steps: Step 501: The service quality client requests the corresponding service quality quota from the service quality server based on the service quality domain identifier to which the input and output requests belong.

[0081] Step 502: The Quality of Service (QoS) server dynamically calculates and allocates QoS quotas based on the current system resource allocation and usage status, and broadcasts the updated quota information to each QoS client.

[0082] For a description of steps 501-502, please refer to the description of steps 101-102 in the above embodiment. This embodiment will not repeat the details further.

[0083] Step 503: The service quality client periodically sends heartbeat information to the service quality server and reports resource usage; the service quality server updates the timeout time of each service quality client based on the heartbeat information and periodically broadcasts global quota adjustment information.

[0084] In some embodiments, the client encapsulates a "heartbeat reporting message" according to a protocol format agreed upon with the server. The message contains two types of core data: Basic heartbeat fields: client identifier (such as device ID, IP address), heartbeat cycle version, and current business activity status of the client (such as "normal" or "low activity", where low activity means that there are less than 10 IO requests in two consecutive heartbeat cycles). Resource usage details field: Real-time resource consumption data for the relevant service quality domain (volume level / host level) needs to be reported, including: Allocated quota utilization (IOPS utilization = actual IOPS / allocated IOPS, bandwidth utilization = actual bandwidth / allocated bandwidth); High-priority IO queuing status (queue size, average waiting time, echoing the high-priority IO management requirements in step 103). Token bucket status (current remaining tokens, token generation rate, verifying the consistency between local control and server quota).

[0085] The heartbeat sending mechanism defaults to a fixed period of 1 second per heartbeat, but supports configuration based on business scenarios (e.g., adjusting to 3 seconds per heartbeat for lightweight businesses, and maintaining 1 second per heartbeat for high-frequency businesses) to ensure the server obtains the status in real time. It uses a dedicated TCP link for sending; if the heartbeat timeout (default timeout is 2 seconds), it automatically triggers 3 retransmissions. If a retransmission fails, it is marked as "link abnormal," and resource usage data is temporarily stored locally. Once the link is restored, it is reported in batches to avoid data loss. If the client has executed step 103 (high-priority IO rate increase) or step 202 (quota application) within the heartbeat period, an additional "resource adjustment flag" must be added to the heartbeat message to prompt the server to prioritize processing the client's resource data and shorten adjustment response latency.

[0086] After receiving heartbeat messages from each client, the service quality server needs to perform status verification and timeout updates to provide a basis for subsequent quota adjustments and idle resource reclamation. Based on the resource data aggregated from heartbeats, the server periodically generates a global quota adjustment plan and broadcasts it to all clients to ensure that quotas at both ends are consistent. Figure 1 To.

[0087] This application achieves state synchronization between the service quality server and service quality clients through heartbeat reporting, solving the problem of resource allocation lagging behind business needs due to the lack of real-time interaction between clients and servers, and ensuring that the local quotas of all clients are aligned with the global server quota. Figure 1 To.

[0088] Step 504: When the service quality client detects that the number of high-priority input / output requests exceeds the preset ratio of its current service quality quota, it increases the token generation rate of the service quality domain to a preset threshold based on the service quality score, and reports the adjusted high-priority resource usage to the service quality server in the next heartbeat cycle.

[0089] Step 505: The Quality of Service (QoS) server reduces the quota of a preset number of low-priority QoS domains based on the high-priority resource usage reported by each client, in order to maintain the load balance of the storage system.

[0090] For a description of steps 504-505, please refer to the description of steps 103-104 in the above embodiment. This embodiment will not repeat these steps in detail.

[0091] Figure 6 This is a schematic diagram of the structure of a storage service quality dynamic control device provided in an embodiment of the present disclosure, as shown below. Figure 6 As shown, it includes: application module 601, allocation module 602, upward adjustment module 603, and downward adjustment module 604.

[0092] The application module 601 is configured so that the service quality client can apply for the corresponding service quality quota from the service quality server based on the service quality domain identifier to which the input and output requests belong.

[0093] The allocation module 602 is configured to dynamically calculate and allocate service quality quotas based on the current system resource allocation and usage status, and then broadcast the updated quota information to each service quality client.

[0094] The up-adjustment module 603 is configured to, when a service quality client detects that the number of high-priority input / output requests exceeds a preset proportion of its current service quality quota, increase the token generation rate of the service quality domain to a preset threshold based on the service quality score, and report the adjusted high-priority resource usage to the service quality server in the next heartbeat cycle.

[0095] The downgrade module 604 is configured to allow the Quality of Service (QoS) server to reduce the quota of a preset number of low-priority QoS domains based on the high-priority resource usage reported by each client, in order to maintain the load balance of the storage system.

[0096] In some examples of this embodiment, the application module 601 is specifically configured such that after receiving an input / output request, the quality of service client traverses the local configuration cache to determine whether the request belongs to a volume-level or host-level quality of service domain; if it belongs to a quality of service domain, the volume identifier and host identifier are encapsulated into a quota application message and sent to the quality of service server.

[0097] In some examples of this embodiment, the allocation module 602 is specifically configured to allocate all or a first proportion of the remaining service quality resources to the accessed service quality clients if the current remaining service quality resources are greater than a first preset threshold; if the remaining resources are less than the first preset threshold, check whether there are clients whose allocated quota exceeds a second preset threshold; if so, reclaim the second proportion quota and redistribute it; otherwise, allocate the remaining resources equally to all clients.

[0098] It should be noted that other corresponding descriptions of the functional units involved in the dynamic control device for storage service quality provided in this embodiment can be found in [reference needed]. Figure 1 , Figure 2 , Figure 3 , Figure 4 and Figure 5 The corresponding descriptions in [the document] will not be repeated here.

[0099] Based on the above, Figure 1 , Figure 2 , Figure 3 , Figure 4 and Figure 5 The embodiment illustrates a dynamic control method for storage service quality. Correspondingly, this embodiment also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described method. Figure 1 , Figure 2 , Figure 3 , Figure 4 and Figure 5 This illustrates a dynamic control method for storage service quality.

[0100] Based on the above, Figure 1 , Figure 2 , Figure 3 , Figure 4 and Figure 5 The embodiment illustrates a dynamic control method for storage service quality. Correspondingly, this embodiment also provides a computer program product storing a computer program that, when executed by a processor, implements the above-described method. Figure 1 , Figure 2 , Figure 3 , Figure 4 and Figure 5 This illustrates a dynamic control method for storage service quality.

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

[0102] Based on the above, Figure 1 , Figure 2 , Figure 3 , Figure 4 Figure 5 The above describes a dynamic control method for storage service quality, and Figure 6 To achieve the above objectives, the present application also provides an electronic device, such as a personal computer or a server, in the illustrated virtual device embodiment. This device includes a storage medium and a processor; the storage medium stores a computer program; the processor executes the computer program to implement the above-described virtual device. Figure 1 , Figure 2 , Figure 3 , Figure 4 and Figure 5 This illustrates a dynamic control method for storage service quality.

[0103] In some embodiments, the aforementioned physical device may further include a user interface, a network interface, a camera, radio frequency (RF) circuitry, sensors, audio circuitry, a Wi-Fi module, etc. The user interface may include a display screen, an input unit such as a keyboard, etc., and optionally, a USB interface, a card reader interface, etc. In some embodiments, the network interface may include a standard wired interface, a wireless interface (such as a Wi-Fi interface), etc.

[0104] Those skilled in the art will understand that the physical device structure provided in this embodiment does not constitute a limitation on the physical device, and may include more or fewer components, or combine certain components, or have different component arrangements.

[0105] The storage medium may also include an operating system and a network communication module. The operating system is a program that manages the hardware and software resources of the aforementioned physical device, supporting the operation of information processing programs and other software and / or programs. The network communication module is used to enable communication between the various components within the storage medium, as well as communication with other hardware and software in the information processing physical device.

[0106] Through the above description of the embodiments, those skilled in the art can clearly understand that this application can be implemented by means of software plus necessary general-purpose hardware platform, or it can be implemented by hardware.

[0107] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes the element.

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

Claims

1. A method for dynamic control of storage service quality, characterized in that, include: The service quality client requests the corresponding service quality quota from the service quality server based on the service quality domain identifier of the input and output requests; The service quality server dynamically calculates and allocates service quality quotas based on the current system resource allocation and usage status, and broadcasts the updated quota information to each service quality client. When the service quality client detects that the number of high-priority input / output requests exceeds the preset ratio of its current service quality quota, it increases the token generation rate of the service quality domain to a preset threshold based on the service quality score, and reports the adjusted high-priority resource usage to the service quality server in the next heartbeat cycle. The Quality of Service (QoS) server reduces the quota of a preset number of low-priority QoS domains based on the high-priority resource usage reported by each client, in order to maintain the load balance of the storage system.

2. The method for dynamic control of storage service quality according to claim 1, characterized in that, The quality of service domain identifier includes a volume identifier and a host identifier; The service quality client requests a corresponding service quality quota from the service quality server based on the service quality domain identifier to which the input and output requests belong, including: After receiving an input / output request, the QoS client traverses the local configuration cache to determine whether the request belongs to a volume-level or host-level QoS domain. If it belongs to the Quality of Service (QoS) domain, the volume identifier and the host identifier are encapsulated into a quota request message and sent to the QoS server.

3. The method for dynamic control of storage service quality according to claim 1, characterized in that, The dynamic calculation and allocation of service quality quotas includes: If the current remaining service quality resources are greater than the first preset threshold, then all or a first proportion of the remaining resources will be allocated to the access service quality clients. If the remaining resources are less than the first preset threshold, check if there are any clients whose allocated quota exceeds the second preset threshold. If so, reclaim the second proportion quota and redistribute it; otherwise, distribute the remaining resources equally among all clients.

4. The method for dynamic control of storage service quality according to claim 1, characterized in that, The service quality score is calculated using the following formula: Service Quality Score = α·Normalized I / O operations per second + β·Normalized bandwidth + γ·Reciprocal of normalized latency The weighting coefficients α, β, and γ correspond to input / output operation-sensitive services, bandwidth-sensitive services, and latency-sensitive services, respectively.

5. The method for dynamic control of storage service quality according to claim 1, characterized in that, Also includes: The Quality of Service (QoS) server detects the business activity status of each QoS client. If a QoS client has no input or output requests within a preset timeout period, its QoS quota is released and redistributed to other QoS clients.

6. The method for dynamic control of storage service quality according to claim 1, characterized in that, Also includes: The service quality client periodically sends heartbeat information to the service quality server and reports resource usage. The Quality of Service (QoS) server updates the timeout time of each QoS client based on heartbeat information and periodically broadcasts global quota adjustment information.

7. A dynamic control device for storage service quality, characterized in that, include: The application module is used by the service quality client to apply for the corresponding service quality quota from the service quality server based on the service quality domain identifier of the input and output requests. The allocation module is used by the service quality server to dynamically calculate and allocate service quality quotas based on the current system resource allocation status and resource usage status, and to broadcast the updated quota information to each service quality client. The up-adjustment module is used to increase the token generation rate of the service quality domain to a preset threshold according to the service quality score when the service quality client detects that the number of high-priority input and output requests exceeds a preset proportion of its current service quality quota, and to report the adjusted high-priority resource usage to the service quality server in the next heartbeat cycle. The downgrade module is used by the service quality server to reduce the quota of a preset number of low-priority service quality domains based on the high-priority resource usage reported by each client, in order to maintain the load balance of the storage system.

8. An electronic device, characterized in that, include: At least one processor; and a memory communicatively connected to the at least one processor; The memory stores instructions that can be executed by the at least one processor, which are executed by the at least one processor to enable the at least one processor to perform the storage service quality dynamic control method according to any one of claims 1-6.

9. A non-transitory computer-readable storage medium storing computer instructions, characterized in that, The computer instructions are used to cause the computer to execute the dynamic control method for storage service quality according to any one of claims 1-6.

10. A computer program product, characterized in that, It includes a computer program that, when executed by a processor, implements the dynamic control method for storage service quality according to any one of claims 1-6.

Images