A method and system for processing IO current limiting for distributed block storage

Abstract

The present invention discloses a processing method and system for IO current limiting of distributed block storage, comprising the following steps: using an IO flow controller to send a Token application request to an IO flow manager, the IO flow manager synchronously processes the Token application request in a window and sends a reply to the Token application request sent by the IO flow controller; the IO flow manager synchronously processes the Token application request in a window on the IO flow controller using a priority order and sends a reply; caching the reply to the Token application request to a coordination node, calculating the number of Tokens; and executing write IO using the coordination node according to the number of Tokens.

Description

Technical Field

[0001] The present invention relates to the field of data storage, and in particular to a method and system for processing IO current limiting of distributed block storage. Background Art

[0002] In distributed block storage systems, data blocks are typically stored using redundancy methods such as multiple replicas or erasure coding (EC) to improve fault tolerance. When a data block is created, the system determines which nodes to store the replicas or EC shards based on the storage space's load balancing policy. The process of writing a data block involves the system designating a node as the coordinator for the block. The coordinator node then sends write I / O requests to each storage node for the block. After receiving a successful response from each storage node, the coordinator reports the write success to the user.

[0003] The computing, storage, and network resources of each storage node are limited, and current limiting is needed to prevent external IO from occupying a large number of resources. For example, each storage node limits the external write IO speed to no more than 500MiB / s to avoid excessive occupation of the node's network and disk bandwidth, so as to reserve some resources to maintain the normal operation of other internal businesses. Traditional single-machine current limiting solutions generally adopt a leaky bucket or token bucket mode. In the initial state, IO is allowed to pass, but when the IO traffic exceeds the specified threshold, subsequent IO needs to enter the waiting queue or be discarded. In single-machine current limiting, IO load statistics, current limiting decisions, and current limiting actions can all be implemented on the resource provider, that is, the module responsible for disk IO. However, single-machine current limiting solutions are not suitable for distributed scenarios. Summary of the Invention

[0004] The purpose of the present invention is to provide a method and system for processing IO current limiting of distributed block storage, which solves the above-mentioned technical problems pointed out in the prior art.

[0005] The present invention provides a method for processing IO current limiting of distributed block storage, comprising the following steps:

[0006] The IO flow controller sends a token application request to the IO flow manager, and the IO flow manager performs synchronous window processing on the token application request sent by the IO flow controller and sends a reply;

[0007] The IO flow manager processes the Token application request to the IO flow controller synchronization window in priority order and sends a reply;

[0008] The reply to the token application request is cached in the coordination node, and the number of tokens is calculated; and the coordination node is used to perform write IO according to the number of tokens.

[0009] Preferably, the IO flow controller is used to send a token application request to the IO flow manager, and the IO flow manager performs synchronous window processing on the token application request sent by the IO flow controller and sends a reply. The specific operation steps are as follows:

[0010] Set the token request time interval; search the number of IO flow controllers;

[0011] Utilize all IO flow controllers to send Token application requests to the IO flow manager according to the Token application request time interval;

[0012] According to the Token application request time interval, all Token application requests sent by the IO flow controllers are queued in chronological order;

[0013] A synchronization window is preset, and the IO flow manager processes the Token application request to the IO flow controller in the synchronization window according to the set queue of the Token application request;

[0014] After receiving the reply to the Token application request, the IO flow controller resends the Token application request to the IO flow manager and repeats the above steps.

[0015] Preferably, the IO flow manager processes the token application request to the IO flow controller synchronization window in a priority order and sends a reply. The specific operation steps are as follows:

[0016] When the IO flow manager processes a Token application request for the IO flow controller, it calculates the number of available Tokens that can be allocated based on the load status;

[0017] The available token quantity is used to process token application requests in order of priority based on the needs of all IO flow controllers.

[0018] Preferably, the available token quantity is prioritized according to the needs of all IO flow controllers to process token application requests. The specific operation steps are as follows:

[0019] Calculate the ratio of the previously used tokens and the current number of requests waiting for tokens to the total number of available tokens;

[0020] The token application request allocation rate is calculated by taking a weighted average of the proportion of tokens used in the past and the proportion of requests currently waiting for tokens.

[0021] The final number of tokens allocated to each IO flow controller is calculated based on the token application request allocation rate and the number of available tokens.

[0022] Preferably, the reply to the token application request is cached in the coordination node, and the number of tokens is calculated; and the write IO is performed using the coordination node according to the number of tokens. The specific operation steps are as follows:

