MClock metadata flow control method of file system

Abstract

The invention provides an mClock metadata flow control method of a file system, which belongs to the technical field of cloud computing storage and comprises the following steps of: declaring an mClock structure, defining limit logic for using the mClock, and adding flow control logic to metadata operation. According to the method, the upper limit of the IOPS of the metadata of the cloud file system of the single client is limited, and on the premise of maintaining a multi-thread scene, by limiting the IOPS of the metadata operation of the single client, the occupation of storage resources of each client is effectively controlled, and resource waste caused by scrambling is avoided, so that the user experience is improved, and the user experience is improved. Meanwhile, the load pressure of the cluster is controlled to a certain extent, and the problem triggering probability and the equipment loss rate are reduced.

Description

Technical Field

[0001] The present invention relates to the technical field of cloud computing storage, and in particular to an mClock metadata flow control method for a file system. Background Art

[0002] In current usage scenarios of cloud storage, it often involves multiple clients using the server resources of the same storage cluster. Since the server resources of the storage cluster are limited, flow control is usually adopted to limit the usage pressure of a single client, such as the IOPS of operations, among which metadata operations are relatively frequent and complex. This way can maintain that the resource utilization rate of the storage cluster will not be too high, thus avoiding resource waste caused by contention.

[0003] (1) When the usage pressure of a certain client is relatively high, it will have a negative impact on the usage of other clients. The resulting resource contention and resource occupation will affect the usage performance and user experience of the clients.

[0004] (2) Being under a high pressure load for a long time will shorten the service life of the server and disks, thus increasing the probability of problems occurring in the storage cluster in the later stage. Summary of the Invention

[0005] To solve the above technical problems, the present invention provides an mClock metadata flow control method for a file system.

[0006] The technical solution of the present invention is as follows:

[0007] An mClock metadata flow control method for a file system, in which the client uses the mClock algorithm to perform flow control restrictions on file system metadata operations. The specific aspect of the restriction is the IOPS of metadata operations on files or directories; in the metadata operation scenario, the metadata operation is verified by the mClock algorithm to determine whether it can be executed. If the verification is successful, the subsequent metadata execution logic is continued; otherwise, the request lock is released and waiting for the next round of verification until the verification is successful.

[0008] The mClock algorithm logic is as follows:

[0009] First, for each request, corresponding tags and an ordered queue are generated according to the reserved values, upper limit values, and weights of different operation types defined. Among them, the tag is essentially the calculation of a timestamp, and the ordered queue is to sort the requests corresponding to the tags.

[0010] After processing the request, it includes two stages, namely the Constraint-based stage and the Weight-based stage; in the Constraint-based stage, requests with reservation tags less than the current time are executed from the reserved queue, while in the Weight-based stage, the weight queue is traversed and requests with upper limit tags less than the current time are executed.

[0011] Furthermore,

[0012] Specifically, it includes:

[0013] Declare the mClock structure, that is, define the client's mClock-related configurations and data structures; including declaring mClock-related parameters, declaring the mClock queue, and calculating request tags.

[0014] Declare the mClock flow control verification logic, that is, implement the modified mClock flow control logic; including defining the Constraint-based stage and defining the Weight-based stage.

[0015] Add flow control logic to metadata operations, that is, determine whether to continue executing subsequent metadata logic according to the verification result of the mClock flow control logic; including successful flow control verification logic and failed flow control verification logic.

[0016] Among them,

[0017] The declared mClock-related parameters, that is, declare the corresponding reservation values, upper limit values, and weights according to the metadata type, and the specific parameter meanings are as follows:

[0018] Reservation value: The minimum limit of this type of operation, that is, the minimum IOPS of this metadata operation for a single client, and the value range is greater than 0.

[0019] Upper limit value: The maximum limit of this type of operation, that is, the maximum IOPS of this metadata operation for a single client, and the value range is greater than 0; the expected effect is that in the single-client scenario, the metadata IOPS is maintained between the reservation value and the upper limit value.

