HK1231197B - Workload-aware i/o scheduler in software-defined hybrid storage system - Google Patents

Description

Workload-aware input/output scheduler in software-defined hybrid storage systems

Technical Field

The present invention relates to an input/output scheduler, and in particular to a workload-aware input/output scheduler in a software-defined hybrid storage system.

Background Art

Computer operating systems use an I/O scheduler to determine the order in which block I/O jobs are submitted to storage volumes. Depending on the purpose, an I/O scheduler might aim to minimize the time spent on disk seeks, prioritize processing of certain I/O requests, allocate a portion of disk bandwidth to each running process, and/or ensure that certain I/O requests begin executing before a specific deadline. For example, the deadline scheduler within the Linux kernel guarantees a service start time for requests by imposing a deadline on all I/O jobs to prevent request starvation. Thus, by using separate I/O queues, the deadline scheduler favors reads over writes. It works well for database workloads. Another example is the Complete Fair Queuing scheduler. The Complete Fair Queuing scheduler places simultaneous requests submitted by a process into a number of per-process queues and then allocates time slices to each queue for disk access. Consequently, the Complete Fair Queuing scheduler is well-suited for continuous reads of video or audio streams and general host workloads.

The above-mentioned scheduler is proposed based on improving the performance of a hard disk or a storage system composed of hard disks. The following are some characteristics of a hard disk storage system: First, multiple input/output requests (both read and write) may be merged into a single request, and the single request is processed under the movement of a read/write head. Therefore, the number of times the read/write head moves can be reduced, thereby increasing the throughput of the hard disk. Second, the input/output requests are classified to improve the seek time by reducing the back and forth movement of the hard disk read/write head. Based on these characteristics, the input/output requests queued for future processing can be merged and classified. When different schedulers are used, workloads with different characteristics can be processed with better performance.

A mainstream storage system, especially for cloud systems, uses a mix of SSDs and HDDs, rather than just HDDs, so the latest schedulers may not be able to achieve the goals they are required to achieve when they are installed in the storage system. SSDs have distinct characteristics that are different from HDDs, which are described below. First, SSDs do not need to merge and classify SSD input/output requests, which implies that there is no time required for merging and classification. Input/output requests should be transmitted to the SSD at the fastest speed. Second, because many modern SSDs have multiple channels, SSD input/output requests may be processed in parallel, and the multiple channels can accommodate multiple input/output requests at the same time. If the storage system to which the scheduler is applied is a software-defined hybrid storage system, it will be more complicated to handle the scheduler requirements. Taking into account the presence of SSDs, it is necessary to change and improve the existing scheduler.

Furthermore, upon further investigation, workload traffic characteristics are another important issue. Any workload may have certain characteristics that differ from other workloads. These characteristics may include input/output patterns (sequential or random), read/write ratios, and SSD cache hits. For example, an online transaction processing (OLTP) database workload has a random input/output pattern, a read/write ratio greater than 1, and a small storage block size; while a MongoDB workload has a sequential input/output pattern, a read/write ratio less than 1, and a large storage block size. If these two workloads are executed on the same hybrid storage system, recently developed schedulers cannot meet the performance requirements of both in the Service Level Agreements (SLAs), or at least a noisy neighbor problem may exist, affecting these workloads.

Several existing technologies offer solutions to these requirements, one example of which is disclosed in U.S. Patent No. 8,756,369. In this patent, a storage system includes a command classifier for determining a target storage device for at least one SSD command and one HDD command, placing the command in an SSD standby queue if the SSD command is destined for an SSD storage device of the storage system, and placing the HDD command in a HDD standby queue if the HDD command is destined for a HDD storage device of the storage system. The storage system also includes an SSD standby queue for queuing SSD commands destined for the SSD storage device and a HDD standby queue for queuing HDD commands destined for the HDD storage device. Simultaneously, a command scheduler retrieves HDD and SSD commands from the standby queues and places them in a command processor. Based on the availability level of a processing queue of a target device corresponding to the particular command, the command scheduler places a particular (HDD or SSD) command from its respective standby queue into the command processor. Then, the command processor gives the storage commands to the processing queue.

The storage system provided by U.S. Patent No. 8,756,369 distinguishes between hard disk commands (input/output requests) and solid-state drive commands, which facilitates hardware operations for a workload. However, if applied to multiple workloads, the storage system may not operate as it is designed to. On the other hand, for various workloads running on the storage system, there is no suitable way to coordinate requests from each workload so that each workload can meet service level agreements or quality of service requirements. Therefore, a workload-aware input/output scheduler is needed in the software-defined hybrid storage system, which can be used to solve the above problems.