[0023] All IO flow controllers cache the replies to the Token application requests allocated by the IO flow manager to each coordination node, and count the number of tokens in the replies to the Token application requests in each coordination node;

[0024] The IO flow controller manages IO requests through the number of tokens in the current coordination node, and the IO requests are written according to the storage node;

[0025] A preset token quantity threshold is used to determine whether the number of tokens in each storage node is greater than the token quantity threshold to satisfy the IO request.

[0026] If yes, then use the storage node to perform the write IO of the IO request;

[0027] If not, the IO request is added to the waiting queue. When the number of waiting tokens is sufficient, the storage node executes the write IO request again.

[0028] Preferably, the IO request is added to the waiting queue. When the number of waiting tokens is sufficient, the storage node executes the write IO request again. The specific operation steps are as follows:

[0029] When the IO flow controller receives a response from the IO flow manager for the newly allocated Token application request, it traverses each IO request in the waiting queue and caches it in the coordination node;

[0030] If the number of tokens in the storage node meets the conditions, re-determine whether the number of tokens in the storage node is greater than the token number threshold;

[0031] If so, the coordinating node sends the write IO of the IO request to the relevant storage node, and the storage node executes the write IO;

[0032] If not, continue to execute the above steps to apply for tokens until the number of tokens meets the requirements;

[0033] Identifying abnormal states of storage nodes corresponding to the IO requests in the waiting queue;

[0034] If a storage node is in an abnormal state, a token timeout threshold p is preset for the storage node. When the time interval of the IO request in the waiting queue is greater than the token timeout threshold p, the coordinating node directly executes the write IO request to the relevant storage node, and the storage node executes the write IO.

[0035] Or the storage node is determined to be an abnormal node, and the response to the Token application request continues to be processed in the order of the IO requests in the waiting queue, skipping the storage node of the abnormal node until the execution coordination node sends the write IO request to the relevant storage node, and the storage node executes the write IO.

[0036] Accordingly, the present invention also proposes a distributed block storage IO current limiting processing system, comprising: an application module; an allocation module; a coordination module;

[0037] The application module is used to use the IO flow controller to send a token application request to the IO flow manager, and the IO flow manager performs synchronous window processing on the token application request sent by the IO flow controller and sends a reply;

[0038] The allocation module is used for the IO flow manager to process the Token application request for the IO flow controller synchronization window in priority order and send a reply;

[0039] The coordination module is used to cache the reply to the Token application request to the coordination node, calculate the number of Tokens, and use the coordination node to perform write IO based on the number of Tokens.

[0040] Compared with the prior art, the embodiments of the present invention have at least the following technical advantages:

[0041] An analysis of the IO current limiting processing method for distributed block storage provided by the present invention shows that, in specific applications, a Token application request time interval is set; the number of IO flow controllers is searched to prevent time delays; all IO flow controllers are used to send Token application requests to the IO flow manager according to the Token application request time interval, and the queues are assembled in chronological order to avoid frequent processing of each request, which leads to resource waste; a synchronization window is preset, and the IO flow controllers are synchronized according to the assembled queue of Token application requests to process the Token application requests in the synchronization window to avoid the impact on the allocation of Token application requests due to network delays;

[0042] Furthermore, when the IO flow manager processes token application requests from IO flow controllers, it calculates the number of available tokens that can be allocated based on the load status to avoid system overload; it processes token application requests in a sequential priority order based on the needs of all IO flow controllers to ensure fairness and effectiveness;

[0043] Furthermore, the IO flow manager caches the replies to token application requests allocated to each coordination node. The number of tokens in the replies to token application requests in each coordination node is counted to determine whether there are sufficient resources to initiate IO requests to the storage node, avoiding initiating more IO requests to overloaded nodes. A preset token quantity threshold is used to determine whether the number of tokens in each storage node is greater than the token quantity threshold. This allows us to understand whether the number of tokens in the storage node is sufficient to execute write IO, illustrating the practical application of token quantity control. When the number of tokens on a storage node is insufficient, the IO request cannot be fully satisfied and is placed in a waiting queue, reducing errors or performance bottlenecks.

