A method for implementing network resource throttling in an object storage system

Abstract

The application discloses a method for realizing network resource flow limiting in an object storage system, and relates to the technical field of object storage systems, and comprises the following steps: configuring global or local flow limiting rules; deploying flow limiting logic programs; reading the flow limiting rules from the cluster when a request arrives; judging whether the set flow limiting rules are activated; if the flow limiting rules are in the activated state, the subsequent steps are continuously executed, otherwise, no flow limiting logic judgment is performed; retrieving token bucket information corresponding to the flow limiting rules from the object storage cluster; updating the available token number of the corresponding operation type according to the flow limiting information and the corresponding token bucket information; each operation consumes a preset number of tokens, and when the tokens are used up, the operation cannot be performed, at this time, the flow limiting condition is reached, the current request is terminated, and the client receives a prompt that the request is terminated due to the reached flow limiting condition. The application can meet the flow limiting requirements of the object storage service.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of object storage system, in particular to a method for realizing network resource flow limiting in an object storage system. BACKGROUND

[0002] In an object storage system, with the continuous increase of users, the number of objects uploaded and downloaded to the object storage system at the same time is increasing, and the load pressure faced by the object storage service is also increasing, which poses a great challenge to the iops and bandwidth capacity that the object storage service can provide. In the process of coping with massive file uploading and downloading, in order to maintain the performance and stable operation of the entire system, relevant restrictions need to be set in terms of bandwidth, requests, etc., to avoid product unavailability caused by a large number of requests in a short time or resource preemption caused by a large number of requests or bandwidth occupation by a specific user in a short time.

[0003] In addition, in addition to coping with such overall load pressure challenges, the object storage system should also consider how to more finely control the bandwidth and iops network resource limitations that can be provided. For example, in an object storage system, there are concepts of user and bucket data entities, and different users may have different network resource capabilities, and the same is true for different buckets. Fine-grained control of the network resource capabilities that a certain data entity can provide can greatly improve the stability and flexibility of the object storage service. SUMMARY

[0004] The present application provides a method for realizing network resource flow limiting in an object storage system to improve the stability and flexibility of the object storage service.

[0005] The technical solution adopted by the method for realizing network resource flow limiting in an object storage system to solve the above technical problems is as follows:

[0006] A method for realizing network resource flow limiting in an object storage system, comprising the following steps:

[0007] S1. Configure global or local flow limiting rules through a command line tool or an administrator interface;

[0008] S2. Deploy a flow limiting logic program on the object storage system server. When a request arrives at the object storage system server, the object storage system server reads the flow limiting rules from the cluster and temporarily stores the read flow limiting rules in the memory;

[0009]

[0009] S3. Determine whether the set flow limiting rules are activated. If the flow limiting rules are in the activated state, continue to execute the subsequent steps, otherwise, do not perform any flow limiting logic judgment;

[0010] S4, retrieve the token bucket information corresponding to the flow limiting rule from the object storage cluster and store in the memory for use;

[0011] S5, update the available token number of the corresponding operation type according to the flow limiting information and the corresponding token bucket information, each operation will consume a preset number of tokens, when the tokens are used up, the operation cannot be performed, at this time, the flow limiting condition is reached;

[0012] S6, if the flow limiting condition is reached, the current request will be terminated, and the client will receive a prompt that the request is terminated due to reaching the flow limiting condition.

[0013] Optionally, when step S1 is performed,

[0014] The configured global flow limiting rule is applicable to three types of data entities: global users, global buckets and anonymous users; the configured global flow limiting rule allows setting the limit of read I / O operation times, write I / O operation times, read bandwidth and write bandwidth for the aforementioned three types of data entities respectively; during the configuration process, the type of the data entity to be targeted needs to be specified: using "globaluser" to represent global users, using "global bucket" to represent global buckets, and using "anon" to represent anonymous users;

[0015] The configured local flow limiting rule is only targeted at a single user, bucket or interface specified in advance, that is, the limitation of network resources only affects the specified data entity, and does not affect the users, buckets or interfaces that are not specified.

[0016] Further optionally, the anonymous user is a user who does not provide a secret key when accessing the object storage, and the operations of such users are separately limited;

