Processing method and system for IO current limiting of distributed block storage

Abstract

The invention discloses a processing method and system for IO flow limiting of distributed block storage, and the method comprises the following steps: transmitting a Token application request to an IO flow manager through an IO flow controller, carrying out the synchronous window processing of the Token application request for the Token application request transmitted by the IO flow controller through the IO flow manager, and transmitting a reply; the IO flow manager processes the Token application request for the synchronous window of the IO flow controller according to the priority sequence and sends a reply; the reply of the Token application request is cached to the coordination node, and the number of Token is calculated; and executing IO writing by using the coordination node according to the Token number.

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 a distributed block storage system, data blocks are generally stored in a redundant manner such as multiple copies or erasure codes (EC) to improve data fault tolerance. When a data block is created, the system will determine which nodes each copy or EC shard is stored on based on the load balancing strategy of the storage space. The process of writing a data block is as follows: the system designates a node as the coordinator of the data block, and the coordinating node sends write IO to each storage node of the data block. After waiting for the reply from each storage node that the write is successful, the coordinating node 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 500 MiB / 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, which allows IO to be released in the initial state, 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 supplier, 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 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 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;

[0007] 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;

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

[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, the Token application requests sent by all 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 uses the priority order to synchronize the window processing Token application request to the IO flow controller and sends a reply, and the specific operation steps are as follows:

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

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

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

[0019] Calculate the ratio of the amount of tokens used in the past and the number of requests currently waiting for tokens to the 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 number of tokens finally 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 perform write IO according to the storage node;

[0025] A token quantity threshold is preset to determine whether the token quantity in each storage node is greater than the token quantity threshold to satisfy the IO request;

[0026] If yes, the storage node is used 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 reply 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;

[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 yes, 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 conditions;

[0033] Identifying abnormal status 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 of the IO request to the relevant storage node, and the storage node executes the write IO;

[0035] Or determine that the storage node is an abnormal node, continue to process the reply of the Token application request according to the arrangement order of the IO requests in the waiting queue, skip the storage node of the abnormal node, until the execution coordination node sends the write IO of the 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, including: 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 according to the number of Tokens.

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

[0041] By analyzing the above-mentioned IO current limiting processing method of the distributed block storage provided by the present invention, it can be known that in specific applications, a Token application request time interval is set; the number of IO flow controllers is searched to prevent the problem of time delay; 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 collection queue is performed in chronological order to avoid frequent processing of each request, resulting in resource waste; a synchronization window is preset, and the IO flow controller is synchronized according to the collection queue of the Token application request to process the Token application request in the synchronization window to avoid the impact on the allocation of the Token application request due to network delay;

[0042] Furthermore, 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 based on the load status to avoid system overload; it processes the Token application request in order of priority according to the needs of all IO flow controllers to ensure fairness and effectiveness;

[0043] Furthermore, the replies to the Token application requests allocated by the IO flow manager are cached to each coordination node, and the number of Tokens in the replies to the Token application requests in each coordination node is counted to determine whether there are sufficient resources to initiate IO requests to the storage node, thereby avoiding initiating more IO requests to overloaded nodes; a Token number threshold is preset to determine whether the number of Tokens in each storage node is greater than the Token number threshold, so as to understand whether the number of Tokens in the storage node is sufficient to perform write IO, which illustrates the practical application of Token number control; when the number of Tokens in a storage node is insufficient, the IO request cannot be fully satisfied and waits in the waiting queue, thereby 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 as an abnormal node, and the replies to the Token application requests 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 replies to the Token application requests 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 executes the write IO. BRIEF DESCRIPTION OF THE DRAWINGS

[0045] Figure 1 An overall flow chart of a method for processing IO current limiting of 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 of distributed block storage provided in the first embodiment 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 Embodiment 1 of the present invention;

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

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

[0050] The technical solution of the present invention will be described clearly and completely below in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

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

[0052] Embodiment 1

[0053] like Figure 1 As shown, 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 a token application request to the IO flow manager, and the IO flow manager allocates synchronous windows to the request, which can ensure that multiple requests are processed according to certain rules and order; this can avoid conflicts and resource competition problems caused by multiple requests competing for resources at the same time;

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

[0057] S2: 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;

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

[0059] The priority mechanism can prevent low-priority requests from being unprocessed for a long time and improve 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 according to 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 coordinated execution of write IO operations is ensured;

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

[0063] Specifically, in step S1, 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 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, the Token application requests sent by all 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 a token application request is immediately sent to the IO flow manager. Due to network delays and processing delays of each node, the token application requests sent by each IO flow controller will not arrive at the IO flow manager at the same time. In order to deal with this asynchrony, it is necessary to control the interval of the IO flow manager processing the token application request, so a token application request time interval needs to be set to prevent the problem of time delay. After receiving the token application request from different IO flow controllers, the IO flow manager will not respond immediately, but put the request into a request queue to avoid frequent processing of each request, resulting in resource waste.

[0068] S12: Preset a 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 is set with a fixed time interval (i.e., synchronization window) to process the Token application requests in the collection queue. Assume that the synchronization window time interval is 100ms, and the IO flow manager will process all the Token application requests entering the collection queue at once 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 window 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. You only need to define a fixed time interval or resource allocation rule, and the system can schedule resources in a preset manner.) If the synchronization window time interval is too small, the IO flow manager will frequently process token application requests, which may waste network bandwidth and CPU resources; if the time interval is too long, it may cause the IO flow controller in the request queue to wait too long, affecting the IO delay of the entire system; in modern data centers, network delays are 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 a token reply 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 stream manager can also keep track of the token usage of each IO stream controller in a timely manner;

[0073] Specifically, in step S2, 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, and the specific operations are as follows:

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

[0075] The available token quantity is used to process token application requests in order of priority according to 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 speed limit strategy, 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 speed limit and time window, which ensures that the system processes requests at a predetermined rate); the available token (avail_token) is the embodiment of the speed limit; assume that: the user sets a fixed rate of 500MiB / s, and the size of each IO is 1MiB; the 100ms interval means that within each 100ms time window, the system can provide a maximum of 50 tokens; this number is fixed, indicating the upper limit of the number of IO requests that the system can process within this time period; the core task of the IO flow manager is to allocate 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 (i.e., prev_used) is the number of tokens that each IO flow controller has used in the past period of time. It is calculated by statistical historical data and reflects the historical demand for resources of a certain IO flow controller.