[0044] Furthermore, the load status of the storage nodes corresponding to the IO requests in the waiting queue is identified to avoid long-term blocking of IO requests. A Token timeout is set. Once this time is exceeded, the coordination node will give up waiting and directly execute the IO request, so that the coordination node can continue to work when some nodes fail, ensuring the high availability of the system; at the same time, the storage node can also be determined to be an abnormal node, and the reply to the Token application request will continue to be processed in the order of the IO requests in the waiting queue. The storage node of the abnormal node will be skipped, and the reply to the Token application request will continue to be processed for the remaining storage nodes corresponding to the IO requests in the waiting queue. The system can respond faster, improve the overall performance of the system, and execute the write IO of the IO request to the relevant storage node, and the storage node will execute the write IO. BRIEF DESCRIPTION OF THE DRAWINGS

[0045] Figure 1 This is an overall flow chart of a method for processing IO current limiting for distributed block storage provided in the first embodiment of the present invention;

[0046] Figure 2 A schematic diagram of a token application request for a method for processing IO current limiting for distributed block storage provided in Example 1 of the present invention;

[0047] Figure 3 A schematic diagram of a storage node waiting to process a token application request and sending a reply in a method for processing IO current limiting of distributed block storage provided in the first embodiment of the present invention;

[0048] Figure 4This is a flowchart of a distributed block storage IO current limiting processing system provided in the first embodiment of the present invention;

[0049] Label: application module 10; allocation module 20; coordination module 30. DETAILED DESCRIPTION

[0050] The technical solution of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the embodiments described are only some embodiments of the present invention, not all embodiments. All other embodiments obtained by ordinary technicians in this field based on the embodiments of the present invention without making any creative efforts shall fall within the scope of protection of the present invention.

[0051] The present invention will be further described in detail below through specific embodiments in conjunction with the accompanying drawings.

[0052] Example 1

[0053] The present invention provides a method for processing IO current limiting of distributed block storage, comprising the following steps:

[0054] S1: Use the IO flow controller to send a token application request to the IO flow manager, and the IO flow manager performs synchronous window processing on the token application request sent by the IO flow controller and sends a reply;

[0055] It should be noted that the IO flow controller sends token application requests to the IO flow manager, and the IO flow manager allocates synchronous windows to the requests, which ensures that multiple requests are processed according to certain rules and order. This can avoid conflicts and resource contention caused by multiple requests competing for resources at the same time.

[0056] The synchronization window mechanism can prevent sudden excessive requests from exhausting or overloading system resources. Each request is processed within a reasonable time window, which helps balance the system load and improve resource utilization.

[0057] S2: The IO flow manager processes the Token application request to the IO flow controller synchronization window in priority order and sends a reply;

[0058] It should be noted that sorting token application requests by priority ensures that critical, urgent, or important requests are processed first; high-priority requests can obtain resources first, preventing important operations from being blocked by low-priority requests. This can optimize system response time and reduce latency, especially when multiple tasks compete for limited resources, ensuring that critical tasks can be completed in a timely manner.

[0059] The priority mechanism can prevent low-priority requests from being left unprocessed for a long time, thus improving the system's service quality, especially when resource competition is fierce;

[0060] S3: Cache the reply to the token application request to the coordination node, calculate the number of tokens, and use the coordination node to perform write IO based on the number of tokens.

[0061] It should be noted that through caching and token quantity management, resource usage is optimized, unnecessary delays are reduced, and the coordinated execution of write IO operations is ensured;

[0062] At the same time, repeated token application requests are made based on the load of the storage node to avoid resource competition and overload caused by instantaneous requests, while improving system throughput and performance. The coordination node executes write IO to ensure consistent execution order across multiple storage nodes, avoiding data confusion or conflicts caused by concurrent writes. The coordination mechanism helps maintain the atomicity and consistency of operations.

[0063] Specifically, in step S1, the IO flow controller sends a token application request to the IO flow manager. The IO flow manager performs synchronous window processing on the token application request sent by the IO flow controller and sends a reply. The specific operations are as follows:

[0064] S11: Setting the Token application request time interval; searching the number of the IO flow controllers;

[0065] Utilize all IO flow controllers to send Token application requests to the IO flow manager according to the Token application request time interval;

[0066] According to the Token application request time interval, all Token application requests sent by the IO flow controllers are queued in chronological order;

[0067] It should be noted that when applying for a token, first, all IO flow controllers are started and immediately send a token application request to the IO flow manager. Due to network delays and processing delays at each node, the token application requests sent by each IO flow controller will not arrive at the IO flow manager at the same time. To cope with this asynchrony, it is necessary to control the interval at which the IO flow manager processes token application requests. Therefore, a token application request interval needs to be set to prevent time delays. After receiving token application requests from different IO flow controllers, the IO flow manager does not respond immediately, but puts the requests into a request queue to avoid frequent processing of each request, which would waste resources.

