Design and analysis of an efficient QoS improvement policy in cloud computing

Abstract

Cloud computing offers the proficiency to use computing and storage resources on a metered basis and reduces the investments in Information Technology domain. This paper highlights a major research issue, i.e., providing good quality of service (QoS) to the cloud users. The QoS is associated with several parameters such as completion time, response time, turnaround time (TAT), waiting time (WT), bandwidth. A new cloudlet scheduling algorithm—improved round robin cloudlet scheduling algorithm—has been proposed which improves the TAT, WT and number of context switching. It enhances the resource utilization. The experimental results are obtained by CloudSim toolkit extending few base classes and compared by classical round robin algorithm.

1 Introduction

Over the years, distributed environments have evolved from shared community platform to utility-based models; the latest of these being cloud computing [1–3]. The cloud computing enables the delivery of IT resources over the Internet and follows an on-demand service model where the users are charged based on their consumption. There are various types of Cloud providers into hierarchy of as-a-service terms [4, 5]—software as a service (SaaS), platform as a service (PaaS), infrastructure as a service (IaaS), database as a service (DaaS), identity as a service (IdaaS), etc. Moreover, they offer the flexibility, elasticity and scalability to acquire or release resources with varying configuration to best suit the requirements of an application. Even though this empowers the cloud users (CUs) [6] and gives the registered users more control over the resources. It also dictates the development of innovative scheduling techniques so that the distributed resources are efficiently utilized. The cloud computing [7, 8] is a type of parallel and distributed system consisting of collection of large-scale heterogeneous interconnected and virtualized [9, 10] computers that are dynamically provisioned and presented as one or more unified computing resources established through negotiation between the service providers and customers.

In this domain, the background activities like virtual machine (VM) [10, 11] allocation, load sharing, load balancing [3, 12], cloudlet migration, and distributed shared memory access are completely abstracted from the user’s purview. Here, the end users or the customers can access the cloud-based applications [3, 4] as well as infrastructure through logging in to a cloud interface. To make the cloud services proficient in that environment, one of its challenges is to provide an efficient cloudlet scheduling policy. The cloudlet scheduling policy [11, 13] plays a vital role to improve the overall system performance minimizing the turnaround time, waiting time and context switching. A proper scheduling policy may eventually lead to improve the QoS [14] of the overall system.

1.1 Our contribution

In the domain of cloud computing [15], several research works are going on. There are many traditional methods which are used to highlight the parameters involved in QoS of cloud. Based on the literature survey, it is found that little amount of research work has been done to emphasize the QoS parameter evaluation. In this paper, a new cloudlet scheduling algorithm has been proposed and simulated in the famous CloudSim 3.0.3 [16]. The obtained result sets are compared by RRA. In comparison with RRA, the proposed IRRCSA provides better turnaround time, waiting time and context switching of the cloudlets allotted to the VMs and VMs present in the host in DC. Hence, the system utilization has been improved also. So many research works have been undertaken, based on scheduling techniques with various network scenarios and combinations of service classes [17–19]. A detail description and justification with proper analysis is sited in Sects. 4 and 5.

1.2 Organization

The rest of the paper is organized as follows—Sect. 2 describes the different related works regarding existing cloudlet scheduling algorithms. In Sect. 3, the proposed work has been emphasized with algorithm and flowchart. In Sect. 4, the experimental result of the proposed scheduling algorithm—IRRCSA—is described. Section 5 presents the comparison result and simulated graphs to illustrate the prominence of this proposed algorithm over some existing algorithms. Finally, Sect. 6 concludes and discusses future scope of the proposed work.

2 Related work

2.1 CloudSim toolkit