[0020] Weight: The proportion of this type of operation among all operations, that is, the proportion for a single client, and the value range is greater than 0; it is stipulated that the proportions of various metadata operations are equal. For those with a read demand proportion exceeding 70%, adjust the proportion of their view-type metadata operations to 9:1. When the read demand proportion exceeds 70%, the common operations in some scenarios are reading and querying files, and the usage of creating, modifying, and deleting files is relatively small. For example, scenarios such as web resource acquisition, database query, and training AI using a large number of small files.

[0021] The calculation request tag is calculated according to the parameters of the previous step when the metadata request is executed on the client side.

[0022] The declared mClock queues mean that reserved queues, upper limit queues, and weight queues are declared in the client, and the reserved tags, upper limit tags, and weight tags of each request are generated into tags. The structure of the number of requests, that is, the request tag, is then added to the corresponding reserved queue, upper limit queue, and weight queue according to the tag size of the request tag.

[0023] Specifically,

[0024] Add reserved values, upper limit values, and weights to the configuration of the libcephfs client. The default reserved value for metadata operations is 1, the upper limit value is 1000, and the weight is 1, which means restricting the metadata operation IOPS within 1000.

[0025] In the libcephfs client, calculate the reserved tag, upper limit tag, and weight tag before each metadata operation is executed.

[0026] In the libcephfs client, define reserved queues, upper limit queues, and weight queues. The queues initially contain the 0th request tag, and the tag values are all 0.

[0027] The defined Constraint-based phase means checking whether the reserved tag corresponding to the current request in the reserved queue is less than or equal to the current time. If the condition is met, the verification is successful and the flow control verification logic ends; otherwise, the Weight-based phase is executed.

[0028] The defined Weight-based phase means checking whether the upper limit tag corresponding to the current request in the upper limit queue is less than or equal to the current time. If the condition is met, the verification is successful; otherwise, the verification fails. In both cases, the flow control verification logic ends.

[0029] Specifically,

[0030] In the libcephfs client, find the corresponding reserved tag according to the number of requests of the request tag. If the reserved tag is less than or equal to the current time, return verification success and recalculate the reserved tags of the request tags in the subsequent reserved queue.

[0031] In the libcephfs client, find the corresponding upper limit tag according to the number of requests of the request tag. If the upper limit tag is less than or equal to the current time, return verification success.

[0032] The flow control verification success logic means that after the flow control verification is successful, the reservation tag, upper limit tag, and weight tag of the previous request corresponding to this request are removed from the reservation queue, upper limit queue, and weight queue. Then, the subsequent metadata execution logic is executed.

[0033] The flow control verification failure handling means that after the flow control verification fails, wait for the time interval corresponding to the upper limit value, and execute the flow control verification again until the verification is successful.

[0034] Specifically,

[0035] When the flow control verification is successful, the request tag is removed from the reservation queue, upper limit queue, and weight queue of the libcephfs client, and the subsequent upper limit tag and weight tag are recalculated.

[0036] When the flow control verification fails, re-verify after waiting for the time interval corresponding to the upper limit value in the libcephfs client until the verification is successful; release the libcephfs exclusive lock during the waiting period to allow other requests to execute, and obtain the libcephfs exclusive lock before verification to restrict the serialization of the flow control verification.

[0037] The beneficial effects of the present invention are

[0038] (1) By restricting the maximum resources that can be used by a single client, the situation where the use of other clients is affected due to excessive use pressure of a single client is reduced.

[0039] (2) At the same time, since an upper limit is set for the resources that can be used by a single client, the pressure on the storage cluster is gradually controllable, thereby extending the service life of the storage cluster to a certain extent and reducing the probability of problems that may occur in the later stage. BRIEF DESCRIPTION OF THE DRAWINGS

[0040] Figure 1 is a schematic diagram of the working process of the present invention;

[0041] Figure 2 is a schematic diagram of the tag calculation formula. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0042] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are some, but not all, of the embodiments of the present invention. All other embodiments obtained by those of ordinary skill in the art based on the embodiments of the present invention without creative efforts shall fall within the protection scope of the present invention.

[0043] Flow control, namely traffic control, is a solution to limit the communication traffic between the client and the server. Broadly speaking, it can be understood as restricting the request frequency and request size of the client. The use of flow control realizes the control and management of the traffic transmitted in the network, thereby reducing problems such as network congestion caused by network fluctuations. At the same time, while reducing the network pressure, it also enables the server pressure to be initially controlled, thereby extending the working life of the server.

