A scheduling control method, device and computer storage medium

Abstract

The present application provides a scheduling control method, device, and computer storage medium. The method includes: receiving pending input / output (IO) requests sent by a user device, and determining attribute parameters of the pending IO requests; wherein the attribute parameters include at least a preset throughput parameter and a preset forwarding rate parameter; based on the preset throughput parameter and the preset forwarding rate parameter, label allocation processing is performed on the pending IO requests, and a target time label value of the pending IO requests is determined; based on the target time label value of the pending IO requests, the pending IO requests are scheduled. In this way, reasonable scheduling of batch pending IO requests is achieved according to the preset forwarding rate parameter and the preset throughput parameter, which can achieve service quality control that takes into account both forwarding rate performance and throughput performance, and can provide high-quality storage services in various storage business scenarios.

Description

Technical Field

[0001] The present application relates to the field of cloud computing technology, and in particular to a scheduling control method, device, and computer storage medium. Background Art

[0002] Due to the decentralized nature of distributed storage systems, the same storage device can be accessed by multiple storage user devices simultaneously, leading to competition for storage resources. To address this issue, storage systems use Quality of Service (QoS) control to allocate different storage resources to user devices with different services, ensuring fair and reasonable allocation of storage resources.

[0003] In related technologies, the Dmclock algorithm is commonly used to schedule and control different storage input / output (IO) requests, thereby allocating different storage resources to storage user devices with different services. However, the Dmclock algorithm only considers forwarding rate performance when scheduling pending IO requests. This incomplete consideration leads to unsatisfactory quality of service (QoS) control in some business scenarios. Summary of the Invention

[0004] The present application provides a scheduling control method, device and computer storage medium, which schedule IO requests to be processed on the basis of taking into account forwarding rate performance and throughput performance, and can provide high-quality storage services.

[0005] The technical solution of this application is achieved as follows:

[0006] In a first aspect, an embodiment of the present application provides a scheduling control method, applied to a service device, the method comprising:

[0007] Receive a pending input / output (IO) request sent by a user device, and determine attribute parameters of the pending IO request; wherein the attribute parameters include at least a preset throughput parameter and a preset forwarding rate parameter;

[0008] Based on the preset throughput rate parameter and the preset forwarding rate parameter, label allocation processing is performed on the pending IO request to determine the target time label value of the pending IO request;

[0009] Based on the target time tag value of the pending IO request, the pending IO request is scheduled.

[0010] In a second aspect, an embodiment of the present application provides a service device, which includes a determination unit, a label unit, and a recommendation unit; wherein,

[0011] A determination unit configured to receive a pending input / output (IO) request sent by a user device and determine attribute parameters of the pending IO request; wherein the attribute parameters include at least a preset throughput parameter and a preset forwarding rate parameter;

[0012] a label unit configured to perform label allocation processing on the pending IO request based on a preset throughput parameter and a preset forwarding rate parameter, and determine a target time label value of the pending IO request;

[0013] The scheduling unit is configured to schedule the pending IO requests based on target time tag values ​​of the pending IO requests.

[0014] In a third aspect, an embodiment of the present application provides a service device, which includes a memory and a processor; wherein,

[0015] a memory for storing computer programs capable of running on the processor;

[0016] A processor is configured to execute the steps of the method of the first aspect when running a computer program.

[0017] In a fourth aspect, an embodiment of the present application provides a computer storage medium, which stores a computer program, and when the computer program is executed, implements the steps of the method of the first aspect.

[0018] The present application provides a scheduling control method, device and computer storage medium, which receives pending input and output IO requests sent by user devices and determines the attribute parameters of the pending IO requests; wherein the attribute parameters include at least a preset throughput parameter and a preset forwarding rate parameter; based on the preset throughput parameter and the preset forwarding rate parameter, labels are assigned to the pending IO requests to determine the target time label value of the pending IO requests; based on the target time label value of the pending IO requests, the pending IO requests are scheduled. In this way, according to the preset forwarding rate parameter and the preset throughput parameter, corresponding time label values ​​can be assigned to the pending IO requests, thereby realizing reasonable scheduling of batch pending IO requests, realizing service quality control that takes into account both forwarding rate performance and throughput performance, and thus being able to provide high-quality storage services in various storage business scenarios. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] Figure 1 A flowchart of a scheduling control method provided in an embodiment of the present application;

[0020] Figure 2 A flowchart of another scheduling control method provided in an embodiment of the present application;

[0021] Figure 3A schematic diagram of the working process of a scheduling control method provided in an embodiment of the present application;

[0022] Figure 4 A schematic diagram of the working process of another scheduling control method provided in an embodiment of the present application;

[0023] Figure 5 A schematic diagram of the working process of another scheduling control method provided in an embodiment of the present application;

[0024] Figure 6 A schematic diagram of the structure of a service device provided in an embodiment of the present application;

[0025] Figure 7 A schematic diagram of the hardware structure of a service device provided in an embodiment of the present application;

[0026] Figure 8 A schematic diagram of the structure of a distributed storage system provided in an embodiment of the present application. DETAILED DESCRIPTION

[0027] The following will be combined with the accompanying drawings in the embodiments of the present application to clearly and completely describe the technical solutions in the embodiments of the present application. It should be understood that the specific embodiments described herein are only used to explain the related applications and are not intended to limit the applications. It should also be noted that for ease of description, only the parts relevant to the related applications are shown in the drawings.

[0028] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by those skilled in the art to which this application pertains. The terms used herein are for the purpose of describing the embodiments of this application only and are not intended to limit this application.

[0029] In the following description, reference is made to “some embodiments”, which describes a subset of all possible embodiments, but it will be understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.

[0030] It should be pointed out that the terms "first\second\third" involved in the embodiments of the present application are only used to distinguish similar objects and do not represent a specific ordering of the objects. It can be understood that "first\second\third" can be interchanged with a specific order or sequence where permitted, so that the embodiments of the present application described here can be implemented in an order other than that illustrated or described here.

[0031] The following are the professional terms involved in the embodiments of this application:

[0032] Input / Output Operations Per Second (IOPS): The number of pending I / O requests processed by a storage device (or storage server) per second.

[0033] Throughput: The amount of data processed per second by a storage device when processing pending I / O requests. Measured in kilobytes per second (KB / s), megabytes per second (MB / s), or gigabytes per second (GB / s).

[0034] Table 1 shows the symbols involved in the embodiments of this application. Please see Table 1 for details.

[0035] Table 1

[0036]

[0037]

[0038] The principle of a distributed storage system is to distribute stored data (files, block data, and objects) across multiple independent storage devices, interconnecting them through a network and enabling horizontal scalability, thereby effectively sharing the load across multiple storage devices. Compared to traditional storage systems, distributed storage systems significantly improve reliability, availability, and access efficiency, and are easily scalable. In other words, distributed storage systems construct these dispersed storage devices into a large, virtual storage resource pool for upper-layer applications to use. However, precisely because of the distributed nature of data storage in distributed storage systems, the same storage device can be accessed simultaneously by multiple storage user devices, leading to contention for storage resources.

[0039] In related technologies, in order to solve the resource competition problem of distributed storage, the distributed storage system allocates different storage resources (such as forwarding rate IOPS) to user devices of different services through service quality control to achieve fair and reasonable allocation of storage resources. Specifically, for a distributed storage system, the Dmclock algorithm can be used to schedule different pending IO requests. The algorithm uses a time tag value to schedule the pending IO requests of the user device. Specifically, the time tag value controls the storage IO performance of the storage user device through three dimensions: reservation (Reservation tag), upper limit (Limit tag) and weight (Proportion tag). Among them, the reservation time tag value (or called reservation tag value) ensures the minimum IOPS performance of the user device, the upper limit time tag value (or called upper limit tag value) limits the maximum IOPS performance of the user device, and the weight time tag value (or called weight tag value) represents the scheduling priority of the user device request. When the reserved performance of all user devices is met, the remaining IOPS performance is allocated to each user device according to the weight.