Summary of the Invention

In order to meet the above requirements, the present invention provides a workload-aware input and output scheduler in a software-defined hybrid storage (SDHS) system, wherein the software-defined hybrid storage includes at least a hard disk and a solid-state drive. The workload-aware input/output scheduler in the software-defined hybrid storage system includes a queue management module, a workload characteristic database and a traffic monitoring module. The queue management module is used to manage queues, read requests and write requests. The queue management module includes a request receiving submodule, a request control submodule and a request scheduling submodule, wherein the request receiving submodule is used to temporarily store the read requests and write requests; the request control submodule is used to create workload queues, dynamically configure the workload queues according to a scheduler configuration function and arrange the read requests and write requests to the workload queues; the request scheduling submodule is used to create device queues and schedule each read request or write request from the workload queue to a specific device queue; the workload characteristic database is used to store the characteristics of the workload for access; the traffic monitoring module is used to monitor and continuously record the value of a performance parameter of the software-defined hybrid storage system, and provide the values of the performance parameters to the request control submodule.

The scheduler configuration function calculates a queue depth and a waiting time for each workload queue based on the characteristics provided by the workload characteristic database and the values of the received performance parameters, so as to adjust the performance parameter value of the software-defined hybrid storage system to fall between a performance guarantee value and a performance adjustment value set for the performance parameter in the future.

The workload-aware input/output scheduler in the above-mentioned software-defined hybrid storage system may further include a traffic model module, which is used to model the storage traffic of those requests from the workload and provide predicted storage traffic of those characteristics at a specific time point in the future.

Preferably, the characteristics are read/write ratio, merge ratio, SSD hit rate, and storage block size. The performance parameter is input/output operations per second, throughput, latency, or a combination of the three. The performance guarantee value and performance adjustment value are defined by the service level agreement (SLA) or quality of service (QoS) requirements of the workload. Each workload queue is categorized as deep, medium, or shallow, and each waiting time is categorized as long latency, medium latency, or short latency, wherein the queue depth of a deep workload queue accommodates more read requests or write requests than the queue depth of a medium workload queue; the queue depth of a medium workload queue accommodates more read requests or write requests than the queue depth of a shallow workload queue; the storage block size is a medium size; the long latency is longer than the medium latency; and the medium latency is longer than the short latency.

In one example, if the received input/output operations per second or throughput value is close to the respective performance adjustment value, the received latency value is close to or lower than the performance guarantee value, the read/write ratio is greater than or equal to 1, and the storage block size is greater than or equal to the medium size, then the queue depth of the workload queue is set to the medium level, and the waiting time for each workload queue is set to short latency.

In another example, if the received input/output operations per second or throughput value is close to the respective performance adjustment value, the received latency value is close to or lower than the guaranteed value, the read/write ratio is greater than or equal to 1, and the storage block size is less than the medium size, then the queue depth of the workload queue is set to deep level and the waiting time for each workload queue is set to medium delay.

In another example, if the received input/output operations per second or throughput value is close to the respective performance adjustment value, the received latency value is close to or lower than the performance guarantee value, and the read/write ratio is less than 1, the queue depth of the workload queue is set to a medium level, and the waiting time for each workload queue is set to a short delay.

In another example, if the received input/output operations per second or throughput value is close to or lower than the respective performance guarantee value, the received latency value is close to or lower than the performance guarantee value, the read/write ratio is greater than or equal to 1, and the storage block size is greater than or equal to the medium size, then the queue depth of the workload queue is set to shallow, and the waiting time for each workload queue is set to short delay.

In another example, if the received input/output operations per second or throughput value is close to or lower than the respective performance guarantee value, the received latency value is close to or lower than the performance guarantee value, the read/write ratio is greater than or equal to 1, and the storage block size is less than the medium size, then the queue depth of the workload queue is set to a medium level, and the waiting time for each workload queue is set to a medium delay.

In another example, if the received input/output operations per second or throughput value is close to or lower than the respective performance guarantee values, the received latency value is close to or lower than the performance guarantee value, and the read/write ratio is less than 1, the queue depth of the workload queue is set to shallow, and the waiting time for each workload queue is set to short delay.

In another example, if the received input/output operations per second or throughput value is close to the respective performance adjustment value, the received latency value is not close to or lower than the performance guarantee value, the read/write ratio is greater than or equal to 1, and the storage block size is greater than or equal to the medium size, then the queue depth of the workload queue is set to the medium level, and the waiting time for each workload queue is set to the medium delay.