Several grid simulators [20–22], such as GridSim, SimGrid and GangSim, are capable of modeling and simulating the grid application in a distributed environment, but fail to support the infrastructure and application-level requirements arising from cloud computing paradigm [23]. A cloud infrastructure modeling and simulation toolkits must support real-time trading of services between customers and providers. The open-source CloudSim framework [6, 24] shown in Fig. 1 is developed on GridSim toolkit that offers support for economic-driven resource management and application scheduling simulation. It provides users a series of extended entities and methods. In addition, it helps users to analyze their own scheduling and allocation strategy at different levels including modification of module deployment techniques and conduct related performance testing by expanding few interfaces. The present study aims at expanding CloudSim by utilizing the broker policy. The data center broker policy is a decision-making procedure which makes the best match between cloudlets and VMs. The modules of CloudSim toolkit which are relevant to our research are as follows.

• VM scheduler VM scheduler is an abstract class implemented by a host component, represents the policies (space-shared, time-shared) required for scheduling VMs to PE (Processing Element) [12, 25].

• VM allocation policyVM allocation policy [12, 25] is used to select available host in a data center, which meets the memory, storage and availability requirement for a VM deployment.

• Cloudlet scheduling The cloudlet scheduler selects the cloudlets from the local queue (LQ) of each VM and allocates them in the available VM

Fig. 1

CloudSim work style

2.2 Scheduling algorithm

There are many different types of cloudlet scheduling [17, 24] algorithms present, but one them has been chosen in this study.

Round robin algorithm (RRA) [17, 18]: In this policy, a small unit of time is defined, which is known as time quantum (TQ). The execution time [26] of a cloudlet is decreased by the TQ. If the execution time of a cloudlet is less than or equal to the TQ, that is allowed to continue till normal termination. If the execution time is greater than TQ, the cloudlet is preempted and added to the tail of the LQ. Then, the next cloudlets in the LQ start running. It will continue until the cloudlet is completed.

For example, there are three cloudlets with their execution time $\hbox {C}_{0} = 25, \hbox {C}_{1} = 10~\hbox {and}~\hbox {C}_{2} =12$ and the TQ is 5.

C$_{0}$	C$_{1}$	C$_{2}$	C$_{0}$	C$_{1}$	C$_{2}$	C$_{0}$	C$_{2}$	C$_{0}$
0	5	15	20	25	30	35	37	47

Number of context switch (CS) is 8 (Tables 1 and 2).

Disadvantages:

• (i) The average waiting time and turnaround time is maximum in comparison with the proposed IRRCSA.

• (ii) Number of CS is larger in comparison with IRRCSA.

Table 1 Average waiting time using RRA

Table 2 Average turnaround time using RRA

The disadvantages are justified in Sects. 4 and 5.

3 Proposed work

The proposed IRRCSA has overcome the disadvantages of the above scheduling algorithm. In this proposed work, all the VMs are stored in vm_list [11] array with their corresponding million instructions per second (MIPS) and also a batch of cloudlets is stored in the cloudlet_list [11] array with their corresponding million instructions (MI). Initially, the cloudlets are assigned to the LQ(s) of the VM(s), following the circular first come first serve (FCFS) manner. This cloudlet allocation policy continues till all the cloudlets in the global queue (GQ) are allotted into the LQ(s) of the VM(s). Then, the expected execution time (ET) of each cloudlet is calculated according to the Eq. 1. The ET of a cloudlet is defined as the ratio of MI (Million Instruction) of the cloudlet to the MIPS of the allotted VM. Then, sort the cloudlets in ascending order according to their ET. After sorting the cloudlets, the data center broker (DCB) sets a time quantum (TQ) and starts executing the cloudlets. The execution of the cloudlet continues till the TQ expires, and the scheduler checks the remaining execution time (RET) of the cloudlet concurrently following Eq. 2. If the RET of that cloudlet is less than the expected execution time among the remaining cloudlets in the LQ of that VM, then it is allowed to continue its execution. Otherwise, the cloudlet is switched and the next cloudlet from the cloudlet_list starts its execution. This process continues till the LQ becomes empty. The model is mentioned in Fig. 2.