[0040] The following is a code diagram of the Dmclock scheduling algorithm:

[0041]

[0042]

[0043] Based on the above code, the scheduling principle of the Dmclock scheduling algorithm process is explained in detail.

[0044] Here, the scheduling algorithm runs on each storage server and is mainly divided into three important parts: (1) label value allocation; (2) label value adjustment; (3) request scheduling.

[0045] (1) Label value allocation: For the VM v from the user device i The request is assigned three types of label values: R, L and P. Taking the reserved time label value R as an example, the time label value of the pending IO request is the maximum of the following two: the time label value of the previous IO request plus ρ i / r i (the delay that satisfies the reserved forwarding rate) and the current time t (Currenttime), as shown in formula (1). Through the above method, the reserved time label values ​​of all IO requests can form a linear increasing relationship in time. In particular, when a user device VM changes from an inactive state to an active state, the reserved time label value assigned to its request is the current time of this request. This can avoid scheduling confusion and affect the IO performance of other active VMs. The L and P label value allocation rules are basically the same as R.

[0046]

[0047] (2) Label value adjustment: When the inactive user device VM v i When it turns to active state, according to the above label allocation rules, the weighted time label value assigned to the IO request of the user device is the current time t of the IO request. However, in this case, the user device VM v i The weighted time label value queue of the IO request is not on the same basis (not forming a linear relationship) as the request weighted time label value queue of other active user device VMs (which is a linearly increasing queue), which will cause VMv i The request weight value of VM v does not form a true proportional relationship with the request weight values ​​of other VMs. Therefore, it is necessary to i The weighted time tag value queue of the request is aligned with the request tag value queues of other active VMs. To address the above issue, first, the minimum value minPtag in the current weighted tag queue is selected and the difference is formed with the current time. Then, the weighted time tag values ​​of the requests of other active user devices are subtracted from this difference, as shown in Formula (2). Since only the P tag value is adjusted, it will not affect the constrained scheduling stage.

[0048]

[0049] Where minPtag represents the minimum P tag of the current request, and t represents the current time.

[0050] (3) Request scheduling: It is divided into two scheduling stages, namely the constraint scheduling stage and the weight scheduling stage. In the constraint scheduling stage, requests are scheduled according to the R label values ​​of all user device VM requests. All requests with R label values ​​lower than the current time t are grouped into an ordered queue. Scheduling starts from the request with the smallest R label value until all queue requests are scheduled. This completes the scheduling of this stage and ensures that all user device VM requests meet the reserved forwarding rate performance. In the weight scheduling stage, requests are scheduled according to the L and P label values ​​of all user device VM requests. First, all requests with L label values ​​lower than the current time t are grouped into an ordered queue according to the P label value. Scheduling starts from the request with the smallest P label value until all queue requests are scheduled. In order to make requests from the same user device VM v k The request queue is kept linear, and the user device VM v to which the request belongs is scheduled at the same time. k The R tag value of all subsequent requests in the request queue minus ρ k / r k .

[0051] However, the Dmclock algorithm only provides a scheduling algorithm for IO forwarding rate, or IOPS performance, while more business scenarios often require simultaneous QoS control of both forwarding rate IOPS and throughput. For example, in business scenarios with a large number of small files, the primary focus is on controlling the forwarding rate IOPS performance, while in business scenarios with larger files, the primary focus is on controlling the throughput performance. Public cloud business scenarios are particularly important, as multiple tenants share the performance of the underlying storage cluster. Due to the unpredictable nature of the upper-layer businesses deployed by tenants, a variety of storage business scenarios are often mixed. Therefore, it is essential to implement QoS control for both forwarding rate IOPS and throughput performance in distributed storage systems.

[0052] Based on this, an embodiment of the present application provides a scheduling control method, the basic idea of ​​which is: receiving pending input and output IO requests sent by a user device, and determining the attribute parameters of the pending IO requests; wherein the attribute parameters include at least a preset throughput parameter and a preset forwarding rate parameter; based on the preset throughput parameter and the preset forwarding rate parameter, label allocation processing is performed on the pending IO requests to determine the target time label value of the pending IO requests; based on the target time label value of the pending IO requests, the pending IO requests are scheduled. In this way, according to the preset forwarding rate parameter and the preset throughput parameter, corresponding time label values ​​can be assigned to the pending IO requests, and then reasonable scheduling of batch pending IO requests can be achieved, and service quality control that takes into account both forwarding rate performance and throughput performance can be achieved, so that high-quality storage services can be provided in various storage business scenarios.

[0053] The embodiments of the present application will be described in detail below with reference to the accompanying drawings.

[0054] In one embodiment of the present application, see Figure 1 , which shows a flow chart of a scheduling control method provided by an embodiment of the present application. Figure 1 As shown, the method may include:

[0055] S101: receiving an input / output (IO) request to be processed sent by a user device, and determining attribute parameters of the IO request to be processed.

[0056] It should be noted that the scheduling control method provided in the embodiment of the present application is applied to a service device (also referred to as a "storage server" or "server") in a distributed storage system.

[0057] Specifically, in a distributed storage system, stored data (files, block data, objects, etc.) is distributed across multiple independent service devices, meaning that the same service device can be accessed by multiple clients (hereinafter referred to as user devices) simultaneously. Therefore, a physical service device may receive multiple input / output (IO) requests from one or more user devices in a short period of time. Properly scheduling and completing these IO requests is crucial for achieving quality of service (QoS) control. The method provided in the embodiments of this application is designed to address this issue.

[0058] For the scheduling control method provided in the embodiment of the present application, after receiving the pending IO request sent by the user equipment, it is necessary to determine the attribute parameters of the pending IO request. Here, the attribute parameters include at least a preset forwarding rate parameter and a preset throughput rate parameter.

[0059] For example, based on the importance, priority and performance of the user equipment, the service device sets corresponding theoretical performance parameters for each user equipment. In other words, the preset forwarding rate parameters and preset throughput rate parameters are pre-set by the server for different user equipments.

[0060] Here, although one or more user devices generally send multiple consecutive IO requests to the service device, the initial processing performed by the service device on these IO requests is the same, such as determining the attribute parameters of each IO request, setting different labels for each IO request, etc. Therefore, the pending IO request can be considered as a whole composed of multiple IO requests sent by one or more user devices, or can be considered as a specific one of the multiple IO requests sent by one or more user devices. For the sake of convenience, the technical solution is described from the perspective that the pending IO request is a specific IO request in the embodiment of the present application, but this does not constitute a relevant limitation.

[0061] S102: Based on a preset throughput parameter and a preset forwarding rate parameter, label allocation processing is performed on the IO request to be processed, and a target time label value of the IO request to be processed is determined.

[0062] It should be noted that the scheduling control method provided in the embodiments of the present application is essentially an optimization of the Dmclock algorithm, and still uses the framework of the Dmclock algorithm. Therefore, after determining the preset forwarding rate parameter and preset throughput parameter corresponding to the pending I / O request, a target time stamp value is assigned to the pending I / O request based on the determined parameters.

[0063] It should also be noted that the preset forwarding rate parameter may include a reserved forwarding rate parameter and an upper limit forwarding rate parameter, and the preset throughput rate parameter may include a reserved throughput rate parameter and an upper limit throughput rate parameter. Accordingly, the target time label value may include a reserved time label value and an upper limit time label value.