[0068] S12: Preset the synchronization window, and the IO flow manager processes the Token application request to the IO flow controller in the synchronization window according to the set queue of the Token application request;

[0069] It should be noted that the IO flow manager sets a fixed time interval (i.e., synchronization window) to process the Token application requests in the collection queue. Assume that the synchronization window interval is 100ms. The IO flow manager will process all the Token application requests entering the collection queue at once within every 100ms. This interval helps to collect more Token application requests and fairly distribute the Token application requests. For example, Figure 2 As shown;

[0070] The preset synchronization window needs to be adjusted dynamically (that is, the synchronization window can also be static. Static synchronization windows can simplify the system design and implementation process because there is no need to calculate and adjust the window size or scheduling strategy in real time. Only fixed time intervals or resource allocation rules need to be defined, and the system can schedule resources according to the preset method). If the synchronization window interval is too small, the IO flow manager will frequently process token application requests, which may waste network bandwidth and CPU resources. If the interval is too long, the IO flow controller in the request queue may wait too long, affecting the IO latency of the entire system. In modern data centers, network latency is usually within 10ms, so a synchronization window time of 100ms is usually a suitable choice.

[0071] S13: After receiving the reply to the Token application request, the IO flow controller resends the Token application request to the IO flow manager and repeats the above steps;

[0072] It should be noted that when the IO flow controller receives the token response from the IO flow manager, it will continue to process the IO request according to the number of tokens allocated. Regardless of whether a token is needed, a new token application request will be issued immediately, such as Figure 2 As shown; this process will be repeated continuously to ensure that each operation that requires a token can be processed in a timely manner, and the IO flow manager can also keep track of the token usage of each IO flow controller in a timely manner;

[0073] Specifically, in step S2, the IO flow manager processes the Token application request to the IO flow controller synchronization window in order of priority and sends a reply, and the specific operations are as follows:

[0074] S21: When the IO flow manager processes a Token application request for the IO flow controller, it calculates the number of available Tokens that can be allocated based on the load status;

[0075] The available token quantity is used to process token application requests in order of priority based on the needs of all IO flow controllers.

[0076] It should be noted that the IO flow manager calculates the number of tokens that the current system can provide based on the system load (such as network bandwidth, disk IO, and user-configured load rate limiting policies, etc.) (that is, the calculation of the number of available tokens is to limit the total amount of tokens processed by the system to avoid system overload; the calculation of the number of tokens is based on the rate limit and time window, which ensures that the system processes requests at the predetermined rate); the available tokens (avail_token) are a reflection of the rate limit; suppose: the user sets a fixed rate of 500MiB / s, each IO size is 1MiB; 100ms interval means that within each 100ms time window, the system can provide a maximum of 50 tokens; this number is fixed and represents the upper limit of the number of IO requests that the system can process within that time period; the core task of the IO flow manager is to distribute these 50 tokens to different IO flow controllers according to a certain algorithm to ensure fairness and effectiveness;

[0077] The number of tokens used in the past (prev_used) is the number of tokens used by each I / O flow controller in the past period of time. It is calculated by statistically analyzing historical data and reflects the historical resource demand of an I / O flow controller.

[0078] The number of requests currently waiting for tokens (i.e., cur_requested) is the number of tokens that the current I / O flow controller is waiting to be allocated, which is usually related to the depth of its I / O request queue. If a flow controller currently has a large number of requests waiting, its priority will be higher because it needs to process these requests as quickly as possible to ensure low latency and high efficiency.

[0079] These two factors work together to ensure fair allocation. The past token usage (prev_used) can be used to ensure IO performance continuity. Considering the temporal locality of IO requests issued by users, if more tokens were used previously, there may be more demand for tokens in the future. For example, if prev_used is high but cur_requested is 0 (because the user did not issue an IO request during this time window), the user may issue an IO request next, so a certain amount of token allocation can be made to ensure IO performance continuity. The current request queue depth (i.e., the number of requests currently waiting for tokens) can reflect real-time resource needs, giving priority to the flow controller currently waiting for tokens to ensure real-time performance.

[0080] Specifically, in step S21, the available token quantity is prioritized according to the needs of all IO flow controllers to process token application requests. The specific operation steps are as follows:

[0081] S211: Calculate the proportion of the previously used token amount and the current number of requests waiting for tokens in the available token amount;

[0082] The token application request allocation rate is calculated by taking a weighted average of the proportion of tokens used in the past and the proportion of requests currently waiting for tokens.

[0083] It should be noted that the proportion of tokens used in the past by each I / O flow controller is calculated; the proportion of current requests to the total requests of all flow controllers is calculated; 30% of the weight is given to past token usage and 70% of the weight is given to the current request queue depth to calculate the token application request allocation rate. In this way, both historical and real-time requirements can be taken into account.

[0084] The number of token requests each I / O flow controller deserves is fairly calculated using a weighted average approach. Both historical usage (prev_used) and current demand (cur_requested) are taken into account, ensuring fairness and real-time performance. More importantly, this approach avoids unfair distribution caused by extreme cases (such as excessive historical usage or very few current requests).

[0085] S212: Calculate the final number of tokens allocated to each IO flow controller based on the token application request allocation rate and the number of available tokens (i.e., the number of tokens is the calculated number of token application requests that should be allocated to the IO flow controller, which is different from the meaning of the number of tokens in step S31);

[0086] It should be noted that the number of token application requests ultimately allocated to each IO flow controller is obtained by multiplying the token application request allocation rate by the number of available tokens.

[0087] This calculation allows tokens to be allocated based on the flow controller's historical usage and current request volume. Flows that have used more tokens in the past will receive more resources, while flows that are currently in urgent need of resources can also be met in a timely manner.

[0088] If at a certain point in time, the historical usage and current request counts of all I / O flow controllers' request queues are both 0, indicating no urgent demand, tokens will be evenly distributed across all flows. This equal distribution ensures that each flow can fairly obtain tokens in the idle state, preventing some flows from being starved of resources for extended periods.

[0089] When an IO flow controller suddenly needs a token, the system will immediately provide it with resources without waiting for the next round of allocation. This design ensures the system's responsiveness and efficiency.

[0090] Specifically, in step S3, the reply to the token application request is cached in the coordination node, and the number of tokens is calculated; and the coordination node is used to perform write IO based on the number of tokens. The specific operation steps are as follows:

[0091] S31: All IO flow controllers cache the replies to the Token application requests allocated by the IO flow manager in each coordination node, and count the number of tokens in the replies to the Token application requests in each coordination node (i.e., the number of tokens is the number of replies to the Token application requests of each coordination node counted after the replies to the Token application requests are cached in each coordination node; the meaning of the number of tokens is different from the above step S212);

[0092] The IO flow controller manages IO requests through the number of tokens in the current coordination node, and the IO requests are written according to the storage node;

[0093] It should be noted that all IO flow controllers cache the replies to the allocated token application requests in each coordination node and count the number of tokens in the replies to the token application requests in each coordination node. By caching these token counts, the IO flow controller can determine whether there are sufficient resources to process new requests, avoiding issuing more IO requests to overloaded nodes.

[0094] The coordinator node is responsible for managing the scheduling of IO requests (i.e., storage requests initiated by the coordinator node (or the system component that initiates the request), which are usually read and write operations for data blocks (i.e., write IO. In data storage systems, write IO refers to IO requests for write operations, that is, writing data from the coordinator node to one or more storage nodes; this is a type of IO request specifically for write operations)). It determines which storage nodes to write data to based on the distribution of data block replicas (i.e., each data block has multiple copies stored on different storage nodes to increase data reliability) or EC shards (Erasure Coding, which uses data encoding technology to split data into multiple fragments and store them on different nodes to increase redundancy and fault tolerance).

[0095] Ensure that the coordination node knows exactly which IO request needs to be sent to which storage nodes; then, the coordination node checks whether these target storage nodes have enough tokens. Only when the tokens of all target nodes are available can the target storage node proceed with the IO operation (i.e., the IO request is written according to the storage node);

[0096] S32: Preset a token quantity threshold and determine whether the number of tokens in each storage node is greater than the token quantity threshold to satisfy the IO request.

[0097] If yes, then use the storage node to perform the write IO of the IO request;

[0098] If not, the IO request is added to the waiting queue. When the number of waiting tokens is sufficient, the storage node executes the IO request again.