$$\begin{aligned}&\hbox {Execution time}_{\mathrm{j}}\,(\hbox {ET}_{\mathrm{j}}) = \hbox {MI of cloudlet}_{\mathrm{j}}/ \hbox {MIPS of VM}_{\mathrm{i}}. \end{aligned}$$

(1)

$$\begin{aligned}&\hbox {Remaining execution time}_{\mathrm{j}} = \hbox {Execution time}_{\mathrm{j}} - \hbox {TQ}. \end{aligned}$$

(2)

Fig. 2

Proposed model for IRRCSA

3.1 Proposed model

Initially, the CUs [11] send batches of cloudlets to the CSP [11] that are stored in global queue (GQ). Then, the data center broker (DCB) [11] selects the VM from vm_list. Then, the VMs are allotted to the host in a data center (DC) [11] according to VM allocation policy [11]. The DCB module assigns the cloudlets to the VMs according to proposed policy.

3.2 Scheduling criteria

• (i) VM utilization [16]: It is the average fraction of time. It ranges from 0 to 100 %. It keeps the VM as busy as possible.

• (ii) Throughput [16]: Throughput is defined as the rate of the cloudlets completed per unit of time (number of cloudlets/unit time).

• (iii) Context switching [16, 27]: It is the process of storing and restoring the state of cloudlets so that execution can be resumed from the same point at a later time.

• (iv) Fairness [16]: Each of the cloudlets should have the fair [17] share of VM. All tasks must get their chance at VM.

• (v) Response time [16]: It gets first response on the VM to start its cloudlet execution.

• (vi) Waiting time [16]: It is an amount of time a cloudlet needs to wait in ready queue. In RRA and IRRCSA scheduling algorithm, waiting time is referred to as the time for which the cloudlet is ready to execute but cannot execute by the VM.

• (vii) Turnaround time [16]: It means the amount of time taken to execute a requested cloudlet by the VMs. In RRA and IRRCSA scheduling, turnaround time is defined as the total time taken by the cloudlet between the submission of a cloudlet for execution and the return of the complete output.

Fig. 3

Flowchart of proposed IRRCSA

3.3 IRRCSA algorithm

3.4 Explanation of the IRRSCA algorithm

Initially, the vm_list array is prepared by creating the VMs and arranging them in ascending order following their MIPS. The cloudlets are created and stored in cloudlet_list. Here, “n” is the number of VMs present in the vm_list and “k” is the number of cloudlets allotted to each VM.

Each VM contains a LQ where the cloudlets are allocated following FCFS manner. Then, TQ is assigned for fare share execution of each cloudlets. The execution of the cloudlet continues till the TQ expires, and the scheduler checks the RET of the cloudlet concurrently following Eq. 2. If the RET of that cloudlet is less than the expected execution time among the remaining cloudlets in the LQ of that VM, then it is allowed to continue its execution. Otherwise, the cloudlet is switched and the next cloudlet from the cloudlet_list starts its execution. This process continues till the LQ becomes empty.

3.5 Flowchart of proposed IRRCSA algorithm

Figure 3 shows the flowchart of the proposed cloudlet scheduling algorithm—IRRCSA.

4 Experimental result

The proposed cloudlet scheduling algorithm has been described and analyzed using a suitable example. Due to space constraint, ten cloudlets and three VMs have been considered in this experiment. We have considered waiting time, turnaround time and context switching to evaluate the performance of the proposed algorithm in this paper.

Table 3 Properties of cloudlets

Table 4 Properties of VM

Tables 3 and 4 show ten cloudlets with their size in millions of instruction (MI) and four VMs with their processing power in MIPS, respectively. The cloudlet id is represented as cld_id and VM id is represented as vm_id.

Table 5 plays a significant role in describing the cloudlet to the VM mapping as well as execution time for each cloudlet. It shows the cloudlets are allotted to the corresponding VM following the proposed IRRCSA algorithm.

Table 5 Cloudlet to VM map table with execution time

The execution time of allotted cloudlets is shown separately in Tables 6, 7, 8 and 9. Without calculating the execution time the RET cannot be estimated.