[0064] Here, the reserved time tag value ensures the minimum storage processing performance of the user device. In other words, when the reserved time tag value of the pending IO request is greater than the current time, it means that the corresponding storage resources allocated by the service device to the user device have met the minimum value; the upper limit time tag value ensures the highest storage processing performance of the user device. In other words, when the upper limit time tag value of the pending IO request is greater than the current time, it means that the corresponding storage resources allocated by the service device to the user device have met the maximum value.

[0065] Specifically, the preset forwarding rate parameter may include a reserved forwarding rate parameter and an upper limit forwarding rate parameter, the preset throughput parameter may include a reserved throughput parameter and an upper limit throughput parameter, and the target time tag value may include a reserved time tag value and an upper limit time tag value. Therefore, in some embodiments, performing label allocation processing on the pending IO request based on the preset throughput parameter and the preset forwarding rate parameter and determining the target time tag value of the pending IO request may include:

[0066] According to the reserved forwarding rate parameter and the reserved throughput rate parameter, labels are assigned to the pending IO requests to obtain the reserved time label value of the pending IO requests;

[0067] According to the upper limit forwarding rate parameter and the upper limit throughput rate parameter, label allocation processing is performed on the IO request to be processed to obtain the upper limit time label value of the IO request to be processed.

[0068] It should be noted that, generally speaking, a service device sets two types of theoretical performance parameters for each user device: reserved performance parameters and upper limit performance parameters. The reserved performance parameters limit the minimum service performance that the user device can obtain from the service device, while the upper limit performance parameters limit the maximum service performance that the user device can obtain from the service device.

[0069] Therefore, based on the reserved forwarding rate parameter and the reserved throughput rate parameter, the service device can calculate the reserved time required to complete the pending IO request, and then allocate a reserved time label value to the pending IO request according to the reserved time.

[0070] Based on the upper limit forwarding rate parameter and the upper limit throughput rate parameter, the storage device can calculate the upper limit time required to complete the pending IO request, and then assign an upper limit time label value to the pending IO request based on the upper limit time.

[0071] Specifically, in some embodiments, the attribute parameter further includes a data length value; the specific process of determining the reserved time tag value is as follows:

[0072] Determine a reserved forwarding rate delay and a reserved throughput rate delay; wherein the reserved forwarding rate delay is calculated based on the reserved forwarding rate parameter, and the reserved throughput rate delay is calculated based on the data length value and the reserved throughput rate parameter;

[0073] Determine a reserved forwarding rate delay and a reserved throughput rate delay; wherein the reserved forwarding rate delay is calculated based on the reserved forwarding rate parameter, and the reserved throughput rate delay is calculated based on the data length value and the reserved throughput rate parameter;

[0074] The minimum value of the reserved throughput rate delay and the reserved forwarding rate delay is determined as the target reserved delay;

[0075] After obtaining the previous reserved time tag value and the current time tag value, the reserved time tag value of the pending IO request is determined according to the target reserved delay, the previous reserved time tag value and the current time tag value;

[0076] The previous reserved time tag value refers to the reserved time tag value of the previous IO request from the same user equipment as the to-be-processed IO request.

[0077] It should be noted that the attribute parameter may also include a data length value, which refers to the length of the target data corresponding to the pending IO request. For example, the data length value is calculated by the user device and sent to the service device when the pending IO request is sent to the service device.

[0078] For the sake of convenience, the time required for the service device to process the pending IO request at the reserved forwarding rate is called the reserved forwarding rate delay, and the time required for the service device to process the pending IO request at the reserved throughput rate is called the reserved throughput rate delay.

[0079] Since the forwarding rate refers to the number of IO requests processed by the service device per unit time, the reciprocal of the reserved forwarding rate parameter is the reserved forwarding rate delay. For example, if the reserved forwarding rate parameter can be 100 / second, then the reserved forwarding rate delay is 1 / 100 second. Similarly, since the throughput rate refers to the amount of data processed by the service device per unit time, the reserved throughput rate delay needs to be calculated by dividing the data length value by the throughput rate.

[0080] On the basis of simultaneously meeting the reserved forwarding rate and the reserved throughput rate, the reserved time label value needs to be allocated according to the high quality of service requirement, that is, the minimum value of the reserved throughput rate delay and the reserved forwarding rate delay is determined as the target reserved delay.

[0081] After obtaining the target reservation delay, it is necessary to determine the reservation time tag value of the pending IO request based on the target reservation delay, the previous reservation time tag value, and the current time tag value. Here, the previous reservation time tag value refers to the reservation time tag value of the previous IO request of the user device, and the current time tag value refers to the current system time of the service device. That is, the specific value of the current time tag value is different in different steps. The specific instructions are as follows:

[0082] The service device may also have other IO requests previously sent by the user device that have not been processed. All IO requests of a user device should be executed sequentially and continuously. Therefore, it is necessary to calculate the reservation time tag value of the user device's previous IO request (i.e., the previous reservation time tag value) and the target reservation delay to determine the theoretical reservation time tag value of the pending IO request.

[0083] Here, when calculating the theoretical reserved time label value, the first request number (ρ i ), which represents the number of requests sent by the user device to the current storage server that were processed during the reservation scheduling phase between the last request and the current request. For a single storage server, this value is 1. The first request number is calculated by the user device and sent to the service device along with the pending IO request. This means that the first request number is also one of the attribute parameters of the pending IO request. The theoretical reservation label is obtained by multiplying the first request number by the target reservation delay to the value of the previous reservation time label.

[0084] In particular, if the pending IO request is the first IO request sent by the user device after it changes from an inactive state to an active state, the current time tag value can be used as its reserved time tag value, such as the time when the server receives the pending IO request.

[0085] Therefore, the maximum value between the theoretical reserved time label value and the current time needs to be used as the reserved time label of the pending IO request, as shown in formula (3).

[0086]

[0087] Furthermore, in some embodiments, the specific process of determining the upper limit signature value is as follows:

[0088] Determine the upper limit forwarding rate delay and the upper limit throughput rate delay; wherein, the upper limit forwarding rate delay is calculated based on the upper limit forwarding rate parameter, and the upper limit throughput rate delay is calculated based on the data length value and the upper limit throughput rate parameter;

[0089] The maximum value of the upper limit throughput rate delay and the upper limit forwarding rate delay is determined as the target upper limit delay;

[0090] After obtaining the previous upper limit time tag value and the current time tag value, the upper limit time tag value of the pending IO request is determined based on the target upper limit delay, the previous upper limit time tag value, and the current time tag value;

[0091] The previous upper limit time tag value refers to the upper limit time tag value of the previous IO request from the same user device as the to-be-processed IO request.

[0092] It should be noted that, similar to the calculation method of reserved forwarding rate delay and reserved throughput rate delay, the reciprocal of the upper limit forwarding rate parameter is determined as the upper limit forwarding rate delay, and the data length value is divided by the upper limit throughput rate parameter to obtain the upper limit throughput rate delay.

[0093] However, to complete the current I / O request, only one of the upper throughput limit and the upper forwarding limit can be met. The longer the required time, the lower the upper quality of service. Furthermore, the upper time tag value must be allocated based on the lower quality of service requirement. Specifically, the maximum value of the reserved throughput delay or the reserved forwarding delay is determined as the target upper delay.

[0094] After obtaining the target upper limit delay, it is necessary to determine the upper limit time tag value of the pending IO request based on the target upper limit delay, the previous upper limit time tag value, and the current time tag value. Here, the previous upper limit time tag value refers to the upper limit time tag value of the previous IO request of the user device. The specific instructions are as follows:

[0095] Similarly, after determining the target upper limit delay, the upper limit time tag value of the previous IO request of the user equipment (ie, the previous upper limit time tag value) and the target upper limit delay are used for calculation to obtain the theoretical upper limit time tag value.