[0044] The present invention provides an mClock data flow control method for a file system. The flow control algorithm used in this method is mClock, which has been used in the osd currently. The specific algorithm logic is as follows: First, for each request, corresponding tags and an ordered queue are generated according to the reserved values, upper limit values, and weights of different operation types defined. Among them, the tag is essentially the calculation of a timestamp, and the ordered queue is to sort the requests corresponding to the tags. Then, when processing requests, it includes two stages, namely the Constraint-based stage and the Weight-based stage. In the Constraint-based stage, requests with reserved tags less than the current time are executed from the reserved queue, and in the Weight-based stage, the weight queue is traversed to execute requests with upper limit tags less than the current time.

[0045] The present invention performs flow control restrictions on file system metadata operations through the mClock algorithm on the client side. The specific restriction aspect is the IOPS of metadata operations on files or directories. In the metadata operation scenario, the metadata operation needs to be verified by the mClock algorithm to determine whether it can be executed. If the verification is successful, the subsequent metadata execution logic is continued; otherwise, the request lock is released and waiting for the next round of verification until the verification is successful. Taking the cephfs file system as an example, the specific implementation steps are as follows: including

[0046] Declare the mClock structure

[0047] Declare the mClock flow control verification logic

[0048] Add flow control logic to metadata operations

[0049] 1.1 The so-called declaration of the mClock structure, that is, defining the mClock-related configurations and data structures of the client, specifically including

[0050] Declare mClock-related parameters

[0051] Declare the mClock queue

[0052] Calculate the request tag

[0053] 1.1.1 The mClock-related parameters in the metadata operation scenario, that is, the corresponding reserved values, upper limit values, and weights are declared according to the metadata type. The specific meanings of the parameters are as follows:

[0054] Reserved value: The minimum limit of this type of operation, that is, the minimum value of the metadata operation IOPS of a single client, and the value range is greater than 0

[0055] Upper limit value: The maximum limit of this type of operation, that is, the maximum value of the metadata operation IOPS of a single client, and the value range is greater than 0. The expected effect is that in the single-client scenario, the metadata IOPS is maintained between the reserved value and the upper limit value

[0056] Weight: The proportion of this type of operation in all operations, that is, the proportion of a single client, and the value range is greater than 0. Since the requirements for various metadata operations are different in different business scenarios, the weight will also be adjusted accordingly. In this method, it is tentatively assumed that the proportions of various metadata operations are equal. For some operations with high read requirements, such as web browsing and database queries, the proportion of view-type metadata operations can be adjusted to 9:1.

[0057] Specifically, add the reserved value, upper limit value, and weight in the configuration of the libcephfs client. The default reserved value for metadata operations is 1, the upper limit value is 1000, and the weight is 1, that is, the metadata operation IOPS is limited within 1000.

[0058] 1.1.2 The calculation request tag, that is, calculate the tag when the client executes the metadata request according to the above parameters. The specific calculation method of the tag is as Figure 1 shown, where r, w, l are the reserved value, upper limit value, and weight parameters set above, t is the current request time, and r is the number of the request. For the tag calculation formula of a request, the tag of the 0th request is defaulted to 0.

[0059] Specifically, in the libcephfs client, calculate the reserved tag, upper limit tag, and weight tag before each metadata operation is executed.

[0060] For example, if the reserved tag of the previous request is 10 and the current time is 11, then the reserved tag of this request is the maximum value of 10.001 and 11, that is, 11.

[0061] 1.1.3 Declare the mClock queue, that is, declare the reserved queue, upper limit queue, and weight queue in the client, and generate the tag, the structure of the number of requests, that is, the request tag, for the reserved tag, upper limit tag, and weight tag of each request, and then add them to the corresponding reserved queue, upper limit queue, and weight queue according to the size of the request tag.

[0062] Specifically, in the libcephfs client, a reservation queue, an upper limit queue, and a weight queue are defined. The queue initially contains the 0th request tag, and the tag values are all 0.