[0099] It should be noted that, for example: the IO flow controller of the coordination node C1 finds that the storage node S1 has 100 tokens, the storage node S2 has no available tokens, and the storage node S3 has 200 tokens. Although the coordination node C1 wants to write data to the storage nodes S1 and S2, the storage node S2 has no tokens and cannot complete the IO request; therefore, the coordination node C1 can only consume the tokens of the storage node S1 and update its tokens: the storage node S1 has 99 tokens (that is, consuming one token means that the coordination node C1 has obtained the permission to operate the storage node S1, but this does not mean that the write operation has been completed immediately), the storage node S2 has no available tokens, and the request is added to the waiting queue, waiting for the tokens of the storage node S2 to become available before continuing;

[0100] This article explains the practical application of token quantity control. When a node has insufficient tokens, I / O requests cannot be fully satisfied and will be suspended. By recording held and missing tokens, the system can subsequently determine when to resume I / O requests and reduce errors or performance bottlenecks.

[0101] Specifically, in step S32, the IO request is added to the waiting queue. When the number of waiting tokens is sufficient, the storage node executes the write IO request again. The specific operation steps are as follows:

[0102] S321: When the IO flow controller receives a response to the newly allocated Token application request from the IO flow manager, it traverses each IO request in the waiting queue and caches them in the coordination node;

[0103] It should be noted that the waiting queue is traversed to check whether each IO request can satisfy the IO request, and the response to the new token application request is cached in the coordination node;

[0104] This ensures that the system can promptly resume IO requests in the waiting queue after obtaining a token, improving the throughput of IO requests and effectively avoiding resource waste.

[0105] S322: If the number of tokens in the storage node meets the condition, re-determine whether the number of tokens in the storage node is greater than the token number threshold;

[0106] If so, the coordinating node sends the write IO of the IO request to the relevant storage node, and the storage node executes the write IO;

[0107] If not, continue to execute step S311 to apply for tokens until the number of tokens meets the conditions;

[0108] It should be noted that when the number of tokens in the storage node meets the conditions, it is necessary to continue to determine the token quantity threshold. If the conditions are met, the coordination node sends the write IO request to the relevant storage node, and the storage node executes the write IO. If the conditions are not met, it continues to wait in the waiting queue for the token application request to be processed and a reply is sent, such as Figure 3 As shown;

[0109] S323: Identify abnormal status of the storage node corresponding to the IO request in the waiting queue;

[0110] If a storage node is in an abnormal state, a token timeout threshold p is preset for the storage node. When the time interval of the IO request (i.e., the storage node corresponding to the IO request) in the waiting queue is greater than the token timeout threshold p, the coordinating node directly executes the write IO request to the relevant storage node, and the storage node executes the write IO.

[0111] Or the storage node is determined to be an abnormal node, and the response to the token application request continues to be processed in the order of the IO requests in the waiting queue until the execution coordination node sends the write IO request to the relevant storage node, and the storage node executes the write IO;

[0112] It should be noted that in actual operation, storage nodes may not be able to provide sufficient tokens due to network anomalies, node failures, or high load. To avoid long-term blocking of IO requests, the system sets a token timeout. Once this time is exceeded, the coordination node will give up waiting and directly execute the IO request. This timeout mechanism ensures that the system performance will not be degraded or IO requests will be blocked due to the anomaly of a single node. In this way, the coordination node can continue to work when some nodes fail, ensuring high availability of the system.

[0113] Even if the number of tokens of some storage nodes cannot be obtained, the coordination node will still execute according to the replica IO process; replica IO means that there are data copies in multiple storage nodes. Therefore, if the write of a copy fails, the other copies can still ensure the integrity of the data. This step ensures that when some storage nodes are unavailable, data writing can still continue on other nodes, ensuring the fault tolerance and data consistency of the system. The system will automatically eliminate the replicas that cannot be processed to avoid continuing operations when data consistency cannot be guaranteed.

[0114] At the same time, if the system cannot obtain a token application request from a storage node within a short period of time, the coordination node will directly skip the storage node, mark the replica IO as failed (that is, delete the storage node), and try to write the data to other healthy nodes. This optimization can speed up the processing of IO requests, reduce waiting time, and avoid long delays in obtaining token application requests that may cause the entire IO request to be blocked. By directly skipping abnormal nodes, the system can respond faster and improve overall system performance.

[0115] Example 2

[0116] like Figure 4 As shown, the present invention also provides a distributed block storage IO current limiting processing system, including: an application module 10; an allocation module 20; a coordination module 30;