[0017] In the object storage system, data entities include users, storage buckets and objects, and there is a hierarchical relationship among the three, wherein: the user is the user of the object storage system, and a user has one or more storage buckets; the storage bucket is a container for storing objects; the object is the basic unit of storage;

[0018] The user-level flow limiting setting affects all operations of the user, the bucket-level flow limiting setting affects all operations on the bucket, and the interface-level flow limiting setting affects all operations of the interface.

[0019] Further optionally, the flow limiting rules are saved in different locations in the object storage cluster according to the different data entities set, wherein:

[0020] The global flow limiting rule is saved in the global variable of the object storage system server;

[0021] In local rate limiting rules, user-level rate limiting rules are stored in the extended attributes corresponding to the user, while bucket-level and interface-level rate limiting rules are stored in the extended attributes corresponding to the bucket.

[0022] Optionally, when performing step S2, when a request arrives at the object storage system server, the object storage system server reads the rate limiting rules from the cluster:

[0023] a) If the rate limiting rule is a global rate limiting rule, it is read from the cluster's global variables;

[0024] b) If the rate limiting rule is a local user rate limiting rule, then read it from the extended attribute corresponding to that user;

[0025] c) If the rate limiting rule belongs to a local bucket or an interface rate limiting rule, then read it from the extended attribute corresponding to that bucket.

[0026] Optionally, when performing step S4, the bucket token information is stored in a map container, where the key is the username, bucket name, or interface name, and the value stores the token bucket information corresponding to the user, bucket, or interface; the map container is implemented based on a hash table, which can efficiently store and look up rate limiting information;

[0027] The token bucket stores the number of four types of tokens: read IOPS, write IOPS, read bandwidth, and write bandwidth. These four types of tokens are independent of each other and do not affect each other.

[0028] Optionally, when executing step S5, if the map container of the object storage cluster has not yet initialized a token bucket for the operation type corresponding to the request, the object storage system will initialize the number of bucket tokens corresponding to the configured rate limiting rule after the first request arrives, where:

[0029] The rate limiting threshold configured in the rate limiting rule determines the initial number of tokens in the bucket. The larger the threshold, the more tokens are initially in the bucket.

[0030] The number of tokens in the bucket represents the amount of network resources that the operation can consume. Before using network resources, you must ensure that there are a preset number of tokens to perform the operation. Each operation will consume a preset number of tokens according to the set rules. If the number of tokens consumed by the operation exceeds the number of tokens available in the bucket, the operation will not be able to continue, and the rate limiting condition will be met.

[0031] Further optional, when performing step S5 and updating the token bucket, tokens need to be filled according to the set number. The longer the time interval, the more tokens are filled, but it cannot exceed the upper limit defined in the rate limiting rules.

[0032] The minimum time interval for token filling is 60ms. If the time difference between two requests is less than 60ms, token filling will not be performed.

[0033] For IOPS, once all tokens in the token bucket are used up, subsequent requests will fail. For bandwidth, once all tokens in the token bucket are used up, any unfinished data uploads or downloads will create a "debt" that must be "repaid" through flow control within a set time interval. During the "repayment" period, no further data uploads or downloads are allowed.

[0034] Further optionally, in the rate limiting logic judgment, if rate limiting rules are configured for global, local users, local buckets, and interfaces at the same time, it is necessary to determine which level of rate limiting rule to execute. The overall priority is: local users > global, local buckets > local users, and interfaces > local buckets.

[0035] Further optionally, when performing an interface operation, the operation will first consume a preset number of user-level IOPS tokens and bucket-level IOPS tokens;

[0036] When the interface-level IOPS rate limiting takes effect, i.e., when the tokens are exhausted, it is necessary to replenish tokens to the subordinate bucket and the user's corresponding IOPS token bucket in order to restore the number of tokens consumed by the previous operation.

[0037] The present invention provides a method for implementing network resource rate limiting in an object storage system, which has the following advantages compared with the prior art:

[0038] 1. This invention can provide rate limiting functions at multiple levels of granularity simultaneously. It is simple and flexible to configure, which can improve the stability and flexibility of object storage services and meet most object storage rate limiting requirements.