[0063] The mClock flow control verification logic described in 1.2, that is, implementing the modified mClock flow control logic, is characterized by

[0064] Defining the Constraint-based phase

[0065] Defining the Weight-based phase

[0066] In the Constraint-based phase defined in 1.2.1, check whether the reservation tag corresponding to the current request in the reservation queue is less than or equal to the current time. If the condition is met, the verification is successful and the flow control verification logic ends; otherwise, the Weight-based phase is executed.

[0067] Specifically, in the libcephfs client, find the corresponding reservation tag according to the number of requests of the request tag. If the reservation tag is less than or equal to the current time, return verification success and recalculate the reservation tags of the subsequent request tags in the reservation queue.

[0068] For example, assume the current time is 12. When the reservation tag is 12, the verification is successful; when the reservation tag is 13, enter the Weight-based phase.

[0069] In the Weight-based phase defined in 1.2.2, check whether the upper limit tag corresponding to the current request in the upper limit queue is less than or equal to the current time. If the condition is met, the verification is successful; otherwise, the verification fails. In both cases, the flow control verification logic ends.

[0070] Specifically, in the libcephfs client, find the corresponding upper limit tag according to the number of requests of the request tag. If the upper limit tag is less than or equal to the current time, return verification success.

[0071] For example, assume the current time is 12. When the current upper limit tag is 12, the verification is successful; when the upper limit tag is 13, the verification fails.

[0072] The flow control logic added to the metadata operation described in 1.3, that is, determining whether to continue executing the subsequent metadata logic according to the verification result of the mClock flow control logic, is characterized by

[0073] Flow control verification success logic

[0074] Flow control verification failure logic

[0075] The flow control verification success logic described in 1.3.1, that is, after the flow control verification is successful, the reservation tag, upper limit tag, and weight tag of the previous request corresponding to this request are removed from the reservation queue, upper limit queue, and weight queue. Then, the subsequent metadata execution logic is executed.

[0076] Specifically, when the flow control verification is successful, the request tag is removed from the reservation queue, upper limit queue, and weight queue of the libcephfs client, and the subsequent upper limit tag and weight tag are recalculated.

[0077] The flow control verification failure handling described in 1.3.2, that is, after the flow control verification fails, wait for the time interval corresponding to the upper limit value, and execute the flow control verification again until the verification is successful.

[0078] Specifically, when the flow control verification fails, re-verify after waiting for the time interval corresponding to the upper limit value in the libcephfs client until the verification is successful. Release the libcephfs exclusive lock during the waiting period to allow other requests to execute, and acquire the libcephfs exclusive lock before verification to strictly limit the serialization of flow control verification.

[0079] For example, assume the time is 12, the upper limit tag is 13, and the upper limit value is 10. After multiple loop verifications, the time is 13, the upper limit is 13, the verification is successful, and the subsequent metadata operations are executed.

[0080] The above are only the preferred embodiments of the present invention, which are only used to illustrate the technical solutions of the present invention and are not used to limit the protection scope of the present invention. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principle of the present invention are included in the protection scope of the present invention.

Claims

1. An mClock metadata flow control method for a file system, characterized in that at the client side, the mClock algorithm is used to perform flow control restrictions on file system metadata operations, and the aspect of restriction is the IOPS of metadata operations on files or directories; in the metadata operation scenario, the metadata operation is verified by the mClock algorithm whether it can be executed. If the verification is successful, the subsequent metadata execution logic is continued; otherwise, the request lock is released and waiting for the next round of verification until the verification is successful.

2. The method according to claim 1, characterized in that the mClock algorithm logic is as follows: First, for each request, corresponding tags and ordered queues are generated according to the reserved values, upper limit values, and weights of different operation types defined. Among them, the tag is essentially the calculation of a timestamp, and the ordered queue is to sort the requests corresponding to the tags; After that, when processing requests, it includes two stages, namely the Constraint-based stage and the Weight-based stage; Among them, in the Constraint-based stage, requests with reserved tags less than the current time are executed from the reserved queue, and in the Weight-based stage, the weight queue is traversed to execute requests with upper limit tags less than the current time.