[0117] The application module 10 is used to use the IO flow controller to send a token application request to the IO flow manager, and the IO flow manager performs synchronous window processing on the token application request sent by the IO flow controller and sends a reply;

[0118] The allocation module 20 is used for the IO flow manager to synchronize the window processing Token application request with the IO flow controller in order of priority and send a reply;

[0119] The coordination module 30 is used to cache the reply to the Token application request to the coordination node, calculate the number of Tokens, and use the coordination node to perform write IO according to the number of Tokens.

[0120] In summary, the present invention proposes a method and system for processing IO current limiting for distributed block storage. The method sets a token application request interval, searches for a number of IO flow controllers to prevent time delays, utilizes all IO flow controllers to send token application requests to the IO flow manager according to the token application request interval, and queues them in chronological order to avoid frequent processing of each request, which would waste resources. A synchronization window is preset, and the IO flow controllers are synchronized according to the queue of token application requests to process token application requests, thereby avoiding the impact on token application request allocation due to network delays.

[0121] Furthermore, when the IO flow manager processes token application requests from IO flow controllers, it calculates the number of available tokens that can be allocated based on the load status to avoid system overload; it processes token application requests in a sequential priority order based on the needs of all IO flow controllers to ensure fairness and effectiveness;

[0122] Furthermore, the IO flow manager caches the replies to token application requests after they are allocated to each coordination node. The number of tokens in the replies to token application requests in each coordination node is counted to determine whether there are sufficient resources to initiate IO requests to the storage node, avoiding initiating more IO requests to overloaded nodes. A preset token quantity threshold is used to determine whether the number of tokens in each storage node is greater than the token quantity threshold. This allows us to understand whether the number of tokens in the storage node is sufficient to execute write IO, illustrating the practical application of token quantity control. When the number of tokens on a storage node is insufficient, the IO request cannot be fully satisfied and is placed in a waiting queue, reducing errors or performance bottlenecks.

[0123] Furthermore, the load status of the storage nodes corresponding to the IO requests in the waiting queue is identified to avoid long-term blocking of IO requests. A Token timeout is set. Once this time is exceeded, the coordination node will give up waiting and directly execute the IO request, so that the coordination node can continue to work when some nodes fail, ensuring the high availability of the system; at the same time, the storage node can also be determined to be an abnormal node, and the reply to the Token application request will continue to be processed in the order of the IO requests in the waiting queue. The storage node of the abnormal node will be skipped, and the reply to the Token application request will continue to be processed for the remaining storage nodes corresponding to the IO requests in the waiting queue. The system can respond faster, improve the overall performance of the system, and execute the write IO of the IO request to the relevant storage node, and the storage node will execute the write IO.

[0124] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit them. A person skilled in the art may modify the technical solutions described in the above embodiments, or replace some or all of the technical features therein with equivalents. However, these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. A method for processing IO current limiting of distributed block storage, characterized in that: The following steps are involved: The IO flow controller sends a token application request to the IO flow manager, and the IO flow manager performs synchronous window processing on the token application request sent by the IO flow controller and sends a reply; The IO flow manager processes the Token application request to the IO flow controller synchronization window in priority order and sends a reply; Cache the reply to the token application request to the coordination node and calculate the number of tokens; use the coordination node to perform write IO based on the number of tokens; The IO flow controller sends a token application request to the IO flow manager. The IO flow manager performs synchronous window processing on the token application request sent by the IO flow controller and sends a reply. The specific operation steps are as follows: Set the token request time interval; search the number of IO flow controllers; Utilize all IO flow controllers to send Token application requests to the IO flow manager according to the Token application request time interval; According to the Token application request time interval, all Token application requests sent by the IO flow controllers are queued in chronological order; A synchronization window is preset, and the IO flow manager processes the Token application request to the IO flow controller in the synchronization window according to the set queue of the Token application request; After receiving the reply to the Token application request, the IO flow controller resends the Token application request to the IO flow manager and repeats the above steps; The IO flow manager uses the priority order to synchronize the window processing token application request to the IO flow controller and sends a reply. The specific operation steps are as follows: When the IO flow manager processes a Token application request for the IO flow controller, it calculates the number of available Tokens that can be allocated based on the load status; The available token quantity is prioritized according to the needs of all IO flow controllers to process token application requests in order; The available tokens are processed sequentially and prioritized based on the needs of all IO flow controllers. The specific steps are as follows: Calculate the ratio of the number of tokens used in the past and the number of requests currently waiting for tokens to the total number of available tokens. The token application request allocation rate is calculated by taking a weighted average of the proportion of tokens used in the past and the proportion of requests currently waiting for tokens. The final number of tokens allocated to each IO flow controller is calculated based on the token application request allocation rate and the number of available tokens.