In another example, if the received input/output operations per second or throughput value is close to the respective performance adjustment value, the received latency value is not close to or lower than the performance guarantee value, the read/write ratio is greater than or equal to 1, and the storage block size is less than the medium size, then the queue depth of the workload queue is set to deep level, and the waiting time for each workload queue is set to long delay.

In another example, if the received input/output operations per second or throughput value is close to the respective performance adjustment value, the received latency value is not close to or lower than the performance guarantee value, the read/write ratio is less than 1, and the storage block size is greater than or equal to the medium size, then the queue depth of the workload queue is set to the medium level, and the waiting time for each workload queue is set to short latency.

In another example, if the received input/output operations per second or throughput value is close to the respective performance adjustment value, the received latency value is not close to or lower than the performance guarantee value, the read/write ratio is less than 1, and the storage block size is less than the medium size, then the queue depth of the workload queue is set to the medium level, and the waiting time for each workload queue is set to the medium delay.

In another example, if the received input/output operations per second or throughput value is close to or lower than the respective performance guarantee value, the received latency value is not close to or lower than the performance guarantee value, and the storage block size is greater than or equal to the medium size, then the queue depth of the workload queue is set to shallow, and the waiting time for each workload queue is set to short delay.

In another example, if the received input/output operations per second or throughput value is close to or lower than the respective performance guarantee values, the received latency value is not close to or lower than the performance guarantee value, and the storage block size is smaller than the medium size, then the queue depth of the workload queue is set to shallow, and the waiting time for each workload queue is set to medium delay.

In another example, if the SSD hit rate increases, the queue depth of the workload queue remains the same or becomes shallower, and the waiting time for each workload queue remains the same or becomes shorter; otherwise, the queue depth of the workload queue remains the same or becomes deeper, and the waiting time for each workload queue remains the same or becomes longer.

In another example, if the merge ratio increases, the queue depth of the workload queue remains the same or becomes shallower, and the waiting time for each workload queue remains the same or becomes shorter, otherwise the queue depth of the workload queue remains the same or becomes deeper, and the waiting time for each workload queue remains the same or becomes longer.

Preferably, the median size is 8KB.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG1 is a schematic diagram of the structure of a storage system of a workload-aware input/output scheduler in a software-defined hybrid storage system according to the present invention;

FIG2 is a schematic diagram of the operation of a request control submodule and a request scheduling submodule;

Figure 3 shows the complete picture of the I/O scheduler workload.

Explanation of the accompanying drawings: 1-remote user; 5-cloud storage system; 10-scheduler; 50-host; 55-file system; 60-device driver module; 61-solid state drive; 62-solid state drive; 63-hard disk; 64-hard disk; 100-queue management module; 101-request receiving submodule; 102-request control submodule; 103-request scheduling submodule; 110-workload characteristic database; 120-traffic monitoring module; 130-traffic model module; W1-workload queue group; W2-workload queue group; Wn-workload queue group; QW1-queue depth; QW2-queue depth; QWn-queue depth; QS1-first solid state drive device queue; QS2-second solid state drive device queue; QH1-first hard disk device queue; QH2-second hard disk device queue.

DETAILED DESCRIPTION

The present invention will be described more specifically with reference to the following embodiments.

As shown in Figure 1, it describes an embodiment of the present invention. The cloud storage system 5 shown in Figure 1 is a software-defined hybrid storage system. This software-defined hybrid storage enables the rapid creation, removal and management of storage systems based on principles under the cloud architecture. Software-defined hybrid storage usually separates software from the storage hardware it manages in the form of storage virtualization. Unlike general software-defined storage, the software-defined hybrid storage system includes more than one disk type. It is usually composed of two types of disks, such as hard disks and solid-state drives, to meet the needs of workloads with different characteristics. Therefore, the cloud storage system 5 can also be applied to many workloads. These workloads can be an online transaction processing database, a video streaming service, a virtual desktop infrastructure environment, an email server, a backup server or a file server. All services or architectures that use software-defined hybrid storage as a storage unit are workloads in accordance with the spirit of the present invention.

Cloud storage system 5 receives read or write requests from many users on the network. To simplify the description of this invention, a single remote user 1 is used to represent all users. Fundamentally, the input/output operations of cloud storage system 5 are the same for all users, but the processing priority and response latency for each workload vary in different situations. When reading this embodiment, it should be considered that many remote users 1 are issuing read/write requests to cloud storage system 5 and simultaneously awaiting responses.