3. The method according to claim 1 or 2, characterized in that specifically includes: Declare the mClock structure, that is, define the mClock-related configurations and data structures of the client; including declaring mClock-related parameters, declaring the mClock queue, and calculating request tags; Declare the mClock flow control verification logic, that is, implement the modified mClock flow control logic; including defining the Constraint-based stage and defining the Weight-based stage; Add flow control logic to metadata operations, that is, determine whether to continue to execute the subsequent metadata logic according to the verification result of the mClock flow control logic; including the flow control verification success logic and the flow control verification failure logic.

4. The method according to claim 3, characterized in that the declaration of mClock-related parameters, that is, declare the corresponding reserved values, upper limit values, and weights according to the metadata type, and the specific parameter meanings are as follows: Reserved value: The minimum limit of this type of operation, that is, the minimum value of the metadata operation IOPS of a single client, and the value range is greater than 0; Upper limit value: The maximum limit of this type of operation, that is, the maximum value of the metadata operation IOPS of a single client, and the value range is greater than 0; the expected effect is that in the single client scenario, the metadata IOPS is maintained between the reserved value and the upper limit value; Weight: The proportion of this type of operation in all operations, that is, the proportion of a single client, and the value range is greater than 0; it is stipulated that the proportions of various metadata operations are equal. For those with a read demand proportion exceeding 70%, the proportion of their view type metadata operations is adjusted to 9:1; The calculation of the request tag, that is, calculate the tag when the client executes a metadata request according to the above parameters. The aforementioned declared mClock queues, i.e., declare reserved queues, upper limit queues, and weight queues in the client, and generate tags for the reserved tags, upper limit tags, and weight tags of each request, and the structure of the number of requests, i.e., request tags. Then, add them to the corresponding reserved queues, upper limit queues, and weight queues according to the tag sizes of the request tags.

5. The method according to claim 4, wherein Add reserved values, upper limit values, and weights in the configuration of the libcephfs client. The default reserved value for metadata operations is 1, the upper limit value is 1000, and the weight is 1, that is, limit the metadata operation IOPS within 1000. In the libcephfs client, calculate the reserved tag, upper limit tag, and weight tag before each metadata operation is executed. In the libcephfs client, define a reserved queue, an upper limit queue, and a weight queue. The queue initially contains the 0th request tag, and the tag values are all 0.

6. The method according to claim 3, wherein The defined Constraint-based phase means to check in the reserved queue whether the reserved tag corresponding to this request is less than or equal to the current time. If the condition is met, the verification is successful and the flow control verification logic ends. Otherwise, the Weight-based phase is executed. The defined Weight-based phase means to check in the upper limit queue whether the upper limit tag corresponding to this request is less than or equal to the current time. If the condition is met, the verification is successful. Otherwise, the verification fails. In both cases, the flow control verification logic ends.

7. The method according to claim 6, wherein In the libcephfs client, find the corresponding reserved tag according to the number of requests of the request tag. If the reserved tag is less than or equal to the current time, return verification success and recalculate the reserved tags of the request tags in the subsequent reserved queue. In the libcephfs client, find the corresponding upper limit tag according to the number of requests of the request tag. If the upper limit tag is less than or equal to the current time, return verification success.

8. The method according to claim 3, wherein The flow control verification success logic means that after the flow control verification is successful, remove the reserved tag, upper limit tag, and weight tag of the previous request corresponding to this request from the reserved queue, upper limit queue, and weight queue. Then execute the subsequent metadata execution logic. The flow control verification failure handling means that after the flow control verification fails, wait for the time interval corresponding to the upper limit value, and execute the flow control verification again until the verification is successful.

9. The method according to claim 8, wherein When the flow control verification is successful, remove the request tag from the reserved queue, upper limit queue, and weight queue in the libcephfs client, and recalculate the subsequent upper limit tags and weight tags. When the flow control verification fails, wait for the time interval corresponding to the upper limit value in the libcephfs client and then re-verify until the verification is successful. Release the libcephfs exclusive lock during the waiting period to allow other requests to execute, and acquire the libcephfs exclusive lock before verification to limit the serialization of the flow control verification.

Images