[0096] Here, when calculating the theoretical upper limit time label value, the second request number (δ i ), which represents the number of requests sent by the user device to the current storage server that have been processed between the last request and the current request. For a single storage server, this value is 1. The second request number is calculated by the user device and sent to the service device along with the pending I / O request. This second request number is also an attribute parameter of the pending I / O request. The theoretical upper limit label is obtained by multiplying the second request number by the target upper limit delay to the previous upper limit time label value.

[0097] In particular, if the pending IO request is the first IO request sent by the user device after the user device changes from an inactive state to an active state, the current time stamp value may be used as the upper limit time stamp value.

[0098] In this way, the maximum value between the theoretical upper limit time tag value and the current time needs to be used as the upper limit time tag value of the IO request to be processed, as shown in formula (4).

[0099]

[0100] Furthermore, in some embodiments, the attribute parameter further includes a weight parameter, and the target time tag value further includes a weighted time tag value;

[0101] Accordingly, the performing label assignment processing on the pending IO request based on the preset throughput parameter and the preset forwarding rate parameter and determining the target time label value of the pending IO request may further include:

[0102] Label allocation is performed on the pending IO request according to the weight parameter to obtain a weighted time label value of the pending IO request.

[0103] It should be noted that the weight parameter is used to indicate the priority set by the service device for the user device. According to the weight parameter, the service device assigns a weighted time tag value to the to-be-processed IO request.

[0104] Specifically, in some embodiments, the specific process of determining the weighted time tag value is as follows:

[0105] Determine a target weighted delay; wherein the target weighted delay is calculated based on a weight parameter;

[0106] After obtaining the previous weighted time tag value and the current time tag value, the weighted time tag value of the pending IO request is determined based on the target weighted delay, the previous upper limit time tag value, and the current time tag value;

[0107] The previous weighted time tag value refers to the weighted time tag value of the previous IO request from the same user device as the to-be-processed IO request.

[0108] It should be noted that, unlike forwarding rate and throughput, the weight parameter is only a relative parameter between different user devices and does not have a unit. Generally speaking, the higher the weight parameter, the higher the processing priority of the user device, so the reciprocal of the weight parameter is generally determined as the target weighted delay.

[0109] After obtaining the target weighted delay, it is necessary to determine the weighted time tag value of the pending IO request based on the target weighted delay, the previous weighted time tag value, and the current time tag value. Here, the previous weighted time tag value refers to the weighted time tag value of the previous IO request of the user device. The specific instructions are as follows:

[0110] Similarly, after determining the target weight delay, the weight time tag value of the previous IO request of the user device (ie, the previous upper limit time tag value) and the target weight delay are calculated to obtain the theoretical weight limit tag value.

[0111] Here, when calculating the theoretical weight time label value, the second request number (δ i ). Based on the previous weight time label value, the product of the second request number and the target weight delay is added to obtain the theoretical weight label.

[0112] In particular, if the pending IO request is the first IO request sent by the user device after the user device changes from an inactive state to an active state, the current time stamp value may be used as its weighted time stamp value.

[0113] In this way, the maximum value between the theoretical weighted time tag value and the current time tag value needs to be used as the weighted time tag value of the IO request to be processed, as shown in formula (5).

[0114]

[0115] In this case, the weight tag of the IO request to be processed and the weight tags of the IO requests of other user devices in the service device will not be in the same linear echelon. In this case, it is necessary to refer to the aforementioned formula (2) to adjust the IO requests of other user devices in the service device.

[0116] From the above processing, it can be seen that the service device still needs to assign three types of time tag values ​​to each pending IO request: a reserved time tag value, an upper limit time tag value, and a weighted time tag value. Subsequently, the IO requests are still scheduled using these three types of time tag values. However, the related art only assigns three types of time tag values ​​to IO requests based on the forwarding rate and weight, while the embodiment of the present application assigns three types of time tag values ​​to IO requests based on the forwarding rate, throughput rate, and weight. Therefore, it can better provide storage services based on a balance of forwarding rate, throughput rate, and priority.

[0117] In this way, through the above processing method, the reserved time label value, upper limit time label value and weighted time label value of the pending IO request can be determined, so as to reasonably schedule the pending IO request later.

[0118] S103: Scheduling the IO request to be processed based on the reserved time tag value, the upper limit time tag value and the weighted time tag value.

[0119] It should be noted that the reserved time label value, upper limit time label value, and weighted time label value can comprehensively consider the performance resources of the service device, thereby scheduling pending I / O requests while ensuring quality of service. Because the performance parameters of forwarding rate and throughput are already considered when allocating the reserved time label value, upper limit time label value, and weighted label value, labels can be flexibly allocated based on the different pending I / O requests, thereby ensuring both forwarding rate and throughput when scheduling I / O requests.

[0120] It should be noted that due to the characteristics of the distributed storage system, the service device may receive multiple IO requests from one or more user devices. Hereinafter, all unprocessed IO requests in the service device are referred to as a pending request set. It should be understood that the pending request set contains at least one pending IO request. Therefore, in some embodiments, the scheduling of pending IO requests based on the reserved time tag value, the upper limit time tag value, and the weighted time tag value may include:

[0121] Determining a pending request set including at least one pending IO request;

[0122] Determine whether there is at least one first IO request in the set of pending requests; wherein the reserved time tag value of the first IO request is less than the current time;

[0123] When there is at least one first IO request in the set of pending requests, the at least one first IO request is scheduled according to the reserved time tag value of each of the at least one first IO request.

[0124] Furthermore, in some embodiments, when the first IO request does not exist in the set of pending requests, the method may further include:

[0125] It is determined whether there is at least one second IO request in the set of pending requests; wherein the upper limit time tag value of the second IO request is less than the current time.

[0126] If the judgment result is yes, the at least one second IO request is scheduled according to the weighted time tag value of each of the at least one second IO request.

[0127] It should be noted that for the service device, all IO requests in the system need to be uniformly scheduled. All IO requests are referred to as a pending request set below, that is, a pending request set includes at least one pending IO request. In addition, the current time tag value refers to the current time of the service device.

[0128] At this point, the specific steps for scheduling the set of requests to be processed include:

[0129] (1) Constrained scheduling stage: In the set of pending requests, it is determined whether there is an IO request whose reserved time tag value is less than the current time tag value, that is, the first IO request.

[0130] If there is at least one first IO request, the at least one first IO request is scheduled in ascending order of reserved time tag value; if there is no at least one first IO request, the weight scheduling phase is entered.

[0131] Here, the constrained scheduling stage can ensure that the IO requests of all user devices meet the reserved forwarding rate performance and the reserved throughput rate performance.

[0132] (2) Weighted scheduling phase: In the set of pending requests, determine whether there is an IO request whose upper limit time tag value is less than the current time tag value, that is, the second IO request;

[0133] If there is at least one second IO request, the at least one second IO request is scheduled according to the weighted time tag values ​​in ascending order for the at least two IO requests.

[0134] Specifically, the scheduling strategy of IO requests can be understood as follows: for multiple IO requests, check whether the reserved time tag values ​​of these IO requests are less than the current time tag value. If so, it means that the storage resources allocated by the service device to the first user device (the user device corresponding to the first IO request) have not yet met the theoretical minimum requirements of the first user device, and the IO request of the first user device should be processed first.

[0135] If the reserved time tag values ​​of all IO requests are greater than the current time tag value, it means that the storage resources allocated by the service device to all user devices have met the theoretical minimum requirements of each user device. At this time, the service device selects the second IO request with an upper time tag value less than the current time tag value from all IO requests, and then selects the IO request with the smallest P tag to respond.

[0136] It should be understood that the multiple current time tag values ​​involved in the embodiment of the present invention all change with the system time of the service device, and are not fixed to a certain time point, so the specific time points referred to may be different.

[0137] Furthermore, in some embodiments, when the pending IO request is determined to be a second IO request, the method may further include:

[0138] After the scheduling of the pending IO request is completed, the target time difference is determined according to the reserved time tag value of the pending IO request and the previous reserved time tag value;

[0139] Based on the target time difference, the reserved time tag value of the target IO request corresponding to the pending IO request is updated.

[0140] Here, the target IO request and the pending IO request come from the same user device, and the reserved time tag value of the target IO request is greater than the reserved time tag value of the pending IO request.

[0141] It should be noted that if the pending IO request is scheduled in the weight scheduling stage, for the reserved time label value, in order to keep the IO request queue from the same user device (the IO request queue formed according to the size of the reserved time label value) linearly increasing, it is necessary to move forward sequentially all IO requests after the pending IO request in the request queue corresponding to the user device.

[0142] That is, after the scheduling of the pending IO request is completed, the reserved time label value of the pending IO request is subtracted from the previous reserved time label value to obtain the target time difference, that is, the target time difference is ρ k ×min{s k / r tk , 1 / r fk Then, the target time difference is subtracted from the reserved time tag values ​​of the target IO request corresponding to all pending IO requests to obtain the new reserved time tag value of the target IO request. In this case, the target IO request and the pending IO request come from the same user device, and the reserved time tag value of the target IO request is greater than that of the pending IO request.

[0143] In summary, the present invention provides a method for implementing quality of service (QoS) control by optimizing the Dmclock algorithm, thereby better addressing QoS control issues currently encountered in many business scenarios, particularly in shared storage business scenarios on public clouds. In the present invention, the method primarily includes:

[0144] (1) For user device VM v i Set the reserved forwarding rate parameter r fi and the reserved throughput parameter r ti , set the upper limit forwarding rate parameter l fi and the upper limit throughput parameter l ti , and set the weight value w i ;

[0145] (2) User device VM v i To storage server j The IO request sent carries the IO request length s i , the first request number ρ i and the second request number δ i , s i, ρ i and δ i The value is calculated by the user device VM side;

[0146] (3) Storage servers j Optimize Dmclock algorithm for user device VM v i IO requests are scheduled. Specifically, the optimization of the Dmclock algorithm includes label allocation and request scheduling.

[0147] (a) The above label allocation optimization includes:

[0148] For the reserved time label value calculation, calculate the reserved throughput delay s for completing the current request respectively. i / r ti and reserved forwarding rate delay 1 / r fi ; Take the above throughput delay s i / r ti The forwarding rate delay is 1 / r fi The minimum value of the two is used to calculate the reserved time label value, as shown in formula (3).

[0149] For the calculation of the upper limit time label value, calculate the upper limit throughput delay s of the current request respectively. i / l ti and upper limit forwarding rate delay 1 / l fi ; Take the above throughput delay s i / l ti Delay 1 / 1 compared to the above forwarding rate fi The maximum value of the two is used to calculate the upper limit time tag value, as shown in formula (4).

[0150] The calculation of the weighted time label value is shown in formula (5).

[0151] (b) Optimizing the scheduling of the above requests includes:

[0152] In the weight scheduling phase, in order to make VM v from the same user device k The request queue keeps increasing linearly, and when scheduling a request, the user device VM v to which the request belongs is k The R tag value of all subsequent requests in the request queue minus ρ k ×min{s k / r tk , 1 / r fk}.

[0153] Thus, compared with the related art, the embodiment of the present application optimizes the Dmclock algorithm, thereby enabling the distributed storage system to simultaneously achieve service quality control of the forwarding rate IOPS and throughput performance.

[0154] The embodiment of the present application provides a scheduling control method, which receives pending input and output IO requests sent by a user device and determines the attribute parameters of the pending IO requests; wherein the attribute parameters include at least a preset throughput parameter and a preset forwarding rate parameter; based on the preset throughput parameter and the preset forwarding rate parameter, labels are assigned to the pending IO requests to determine the target time label value of the pending IO requests; based on the target time label value of the pending IO requests, the pending IO requests are scheduled. In this way, according to the preset forwarding rate parameter and the preset throughput parameter, corresponding time label values ​​can be assigned to the pending IO requests, thereby realizing reasonable scheduling of batch pending IO requests, realizing service quality control that takes into account both forwarding rate performance and throughput performance, and thus being able to provide high-quality storage services in various storage business scenarios.

[0155] In another embodiment of the present application, a user device VM v i and storage servers j Taking the distributed storage system as an example, the scheduling control method is described in detail. Figure 2 , which shows a flow chart of another scheduling control method provided by an embodiment of the present application. Figure 2 As shown, the method may include:

[0156] S201: User device VM v i To storage server j Send IO request and calculate IO request length s i , the current IO request is the same as the last one sent to the storage server s j During the IO request period, the user device VM v i The total number of completed requests δ i and the number of requests during the constraint phase ρ i , together with the IO request, is sent to the storage server s j .

[0157] It should be noted that the user device VM v i To storage server j Send IO request, request length s i (equivalent to the aforementioned data length value), the number of requests δ i and the number of requests ρ i .

[0158] In addition, the request length s i It can also be performed by a user device VM v i Sending, but user equipment s j It is confirmed after receiving the IO request.

[0159] S202: Storage Server j After receiving the IO request, the Dmclock algorithm is run and the request length s of the current IO request is input when allocating the label value. i , number of requests δ i and the number of requests ρ i , a preset label allocation model is used to allocate the time label value of the current IO request. When the IO request is scheduled, the IO request is scheduled according to the time label value of the IO request.

[0160] It should be noted that, in the storage server s j After receiving the IO request, according to the request length s of the current IO request i , number of requests δ i and the number of requests ρ i , using a preset label allocation model to assign a label value to the current IO request. Then, based on the time label value of the IO request, the IO request is scheduled. Here, the preset label allocation model is the optimized Dmclock algorithm mentioned above.

[0161] exist Figure 3 The principle of configuring the reserved time label value in the scheduling control algorithm provided in the embodiment of the present application is explained in the following. Here, according to the label value allocation rules, whether it is the reserved forwarding rate IOPS or the reserved throughput rate, it must ultimately be reflected as a reserved time slice, that is, the delay required to achieve the reserved forwarding rate and throughput rate.

[0162] like Figure 3 As shown in the figure, it is assumed that the reserved forwarding rate IOPS set for user device 1 is to complete 100 IO requests per second, that is, r f1 =100, then the delay required to complete a single IO request is 1 / r f1 = 10 milliseconds (ms), the reserved throughput is 100MB per second, that is, r t1 =100MB / s, the actual length of the current IO request is 2MB, that is, s1 = 2MB, then the delay required to complete the current IO request is s1 / r t1 =20ms;

[0163] Assume that the reserved forwarding rate set for user device 2 is 100 IO requests per second, that is, r f2 =100, then the delay required to complete a single IO request is 1 / r f2 = 10ms, the reserved throughput is 100MB per second, that is, r t2 =100MB / s, the actual length of the current IO request is 0.5MB, that is, s2 = 0.5MB, then the delay required to complete the current IO request is s2 / r t2 =5ms.

[0164] For completing pending IO requests, on the basis of satisfying the time required for the reserved throughput rate and the time required for the reserved forwarding rate, the shorter the time required, the higher the reserved service quality. Therefore, the reserved time label value must be allocated in accordance with the requirements of meeting the high service quality. Therefore, the calculation model of the reserved time label value is shown in formula (3).

[0165] Based on this principle, Figure 3 As shown in Figure 1, the reserved forwarding rate delay of 10ms for completing the rth IO request of user device 1 is lower than the reserved throughput rate delay of 20ms. Therefore, the reserved forwarding rate delay value is used when allocating the reserved time label value: The reserved forwarding rate delay of 10ms for completing the rth IO request of user device 2 is higher than the reserved throughput rate delay of 5ms. Therefore, the reserved throughput rate delay value is used when allocating the reserved time label value:

[0166] like Figure 4 As shown, the principle of the upper limit time label value configuration in the scheduling control algorithm provided in the embodiment of the present application is explained.

[0167] exist Figure 4 In the example, it is assumed that the upper limit forwarding rate IOPS set for user device 1 is 1000 IO requests per second, that is, f1 =100, the delay required to complete a single IO request is 1 / 1 f1 = 1ms, the upper limit throughput is 1000MB per second, that is, l t1 =1000MB / s, the actual length of the current IO request is s1=2MB, then the delay required to complete the current IO request is s1 / l t1 =2ms.

[0168] Assume that the upper limit forwarding rate set for user device 2 is 400 IO requests per second. f2 =400, then the delay required to complete a single IO request is 1 / 1 f2 = 2ms, the upper limit throughput is 800MB per second, that is, l t2 =800MB / s, the actual length of the current IO request is s2 = 1MB, then the delay required to complete the current IO request is s2 / l t2 =1.25ms.

[0169] To complete the current IO request, only one of the upper throughput rate and the upper forwarding rate can be met. The longer the required time, the lower the upper service quality. Therefore, the upper time label value must be allocated according to the requirement of meeting the lower service quality. Therefore, the following calculation model for the upper time label value is given as shown in Equation (4).

[0170] Based on this principle, Figure 4 As shown in the figure, to complete the rth IO request of user device 1, the upper limit forwarding rate delay of 1ms is lower than the upper limit throughput rate delay of 2ms. Therefore, the upper limit throughput rate delay value is used when allocating the upper limit time label value, which is The upper limit forwarding rate delay of 2ms for completing the rth IO request of user device 2 is higher than the upper limit throughput rate delay of 1.25ms. Therefore, the upper limit forwarding rate delay value is used when allocating the upper limit time label value, which is

[0171] The determination of the weighted time tag value and the specific scheduling process can be referred to above. In particular, for the weighted scheduling stage:

[0172] like Figure 5 As shown, in the weight scheduling stage, for user equipment VM v i The upper limit time label value request queue (i.e., L label request queue) is the rth request (the upper limit time label value is ) is scheduled, at this time the user equipment v i All the reserved time label values ​​of the reserved time label value request queue (ie, R label request queue) are greater than the current time t. In order not to affect the constraint scheduling phase, it is necessary to ensure that the user equipment v i The reserved time label value of the request queue increases linearly. Specifically, for user equipment v i The request queue will be All subsequent reserved time tag values ​​are subtracted from the time tag value of the currently scheduled IO request. The reserved time tag value of the previous IO request The difference, ρ i ×min{s i / r ti , 1 / r fi}(equivalent to the target difference mentioned above). For example, Figure 5 When L1 requests scheduling, all reservation labels of the user equipment that follow the L1 request will move forward ρ i ×min{s i / r ti , 1 / r fi} distance.

[0173] In summary, the embodiments of the present application provide solutions to the problems of implementing QoS control in a distributed storage system based on the Dmclock algorithm, including:

[0174] (1) For user device VM v i Set the reserved forwarding rate parameter r fiand the reserved throughput parameter r ti , set the upper limit forwarding rate parameter l fi and the upper limit throughput parameter l ti , and set the weight value w i ;

[0175] (2) User device VM v i To storage server j The IO request sent carries the IO request length s i , the first request number ρ i and the second request number δ i , s i , ρ i and δ i The value is calculated by the user device VM side;

[0176] (3) Storage servers j Optimize Dmclock algorithm for user device VM v i The IO requests are scheduled.

[0177] Specifically, the optimization of the Dmclock algorithm includes label allocation and request scheduling;

[0178] (a) The above label allocation optimization includes:

[0179] For the reserved time label value calculation, the reserved throughput delay s required to complete the current IO request is calculated separately. i / r ti and reserved forwarding rate delay 1 / r fi ;

[0180] Take the above throughput delay s i / r ti The forwarding rate delay is 1 / r fi The minimum value of the two is used to calculate the reserved time label value. The specific calculation model is:

[0181] For the calculation of the upper limit time label value, calculate the upper limit throughput delay s of the current IO request. i / l ti and upper limit forwarding rate delay 1 / l fi ;

[0182] Take the above throughput delay s i / l ti Delay 1 / 1 compared to the above forwarding rate fi The maximum value of the two is used to calculate the upper limit time label value. The specific calculation model is:

[0183] For the calculation of weighted time label values, the specific calculation model is:

[0184] (b) Optimizing the scheduling of the above requests includes:

[0185] In the weight scheduling phase, in order to make VM v from the same user device k The request queue keeps increasing linearly, and when scheduling a request, the user device VM v to which the request belongs is k The R tag value of all subsequent requests in the request queue minus ρ k ×min{s k / r tk , 1 / r fk}.

[0186] In this way, compared with the technical solution for implementing distributed storage service quality control based on the Dmclock algorithm provided by related technologies, the embodiment of the present application optimizes the Dmclock algorithm to implement service quality control of the distributed storage system based on both forwarding rate IOPS and throughput performance.

[0187] The embodiment of the present application provides a scheduling control method, which describes in detail the specific implementation method of the aforementioned embodiment. It can be seen that, based on the preset forwarding rate parameters and the preset throughput parameters, corresponding time label values ​​can be assigned to pending IO requests, thereby achieving reasonable scheduling of batch pending IO requests, and achieving service quality control that takes into account both forwarding rate performance and throughput performance, thereby providing high-quality storage services in various storage business scenarios.

[0188] In yet another embodiment of the present application, see Figure 6 , which shows a schematic diagram of the composition structure of a service device 30 provided in an embodiment of the present application. Figure 6 As shown, the service device 30 includes a determination unit 301, a label unit 302 and a scheduling unit 303, wherein:

[0189] The determining unit 301 is configured to receive a pending input / output (IO) request sent by a user device and determine attribute parameters of the pending IO request; wherein the attribute parameters include at least a preset throughput parameter and a preset forwarding rate parameter;

[0190] The label unit 302 is configured to perform label allocation processing on the pending IO request based on a preset throughput parameter and a preset forwarding rate parameter, and determine a target time label value of the pending IO request;

[0191] The scheduling unit 303 is configured to schedule the IO requests to be processed based on the target time tag values ​​of the IO requests to be processed.

[0192] In some embodiments, the preset forwarding rate parameter includes a reserved forwarding rate parameter and an upper limit forwarding rate parameter, and the preset throughput rate parameter includes a reserved throughput rate parameter and an upper limit throughput rate parameter; the target time label value includes a reserved time label value and an upper limit time label value; the label unit 302 is specifically configured to perform label allocation processing on the to-be-processed IO request according to the reserved forwarding rate parameter and the reserved throughput rate parameter to obtain the reserved time label value of the to-be-processed IO request; and perform label allocation processing on the to-be-processed IO request according to the upper limit forwarding rate parameter and the upper limit throughput rate parameter to obtain the upper limit time label value of the to-be-processed IO request.

[0193] In some embodiments, the attribute parameters also include a data length value; the label unit 302 is further configured to determine a reserved forwarding rate delay and a reserved throughput rate delay; wherein, the reserved forwarding rate delay is calculated based on the reserved forwarding rate parameter, and the reserved throughput rate delay is calculated based on the data length value and the reserved throughput rate parameter; the minimum value of the reserved throughput rate delay and the reserved forwarding rate delay is determined as the target reserved delay; after obtaining the previous reserved time label value and the current time label value, the reserved time label value of the pending IO request is determined based on the target reserved delay, the previous reserved time label value and the current time label value; wherein, the previous reserved time label value refers to the reserved time label value of the previous IO request from the same user device as the pending IO request.

[0194] In some embodiments, the attribute parameters also include a data length value, and the tag unit 302 is further configured to determine an upper limit forwarding rate delay and an upper limit throughput rate delay; wherein, the upper limit forwarding rate delay is calculated based on the upper limit forwarding rate parameter, and the upper limit throughput rate delay is calculated based on the data length value and the upper limit throughput rate parameter; the maximum value of the upper limit throughput rate delay and the upper limit forwarding rate delay is determined as the target upper limit delay; after obtaining the previous upper limit time tag value and the current time tag value, the upper limit time tag value of the pending IO request is determined based on the target upper limit delay, the previous upper limit time tag value and the current time tag value; wherein, the previous upper limit time tag value refers to the upper limit time tag value of the previous IO request from the same user device as the pending IO request. In some embodiments, the attribute parameters also include a weight parameter, and the target time tag value also includes a weight time tag value; the tag unit 302 is further configured to determine a target weight delay; wherein the target weight delay is calculated based on the weight parameter; after obtaining the previous weight time tag value and the current time tag value, the weight time tag value of the pending IO request is determined based on the target weight delay, the previous weight time tag value and the current time tag value; wherein the previous weight time tag value refers to the weight time tag value of the previous IO request from the same user device as the pending IO request.

[0195] In some embodiments, the scheduling unit 303 is specifically configured to determine a pending request set including at least one pending IO request and a current time tag value; determine whether there is at least one first IO request in the pending request set; wherein the reserved time tag value of the first IO request is less than the current time tag value; if there is at least one first IO request in the pending request set, schedule the at least one first IO request according to the respective reserved time tag values ​​of the at least one first IO request.

[0196] In some embodiments, the scheduling unit 303 is further configured to, when there is no first IO request in the set of pending requests, determine whether there is at least one second IO request in the set of pending requests; wherein the upper limit time tag value of the second IO request is less than the current time tag value; and when there is at least one second IO request in the set of pending requests, schedule the at least one second IO request according to the weighted time tag value of each of the at least one second IO request.

[0197] In some embodiments, the scheduling unit 303 is further configured to determine a target time difference value based on the reserved time tag value of the pending IO request and the previous reserved time tag value after the scheduling of the pending IO request is completed; based on the target time difference value, update the reserved time tag value of the target IO request corresponding to the pending IO request; wherein, the target IO request and the pending IO request come from the same user device, and the reserved time tag value of the target IO request is greater than the reserved time tag value of the pending IO request.

[0198] It is understood that in this embodiment, a "unit" can be a portion of a circuit, a portion of a processor, a portion of a program or software, etc., and can also be a module or a non-modular system. Furthermore, the various components in this embodiment can be integrated into a single processing unit, or each unit can exist physically separately, or two or more units can be integrated into a single unit. The aforementioned integrated units can be implemented in the form of hardware or software functional modules.

[0199] If the integrated unit is implemented in the form of a software functional module and is not sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this embodiment, or the part that contributes to the existing technology, or all or part of the technical solution can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes a number of instructions for causing a computer device (which can be a personal computer, server, or network device, etc.) or a processor to execute all or part of the steps of the method of this embodiment. The aforementioned storage medium includes various media that can store program code, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0200] Therefore, this embodiment provides a computer storage medium, which stores a computer program. When the computer program is executed by multiple processors, the steps of the method in any one of the above embodiments are implemented.