A workload-aware input/output scheduler 10 is installed in the cloud storage system 5 and is an important part of the present invention. The scheduler 10 is workload-aware because it can distinguish the workload of the request source. The scheduler 10 includes a queue management module 100, a workload characteristic database 110, a traffic monitoring module 120, and a traffic model module 130. Each of these will be described in detail later. It should be noted that the input/output scheduler 10 can be executed in the form of software on a host 50 of the cloud storage system 5, or it can be a hardware device that works for the cloud storage system 5 within the host 50. Alternatively, the input/output scheduler 10 can be partially implemented by hardware, while the rest is driven by software, which is not limited by the present invention.

The main function of the queue management module 100 is to manage queues, read requests, and write requests. The aforementioned read requests and write requests originate from a file system 55 of the host 50. The queue management module 100 includes three important submodules: a request receiving submodule 101, a request control submodule 102, and a request scheduling submodule 103. The request receiving submodule 101 temporarily stores read and write requests from the file system 55. These requests are then classified according to workload and assigned to a write queue and a read queue within a workload queue group. The write queue sorts write requests for a specific workload, while the read queue sequentially stores read requests for the same workload. It should be emphasized that many workloads use the cloud storage system 5 simultaneously, and there are also many workload queue groups W1 to Wn shown in FIG. 2 .

The request control submodule 102 is responsible for creating workload queues (write queues and read queues) for each workload request. After the workload queues are established, the request control submodule 102 can further dynamically configure the workload queues according to a scheduler configuration function. The scheduler configuration function determines the depth of the workload queues and the length of time each request waits for a merge opportunity, which will be described in detail later. Therefore, the request control submodule 102 schedules read and write requests into the corresponding workload queues.

The request scheduling submodule 103 is responsible for creating device queues. Each device queue contains requests (read and/or write) for a specific device, namely, solid-state drives 61, 62 or hard disks 63, 64. The requests can come from a workload queue group or certain workload queue groups. The request scheduling submodule 103 schedules each read request or write request from a workload queue to a specific device queue. If other queued requests have been processed before a request, the request will be processed next. In some host 50 designs, scheduling can be achieved by triggering the driver of the corresponding storage device through a device driver module 60. The request scheduling submodule 103 provides an excellent function that other schedulers cannot achieve. It separates requests to the hard disk from requests to the solid-state drive. As a result, requests to the solid-state drive can be executed directly without having to wait in the queue with other requests to the hard disk, and the performance of the cloud storage system 5 can be improved.

The workload characteristics database 110 stores the characteristics of each workload for access purposes. These characteristics are factors used by the scheduler configuration function to determine the queue depth and waiting time. According to the present invention, these characteristics are the read/write ratio, the solid-state drive hit rate, the merge ratio, and the storage block size. The read/write ratio is the ratio of the number of read requests to the number of write requests for a workload. For a workload, it usually has a specific usage pattern, with the number of read requests being greater than the number of write requests or the number of write requests being greater than the number of read requests. For some special cases, a workload, such as a backup server, may have write requests but no read requests.

The SSD hit rate refers to the frequency with which the SSDs in the cloud storage system 5 are accessed, regardless of the workload from which these requests originate. The number or space of SSDs used for each workload may vary depending on workload usage. Therefore, the SSD hit rate for each workload is constantly changing. If the SSD hit rate increases, the queue depth of the workload queue may remain the same or become shallower, and the wait time for each workload queue may remain the same or become shorter. Conversely, the queue depth of the workload queue may remain the same or become deeper, and the wait time for each workload queue may remain the same or become longer. Maintaining or changing the queue depth or wait time depends on the degree of increase/decrease. The threshold between maintaining and changing, as well as the magnitude of the change, can be set before the cloud storage system 5 goes live. The aforementioned method is a criterion for formulating rules, and quantitative descriptions such as "shallow," "short," "deep," and "long" will be explained later. Comparisons are used to illustrate increases or decreases relative to existing levels.

The read/write ratio is an indicator of the read/write pattern. The merge ratio only counts accesses to the hard drive. It is the ratio of requests that are merged with other requests (a change in processing priority) during the same movement of the read/write head. For example, at the beginning of a fixed time limit (ta), there are 10 hard drive read requests in the queue. At the end of the time limit (tb), the requests are merged, resulting in 7 requests in the queue. The merge ratio at tb is 0.3, which is derived from the following formula:

where t _b > t _a