Table 6 Allotted cloudlet to VM$_{0}$ with their execution time

Table 7 Allotted cloudlet to VM$_{1}$ with their execution time

Table 8 Allotted cloudlet to VM$_{2}$ with their execution time

Table 9 Allotted cloudlet to VM$_{3}$ with their execution time

The VM-specific improvement in waiting time and turnaround time has been clearly mentioned from Tables 10, 11, 12, 13, 14, 15, 16 and 17. The rate of improvement of parameters has been mention.

Tables 10 and 11 show the improvement of waiting time and turnaround time of IRRCSA over RRA, respectively, in VM$_{0}$. The average waiting time and turnaround time has been mentioned to justify the improvement.

Table 10 Waiting time for RRA and IRRCSA

Table 11 Turnaround time for RRA and IRRCSA

Table 12 Waiting time for RRA and IRRCSA

Table 13 Turnaround time for RRA and IRRCSA

Table 14 Waiting time for RRA and IRRCSA

Tables 12 and 13 show the improvement of waiting time and turnaround time of IRRCSA over RRA, respectively, in VM$_{1}$.

Tables 14 and 15 show the improvement of waiting time and turnaround time of IRRCSA over RRA, respectively, in VM$_{2}$.

Table 15 Turnaround time for RRA and IRRCSA

Tables 16 and Table 17 show the improvement of waiting time and turnaround time of IRRCSA over RRA, respectively, in VM$_{3}$. The rate of improvement has been shown in Table 18.

Table 16 Waiting time for RRA and IRRCSA

Table 17 Turnaround time for RRA and IRRCSA

Table 18 Summery table for performance gain

5 Comparison result and simulated graph

This section deals with analyzing the improvement of the QoS in association with three parameters, such as waiting time, turnaround time and context switching. The performance of the proposed IRRCSA is compared and analyzed by RRA. The simulated results are evaluated and analyzed in several aspects. The performance was measured by allocating cloudlets to the corresponding VMs present in the host. The improvement of waiting time, turnaround time and context switching is explained with the help of the simulated graphs from Figures 4, 5, 6, 7, 8, 9, 10, 11, 12 and 13. The improvement in the result using the proposed IRRCSA indicates the enhancement of the QoS of a cloud.

Fig. 4

Waiting time comparison: RRA vs. RRCSA in VM$_{0}$

Fig. 5

Waiting time comparison: RRA vs. IRRCSA in VM$_{1}$

Fig. 6

Waiting time comparison: RRA vs. IRRCSA in VM$_{2}$

Fig. 7

Turnaround time comparison: RRA vs. IRRCSA in VM$_{0}$

Fig. 8

Turnaround time comparison: RRA vs. IRRCSA in VM$_{1}$

Fig. 9

Turnaround time comparison: RRA vs. IRRCSA in VM$_{2}$

Fig. 10

Context switching comparison: RRA vs. IRRCSA in VM$_{0}$

Waiting time: In Figs. 4, 5 6 the improvement of waiting time is presented.

Turnaround time In Figs. 7, 8 9 shows the improvement of turnaround time.

Context switching In Figs. 10, 11 and 12 the improvement of context switching of the cloudlets is presented.

Fig. 11

Context switching comparison: RRA vs. IRRCSA in VM$_{1}$

Fig. 12

Context switching comparison: RRA vs. IRRCSA in VM$_{2}$

Fig. 13

Context switching of comparison: RRA vs. IRRCSA

Figure 13 shows the improvement of CS of the VMs.

6 Conclusion and future work

The proposed work provides better turnaround time and waiting time and returns reduced number of context switching. The basic idea of the proposed “IRRCSA” mechanism is to leverage the strengths of round robin algorithm. This modification supports to minimize several parameters associated with QoS.

This proposed technique does not consider the fault tolerance issues. We will extend this work to include few issues like fault tolerance and scalability in the next work.