[0201] Based on the composition of the above-mentioned service device 30 and the computer storage medium, see Figure 7 , which shows a hardware structure diagram of a service device 30 provided in an embodiment of the present application. Figure 7 As shown, the service device 30 may include: a communication interface 401, a memory 402, and a processor 403; each component is coupled together via a bus device 404. It is understood that the bus device 404 is used to achieve connection and communication between these components. In addition to the data bus, the bus device 404 also includes a power bus, a control bus, and a status signal bus. However, for the sake of clarity, Figure 7 Various buses are labeled as bus devices 404. Among them, the communication interface 401 is used to receive and send signals during the process of sending and receiving information between other external network elements;

[0202] Memory 402, used to store computer programs that can be run on processor 403;

[0203] Processor 403 is configured to, when running the computer program, execute:

[0204] Receive a pending input / output (IO) request sent by a user device, and determine attribute parameters of the pending IO request; wherein the attribute parameters include at least a preset throughput parameter and a preset forwarding rate parameter;

[0205] Based on the preset throughput rate parameter and the preset forwarding rate parameter, label allocation processing is performed on the pending IO request to determine the target time label value of the pending IO request;

[0206] Based on the target time tag value of the pending IO request, the pending IO request is scheduled.

[0207] It is understood that the memory 402 in the embodiment of the present application can be a volatile memory or a non-volatile memory, or can include both volatile and non-volatile memories. Among them, the non-volatile memory can be a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), or a flash memory. The volatile memory can be a random access memory (RAM), which is used as an external cache. By way of example and not limitation, many forms of RAM are available, such as static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDRSDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous link DRAM (SLDRAM), and direct RAM bus random access memory (DRRAM). The memory 402 of the apparatus and methods described herein is intended to include, but is not limited to, these and any other suitable types of memory.