r(t) represents the function of the number of requests in a queue at time t. The higher the merge ratio, the greater the throughput of the disk (in this example, it is greater than 30%). However, if the request waits long enough to obtain maximum throughput, the latency may become longer, and longer latency may result in a poor user experience. For a workload, its merge ratio may also change over time. If the merge ratio increases, the queue depth of the workload queue may remain the same or become shallower, and the wait time for each workload queue may remain the same or become shorter. Otherwise, the queue depth of the workload queue may remain the same or become deeper, and the wait time for each workload queue may remain the same or become longer. Similarly, quantitative descriptions such as "shallow," "short," "deep," and "long" will be explained later. Comparisons are used to illustrate increases or decreases relative to existing levels.

The block size is the basic unit of storage space in a storage device, whether a hard drive or solid-state drive. It can range from 4KB or less to 16MB or more. Generally speaking, 8KB is the most common medium-sized block size. As storage device technology evolves, this medium-sized block size will increase. For illustrative purposes, this specification uses 8KB as the medium-sized block size; however, this does not limit the present invention. The scheduler configuration function uses different strategies for determining queue depth and wait time for different block sizes and conditions, as explained below.

The traffic monitoring module 120 can monitor and continuously record the value of a performance parameter of the cloud storage system 5, and can also provide the value of the performance parameter to the request control submodule 102. The performance parameter can be the number of input and output operations per second, throughput, latency, or a combination of the three. The traffic modeling module 130 is used to model the storage traffic from workload requests and provide a prediction of storage traffic with certain characteristics at a specific time point in the future. The data used for modeling comes from the traffic monitoring module 120. Any suitable method, algorithm, or module can be applied, and it is preferred to use a storage device traffic model provided by the same inventor in U.S. patent application No. 14/290,533, which can be used as a common reference for the same technology. The modeled storage traffic from workload requests and the predicted value of the storage traffic can be provided to the request control submodule 102 for reference in preparing for the configuration of future workload queues and waiting times.

The following describes the operation of the scheduler configuration function using examples of all scenarios. The scheduler configuration function calculates the queue depth and wait time for each workload queue based on the characteristics provided by the workload characteristics database and the received performance parameter values. Therefore, the scheduler configuration function can adjust the performance parameter value of the cloud storage system 5 so that it falls between a performance guarantee value and a performance adjustment value set for the performance parameter in the future. The aforementioned performance guarantee value and performance adjustment value are defined by the workload's service level agreement or quality of service requirements. Each workload queue is categorized as deep, medium, or shallow. Each wait time is categorized as long, medium, or short latency.

According to the present invention, there are no absolute delimiters for each workload queue classification, just as there are categorized wait times during operation. A guideline is that the queue depth of a deep workload queue should accommodate more read or write requests than the queue depth of a medium workload queue; the queue depth of a medium workload queue should accommodate more read or write requests than the queue depth of a shallow workload queue; and the storage block size should be medium. Similarly, long latency is longer than medium latency, which in turn is longer than short latency.

As mentioned above, there are many workload conditions that affect the scheduler configuration function to determine the queue depth and wait time. All conditions are disclosed below. In one embodiment, the cloud storage system 5 supports video streaming, online transaction processing databases, and mail servers. These workloads are for illustration only and do not limit the application of the present invention. Workloads other than the above three can be used. Video streaming is a serial input/output type with a larger number of read requests than write requests, requiring a storage block size greater than or equal to 8K, generating input/output operations per second or throughput values close to their respective performance adjustment values, and having a latency close to or lower than the performance guarantee value of the latency. As shown in Figure 2, a queue depth QW1 of the workload queue in the workload queue group W1 is set to a medium level (5), and the latency for each workload queue is set to a short latency (20ms). The request scheduling submodule 103 arranges requests from the workload queue group W1 to a first solid-state drive device queue QS1 for the solid-state drive 61 and a first hard disk device queue QH1 for the hard disk 63.

The online transaction processing database is a random input/output type, with the same number of read/write requests or more read requests than write requests, requiring a storage block size greater than or equal to 8K, generating input/output operations per second or throughput values close to or lower than their respective performance guarantees, and having a latency close to or lower than the performance guarantee value of the latency. A queue depth QW2 of the workload queue in the workload queue group W2 is set to a shallow level (2), and the waiting time for each workload queue is set to a short delay (20ms). The request scheduling submodule 103 arranges requests from the workload queue group W2 to a first solid-state drive device queue QS1 for the solid-state drive 61 and a second solid-state drive device queue QS2 for the solid-state drive 62.