[0039] 2. This invention uses the token bucket algorithm when making rate limiting logic judgments, which can efficiently and stably meet the rate limiting requirements of object storage services. Attached Figure Description

[0040] Appendix Figure 1 This is a flowchart of the method according to Embodiment 1 of the present invention;

[0041] Appendix Figure 2 This is the rate limiting logic for different data entities in Embodiment 1 of the present invention. Detailed Implementation

[0042] To make the technical solution, the technical problem solved, and the technical effect of the present invention clearer, the technical solution of the present invention will be clearly and completely described below in conjunction with specific embodiments.

[0043] Example 1:

[0044] Combined with appendixFigure 1 This embodiment proposes a method for implementing network resource rate limiting in an object storage system, which includes the following steps:

[0045] S1. Configure global or local rate limiting rules through command-line tools or the administrator interface, including:

[0046] The configured global rate limiting rules apply to three types of data entities: global users, global buckets, and anonymous users. These rules allow setting limits on the number of read I / O operations, write I / O operations, read bandwidth, and write bandwidth for each of these three data entities. During configuration, the specific data entity type must be explicitly specified: "globaluser" represents a global user, "global bucket" represents a global bucket, and "anon" represents an anonymous user. Anonymous users are those who do not provide a key when accessing object storage; operations for these users require separate rate limiting.

[0047] The configured local rate limiting rules only apply to a single user, bucket, or interface that is specified in advance. In other words, network resource restrictions only affect the data entities that are specified in advance, and will not affect users, buckets, or interfaces that are not specified.

[0048] In an object storage system, data entities include users, buckets, and objects. There is a hierarchical relationship among these three: users are the users of the object storage system, and a user owns one or more buckets; buckets serve as containers for objects and are used to store objects; objects are the basic unit of storage; user-level rate limiting settings affect all operations of that user, bucket-level rate limiting settings affect all operations on that bucket, and interface-level rate limiting settings affect all operations on that interface.

[0049] Rate limiting rules are stored in different locations within the object storage cluster depending on the data entity being limited, including:

[0050] Global rate limiting rules are stored in global variables on the object storage system server.

[0051] In local rate limiting rules, user-level rate limiting rules are stored in the extended attributes corresponding to the user, while bucket-level and interface-level rate limiting rules are stored in the extended attributes corresponding to the bucket.

[0052] S2. Deploy rate limiting logic on the object storage system server. When a request arrives at the object storage system server, the object storage system server reads the rate limiting rules from the cluster and temporarily stores the read rate limiting rules in memory.

[0053] In this step, when a request arrives at the object storage system server, the object storage system server reads the rate limiting rules from the cluster:

[0054] a) If the rate limiting rule is a global rate limiting rule, it is read from the cluster's global variables;

[0055] b) If the rate limiting rule is a local user rate limiting rule, then read it from the extended attribute corresponding to that user;

[0056] c) If the rate limiting rule belongs to a local bucket or an interface rate limiting rule, then read it from the extended attribute corresponding to that bucket.

[0057] S3. Determine whether the set rate limiting rule is activated. If the rate limiting rule is activated, continue to execute the subsequent steps; otherwise, do not perform any rate limiting logic judgment.

[0058] S4. Retrieve the token bucket information corresponding to the rate limiting rule from the object storage cluster and store it in memory for later use.

[0059] In this step, the bucket token information is stored in a map container, where the key is the username, bucket name, or interface name, and the value stores the token bucket information corresponding to the user, bucket, or interface. The map container is implemented based on a hash table, which can efficiently store and look up rate limiting information.

[0060] The token bucket stores the number of four types of tokens: read IOPS, write IOPS, read bandwidth, and write bandwidth. These four types of tokens are independent of each other and do not affect each other.

[0061] S5. Based on the rate limiting information and the corresponding token bucket information, update the number of available tokens for the corresponding operation type. Each operation will consume a preset number of tokens. When the tokens are used up, the operation cannot be performed, and the rate limiting condition is met.

[0062] In this step, if the map container of the object storage cluster has not yet initialized a token bucket for the operation type corresponding to the request, the object storage system will initialize the number of bucket tokens corresponding to the configured rate limiting rule after the first request arrives, where:

[0063] The rate limiting threshold configured in the rate limiting rule determines the initial number of tokens in the bucket. The larger the threshold, the more tokens are initially in the bucket.

[0064] The number of tokens in the bucket represents the amount of network resources that the operation can consume. Before using network resources, you must ensure that there are a preset number of tokens to perform the operation. Each operation will consume a preset number of tokens according to the set rules. If the number of tokens consumed by the operation exceeds the number of tokens available in the bucket, the operation will not be able to continue, and the rate limiting condition will be met.

[0065] When performing this step, the token bucket is updated based on the rate limiting information and the corresponding token bucket information. The tokens need to be filled according to the set number. The longer the time interval, the more tokens are filled, but it cannot exceed the upper limit defined in the rate limiting rules.

[0066] The minimum time interval for token filling is 60ms. If the time difference between two requests is less than 60ms, token filling will not be performed.

[0067] For IOPS, once all tokens in the token bucket are used up, subsequent requests will fail. For bandwidth, once all tokens in the token bucket are used up, any unfinished data uploads or downloads will create a "debt" that must be "repaid" through flow control within a set time interval. During the "repayment" period, no further data uploads or downloads are allowed.

[0068] S6. If the rate limiting condition is met, the current request will be terminated, and the client will receive a notification indicating that the request was terminated because the rate limiting condition was met.

[0069] It should be added that: in conjunction with the appendix Figure 2 In the rate limiting logic judgment, if rate limiting rules are configured at the global, local user, local bucket, and interface levels, it is necessary to determine which level of rate limiting rule to execute. The overall priority is: local user > global, local bucket > local user, and interface > local bucket.

[0070] When performing an interface operation, the operation first consumes a preset number of user-level IOPS tokens and bucket-level IOPS tokens. When the interface-level IOPS rate limiting takes effect and the tokens are exhausted, tokens need to be replenished to the subordinate bucket and the user's corresponding IOPS token bucket to restore the number of tokens consumed by the previous operation.

[0071] In summary, the method for implementing network resource rate limiting in an object storage system using the present invention can simultaneously provide rate limiting functions at multiple levels of granularity. It is simple and flexible to configure, which can improve the stability and flexibility of object storage services and meet most object storage rate limiting requirements. The token bucket algorithm is used when making rate limiting logic judgments, which can efficiently and stably meet the rate limiting requirements of object storage services.

[0072] The above specific examples illustrate the principles and implementation methods of the present invention in detail. These embodiments are merely for the purpose of helping to understand the core technical content of the present invention. Based on the above specific embodiments of the present invention, any improvements and modifications made to the present invention by those skilled in the art without departing from the principles of the present invention should fall within the patent protection scope of the present invention.

Claims

1. A method for implementing network resource rate limiting in an object storage system, characterized in that, Includes the following steps: S1. Configure global or local rate limiting rules through command-line tools or the administrator interface. The configured global rate limiting rules apply to three types of data entities: global users, global buckets, and anonymous users. Anonymous users are users who do not provide a key when accessing object storage; rate limiting is applied separately to the operations of such users. In the object storage system, data entities include users, buckets, and objects, which have a hierarchical relationship. Specifically: users are the users of the object storage system, and a user owns one or more buckets; buckets serve as containers for objects and are used to store objects; objects are the basic unit of storage. S2. Deploy rate limiting logic on the object storage system server; when a request arrives at the object storage system server, the object storage system server reads the rate limiting rules from the cluster and temporarily stores the read rate limiting rules in memory; S3. Determine whether the configured rate limiting rules are activated. If the rate limiting rules are activated, continue to the next steps; otherwise, do not perform any rate limiting logic judgment. In the rate limiting logic judgment, if rate limiting rules are configured for global, local users, local buckets, and interfaces, it is necessary to determine which level of rate limiting rule to execute. The overall priority is: local users > global, local buckets > local users, and interfaces > local buckets. S4. Retrieve the token bucket information corresponding to the rate limiting rule from the object storage cluster and store it in memory for later use; S5. Based on the rate limiting information and the corresponding token bucket information, update the number of available tokens for the corresponding operation type. Each operation will consume a preset number of tokens. When the tokens are used up, the operation cannot be performed, and the rate limiting condition is met. S6. If the rate limiting condition is met, the current request will be terminated, and the client will receive a notification indicating that the request was terminated because the rate limiting condition was met.