[0208] Processor 403 may be an integrated circuit chip with signal processing capabilities. During implementation, each step of the above method can be completed by hardware integrated logic circuits or software instructions in processor 403. The above-mentioned processor 403 may be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the various methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor may be a microprocessor or any conventional processor. The steps of the method disclosed in the embodiments of this application can be directly implemented and executed by a hardware decoding processor, or by a combination of hardware and software modules in the decoding processor. The software module can be located in a storage medium well-known in the art, such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, etc. The storage medium is located in memory 402, and processor 403 reads the information in memory 402 and, in conjunction with its hardware, completes the steps of the above method.

[0209] It is understood that the embodiments described herein may be implemented using hardware, software, firmware, middleware, microcode, or a combination thereof. For hardware implementation, the processing unit may be implemented in one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), general-purpose processors, controllers, microcontrollers, microprocessors, or other electronic units or combinations thereof for performing the functions of the present application.

[0210] For software implementation, the technology of the present application can be implemented by modules (e.g., procedures, functions, etc.) that perform the functions of the present application. The software code can be stored in a memory and executed by a processor. The memory can be implemented in the processor or external to the processor.

[0211] Optionally, as another embodiment, the processor 403 is further configured to execute the steps of the method in any one of the aforementioned embodiments when running the computer program.

[0212] In yet another embodiment of the present application, see Figure 8 , which shows a schematic diagram of the composition structure of another distributed storage system 50 provided in an embodiment of the present application. Figure 8 As shown, the distributed storage system 50 includes at least a service device 501 and a user device 502. The service device 501 may refer to the service device 30 in any of the aforementioned embodiments, and a communication connection exists between the service device 501 and the user device 502.

[0213] For the distributed storage system 50, since it includes a service device 501 and a user device 502, and the service device 501 can receive the pending IO requests of the user device 502, and assign corresponding time label values ​​to the pending IO requests according to the preset forwarding rate parameters and the preset throughput parameters, and then reasonably schedule the batch pending IO requests, it can achieve service quality control that takes into account both forwarding rate performance and throughput performance, thereby providing high-quality storage services in various storage business scenarios.

[0214] The above are merely preferred embodiments of the present application and are not intended to limit the scope of protection of the present application.

[0215] It should be noted that, in this application, the terms "comprises," "includes," or any other variations thereof are intended to encompass non-exclusive inclusion, such that a process, method, article, or apparatus comprising a series of elements includes not only those elements but also other elements not explicitly listed, or elements inherent to such process, method, article, or apparatus. In the absence of further limitations, an element defined by the phrase "comprising a ..." does not exclude the presence of other identical elements in the process, method, article, or apparatus comprising the element.

[0216] The serial numbers of the above embodiments of the present application are for description only and do not represent the advantages or disadvantages of the embodiments.