The mail server is a random input/output type, with a larger number of read requests than write requests (or even the same number), requiring a storage block size of less than 8K, generating input/output operations per second or throughput values close to their respective performance adjustment values, and having a latency that is not close to or lower than the performance guarantee value of the latency. A queue depth QWn of the workload queues in the workload queue group Wn is set to a deep level (7), and the waiting time for each workload queue is set to a long delay (100ms). The request scheduling submodule 103 arranges requests from the workload queue group Wn to the first hard disk device queue QH1 for hard disk 63 and the second hard disk device queue QH2 for hard disk 64.

The complete combination of workload scenarios is shown in Figure 3. Clearly, video streaming, online transaction processing database, and mail server are scenarios 1, 5, and 10, respectively. The remaining scenarios are described below.

For condition No. 2, if the received input/output operations per second or throughput value is close to the respective performance adjustment value, the received latency value is close to or lower than the performance guarantee value, the read/write ratio is greater than or equal to 1, and the storage block size is less than the medium size, then the queue depth of the workload queue is set to deep level, and the waiting time for each workload queue is set to medium latency.

For condition No. 3, if the received input/output operations per second or throughput values are close to the respective performance adjustment values, the received latency values are close to or lower than the performance guarantee values, the read/write ratio is less than 1, and the storage block size is greater than or equal to medium size, then the queue depth of the workload queue is set to medium level, and the waiting time for each workload queue is set to short latency.

For condition No. 4, if the received input/output operations per second or throughput values are close to the respective performance adjustment values, the received latency values are close to or lower than the performance guarantee values, the read/write ratio is less than 1, and the storage block size is less than medium, then the queue depth of the workload queue is set to medium level, and the waiting time for each workload queue is set to short latency.

For condition No. 6, if the received input/output operations per second or throughput value is close to or lower than the respective performance guarantee value, the received latency value is close to or lower than the performance guarantee value, the read/write ratio is greater than or equal to 1, and the storage block size is less than the medium size, then the queue depth of the workload queue is set to the medium level, and the waiting time for each workload queue is set to medium latency.

For condition No. 7, if the received input/output operations per second or throughput value is close to or lower than the respective performance guarantee value, the received latency value is close to or lower than the performance guarantee value, the read/write ratio is less than 1, and the storage block size is greater than or equal to medium, then the queue depth of the workload queue is set to shallow and the waiting time for each workload queue is set to short latency.

For condition No. 8, if the received input/output operations per second or throughput values are close to or lower than the respective performance guarantee values, the received latency values are close to or lower than the performance guarantee values, the read/write ratio is less than 1, and the storage block size is less than medium, then the queue depth of the workload queue is set to shallow and the waiting time for each workload queue is set to short latency.

For condition No. 9, if the received values of the number of input and output operations per second or throughput are close to the respective performance adjustment values, the received latency values are not close to or lower than the performance guarantee values, the read/write ratio is greater than or equal to 1, and the storage block size is greater than or equal to medium size, then the queue depth of the workload queue is set to medium level, and the waiting time for each workload queue is set to medium latency.

For condition No. 11, if the received values of the number of input and output operations per second or throughput are close to the respective performance adjustment values, the received latency values are not close to or lower than the performance guarantee values, the read/write ratio is less than 1, and the storage block size is greater than or equal to medium size, then the queue depth of the workload queue is set to medium level, and the waiting time for each workload queue is set to short latency.

For condition No. 12, if the received values of the number of input and output operations per second or throughput are close to the respective performance adjustment values, the received latency values are not close to or lower than the performance guarantee values, the read/write ratio is less than 1, and the storage block size is less than the medium size, then the queue depth of the workload queue is set to the medium level, and the waiting time for each workload queue is set to the medium latency.

For condition No. 13, if the received input/output operations per second or throughput value is close to or lower than the respective performance guarantee value, the received latency value is not close to or lower than the performance guarantee value, the read/write ratio is greater than or equal to 1, and the storage block size is greater than or equal to medium, then the queue depth of the workload queue is set to shallow and the waiting time for each workload queue is set to short latency.

For condition No. 14, if the received I/O operations per second or throughput values are close to or below their respective performance guarantees, the received latency values are not close to or below their respective performance guarantees, the read/write ratio is greater than or equal to 1, and the storage block size is less than medium, then the queue depth of the workload queue is set to shallow and the waiting time for each workload queue is set to medium latency.

For condition No. 15, if the received values of I/O operations per second or throughput are close to or lower than the respective performance guarantee values, the received latency values are not close to or lower than the performance guarantee values, the read/write ratio is less than 1, and the storage block size is greater than or equal to medium, then the queue depth of the workload queue is set to shallow and the waiting time for each workload queue is set to short latency.