2. The method for processing IO current limiting of distributed block storage according to claim 1 is characterized in that: The response to the token application request is cached in the coordination node, and the number of tokens is calculated. The coordination node is used to perform write IO based on the number of tokens. The specific operation steps are as follows: All IO flow controllers cache the replies to the Token application requests allocated by the IO flow manager to each coordination node, and count the number of tokens in the replies to the Token application requests in each coordination node; The IO flow controller manages IO requests through the number of tokens in the current coordination node, and the IO requests are written according to the storage node; A token quantity threshold is preset to determine whether the number of tokens in the storage node is greater than the token quantity threshold to satisfy the IO request. If yes, then use the storage node to perform the write IO of the IO request; If not, the IO request is added to the waiting queue. When the number of waiting tokens is sufficient, the storage node executes the write IO request again.

3. The method for processing IO current limiting of distributed block storage according to claim 2 is characterized in that: The IO request is added to the waiting queue. When the number of waiting tokens is sufficient, the storage node executes the write IO request again. The specific steps are as follows: When the IO flow controller receives a response from the IO flow manager for the newly allocated Token application request, it traverses each IO request in the waiting queue and caches it in the coordination node; If the number of tokens in the storage node meets the conditions, re-determine whether the number of tokens in the storage node is greater than the token number threshold; If so, the coordinating node sends the write IO of the IO request to the relevant storage node, and the storage node executes the write IO; If not, continue to execute the above steps to apply for tokens until the number of tokens meets the requirements; Identifying abnormal states of storage nodes corresponding to the IO requests in the waiting queue; If a storage node is in an abnormal state, a token timeout threshold p is preset for the storage node. When the time interval of the IO request in the waiting queue is greater than the token timeout threshold p, the coordinating node directly executes the write IO request to the relevant storage node, and the storage node executes the write IO. Or the storage node is determined to be an abnormal node, and the response to the Token application request continues to be processed in the order of the IO requests in the waiting queue, skipping the storage node of the abnormal node until the execution coordination node sends the write IO request to the relevant storage node, and the storage node executes the write IO.

4. A distributed block storage IO current limiting processing system, characterized in that: include: Application module; Allocation module; coordination module; The application module is used to use the IO flow controller to send a token application request to the IO flow manager, and the IO flow manager performs synchronous window processing on the token application request sent by the IO flow controller and sends a reply; The allocation module is used for the IO flow manager to process the Token application request for the IO flow controller synchronization window in priority order and send a reply; The coordination module is used to cache the reply of the Token application request to the coordination node and calculate the number of Tokens; use the coordination node to execute write IO according to the number of Tokens; use the IO flow controller to send a Token application request to the IO flow manager, and the IO flow manager performs synchronization window processing on the Token application request sent by the IO flow controller and sends a reply. The specific operation steps are as follows: set the Token application request time interval; search the number of the IO flow controllers; use all IO flow controllers to send Token application requests to the IO flow manager according to the Token application request time interval; according to the Token application request time interval, the Token application requests sent by all IO flow controllers are collected in a queue in chronological order; preset a synchronization window, and the IO flow manager processes the Token application request of the IO flow controller according to the collection queue of the Token application request; after the IO flow controller receives the reply to the Token application request, it re-queues the IO flow manager. Send a Token application request and repeat the above steps; the IO flow manager uses the priority order to synchronize the window processing Token application request with the IO flow controller and sends a reply. The specific operation steps are as follows: when the IO flow manager processes the Token application request for the IO flow controller, it calculates the number of available tokens that can be allocated according to the load status; the number of available tokens is prioritized in sequence according to the needs of all IO flow controllers; the number of available tokens is prioritized in sequence according to the needs of all IO flow controllers, and the specific operation steps are as follows: calculate the proportion of the amount of tokens used in the past and the number of requests currently waiting for tokens in the number of available tokens; calculate the Token application request allocation rate by taking a weighted average of the proportion of the amount of tokens used in the past and the proportion of the number of requests currently waiting for tokens; calculate the final number of tokens allocated to each IO flow controller based on the Token application request allocation rate and the number of available tokens.

Images