KR101652324B1 - Method and apparatus for guaranteeing performance requirement - Google Patents

Abstract

The present invention comprises a method comprising the steps of determining a transmission permissible time of each of a plurality of scheduler queues based on a target requirement and extracting a processing request of each scheduler queue within each determined transmission permissible time, One transmission permissible time is different from the other one transmission permissible time.
By using the present invention, it is possible to provide an I / O performance differentiating according to a user SLA, and at the same time increase the SSD usage rate, thereby improving the overall performance.

Description

METHOD AND APPARATUS FOR GUARANTEEING PERFORMANCE REQUIREMENT [0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a required performance guarantee method and a required performance guarantee apparatus, .

Virtualization is a technology that is the basis of widely used cloud computing. It is a technology that allows a plurality of virtual machines (also referred to as "VMs") to share physical resources. The Cloud Data Center (CDC), the physical infrastructure of cloud computing, uses server consolidation techniques to virtualize and consolidate physical resources based on virtualization technologies.

In a virtualized environment using server consolidation technology, multiple virtual machines run on one physical machine. Each VM is formatted into a Service Level Agreement (SLA) of the cloud computing user with individual performance requirements. Users of a specific VM can present network response time and request processing speed as performance criteria while others can use I / O operation per second (IOPS) or bandwidth And other users can be based on CPU throughput or CPU utilization.

Known commercial cloud systems present data availability, I / O throughput, or Monthly Uptime Percentage as SLAs and strive to comply with SLAs.

Meanwhile, CDC is introducing high IOPS, bandwidth and energy-efficient solid state drives (SSDs) instead of traditional mechanical hard disks. The introduction of SSD can be roughly classified into three types. First, there is a method of using a hybrid storage device or a disk array which is fused with an existing hard disk.

Secondly, there is a way to use it as a host-side cache. CDC uses shared storage (system) consisting of several arrays in general, and uses a storage structure in which physical data and physical servers are separated. This storage structure is accompanied by a lot of data processing, leading to performance degradation due to network bottlenecks or shared storage processing limitations. This problem can be solved by using the host server cache. The SSD is mounted on the physical server that is responsible for the host server, and the I / O requests received from this server are first processed by the embedded SSD before being forwarded to the shared storage, thereby providing high I / O performance for each VM. .

Finally, there is a way to replace all hard disks in shared storage with SSDs. This method is limited due to cost problems.

The host server cache scheme requires a fair scheduling scheme that guarantees SLAs for SSDs used as host server caches in a cost and process-efficient way.

An SSD used as a host server cache is a resource shared by multiple VMs. A hypervisor or a virtual machine monitor, which is a virtual machine management layer, is responsible for allocating SSDs, which are shared resources according to SLAs, . Such device management can take various forms depending on the structure of the virtualization system. For example, a type in which a hypervisor manages hardware directly, and a type in which a hypervisor is executed on an operating system that acts as a host. Both architectures have an I / O scheduler above the SSD and are responsible for providing the SSD resources to the VM in accordance with the SLA. Therefore, the I / O scheduling technique is an important technical factor for utilizing SSD.

Some studies related to I / O scheduling (see non-patent documents 1 to 4) are known.

The I / O scheduler of the non-patent document 1 aims at improving the overall performance of the SSD, but does not provide a function of differentiating the I / O performance of each VM according to the SLA. And does not provide fairness with other VMs.

Non-Patent Document 2 aims to improve performance and fairness of SSD, but it is difficult to use for guaranteeing SLA on I / O performance and it is very difficult to transform into a form satisfying SLA.

The scheduler of the non-patent document 3 and the non-patent document 4 can not simultaneously achieve performance improvement of SSD and fairness between VMs as a fair queuing-based algorithm.

Thus, there is a need for a required performance guarantee method and a required performance assurance device that can improve the processing performance of an SSD mounted on a host server in response to a processing request from several VMs, while satisfying a target requirement according to the SLA.

 Kim, Jaeho, et al. "Disk schedulers for solid state drivers." Proceedings of the seventh ACM international conference on Embedded software. ACM, 2009.  K. Shen, "FlashFQ: A Fair Queuing I / O Scheduler for Flash-Based SSDs," Proc. Of the 2013 USENIX Annual Technical Conference, 2013, pp. 67-78.  Gulati, Ajay, Arif Merchant, and Peter J. Varman. "mClock: handling throughput variability for hypervisor IO scheduling." Proceedings of the 9th USENIX conference on operating systems design and implementation. USENIX Association, 2010.  D. Shue, M. M. J. Freedman, and A. Shaikh, "Performance isolation and fairness for multi-tenant cloud storage," in Proc. 10th USENIX Conference on Operating Systems Design and Implementation, 2012, pp. 349-362.

SUMMARY OF THE INVENTION The present invention has been made in order to solve the above-mentioned problems, and it is an object of the present invention to provide a required performance guarantee method and a required performance guarantee device which can provide I / O performance differentiation adapted to a user SLA, It has its purpose.

According to another aspect of the present invention, there is provided a required performance guarantee method including: determining a transmission allowable time of each of a plurality of scheduler queues based on a target requirement; extracting a processing request of each scheduler queue within each determined transmission allowable time; Wherein the transmission allowance time of one of the plurality of scheduler queues is different from that of the other one of the plurality of scheduler queues.

In order to achieve the above object, a required performance assurance apparatus includes a feedback control module for determining a transmission permissible time of each of a plurality of scheduler queues based on a target requirement, and a feedback control module for processing each scheduler queue within each determined transmission permissible time And an I / O scheduler for extracting a request, and the transfer permission time of one of the plurality of scheduler queues is different from the other transfer permission time.

The required performance guarantee method and the required performance guarantee device according to the present invention as described above provide an I / O performance differentiating according to the user SLA, and at the same time, the SSD usage rate is increased to improve the overall performance.

1 is a diagram illustrating an exemplary cloud system in accordance with the present invention.
2 is a diagram showing an exemplary hardware block diagram of the required performance guaranteeing apparatus.
3 is a diagram illustrating an exemplary functional block diagram of a required performance assurance device for scheduling processing requests.
4 is a diagram showing an exemplary process flow for ensuring required performance.
5 is a diagram showing definitions of symbols used for explaining the present invention.
6 is a diagram showing an algorithm for inserting into a scheduling queue upon receipt of a processing request.
FIG. 7 is a diagram showing an algorithm used at the start of a window to determine a transfer permission time.
8 is a diagram showing an algorithm applied at the start of a new round in the kth window.
FIG. 9 is a diagram showing an algorithm for processing extraction of a processing request and insertion into a dispatch queue using the transmission allowable time.
FIG. 10 illustrates an example of processing a processing request loaded in a scheduling queue of exemplary VMs utilizing the differentiated transfer time in a round.
11 is a diagram showing an algorithm for updating the throughput of a target requirement.

The above and other objects, features and advantages of the present invention will become more apparent from the following detailed description of the present invention when taken in conjunction with the accompanying drawings, in which: It can be easily carried out. In the following description, well-known functions or constructions are not described in detail since they would obscure the invention in unnecessary detail. Hereinafter, preferred embodiments of the present invention will be described in detail with reference to the accompanying drawings.

1 is a diagram illustrating an exemplary cloud system in accordance with the present invention.

1, a cloud system includes a plurality of VMs 100, a required performance assurance device 200, and a shared storage 300. As shown in FIG. The cloud system is configured on the CDC. The CDC is composed of a plurality of physical servers, each type of physical server is allocated to perform the functions of one or more VMs 100, and the other physical servers are allocated to the host server to ensure the required performance according to the present invention And performs the function of the required performance assurance device (200). Other types of physical servers may provide shared storage 300, including multiple hard disks. Any VM 100 may communicate the processing request to the required performance assurance device 200 over a local or wide area network.

In brief, the VM 100 performs a specific function according to a contract between a user who intends to use the cloud system and the cloud system. The VM 100 performs functions such as a file server, a web server, a server for processing Hadoop, and the like. The VM 100 has individual performance requirements in accordance with the contracts (SLAs) between the cloud systems. The performance requirements of each VM 100 may vary depending on performance capabilities. For example, performance requirements can consist of IOPS, bandwidth, response rate, or usage (for example, CPU usage or SSD usage) or a combination of these. Hereinafter, performance requirements to be achieved are referred to as target requirements. Each VM 100 delivers a processing request to the hard disk 205 through an input / output (I / O) delivery method provided by the virtualization technique to the requested performance assurance device 200.

The requested performance assurance apparatus 200 processes the processing request from the VM 100 using the built-in hard disk 205 in accordance with the target requirements of each of the VMs 100. [ The required performance assurance device 200 may be a so-called host server. The required performance assurance apparatus 200 is configured to utilize the built-in hard disk 205 to maximize processing performance and equally achieve different target requirements.

The required performance assurance apparatus 200 functions as a cache server utilizing an embedded SSD (hard disk 205), temporarily buffers data to be written to the shared storage 300, and sends a response of completion of processing to the VM 100 And then write to the shared storage 300.

The required performance assurance device 200 will be described in detail with reference to FIG.

The shared storage 300 stores various data as resources shared by the plurality of VMs 100. [ The shared storage 300 may be physically distributed and may store, extract, and deliver data in the shared storage 300 in response to a processing request from the requested performance assurance device 200.

Here, the processing request transmitted from the VM 100 to the requested performance assurance apparatus 200 indicates an input / output (I / O) processing request to the shared storage 300, and the requested performance guarantee apparatus 200) with I / O (Input / Output) processing for the SSD. Utilizing an embedded SSD enables maximum performance of I / O processing.

2 is a diagram showing an exemplary hardware block diagram of the required performance assurance apparatus 200. As shown in FIG. 2, the required performance assurance device 200 includes an input interface 201, a memory 203, a hard disk 205, a communication interface 207, one or more processors 209, and a system bus / . Some of these blocks may be omitted and the input interface 201 may be omitted according to a modification example.

Referring to each block, the input interface 201 is an interface capable of receiving user input from the manager of the required performance assurance device 200. The input interface 201 is configured to receive a signal corresponding to an input of a mouse or a keyboard, including a mouse, a keyboard, and the like.

The memory 203 temporarily stores or permanently stores various data and programs. The memory 203 may be, for example, a volatile memory, a non-volatile memory, or a volatile memory and a non-volatile memory.

The hard disk 205 is a mass storage medium for storing various data and programs. Particularly, the hard disk 205 is constituted by an SSD and is used for caching a processing request from the external VM 100.

The hard disk 205 includes various controllers and memories therein. The memory is used to queue I / O processing requests received from outside the hard disk 205. A queue configured in the memory is referred to as a " device queue ". The controller inside the hard disk 205 processes the I / O processing request by inserting the received I / O processing request into the device queue and rescheduling the I / O processing request of the device queue according to the internal state. The hard disk 205 according to the present invention is used as a host server caching area.

In particular, the controller of the SSD has a complicated algorithm for maximizing the performance of the SSD. It maximizes the access performance of Flash memories in the SSD by rescheduling I / O processing requests of device queues according to complicated algorithms. A description of the device queue will be further described with reference to FIG.

The communication interface 207 is an interface configured to communicate with the VM 100 or the physical server that executes the VM 100. [ The communication interface 207 can convert the network packet of the MAC (Media Access Control) layer into an analog signal on the physical layer. For example, the communication interface 207 converts an Ethernet packet into an analog signal, outputs the Ethernet packet through an Ethernet cable, converts the analog signal received from the Ethernet cable into an Ethernet packet, and transmits the packet to the inside.

The processor 209 performs various functions set by utilizing the memory 203 and the hard disk 205. The processor 209 includes one or more execution units for executing instructions of program codes therein.

The program executed by the processor 209 may be of various types. For example, according to the structure of a virtualization system to which the present invention is applied, a virtual machine monitor program or a hypervisor directly managing a hard disk 205 such as an SSD may be included or an OS program may be further included. The hypervisor or operating system program may include at least the I / O scheduler 253 and further include a device driver.

The I / O scheduler 253 receives a processing request such as an I / O processing request from the external VM 100, and performs processing using the hard disk 205 in response to the processing request. I / O scheduler 253 and the like will be described with reference to FIG.

The system bus / control bus 211 is a bus capable of transmitting and receiving data and control signals between elements in the required performance assurance apparatus 200. The system bus / control bus 211 is composed of, for example, a parallel bus, a serial bus, a general purpose input / output (GPIO), or a combination thereof.

FIG. 3 is a diagram illustrating an exemplary functional block diagram of a required performance assurance device 200 for scheduling processing requests. 3, the required performance assurance apparatus 200 includes a plurality of scheduler queues 251, an I / O scheduler 253, a dispatch queue 255, a feedback control module 257, and a requirement management module 259 do. The scheduler queue 251, the I / O scheduler 253, the dispatch queue 255, the feedback control module 257 and the requirements management module 259 are included in a program such as a hypervisor or included in an operating system program do.

Each functional block is preferably configured using the program and memory 203 on the processor 209. Each of the functional blocks can be independently performed through a scheduler queue 251 or a dispatch queue 255. [ Accordingly, the I / O scheduler 253, the feedback control module 257, and the requirement management module 259 are independently performed according to internal scheduling or event generation.

Referring to each functional block, a plurality of scheduler queues 251 are mapped to a plurality of VMs 100 and store processing requests from the corresponding VMs 100. [ The scheduler queue 251 is a list of first-in first-out methods in which a stored processing request can be output first under the control of the I / O scheduler 253.

The I / O scheduler 253 receives a processing request from each of the plurality of VMs 100 and inserts the received processing request into the scheduler queue 251 according to a first-in first-out method. Upon insertion, the I / O scheduler 253 can tag the arrival time of the processing request received in the processing request and store it in the scheduler queue 251 or the like.

In addition, the I / O scheduler 253 extracts the processing requests stored in the plurality of scheduler queues 251 within the range of the transmission permission time dynamically determined according to a certain period for each of the scheduler queues 251, Is inserted into the dispatch queue 255. In particular, the I / O scheduler 253 compares the arrival time instant tagged for the processing request with the transmission permissible time determined according to a predetermined period for each scheduler queue 251 to be examined below, Extracts a processing request of each scheduler queue 251 according to the determination, and inserts the processing request into the dispatch queue 255.

The dispatch queue 255 temporarily stores a processing request from the I / O scheduler 253. [ The dispatch queue 255 outputs a processing request, which is input first according to the first-in first-out method, to the device queue of the hard disk 205. The processing request of the dispatch queue 255 is configured to be output immediately at an outputable time through the interface with the controller of the device queue. The dispatch queue 255 may be configured on the device driver, for example.

The requirements management module 259 receives target requirements for each VM 100 through the input interface 201 or the communication interface 207. [ The requirement management module 259 is also connected to the feedback control module 257 to receive the throughput corresponding to the target requirement of the feedback control module 257 and to provide the output interface (not shown) or the communication interface 207 .

The feedback control module 257 determines the transmission allowable time of each of the plurality of scheduler queues 251 based on the target requirement from the requirement management module 259. [ The feedback control module 257 can perform iteratively and allow the transmission time in each iteration to increase or decrease with the change in throughput in the previous iteration.

The transfer time allowed per VM 100 may be different for each VM 100 depending on the target requirements or the change in throughput corresponding to the target requirement.

The requested performance assurance apparatus 200 of FIG. 3 includes a plurality of virtual machines 100, an I / O processing request from a plurality of virtual machines 100 to a common storage in a cloud system environment including public storage, (205).

The processing flow of the I / O scheduler 253 and the feedback control module 257 among the functional blocks of FIG. 3 will be described in detail with reference to FIG.

4 is a diagram showing an exemplary process flow for ensuring required performance.

Prior to the description of FIG. 4, it should be noted that there is a trade-off in maximizing performance and equally satisfying the target requirements of each VM 100 in the hard disk 205 such as the SSD. This will be described below.

There is a fair-queuing scheme as a technique for using in accordance with the various target requirements of each VM 100. As the scheduler of the fair queuing scheme, SFQ (D), BFQ, YFQ, mClock, and FlashFQ are typical examples. The mClock scheduler provides performance differentiation to meet your target requirements when using hard disk-based storage in a virtualized system environment. However, they are achieving this goal at the expense of the overall performance that can be achieved with SSDs. Therefore, a configuration of a scheduler capable of improving the overall performance of the SSD while achieving performance differentiation according to the target requirements is required.

It is widely known that there is a trade-off between performance and fairness in I / O scheduling techniques for storage. The root cause of the rate betrayal results from the relationship between the scheduler queue 251 in the I / O scheduler 253 and the device queue embedded in the hard disk 205.

To ensure fairness, existing scheduling schemes such as mClock can achieve the target requirements by aligning I / O processing requests according to a certain policy and by adjusting the order and amount delivered to the device queue. Accordingly, in order to provide a sufficient level of fairness, a large amount of I / O processing requests must be loaded in the scheduler queue 251. In general, mclock works well for network processing requests.

On the other hand, the hard disk 205 or the like must move the disk head on a platter to approach a position required by the I / O request. Due to the physical movement time, there is a problem that access time increases especially for I / O requests of random access. Accordingly, the hard disk 205 can rearrange the I / O requests loaded in the device queue so as to reduce the access time and minimize the movement of the disk head, thereby providing good performance.

In order to maximize the fairness in the scheduler queue 251, a sufficient amount of I / O processing requests must be loaded, and in order to maximize the processing performance of the hard disk 205, an I / O processing request Should be loaded. However, it is virtually impossible to load a sufficient amount of processing requests in both the scheduler queue 251 and the device queue. In general, it is known that the average length of I / O requests is about 4.87 times per second in a known enterprise server, so that it is virtually impossible to achieve performance fairness and performance of the hard disk 205 at the same time.

Furthermore, in the case where the hard disk 205 is an SSD, the rate betting property is intensified. Compared to traditional hard disks, the role of device queues in SSDs becomes more complex. This is due to the internal structure of the SSD. The SSD has a number of internal flash memory chips and controllers connected by multiple channels. SSD maximizes SSD performance by maximizing parallelism by accessing flash memory chips in parallel using several independent channels.

The SSD controller handles I / O processing requests according to complex algorithms with complex hierarchies for maximum parallelism. In order to maximize parallelism, multiple I / O processing requests must be present in the device queue for each channel to operate without idle time. Accordingly, the controller is required to have a large capacity device queue, and the I / O processing requests are loaded as much as possible, which is an important factor for enhancing SSD performance. This shows a larger performance difference compared to the hard disk 205 which operates a general physical head.

As described above, a scheduling technique is required to achieve two objectives of ensuring fairness according to a target requirement and maximizing performance of the hard disk 205 in consideration of a device queue on the hard disk 205.

는 i 번째(i 는 2 이상) VM(100)을 나타내고,

는

의 스케쥴러 큐(251)를 나타내며,

은

의 n 번째(n 은 0 이상) 처리 요청을 나타낸다.

은

의 도착시각(arrival time)을 나타내는 태그이고

는 k 번째 윈도우에서의 전송 허용 시간을 나타낸다. 전송 허용 시간은 이하 DAT(Differently Allowed Time) 라고도 지칭한다.

는

에 대해서 한 라운드에서의 종료시각을 나타낸다. 종료시각은 DAT와 라운드의 시작시각(시점)으로 계산된다.

은 특정 목표 요구 사항에 대해서 k 번째 윈도우에서

에 대해서 계산된 성능을 나타낸다. 이

는 k 번째 윈도우에서 지속적으로 갱신되고 이하 처리량으로 지칭될 수 있다. 메트릭(metric)은 예를 들어 IOPS, 대역폭, 응답 속도 또는 CPU(또는 SSD) 사용량 등을 지칭하고 특정 메트릭은 특정 목표 요구 사항에 대하여 한 윈도우에서의 처리량에 대응한다.

은 k 번째 윈도우에서

의 특정 메트릭에 대한 목표 요구 사항을 나타낸다. 목표 요구 사항은 적어도 IOPS, 대역폭, 응답 속도 또는 사용량이거나 이 조합으로 구성된다.In order to achieve such a target, the processing flow of FIG. 4 will be described below with reference to FIG. 5 to FIG. First, FIG. 5 shows symbols used for explaining the present invention. 5,

Represents an i-th VM (i is 2 or more) 100,

The

Gt; 251 < / RTI >

silver

(N is greater than or equal to 0) processing request.

silver

The arrival time of the < RTI ID = 0.0 >

Represents the transfer permission time in the kth window. The transmission allowable time is hereinafter also referred to as DAT (Differently Allowed Time).

The

The ending time in one round. The end time is calculated as the start time (point in time) of the DAT and the round.

For a particular target requirement,

Lt; / RTI > this

May be continuously updated in the kth window and may be referred to as throughput. Metrics refer to, for example, IOPS, bandwidth, response rate or CPU (or SSD) usage, and the specific metric corresponds to throughput in one window for a particular target requirement.

In the kth window

The target metric for the particular metric of the metric. The target requirement consists of at least IOPS, bandwidth, response rate, or usage, or a combination of these.

4, the I / O scheduler 253 receives a processing request for input / output (I / O) of the shared storage 300 from a plurality of VMs 100 (S101).

6, the I / O scheduler 253 tags the current time as the arrival time (S103) and inserts the tag into the scheduler queue 251 corresponding to the VM 100 that has sent the processing request (S105). The processing requests inserted into the scheduler queue 251 are scheduled according to the scheduling technique according to the present invention, and maximize fairness and performance by using time units in particular.

The scheduling technique according to the present invention uses at least two time units. One time unit (hereinafter also referred to as a " first time unit ") is used to change the transmission allowance time so as to achieve the target requirement according to the difference between the target performance (requirement) and the processing performance (throughput). This period of the first time unit is referred to as a window. The other time unit (hereinafter also referred to as 'second time unit') is configured to accommodate a different transfer permission time for each VM 100. The interval of the other time unit is referred to as a round. Windows are typically configured in seconds, and rounds are in tens of milliseconds. Because of the time unit difference, the window contains several rounds. In each round, a processing request for each VM 100 is configured to be performed by the I / O scheduler 253 during a different transfer permission time for each VM 100.

At the start of the specific window (e.g., the kth window) (S107), the feedback control module 257 determines the transmission permissible time of each of the plurality of scheduler queues 251 based on the target requirement (S109). Equation (1) below represents a basic equation for determining a transfer permission time to be used in one window for each VM 100.

)에 기초하여 결정된다. 특히 단계 S109는 윈도우의 시작 시점마다 반복적으로 수행되고 이전 윈도우에서의 처리량에 반비례하여 전송 허용 시간을 결정한다. 각 스케쥴러 큐(251)별 전송 허용 시간은 수학식 1에 따라 다른 하나의 전송 허용 시간과 상이할 수 있다. As shown in Equation (1), the transmission allowable time (DAT) of each of the plurality of schedulers is the target requirement Goal, the transfer permission time in the previous window (k-1)

≪ / RTI > In particular, step S109 is repeatedly performed at each start time of the window and determines the transfer permission time in inverse proportion to the throughput in the previous window. The transmission permissible time for each scheduler queue 251 may be different from the other transmission permissible time according to Equation (1).

FIG. 7 shows an algorithm used at window start to determine the transmission allowed time. As can be seen in Fig. 7, this algorithm consists of a number of iterations. Line 1 to line 8 illustrate a method of calculating a candidate transmission allowable time using Equation (1). This candidate transmission time may be the transmission time allowed for each VM 100 in the round.

The target requirement may be set to an absolute value or to a relative weight to another VM 100. Lines 9 to 33 indicate calculation of the transmission permissible time in consideration of when the absolute value and the relative value are set at the same time.

For example, when there are three VMs 100, a required performance ratio for each VM 100 is 1: 1: 1, and one VM 100 has a performance requirement of an absolute value of 50 MByte / S, In case of MByte / S, 100MByte can be allocated according to performance ratio. If the absolute value is taken into account, the VM 100 may have a lower transfer permission time to match 50 MByte / S according to Equation (1). In consideration of the absolute value and the relative value, the lines 9 to 33 compares the transmission permissible time calculated with the absolute value and the transmission permissible time calculated with the relative value, and allocates a larger transmission permissible time. For reference, 'equation 1' of line 4 and line 16 represents equation (1).

In step S109, the feedback control module 257 also initializes various variables and the like. For example, the feedback control module 257 initializes a variable representing the throughput (see line 34 in FIG. 7) for a particular metric of the target requirement.

Step S109 is repeatedly performed by the feedback control module 257 according to the window period, and the transmission allowed time determined in each iteration may be different from the transmission allowed time in the previous iteration.

The window includes a plurality of rounds, and the length (time) of the round is determined as the longest time among the DATs of the VMs 100. [ The determination of the round length may be performed by the I / O scheduler 253 or may be performed by the feedback control module 257. The I / O scheduler 253 sets the end time for each of the plurality of scheduler queues 251 when the round start time (S111) is set (step S113).

8 shows an algorithm at the start of a new round in the kth window. The I / O scheduler 253 controls the feedback control module 257 to determine the end time of each of the scheduler queues 251 of the k- The calculated (determined) transmission allowance time at the start is added to the current time. Thus, the end time is dynamically determined as the time passes by using the transfer permission time. FIG. 8 shows an example in which the I / O scheduler 253 is called (the line 6 in FIG. 8, the scheduler module in FIG. 9) and the processing request of the dispatch queue 255 is transmitted to the device queue of the hard disk 205 after the setting of the end time (Line 7 in FIG. 8).

Then, the I / O scheduler 253 extracts the processing requests loaded in the plurality of scheduler queues 251 within the transmission permission time determined for each of the scheduler queues 251 (step S115) and outputs the extracted processing request to the dispatch queue 255) (step S117). FIG. 9 shows an algorithm for processing extraction of a processing request and insertion into a dispatch queue 255 using the transfer permission time. 9, the I / O scheduler 253 determines whether to extract the processing requests of each of the scheduler queues 251 by comparing the tagged arrival time and the end time, and extracts the corresponding processing request according to the determination do. If the end time of the scheduler queue 251 is greater than the arrival time of the processing request, this processing request is extracted, otherwise it can be extracted in the next round. Steps S115 and S117 are repeatedly performed, and are repeatedly performed a plurality of times in accordance with the cycle of the round in one window.

FIG. 10 shows this example. The length of the round is determined to be the longest time among the transfer permission times of the plurality of VMs 100. Since the transfer time is updated for each window, the round length can also be changed for each window. Each permissible transmission time DAT represents the time in one round.

의 전송 허용 시간으로 결정되고, I/O 스케쥴러(253)는 스케쥴러 큐(251)의 각 처리 요청의 도착시각과 종료시각을 비교하여 추출 여부를 결정한다.

나

는 종료시각이 도과함에 따라 특정 처리 요청이 다운 라운드에서 추출된다. As can be seen in the example of FIG. 10, the length of the round is the longest scheduler queue 251,

The I / O scheduler 253 compares the arrival time and the end time of each processing request of the scheduler queue 251 and determines whether or not to extract the processing request.

I

The specific processing request is extracted in the down-round as the end time passes.

In step S119, processing requests of the dispatch queue 255 are directly transferred to the device queue of the hard disk 205 at a time when it can be transferred to the hard disk 205. [ The hard disk 205 may be an SSD and step S119 may be performed by a device driver that may be performed by the I / O scheduler 253 or may control the hard disk 205.

After step S119, the hard disk 205 processes the processing request of the device queue and returns a response indicating completion of processing to the feedback control module 257. [ The feedback control module 257 updates the throughput corresponding to the target requirement in accordance with the completion of the processing for the specific processing request (S121).

Figure 11 shows an algorithm for updating the throughput of a target requirement. As can be seen from FIG. 11, bandwidth, IOPS, latency and utilization are updated. This throughput can be continuously updated in one window and then used in the calculation of the time allowed for transmission at window iteration.

Utilization refers to usage in an SSD by a single processing request and can be defined in a variety of ways. In general, usage is determined in proportion to the size of the I / O processing request.

Steps S101 to S121 of FIG. 4 are repeatedly performed, in particular, step 109 is repeatedly performed according to the window period, and step S113 is repeated plural times according to the period of the round in the window period. Further, at least the steps S115 to S117 are also repeatedly performed in rounds within each transfer permission time within the round.

4, the required performance assurance apparatus 200 can uniformly differentiate the target requirements of each of the VMs 100 by using the transmission allowance time, and can simultaneously process the processing requests of the dispatch queue 255 And output to the disk 205, thereby maximizing the processing performance of the SSD.

It will be apparent to those skilled in the art that various modifications and variations can be made in the present invention without departing from the spirit or scope of the invention. The present invention is not limited to the drawings.

100: virtual machine 200: required performance guarantee device
201: input interface 203: memory
205: hard disk 207: communication interface
209: Processor 211: System bus / control bus
251: Scheduler queue 253: I / O scheduler
255: Dispatch queue 257: Feedback control module
259: Requirements Management Module
300: Shared storage

Claims (13)

(a) the feedback control module of the required performance assurance device determining a transmission permissible time of each of a plurality of scheduler queues based on a target requirement;
(b) extracting a processing request of each scheduler queue within an I / O scheduler of the requested performance assurance device within each determined transmission permissible time;
(c) inserting the extracted processing request into the dispatch queue by the I / O scheduler; And
(d) a processing request of a dispatch queue is sequentially transmitted to a device queue,
Wherein the transmission permissible time of one of the plurality of scheduler queues is different from the transmission permissible time of the other,
Method for ensuring required performance. The method according to claim 1,
Wherein the step (a) is performed in a designated first time unit, and the step (b) is performed a plurality of times in a second time unit different from the first time unit within the interval of the first time unit, Wherein the time is a time within a second time unit interval,
Method for ensuring required performance. delete The method according to claim 1,
(e) updating the throughput corresponding to the target requirement upon completion of processing of the processing request by the feedback control module,
Wherein said step (a) is performed iteratively and determines a transmission allowed time in subsequent iterations based on said target requirement, said throughput in the previous iteration and said transmission allowance time,
Method for ensuring required performance. The method according to claim 1,
Before the step (b), the I / O scheduler receives a processing request from a plurality of virtual machines and tags the arrival time of the processing request; And
Further comprising the step of the I / O scheduler inserting the processing request into a scheduler queue corresponding to each of the plurality of virtual machines,
Method for ensuring required performance. 6. The method of claim 5,
The step (b) determines whether to extract the processing request by comparing the arrival time tagged in the processing request of each scheduler queue with the ending time dynamically determined for each of the scheduler queues, and extracts the processing request according to the determination doing,
Method for ensuring required performance. The method according to claim 6,
Wherein the step (b) includes the step of extracting the processing request when the end time is greater than the arrival time,
Method for ensuring required performance. 5. The method of claim 4,
The transfer permission time determined in each iteration is determined in inverse proportion to the throughput in the previous iteration,
The target requirements may include I / O throughput, bandwidth, response rate or SSD usage per second,
Method for ensuring required performance. A feedback control module that determines a transmission permissible time of each of a plurality of scheduler queues based on a target requirement;
An I / O scheduler for extracting a processing request of each scheduler queue within each determined transmission permissible time; And
And a dispatch queue for temporarily storing a processing request to be output to the device queue,
Wherein the transmission allowance time of one of the plurality of scheduler queues is different from that of the other one of the scheduler queues,
The I / O scheduler inserts the extracted processing request into a dispatch queue,
Required performance guarantee device. delete 10. The method of claim 9,
A plurality of scheduler queues, each storing a processing request from each of a plurality of virtual machines,
The I / O scheduler receives a processing request from a plurality of virtual machines and tags the arrival time of the processing request.
Required performance guarantee device. 12. The method of claim 11,
The I / O scheduler determines whether to extract a processing request by comparing the arrival time tagged in the processing request of each scheduler queue with the end time dynamically determined by the feedback control module for each scheduler queue, And extracts the processing request according to the request,
Required performance guarantee device. 12. The method of claim 11,
Wherein the requested performance assurance device processes an I / O processing request from a plurality of virtual machines to the shared storage using a built-in SSD under a cloud system environment including a plurality of virtual machines and public storage,
Required performance guarantee device.

Images