For condition 16, if the received I/O operations per second or throughput values are close to or below their respective performance guarantees, the received latency values are not close to or below their respective performance guarantees, the read/write ratio is less than 1, and the storage block size is less than medium, then the queue depth of the workload queue is set to shallow and the waiting time for each workload queue is set to medium latency.

Although the present invention has been disclosed above in terms of embodiments, they are not intended to limit the present invention. Anyone with ordinary knowledge in the technical field may make slight changes and modifications without departing from the spirit and scope of the present invention. Therefore, the scope of protection of the present invention shall be determined by the scope of the claims of this case.

Claims (21)

1. A workload-aware input/output scheduler in a software-defined hybrid storage system, the software-defined hybrid storage system comprising at least one hard disk and one solid-state drive, characterized in that the workload-aware input/output scheduler in the software-defined hybrid storage system includes a queue management module, a workload characteristic database, and a traffic monitoring module, wherein: This queue management module manages queues, read requests, and write requests. It includes a request receiving submodule, a request control submodule, and a request scheduling submodule. The request receiving submodule is used to temporarily store these read and write requests; The request control submodule is used to create workload queues, dynamically configure these workload queues according to a scheduler configuration function, and schedule read and write requests to these workload queues; This request scheduling submodule is used to create device queues and schedule each read or write request from the workload queue to a specific device queue; This workload characteristics database is used to store the characteristics of workloads for access. The traffic monitoring module is used to monitor and continuously record the value of a performance parameter of the software-defined hybrid storage system, and provide the value of these performance parameters to the request control submodule. The scheduler configuration function calculates a queue depth and a waiting time for each workload queue based on the characteristics provided by the workload characteristic database and the received performance parameter values, in order to adjust the performance parameter values of the software-defined hybrid storage system so that they fall between a performance guarantee value and a performance adjustment value set for the performance parameters in the future. 2. The workload-aware input/output scheduler in a software-defined hybrid storage system according to claim 1, characterized in that it further comprises a traffic model module for modeling the storage traffic of the requests from the workload and providing a predicted storage traffic of the characteristics at a specific future point in time. 3. The workload-aware input/output scheduler in the software-defined hybrid storage system according to claim 1, wherein the characteristics are read/write ratio, merge ratio, solid-state drive hit rate, and storage block size. 4. The workload-aware input/output scheduler in a software-defined hybrid storage system according to claim 3, wherein the performance parameter is the number of input/output operations per second, throughput, latency, or a combination of the three. 5. The workload-aware input/output scheduler in a software-defined hybrid storage system according to claim 3, wherein the performance guarantee value and the performance adjustment value are defined by the service level protocol or quality of service requirements of the workload. 6. The workload-aware input/output scheduler in a software-defined hybrid storage system according to claim 4, characterized in that each workload queue is classified as deep, medium, or shallow, and each latency is classified as long latency, medium latency, or short latency, wherein the queue depth of the deep workload queue accommodates more read or write requests than the queue depth of the medium workload queue; the queue depth of the medium workload queue accommodates more read or write requests than the queue depth of the shallow workload queue; the storage block size is a medium size; the long latency is longer than the medium latency; and the medium latency is longer than the short latency. 7. The workload-aware input/output scheduler in the software-defined hybrid storage system according to claim 6, characterized in that, if the received input/output operations per second or throughput value is close to its respective performance adjustment value, the received latency value is close to or lower than the performance guarantee value, the read/write ratio is greater than or equal to 1, and the storage block size is greater than or equal to the medium size, then the queue depth of the workload queue is set to a medium level, and the waiting time for each workload queue is set to a short latency. 8. The workload-aware input/output scheduler in the software-defined hybrid storage system according to claim 6, characterized in that, if the received input/output operations per second or throughput value is close to its respective performance adjustment value, the received latency value is close to or lower than the guaranteed value, the read/write ratio is greater than or equal to 1, and the storage block size is less than the medium size, then the queue depth of the workload queue is set to deep, and the waiting time for each workload queue is set to medium latency. 9. The workload-aware input/output scheduler in the software-defined hybrid storage system according to claim 6, characterized in that, if the received input/output operations per second or throughput value is close to its respective performance adjustment value, the received latency value is close to or lower than the performance guarantee value, and the read/write ratio is less than 1, then the queue depth of the workload queue is set to a medium level, and the waiting time for each workload queue is set to a short latency. 10. The workload-aware input/output scheduler in a software-defined hybrid storage system according to claim 6, characterized in that, if the received input/output operations per second or throughput value is close to or lower than its respective performance guarantee value, the received latency value is close to or lower than the performance guarantee value, the read/write ratio is greater than or equal to 1, and the storage block size is greater than or equal to the medium size, then the queue depth of the workload queue is set to shallow, and the waiting time for each workload queue is set to short latency. 11. The workload-aware input/output scheduler in a software-defined hybrid storage system according to claim 6, characterized in that, if the received input/output operations per second or throughput value is close to or lower than its respective performance guarantee value, the received latency value is close to or lower than the performance guarantee value, the read/write ratio is greater than or equal to 1, and the storage block size is less than the medium size, then the queue depth of the workload queue is set to a medium level, and the waiting time for each workload queue is set to a medium latency. 12. The workload-aware input/output scheduler in the software-defined hybrid storage system according to claim 6, characterized in that, if the received input/output operation count or throughput per second is close to or lower than its respective performance guarantee value, the received latency value is close to or lower than the performance guarantee value, and the read/write ratio is less than 1, then the queue depth of the workload queue is set to shallow level, and the waiting time for each workload queue is set to short latency. 13. The workload-aware input/output scheduler in a software-defined hybrid storage system according to claim 6, characterized in that, if the received input/output operations per second or throughput value is close to its respective performance adjustment value, the received latency value is not close to or lower than the performance guarantee value, the read/write ratio is greater than or equal to 1, and the storage block size is greater than or equal to the medium size, then the queue depth of the workload queue is set to a medium level, and the waiting time for each workload queue is set to a medium delay. 14. The workload-aware input/output scheduler in a software-defined hybrid storage system according to claim 6, characterized in that, if the received input/output operations per second or throughput value is close to its respective performance adjustment value, the received latency value is not close to or lower than the performance guarantee value, the read/write ratio is greater than or equal to 1, and the storage block size is smaller than the medium size, then the queue depth of the workload queue is set to deep, and the waiting time for each workload queue is set to long latency. 15. The workload-aware input/output scheduler in a software-defined hybrid storage system according to claim 6, characterized in that, if the received input/output operations per second or throughput value is close to its respective performance adjustment value, the received latency value is not close to or lower than the performance guarantee value, the read/write ratio is less than 1, and the storage block size is greater than or equal to the medium size, then the queue depth of the workload queue is set to a medium level, and the waiting time for each workload queue is set to a short latency. 16. The workload-aware input/output scheduler in a software-defined hybrid storage system according to claim 6, characterized in that, if the received input/output operations per second or throughput value is close to its respective performance adjustment value, the received latency value is not close to or lower than the performance guarantee value, the read/write ratio is less than 1, and the storage block size is less than the medium size, then the queue depth of the workload queue is set to a medium level, and the waiting time for each workload queue is set to a medium delay. 17. The workload-aware input/output scheduler in a software-defined hybrid storage system according to claim 6, characterized in that, if the received value of the number of input/output operations per second or the throughput is close to or lower than their respective performance guarantee values, the received latency value is not close to or lower than the performance guarantee values, and the storage block size is greater than or equal to the medium size, then the queue depth of the workload queue is set to shallow, and the waiting time for each workload queue is set to short latency. 18. The workload-aware input/output scheduler in a software-defined hybrid storage system according to claim 6, characterized in that, if the received value of the number of input/output operations per second or the throughput is close to or lower than their respective performance guarantee values, the received latency value is not close to or lower than the performance guarantee value, and the storage block size is smaller than the medium size, then the queue depth of the workload queue is set to shallow level, and the waiting time for each workload queue is set to medium latency. 19. The workload-aware input/output scheduler in a software-defined hybrid storage system according to claim 6, characterized in that, if the hit rate of the solid-state drive increases, the queue depth of the workload queue remains the same or becomes shallower, and the waiting time for each workload queue remains the same or becomes shorter; otherwise, the queue depth of the workload queue remains the same or becomes deeper, and the waiting time for each workload queue remains the same or becomes longer. 20. The workload-aware input/output scheduler in a software-defined hybrid storage system according to claim 6, characterized in that, if the merging ratio increases, the queue depth of the workload queue remains the same or becomes shallower, and the waiting time for each workload queue remains the same or becomes shorter; otherwise, the queue depth of the workload queue remains the same or becomes deeper, and the waiting time for each workload queue remains the same or becomes longer. 21. The workload-aware input/output scheduler in a software-defined hybrid storage system according to claim 6, wherein the intermediate size is 8KB.