[0217] The methods disclosed in the several method embodiments provided in this application can be arbitrarily combined without conflict to obtain new method embodiments.

[0218] The features disclosed in the several product embodiments provided in this application can be arbitrarily combined without conflict to obtain new product embodiments.

[0219] The features disclosed in the several method or device embodiments provided in this application can be arbitrarily combined without conflict to obtain new method embodiments or device embodiments.

[0220] The above are only specific embodiments of the present application, but the scope of protection of this application is not limited thereto. Any changes or substitutions that can be easily conceived by a person skilled in the art within the technical scope disclosed in this application should be included in the scope of protection of this application. Therefore, the scope of protection of this application should be based on the scope of protection of the claims.

Claims

1. A scheduling control method, characterized in that: Applied to a service device, the method includes: Receive a pending input / output (IO) request sent by a user device, and determine attribute parameters of the pending input / output (IO) request; wherein the attribute parameters include at least a preset throughput parameter and a preset forwarding rate parameter; Based on the preset throughput parameter and the preset forwarding rate parameter, performing label allocation processing on the pending input / output (IO) request to determine a target time label value of the pending input / output (IO) request; Scheduling the pending input / output IO requests based on the target time tag values ​​of the pending input / output IO requests; wherein the preset forwarding rate parameter includes a reserved forwarding rate parameter and an upper limit forwarding rate parameter, and the preset throughput parameter includes a reserved throughput parameter and an upper limit throughput parameter; the attribute parameter also includes a data length value and a weight parameter; the target time tag value includes a reserved time tag value and an upper limit time tag value; and the target time tag value also includes a weighted time tag value; performing tag allocation processing on the pending input / output IO requests based on the preset throughput parameter and the preset forwarding rate parameter to determine the target time tag value of the pending input / output IO requests includes: Determining a reserved forwarding rate delay and a reserved throughput rate delay; wherein the reserved forwarding rate delay is calculated based on the reserved forwarding rate parameter, and the reserved throughput rate delay is calculated based on the data length value and the reserved throughput rate parameter, and the reserved forwarding rate delay and the reserved throughput rate delay are used to determine a reserved time tag value of the pending input and output IO request; Determining an upper limit forwarding rate delay and an upper limit throughput rate delay; wherein the upper limit forwarding rate delay is calculated based on the upper limit forwarding rate parameter, and the upper limit throughput rate delay is calculated based on the data length value and the upper limit throughput rate parameter, and the upper limit forwarding rate delay and the upper limit throughput rate delay are used to determine an upper limit time tag value of the pending input / output (IO) request; Determine a target weight delay; wherein the target weight delay is calculated based on the weight parameter, and the target weight delay is used to determine the weight time label value.

2. The scheduling control method according to claim 1, characterized in that: The method further comprises: Determining a minimum value of the reserved throughput rate delay and the reserved forwarding rate delay as a target reserved delay; After obtaining the previous reserved time tag value and the current time tag value, determining the reserved time tag value of the pending input / output (IO) request according to the target reserved delay, the previous reserved time tag value and the current time tag value; The previous reserved time tag value refers to the reserved time tag value of the previous IO request from the same user equipment as the to-be-processed input / output IO request.

3. The scheduling control method according to claim 1, characterized in that: The method further comprises: Determine the maximum value of the upper limit throughput rate delay and the upper limit forwarding rate delay as the target upper limit delay; After obtaining the previous upper limit time tag value and the current time tag value, determining the upper limit time tag value of the pending input / output (IO) request according to the target upper limit delay, the previous upper limit time tag value, and the current time tag value; The previous upper limit time tag value refers to the upper limit time tag value of the previous IO request from the same user equipment as the to-be-processed input / output IO request.

4. The scheduling control method according to claim 1, characterized in that: The method further comprises: After obtaining the previous weighted time tag value and the current time tag value, determining the weighted time tag value of the pending input / output (IO) request according to the target weighted delay, the previous weighted time tag value and the current time tag value; The previous weighted time tag value refers to the weighted time tag value of the previous IO request from the same user device as the to-be-processed input / output IO request.

5. The dispatching control method according to claim 4, characterized in that: The scheduling of the pending input / output (IO) request based on the target time tag value of the pending input / output (IO) request includes: Determining a pending request set including at least one pending input / output (IO) request and a current time tag value; Determine whether there is at least one first IO request in the set of pending requests; wherein the reserved time tag value of the first IO request is less than the current time tag value; When there is at least one first IO request in the set of pending requests, the at least one first IO request is scheduled according to the reserved time tag value of each of the at least one first IO request.

6. The dispatching control method according to claim 5, characterized in that: In a case where the first IO request does not exist in the set of pending requests, the method further includes: Determining whether there is at least one second IO request in the set of pending requests; wherein the upper limit time tag value of the second IO request is less than the current time tag value; In a case where there is at least one second IO request in the set of pending requests, the at least one second IO request is scheduled according to the weighted time tag value of each of the at least one second IO request.

7. The dispatching control method according to claim 6, characterized in that: In a case where the pending input / output (IO) request is determined to be a second IO request, the method further includes: After the scheduling of the pending input / output (IO) request is completed, determining a target time difference according to the reserved time tag value of the pending input / output (IO) request and the previous reserved time tag value; Based on the target time difference, updating the reserved time tag value of the target IO request corresponding to the pending input / output IO request; The target IO request and the pending IO request come from the same user device, and the reserved time tag value of the target IO request is greater than the reserved time tag value of the pending IO request.

8. A service device, characterized in that: The service device includes a determination unit, a label unit and a scheduling unit; wherein, The determining unit is configured to receive a pending input / output (IO) request sent by a user device and determine attribute parameters of the pending input / output (IO) request; wherein the attribute parameters include at least a preset throughput parameter and a preset forwarding rate parameter; The label unit is configured to perform label allocation processing on the pending input / output (IO) request based on the preset throughput parameter and the preset forwarding rate parameter, and determine a target time label value for the pending input / output (IO) request; The scheduling unit is configured to schedule the pending input / output (IO) request based on the target time tag value of the pending input / output (IO) request; wherein the preset forwarding rate parameter includes a reserved forwarding rate parameter and an upper limit forwarding rate parameter, the preset throughput rate parameter includes a reserved throughput rate parameter and an upper limit throughput rate parameter; the attribute parameter further includes a data length value and a weight parameter; the target time tag value includes a reserved time tag value and an upper limit time tag value; the target time tag value also includes a weighted time tag value; the tag unit is configured to: Determining a reserved forwarding rate delay and a reserved throughput rate delay; wherein the reserved forwarding rate delay is calculated based on the reserved forwarding rate parameter, and the reserved throughput rate delay is calculated based on the data length value and the reserved throughput rate parameter, and the reserved forwarding rate delay and the reserved throughput rate delay are used to determine a reserved time tag value of the pending input and output IO request; Determining an upper limit forwarding rate delay and an upper limit throughput rate delay; wherein the upper limit forwarding rate delay is calculated based on the upper limit forwarding rate parameter, and the upper limit throughput rate delay is calculated based on the data length value and the upper limit throughput rate parameter, and the upper limit forwarding rate delay and the upper limit throughput rate delay are used to determine an upper limit time tag value of the pending input / output (IO) request; Determine a target weight delay; wherein the target weight delay is calculated based on the weight parameter; the target weight delay is used to determine the weight time label value.

9. A service device, characterized in that: The service device includes a memory and a processor; wherein, The memory is used to store a computer program that can be run on the processor; The processor is configured to execute the steps of the method according to any one of claims 1 to 7 when running the computer program.

10. A computer storage medium, characterized in that The computer storage medium stores a computer program, and when the computer program is executed, the steps of the method according to any one of claims 1 to 7 are implemented.

Images