[0078] The number of requests currently waiting for tokens (i.e., cur_requested) is the number of tokens that the current IO flow controller is waiting to be allocated, which is usually related to the depth of its IO 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] The two work together to ensure the fairness of allocation. The past usage of tokens (prev_used) can be used to ensure the continuity of IO performance. Considering the time locality of users issuing IO requests, more tokens were used before, and the demand for tokens may be greater in the future. For example, prev_used is high, but cur_requested is 0 (because the user did not issue an IO request in this time window). However, the user may issue an IO request next, so a certain amount of token allocation can be made for it to ensure the continuity of IO performance. The depth of the current request queue (that is, the number of requests currently waiting for tokens) can reflect the real-time resource demand, 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 used to process token application requests in order of priority according to the needs of all IO flow controllers. The specific operation steps are as follows:

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

[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 IO flow controller is calculated; the proportion of current requests of each flow controller 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 needs can be taken into account;

[0084] The number of token application requests that each IO flow controller deserves is fairly calculated by weighted average. Both historical usage (prev_used) and current demand (cur_requested) are taken into account to ensure fairness and real-time performance. More importantly, this method avoids unfair distribution caused by extreme situations in one aspect (such as too much historical usage or very few current requests).

[0085] S212: Calculate the number of tokens finally allocated to each IO flow controller according to the Token application request allocation rate and the number of available tokens (that is, the number of tokens is the 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 used more tokens in the past will get more resources, and flows that are in urgent need of resources can also be satisfied in a timely manner.

[0088] If at a certain point in time, the historical usage and current request volume of the request queues of all IO flow controllers are both 0, indicating that there is no particularly urgent demand at the moment, then the token will be evenly distributed to all flows; this equal distribution method ensures that in the idle state, each flow can obtain the token fairly, and some flows will not be deprived of resources for a long time;

[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; the write IO is performed using the coordination node according to 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 to each coordination node, and count the number of Tokens in the replies to the Token application requests in each coordination node (that is, 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 to each coordination node; the meaning of the number of Tokens is different from that of 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 perform write IO according to the storage node;

[0093] It should be noted that all IO flow controllers cache the replies to the allocated Token application requests to 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 numbers, the IO flow controller can determine whether there are enough resources to process new requests, avoiding initiating more IO requests to overloaded nodes.

[0094] The coordination node is responsible for managing the scheduling of IO requests (i.e., storage requests initiated by the coordination node (or the system component that initiates the request), which are usually read and write operations for data blocks (i.e., write IO. In the data storage system, write IO refers to the IO request for write operations, that is, writing data from the coordination node to one or more storage nodes; this is a type of IO request, specifically for write operations)). It determines which storage nodes the data needs to be written to based on the distribution of data block replicas (i.e., each data block will have multiple replicas stored on different storage nodes to increase data reliability) or EC shards (Erasure Coding, which uses data encoding technology to divide 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, the target storage node can continue to perform the IO operation (that is, the IO request is written according to the storage node);

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

[0097] If yes, the storage node is used 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 number of tokens of the storage node S1 and update its number of tokens: the number of tokens for the storage node S1 is 99 (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 number of tokens for the storage node S2 is no available, and the request is added to the waiting queue, waiting for the number of tokens for the storage node S2 to be available before continuing;

[0100] The practical application of token quantity control is explained. When a node has insufficient tokens, IO requests cannot be fully satisfied and will be suspended. By recording the held and missing tokens, the system can determine when to resume IO requests later 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 reply 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 the Token, improves the throughput of IO requests, and effectively avoids 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 yes, 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 a token 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 number threshold. If the conditions are met, the coordination node sends the write IO of the 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 to process the token application request and send a reply, such as Figure 3 As shown;

[0109] S323: Identify abnormal status of storage nodes corresponding to the IO requests 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 of the 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 reply 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 of the 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 enough tokens due to network anomalies, node failures, or high loads. In order 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 can ensure that the system will not cause the performance of the entire system to degrade or IO requests to 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 the 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, so if the writing of a copy fails, 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 copies 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 in 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 cause the entire IO request to be blocked; by directly skipping abnormal nodes, the system can respond faster and improve the overall performance of the system;

[0115] Embodiment 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 perform write IO using the coordination node according to the number of Tokens.

[0120] In summary, the present invention proposes a method and system for processing IO current limiting of distributed block storage, by setting the Token application request time interval; searching the number of IO flow controllers to prevent the problem of time delay; using all IO flow controllers to send Token application requests to the IO flow manager according to the Token application request time interval, and assembling queues in chronological order to avoid frequent processing of each request, resulting in resource waste; presetting a synchronization window, synchronizing the window to process the Token application request of the IO flow controller according to the collection queue of the Token application request, avoiding the impact on the allocation of the Token application request due to network delay;

[0121] Furthermore, 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 based on the load status to avoid system overload; it processes the Token application request in order of priority according to the needs of all IO flow controllers to ensure fairness and effectiveness;

[0122] Furthermore, the IO flow manager caches the replies to the token application requests allocated to each coordination node, counts the number of tokens in the replies to the token application requests in each coordination node, and determines whether there are enough resources to initiate IO requests to the storage node, thereby avoiding initiating more IO requests to overloaded nodes; presets a token number threshold to determine whether the number of tokens in each storage node is greater than the token number threshold, so as to understand whether the number of tokens in the storage node is sufficient to perform write IO, illustrating the practical application of token number control; when the number of tokens in a storage node is insufficient, the IO request cannot be fully satisfied and waits in the waiting queue, thereby 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 as an abnormal node, and the replies to the Token application requests 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 replies to the Token application requests 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 executes 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 it. A person skilled in the art may modify the technical solutions described in the above embodiments, or replace part 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 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 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 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.

2. According to the method for processing IO current limiting of distributed block storage according to claim 1, it is characterized in that: The IO flow controller is used to send 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, the Token application requests sent by all 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.

3. According to the method for processing IO current limiting of distributed block storage according to claim 2, it is characterized in that: 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, the IO flow manager calculates the number of available Tokens that can be allocated according to the load status; The available token quantity is used to process token application requests in order of priority according to the needs of all IO flow controllers.

4. According to the method for processing IO current limiting of distributed block storage according to claim 3, it is characterized in that: The available token quantity is used to process token application requests in order of priority according to the needs of all IO flow controllers. The specific operation steps are as follows: Calculate the ratio of the amount of tokens used in the past and the number of requests currently waiting for tokens to the 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 number of tokens finally allocated to each IO flow controller is calculated based on the token application request allocation rate and the number of available tokens.

5. According to the method for processing IO current limiting of distributed block storage according to claim 4, it is characterized in that: The reply to the token application request is cached in the coordination node, and the number of tokens is calculated; the write IO is performed using the coordination node according to 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 perform write IO according to the storage node; A token quantity threshold is preset to determine whether the token quantity in each storage node is greater than the token quantity threshold to satisfy the IO request; If yes, the storage node is used 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.

6. According to the method for processing IO current limiting of distributed block storage according to claim 5, it 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 reply 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; 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 yes, 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 conditions; Identifying abnormal status 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 of the IO request to the relevant storage node, and the storage node executes the write IO; Or determine that the storage node is an abnormal node, continue to process the reply of the Token application request according to the arrangement order of the IO requests in the waiting queue, skip the storage node of the abnormal node, until the execution coordination node sends the write IO of the IO request to the relevant storage node, and the storage node executes the write IO.

7. 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 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.

Images