2. The method for implementing network resource rate limiting in an object storage system according to claim 1, characterized in that, When performing step S1, The configured global rate limiting rules allow setting limits on the number of read I / O operations, the number of write I / O operations, read bandwidth, and write bandwidth for the aforementioned three types of data entities, respectively. During the configuration process, it is necessary to explicitly specify the data entity type being targeted: use "global user" to represent global users, "global bucket" to represent global buckets, and "anon" to represent anonymous users. The configured local rate limiting rules only apply to a single user, bucket, or interface that is specified in advance. In other words, network resource restrictions only affect the data entities that are specified in advance, and will not affect users, buckets, or interfaces that are not specified.

3. The method for implementing network resource rate limiting in an object storage system according to claim 1, characterized in that, The rate limiting rules are stored in different locations within the object storage cluster depending on the data entity being limited, wherein: Global rate limiting rules are stored in global variables on the object storage system server. In local rate limiting rules, user-level rate limiting rules are stored in the extended attributes corresponding to the user, while bucket-level and interface-level rate limiting rules are stored in the extended attributes corresponding to the bucket.

4. A method for implementing network resource rate limiting in an object storage system according to claim 2, characterized in that, When executing step S2, when a request arrives at the object storage system server, the object storage system server reads the rate limiting rules from the cluster: a) If the rate limiting rule is a global rate limiting rule, it is read from the cluster's global variables; b) If the rate limiting rule is a local user rate limiting rule, then read it from the extended attribute corresponding to that user; c) If the rate limiting rule belongs to a local bucket or an interface rate limiting rule, then read it from the extended attribute corresponding to that bucket.

5. A method for implementing network resource rate limiting in an object storage system according to claim 2, characterized in that, When executing step S4, the bucket token information is stored in a map container, where the key is the username, bucket name, or interface name, and the value stores the token bucket information corresponding to the user, bucket, or interface. The map container is implemented based on a hash table, which can efficiently store and look up rate limiting information. The token bucket stores the number of four types of tokens: read IOPS, write IOPS, read bandwidth, and write bandwidth. These four types of tokens are independent of each other and do not affect each other.

6. A method for implementing network resource rate limiting in an object storage system according to claim 5, characterized in that, When executing step S5, if the map container of the object storage cluster has not yet initialized a token bucket for the operation type corresponding to the request, the object storage system will initialize the number of bucket tokens corresponding to the configured rate limiting rule after the first request arrives, where: The rate limiting threshold configured in the rate limiting rule determines the initial number of tokens in the bucket. The larger the threshold, the more tokens are initially in the bucket. The number of tokens in the bucket represents the amount of network resources that the operation can consume. Before using network resources, you must ensure that there are a preset number of tokens to perform the operation. Each operation will consume a preset number of tokens according to the set rules. If the number of tokens consumed by the operation exceeds the number of tokens available in the bucket, the operation will not be able to continue, and the rate limiting condition will be met.

7. A method for implementing network resource rate limiting in an object storage system according to claim 6, characterized in that, When executing step S5 and updating the token bucket, tokens need to be filled according to the set number. The longer the time interval, the more tokens are filled, but it cannot exceed the upper limit defined in the rate limiting rules. The minimum time interval for token filling is 60ms. If the time difference between two requests is less than 60ms, token filling will not be performed. For IOPS, once all tokens in the token bucket are used up, subsequent requests will fail. For bandwidth, once all tokens in the token bucket are used up, any unfinished data uploads or downloads will create a "liability" that must be "repaid" through flow control within a set time interval. During the "repayment" period, no further data uploads or downloads are allowed.

8. A method for implementing network resource rate limiting in an object storage system according to claim 7, characterized in that, When performing an interface operation, the operation will first consume a preset number of user-level IOPS tokens and bucket-level IOPS tokens; When the interface-level IOPS rate limiting takes effect, i.e., when the tokens are exhausted, it is necessary to replenish tokens to the subordinate bucket and the user's corresponding IOPS token bucket in order to restore the number of tokens consumed by the previous operation.

Images