Policy based resource allocation in IaaS cloud

Future Generation Computer Systems 28 (2012) 94–103

Contents lists available at SciVerse ScienceDirect

Future Generation Computer Systems journal homepage: www.elsevier.com/locate/fgcs

Policy based resource allocation in IaaS cloud Amit Nathani a,1 , Sanjay Chaudhary a,∗,2 , Gaurav Somani b,3 a

DA-IICT, Gandhinagar, India

b

LNMIIT, Jaipur, India

article

info

Article history: Received 22 January 2011 Received in revised form 10 May 2011 Accepted 28 May 2011 Available online 12 June 2011 Keywords: Cloud computing Resource allocation Scheduling

abstract In present scenario, most of the Infrastructure as a Service (IaaS) clouds use simple resource allocation policies like immediate and best effort. Immediate allocation policy allocates the resources if available, otherwise the request is rejected. Best-effort policy also allocates the requested resources if available otherwise the request is placed in a FIFO queue. It is not possible for a cloud provider to satisfy all the requests due to finite resources at a time. Haizea is a resource lease manager that tries to address these issues by introducing complex resource allocation policies. Haizea uses resource leases as resource allocation abstraction and implements these leases by allocating Virtual Machines (VMs). Haizea supports four kinds of resource allocation policies: immediate, best effort, advanced reservation and deadline sensitive. This work provides a better way to support deadline sensitive leases in Haizea while minimizing the total number of leases rejected by it. Proposed dynamic planning based scheduling algorithm is implemented in Haizea that can admit new leases and prepare the schedule whenever a new lease can be accommodated. Experiments results show that it maximizes resource utilization and acceptance of leases compared to the existing algorithm of Haizea. © 2011 Elsevier B.V. All rights reserved.

1. Introduction Cloud provides a managed pool of resources which includes storage, compute power and software services. Cloud provides scalability using virtualization and host applications which suffer high load at certain times. Resources provided to an application can be reconfigured to adjust to a variable load. In IaaS cloud the resources (compute capacity and storage) are provided in the form of virtual machines to users. To optimize resource utilization on cloud provider’s side, it is necessary to handle the following two things: 1. Where to place newly created virtual machine? 2. When to dispatch newly created virtual machine to a particular physical machine? A scheduler can be used to decide when and where to place these virtual machines. The main goal of the scheduler described in this paper is to minimize request rejection rate while satisfying resource allocation policies offered by cloud provider.

∗

Corresponding author. Tel.: +91 79 30510560; fax: +91 79 30520010. E-mail addresses: [email protected] (A. Nathani), [email protected] (S. Chaudhary), [email protected] (G. Somani). 1 Master of Technology student at DA-IICT, Gandhinagar. 2 Professor of Computer Science and Engineering at DA-IICT, Gandhinagar. 3 Lecturer of Computer Science and Engineering at LNMIIT, Jaipur. 0167-739X/$ – see front matter © 2011 Elsevier B.V. All rights reserved. doi:10.1016/j.future.2011.05.016

The rest of this paper is organized as follows. Section 2 describes resource allocation on cloud. In Section 3, we discuss the task model, system requirements, proposed algorithm to provide support for deadline sensitive requests and modifications to the existing algorithm of Haizea. In Section 4, we have discussed the experiments and results obtained by comparing the modified algorithm with the existing one. Section 5 contains discussion on related work. We conclude this paper in Section 6 with future enhancements. 2. Resource Allocation on Cloud IaaS cloud allocates resources to competing requests based on pre-defined resource allocation policies. Presently, most of the cloud providers rely on simple resource allocation policies like immediate and best effort [1]. Comparison of various cloud toolkits and public clouds based on resource allocation policies and VM placement policies is given in Table 1 [1]. Amazon EC2[2] is a public cloud which provides computing resources to general public on pay-per-use model. Nimbus [3], Eucalyptus [4] and OpenNebula [1] are cloud toolkits which can be used to setup a cloud on local infrastructure. Haizea is a resource lease manager that can be used as a scheduler for OpenNebula. The integration of OpenNebula and Haizea provides the only Virtual Infrastructure (VI) management solution offering advance reservation of capacity and configurable VM placement policy. Sometimes it is not possible for cloud providers to satisfy all the requests which come to them on immediate basis due to lack

A. Nathani et al. / Future Generation Computer Systems 28 (2012) 94–103

95

Table 1 Comparison of various cloud toolkits. Cloud toolkits

Allocation policies

VM placement policies

Support for hybrid cloud

Amazon EC2 Nimbus Eucalyptus OpenNebula OpenNebula and Haizea

Best effort Immediate Immediate Best effort Immediate, best effort, advancereservation

Proprietary Static greedy and round robin Static greedy and round robin Initial placement based on rank policy and dynamic placement to consolidate servers Dynamic placement to support advance reservation leases

No Yes No Yes Yes

of resources. Haizea is an open source resource lease manager that tries to address this issue [5–8]. User requests computational resources from Haizea in the form of a lease. The lease is accepted by Haizea if and only if Haizea can assure the resource allocation policy requested by this lease. Assuring the resource allocation policy(or satisfying a lease) means providing requested resources for requested duration at requested start time. Haizea will then reserve the resources for this lease. Whenever start time of a reservation comes, Haizea allocates resources to users in the form of VMs, which are deployed on physical machines. Haizea assumes that best-effort leases are preemptable and they do not have any time constraints. Immediate and advance reservation leases are non-preemptable and have time constraints, such as start time and end time. It will preempt best-effort leases whenever the resources are required for advance reservation or immediate leases. There is no guarantee that a submitted best-effort lease will get resources for completion within a certain time limit. If the system is flooded with lots of advance reservation and immediate leases then besteffort leases will not have enough resources to run on. The consumers of best-effort leases may not like to wait so long to get resources. They will start submitting their requests as advance reservation leases rather than best-effort leases, to be assured that the submitted requests will be completed within a certain time limit. As a result, the system will have more advance reservation leases which will increase fragmentation of free resources. As there are less best-effort leases, very few of these fragmented unused resources will be utilized by them. Thus, the system utilization will go down. To handle this kind of situation, deadlines can be associated with best-effort leases for those consumers who want to get resources for their best-effort leases within certain time limit. These kinds of leases can be considered as deadline sensitive leases. Deadline sensitive leases are assumed to be preemptable but there is a limitation to their preemptability. It is preemptable only if the scheduling algorithm of Haizea can assure that it can be completed before its deadline. Thus, it will assure the consumers that their request will be completed within a certain time limit and at the same time it will also try to use more of fragmented unused resources. 3. Proposed scheduling algorithm for deadline sensitive leases 3.1. System description To request resources from Haizea, consumer has to submit lease in a specific format. Main parameters in this request are number of virtual nodes, amount of physical resources for each node, start time, duration and deadline. CPU and memory are considered to be two computational resources, which can be requested by a user. It also has a software field, where a user can specify the software to be deployed on allotted resources. In this paper, only those leases are considered which demand for full host resources. This is done only for the simplicity of experiments. The proposed model can also handle the leases, demanding a fraction of one host resources. It is also assumed that the leases request number of virtual nodes with the same hardware for each node. The software

specified in software field of the request is considered as VM image. These VM images are stored at a central repository. If a lease is preempted, it is suspended by suspending its VMs. These VMs may then be resumed on the same node or migrated to another node. When a VM is suspended, a memory state file (the contents of the VM’s memory) is created on the node where the VM was running. When a VM is resumed, the VM image of it is transferred to that node and the memory state file is read into memory. When a suspended VM is migrated to a different node, its VM image and memory state file are transferred to that node. Suspending multiple VMs communicating with each other can potentially disrupt communication between the nodes. All these assumptions are made based on the assumptions made in [8]. 3.2. Task characteristics Haizea has four types of tasks(leases) to schedule and they are Advance Reservation (AR), Best effort (BE), Immediate (IM) and Deadline Sensitive (DS).

• All tasks are aperiodic. • Deadline and best-effort tasks are splittable. • All tasks are independent and the scheduling algorithm assumes that there is no communication among tasks.

• Haizea accepts a new task only when it can prepare a feasible schedule for all the old tasks, which were already accommodated in Haizea as well as new task. 3.3. Swapping and backfilling Whenever a new deadline sensitive lease is submitted to Haizea, the existing algorithm in Haizea to handle deadline sensitive leases tries to find a single time slot to satisfy the whole lease. If it is not able to find such a slot then it will reschedule already accommodated deadline sensitive leases to make space for new lease. While rescheduling the leases it does not consider the amount of resources requested by the leases. It just sorts the deadline sensitive leases based on slack value and reschedules them considering preemption. We see several enhancements to this algorithm which are discussed below. The existing algorithm of Haizea to handle deadline sensitive leases tries to find a single time slot to satisfy the whole lease. One enhancement is to consider several time slots, which together can satisfy the complete lease within its deadline. This way several new leases may get scheduled without requiring rescheduling of other leases to make space for them. For example, suppose we have a 2 h deadline sensitive lease to schedule. Now, suppose that we cannot find a 2 h slot which can satisfy this lease within its deadline but we are able to find 2 time slots of 1 h each, which can satisfy the complete lease and are not intersecting with each other. We can split new lease into two parts each of 1 h and can schedule these two parts of lease into the found time slots. Thus, we can use several slots to satisfy a deadline sensitive lease by splitting it and scheduling its parts into the found time slots. If a single slot or multiple slots cannot be found to accommodate new lease then there is a need to check whether we can make space for new lease by rescheduling already accommodated deadline sensitive leases or not. To resolve it, two things need to be found:

96

A. Nathani et al. / Future Generation Computer Systems 28 (2012) 94–103

1. Which leases should be rescheduled to make space for new lease? 2. How these leases should be rescheduled? To answer first question those leases must be considered without which the new lease cannot be accepted, even if there is a feasible schedule. Procedure-1 FIND-LEASES-TO-BE-RESCHEDULED can be used to find such leases. This algorithm is given in [9] and is explained in ‘‘Proposed Algorithm’’ section. This paper proposes two ideas to answer second question. They will try to reschedule the deadline leases found by procedure-1 to make space for new lease. The leases should be rescheduled in such a manner that it can push more idle resources towards requested time slot of new lease. There are two ways of pushing idle resources towards requested time slot of new lease:

Table 2 Information of submitted leases. Lease no.

Nodes Submit time (AM)

Start time (PM)

Duration Deadline (PM)

1 2 3 4 5

2 3 4 1 2

12:00 12:00 12:00 12:30 12:40

40 20 20 40 10

11:10 11:20 11:30 11:40 11:50

01:20 01:20 01:20 01:20 01:20

1. Swapping of consecutive leases. 2. Backfilling of leases. Two consecutive leases can be swapped if and only if, the first lease has requested fewer resources than second lease and after swapping, they must still finish their execution within their deadline. By scheduling a lease with less amount of requested resource behind the lease with higher amount of requested resources, we can bring more idle resources towards requested time slot of a new lease. Now, Consider a case where the first lease is scheduled for the requested duration. Suppose second lease has start time less than the end time of the first lease but it cannot be scheduled at its start time because there are not enough resources for it. It has to wait until it gets its requested resources. There will be a slot with idle resources, which will not be used by second lease in an ordered set. Backfilling process finds leases (residing after second lease in set of leases which should be rescheduled to make space for new lease) which can be scheduled on these idle resources. This way we can utilize idle resources, which are far from requested time slot of new lease and create time slot with idle resources nearer to requested time slot of a new lease. Currently, Haizea uses backfilling to schedule best-effort leases. The backfill procedure used in Haizea is as follows. It will go through the queue of best-effort leases and finds suitable leases, which can be given idle resources. It will try to give idle resources to first lease in the queue, if first lease cannot be satisfied with available resources then it will try to find other leases, which can be satisfied with available idle resources. While backfilling, it will not consider the time constraints and it will check the whole queue until it has idle resources to fill. But the proposed backfill algorithm is for deadline sensitive leases so the time constraint needs to be considered while backfilling. That means while deciding that the available idle resources can be given to a particular lease or not, the proposed algorithm has to consider its deadline. By combining both the processes, the chances of new lease getting requested resources within the requested time slot increase. Following two examples can describe how swapping and backfilling can bring idle resources towards requested time slot of a new lease: Example 1 (Swapping). The first example illustrates how swapping of two consecutive leases can make space for newly arrived deadline lease when preemption based algorithm fails to do so. Table 2 describes the information of submitted leases. It contains requested resources, time at which the lease was submitted, start time, duration in minutes and deadline. For simplicity, memory requirement of leases is not considered for swapping. Table 1 shows the schedule prepared by the existing algorithm of Haizea. The existing algorithm of Haizea will process the leases submitted to it based on the submit time. The lease having earliest submit time, will be processed first. Thus, the existing algorithm will accept lease-1 and schedule it from 12:00 PM to 12:40 PM

Fig. 1. Schedule prepared by existing algorithm.

Fig. 2. Schedule prepared by proposed algorithm (swapping only).

then it will accept lease-2 and schedule it from 12:40 PM to 01:00 PM then it will accept and schedule lease-3 from 01:00 PM to 01:20 PM. UP to now the leases were accepted directly because there were enough resources to satisfy those leases. For lease-4, the existing algorithm will try to find resources but it will not find enough resources. It will try to reschedule the leases, which were already accommodated in the system. Here, it will not be able to find 1 node for 40 min between 12:30 PM to 01:20 PM because it cannot preempt lease-3. As a result, it will reject lease-4. In the same way it will also reject lease-5. Thus, the existing algorithm will be able to schedule only first 3 leases. From Fig. 1 it is clear that slot 12:00 PM to 01:00 PM has idle resources. If these resources can be pushed back towards the new lease, then it might get scheduled on them. Pushing the idle resources towards requested time slot of new lease can be achieved by swapping in a way such that the first lease has higher requested resources, second will have less requested resources than first and so on. Thus, basically it is a sorting of leases to be rescheduled in decreasing order of requested resources. Fig. 2 shows how swapping can be applied to push idle resources towards requested time slot of a new lease. First three leases will be scheduled as shown in Fig. 1. When lease-4 arrives, it will require rescheduling of previous three leases. Swapping will arrange leases in decreasing order of requested resources; i.e. lease-3 followed by lease-2 and lease-1 sequentially. Once scheduled in the order as shown in Fig. 2 there will be enough resources to schedule lease-4. So, lease-4 will be scheduled from 12:30 PM to 01:10 PM. As shown in Fig. 2, after

A. Nathani et al. / Future Generation Computer Systems 28 (2012) 94–103

97

Table 3 Information of submitted leases. Lease no.

Nodes Submit time (AM)

Start time (PM)

Duration Deadline (PM)

1 2 3 4

2 3 2 4

12:00 12:00 12:00 01:00

20 40 50 20

11:10 11:20 11:30 11:40

12:30 01:00 01:50 01:50

Fig. 4. Schedule prepared by existing algorithm after applying backfilling.

Fig. 3. Schedule prepared by existing algorithm.

scheduling leases 1, 2, 3 and 4, there will be enough resources to schedule lease-5 directly. Example 2 (Backfilling). The second example illustrates how backfilling of leases can make space for a newly arrived deadline lease while preemption based algorithm fails to do so. Table 3 describes the information of submitted leases. It contains requested resources, time at which the lease was submitted, start time, duration in minutes and deadline. For simplicity, memory requirement of leases is not considered for backfilling. As shown in Fig. 3 the first three leases will be processed in increasing order of the submitted time. When lease-4 arrives, there are not enough resources to schedule it. In that case, preemption based algorithm tries to make space for lease-4 by rescheduling already accommodated leases. As the algorithm cannot preempt any lease, it will not be able to find 4 nodes for 20 min in slot (01:00 PM, 01:50 PM) and it will reject lease-4. If lease-1 and lease-2 can be swapped then lease-4 can be accommodated. But if lease-2 is scheduled first then lease-1 will miss its deadline. Hence we cannot swap lease-1 and lease-2. Thus, sometimes swapping will also fail to schedule a lease. In this kind of cases backfilling can help as explained below. It is seen in Fig. 3 that there are two nodes unused in slot (12:00 PM, 12:20 PM). To use these resources backfilling can be applied. As lease-2 cannot be scheduled at its start time, there are some idle resources in the slot (12:00 PM, 12:20 PM). The system can try to fill these resources by some other lease residing after lease-2 in the set of leases to be rescheduled. Lease-3 can be scheduled from 12:00 PM to 12:20 PM. It will be suspended at 12:20 PM to allow lease-2 to run. The remaining 30 min of lease-3 can be scheduled from 01:00 PM to 01:30 PM. Due to this backfilling there is a slot (01:30 PM, 01:50 PM) having 4 idle nodes. This slot can be utilized to schedule lease4. There is a limitation of backfilling that it requires preemptions. Fig. 4 shows how backfilling can be used to schedule lease-4 while preemption and swapping could not schedule it. 3.4. Proposed algorithm The proposed algorithm will change the existing algorithm to handle Advance Reservation and Immediate leases. Changes proposed in those existing algorithms and the proposed algorithm to handle deadline sensitive leases are explained below: 3.4.1. Algorithm to handle deadline sensitive leases Fig. 5 shows the algorithm to handle deadline sensitive leases. When a new deadline sensitive lease is submitted to Haizea, it

Fig. 5. Algorithm to handle newly arrived deadline sensitive lease.

needs to check whether accepting this new lease as a deadline sensitive lease is worth or not. This checking is performed based on slack calculation. Slack value is actually the spare time that we will have after executing this new lease for its full duration within its deadline. Slack value will decide the preemptability of this lease. If slack has lower value, then the chances of preempting this new deadline sensitive lease in future and still satisfying its deadline are less. If slack has a higher value, then the chances of preempting the new deadline sensitive lease to make space for advance reservation or immediate lease and still satisfying its deadline are higher. The lower bound for slack can be decided by the cloud provider. We have assigned value 1.1 to it. If slack is less than the decided lower bound for it then it is better to reject this lease and request the user to submit it as an advance reservation lease or extend its deadline. If calculated slack value is higher than the decided lower bound for slack value, then the proposed algorithm can try to schedule this lease as deadline sensitive lease. The algorithm will try to find a single time slot, which can satisfy the complete lease within the specified deadline. If such a time slot is available, then it will schedule this new lease in this time slot. If such a time slot is not available, then it will try to find several time slots which together can satisfy the complete lease within its deadline. If it cannot find a single slot or multiple slots to accommodate a new lease, then it will check whether it can make space for a new lease by rescheduling already accommodated deadline sensitive leases. The Proposed algorithm initially finds set S(leases which should be rescheduled to make space for new lease) by using the procedure FIND-LEASES-TO-BE-RESCHEDULED. It tries to reschedule leases of set S by applying swapping and then if needed backfilling. Once set S is found, it will call procedure FIND-ORDEROF-LEASES-BY-SWAPPING to arrange leases based on swapping

98

A. Nathani et al. / Future Generation Computer Systems 28 (2012) 94–103

Fig. 7. Procedure to reschedule deadline leases which were found in Procedure 1.

Fig. 6. Procedure to find leases which should be rescheduled to make space for new lease.

conditions. After applying swapping, it will try to schedule leases one by one by calling SCHEDULE-WITHOUT-CONSIDERINGBACKFILLING procedure. If any lease misses its deadline then it will try to schedule leases of set S considering backfilling by calling SCHEDULE-CONSIDERING-BACKFILLING procedure. If any lease still misses deadline then the new lease cannot be scheduled and it will be rejected. Descriptions of different procedures are given below: Procedure 1 (FIND-LEASES-TO-BE-RESCHEDULED). This procedure is shown in Fig. 6. It will consider only those leases which are not running that means their start time is greater than the current system time. In first iteration the procedure begins with a set S containing only new lease. Start point (SP) is the start time and end point (EP) is the deadline of the new lease. In the next step, it finds all the leases whose requested time slot intersects with the slot (SP, EP). All these leases are added into set S. In remaining iterations, SP will be equal to maximum of (current time, minimum of (start time of all the leases of S)) and EP will be equal to maximum of (deadline of all the leases of set S). It needs to find all the leases for which requested time slot intersects with the slot (SP, EP). All these leases are added into set S. This procedure runs until the SP and EP of current iteration are equal to the SP and EP of previous iteration respectively. If S is obtained using the above procedure, all remaining leases that are scheduled before SP, but after the current system time are the leases to finish their execution before the start time of any of the leases in S. Hence, they will not affect the scheduled time of any of the leases in S and hence of the new lease [9]. Procedure 2 (RESCHEDULE-DEADLINE-LEASES). This procedure is shown in Fig. 7. It takes as input the set of leases found in procedure-1. It will call the procedure FIND-ORDER-OF-LEASESBY-SWAPPING to arrange the found leases based on swapping conditions explained in example 1. In the next step, it will try to schedule these leases one by one without considering backfilling by calling SCHEDULE-WITHOUT-CONSIDERING-BACKFILLING procedure. If any lease misses its deadline then it will try to schedule them considering backfilling by calling SCHEDULE-CONSIDERINGBACKFILLING procedure. If the lease set is still not schedulable then it will reject new lease. Procedure 3 (FIND-ORDER-OF-LEASES-BY-SWAPPING). This procedure is shown in Fig. 8. It will take as input the leases found by procedure-1 (leases_set). Initially, the procedure will sort the leases of leases_set in increasing order of deadline. It will take

Fig. 8. Procedure to arrange leases of set ‘‘leases_set’’ based on swapping conditions.

leases up to new lease from leases_set and apply bubble sort on them. The bubble sort will try to sort the leases in decreasing order of requested resources. For each pair of consecutive leases, it will check two things to decide whether they can be swapped or not: 1. If the requested resources of a lease are less than the requested resources of next lease. 2. If after swapping, both the leases can be completed within their specified deadline. If above two conditions are satisfied then it will swap two consecutive leases. This procedure will actually swap only those leases which can be swapped without missing any deadline. As an output, this procedure will give leases that are ordered based on swapping conditions. Procedure 4 (SCHEDULE-WITHOUT-CONSIDERING-BACKFILLING). This procedure is shown in Fig. 9. Once we have leases ordered based on swapping conditions, they will be scheduled one by one on available resources using this procedure. To schedule a lease on available resources, it will first try to find single time slot within its deadline. If a single slot is not found then it will try to find multiple slots within its deadline. If any of the leases misses its deadline while being scheduled on available resources then it will cancel schedule prepared by this procedure. This also implies that only swapping is not enough to accommodate a new lease. Now, backfilling can be applied on these leases to see whether a new lease can be accommodated or not. Procedure 5 (SCHEDULE-CONSIDERING-BACKFILLING). This procedure is shown in Fig. 10. It takes as input the set of leases which are produced by the procedure FIND-ORDER-OF-LEASESBY-SWAPPING. It will schedule them one by one on available resources. After scheduling a lease, it will check whether the next lease can be scheduled on its start time or not. If the next lease cannot be scheduled on its start time because of lack of resources then

A. Nathani et al. / Future Generation Computer Systems 28 (2012) 94–103

99

Fig. 9. Procedure to schedule leases obtained from Procedure 3 without considering backfilling.

Fig. 11. Modified algorithm to handle newly arrived immediate or advance reservation lease.

Fig. 10. Procedure to schedule leases obtained from Procedure 3 considering backfilling.

the slot (next_lease_start_time, current_lease_end_time) will have idle resources. These idle resources can be filled by other leases residing after the next lease in the given set of leases. It will find these leases and store them in backfill set. The backfill set will be sorted in decreasing order of requested resources. After that the procedure will schedule leases in backfill set one by one to fill the idle slot. Haizea has an algorithm named schedule-as-soon-as-possible. It finds a single time slot which can satisfy a lease. We have modified this algorithm to find multiple slots also to satisfy a lease. All the procedures use this algorithm whenever they want to schedule a deadline lease on available resources. So, to find out the complexity of proposed algorithm it is necessary to find out the complexity of this algorithm. This algorithm first finds changepoints (The time at which the resource availability will change that is start time, end time, suspend time and resume time of all the VMs in considered time slot) for a particular time slot. For each changepoint, it will try to map virtual nodes of a lease on available physical nodes at that changepoint until the virtual nodes are over or no more virtual nodes can be scheduled on these resources. The complexity of this algorithm is influenced by number of changepoints(C ) and requested virtual nodes(v ) of lease being scheduled. Here, C = (S + e + s + r )

(1)

where, S = start times of all VMs e = end times of all VMs s = suspend times of all VMs r = resume times of all VMs The complexity of the algorithm proposed in the paper mainly depends on the complexities of procedure-1, procedure-3 and procedure-5. The worst case complexity of procedure-1 is O(N 2 ). The worst case complexity of procedure-3 and procedure-5 is O(N 2 C v ). So, the worst case complexity of the proposed algorithm is O(N 2 C v ). Here, N is the number of leases which will be rescheduled to make space for new lease. A typical Utility function for this algorithm will have two important objectives.

• Minimize the rejection rate of the incoming requests. • Minimize reshuffle cost (avoid rescheduling of already accommodated leases as much as possible). This algorithm does not consider lesser preemption as its objective.

3.4.2. Modified algorithm to handle new immediate or advance reservation lease This algorithm is shown in Fig. 11. Whenever a user submits immediate or advance reservation lease, the existing algorithm just checks whether enough resources are available or not for requested duration at requested start time. If the resources are available then Haizea accepts this lease else it will reject it. The modification to existing algorithm to handle immediate and advance reservation lease is described below. As Haizea has deadline sensitive leases already accommodated in the system, it also needs to check if it can make space for a new lease by rescheduling previously accommodated deadline sensitive leases. For rescheduling, Haizea will consider only those deadline sensitive leases, which are currently not active and whose scheduled time slot intersects with requested time slot of new immediate or advance reservation lease. The modified algorithm to handle newly arrived immediate or advance reservation lease is given below: 4. Experiments and results In order to evaluate the performance of proposed algorithm to schedule deadline sensitive leases, it is compared with the existing algorithm of Haizea to schedule deadline sensitive leases. From now we will refer the existing algorithm of Haizea to schedule deadline sensitive leases as existing algorithm. The existing algorithm considers finding single slot to schedule deadline sensitive leases and only preemption to reschedule deadline sensitive leases. In addition to the methods used by existing algorithm, the proposed algorithm also applies finding multiple slots while scheduling deadline sensitive leases and swapping while rescheduling deadline sensitive leases. We have not yet implemented backfilling. To evaluate both the algorithms, following parameters were considered. 1. System Utilization. Here System Utilization (U) is calculated as Used_resources . (2) Total_resources Here Used_resources and Total_resources are calculated as follows: If we submit n leases to system then Total_resources = TotalCPU ∗ (leasen .deadline − lease1 .start ). Used resources for each lease = lease.CPU ∗ lease.duration. Used_resources = Used_resources + Used resources for each lease. Number of leases accepted. Number of leases rejected. Number of leases requiring rescheduling of already accommodated leases to be accepted. Number of leases rescheduled to make space for a newly arrived lease. U =

2. 3. 4. 5.

100

A. Nathani et al. / Future Generation Computer Systems 28 (2012) 94–103

Table 4 Leases accepted, rejected and system utilization for 13 leases.

Table 6 Leases accepted, rejected and system utilization for 33 leases.

Sets for 13 deadline leases

Algorithm

Accepted

Rejected

Utilization

Sets for 33 deadline leases

Algorithm

Accepted

Rejected

Utilization

Set 1

Existing Proposed Existing Proposed Existing Proposed Existing Proposed Existing Proposed

9 12 10 13 11 11 8 10 9.5 11.5

4 1 3 0 2 2 5 3 3.5 1.5

73.27 84.28 90.17 94.64 62.50 62.50 79.46 88.39 76.35 82.45

Set 1

Existing Proposed Existing Proposed Existing Proposed Existing Proposed Existing Proposed

24 29 20 25 28 32 24 32 24 29.5

9 4 13 8 5 1 9 1 9 3.5

72.70 82.4 65.48 69.46 68.81 75 61.16 66.73 67.03 73.39

Set 2 Set 3 Set 4 Average

Table 5 Leases accepted, rejected and system utilization for 22 leases. Algorithm

Accepted

Rejected

Utilization

Set 1

Existing Proposed Existing Proposed Existing Proposed Existing Proposed Existing Proposed

13 18 14 17 16 18 15 18 14.5 17.75

9 4 8 5 6 4 7 4 7.5 4.25

67.96 84.86 58.03 65.53 75 77.77 79.43 88.30 70.10 79.11

Set 3 Set 4 Average

Set 3 Set 4 Average

Table 7 Leases accepted, rejected and system utilization for 43 leases.

Sets for 22 deadline leases

Set 2

Set 2

Sets for 43 deadline leases

Algorithm

Accepted

Rejected

Utilization

Set 1

Existing Proposed Existing Proposed Existing Proposed Existing Proposed Existing Proposed

28 38 33 41 20 40 26 43 26.75 40.5

15 5 10 2 23 3 17 1 16.25 2.75

64.80 81.60 60.33 67.75 61.67 68.26 69.87 82.53 64.16 75.03

Set 2 Set 3 Set 4 Average

4.1. Experimental setup

Existing Algorithm Proposed Algorithm

50

40 Accepted leases

The proposed algorithm is implemented in Python and simulated on Haizea by modifying its VM scheduler component. For this purpose, Haizea was used in simulated mode. For experiment purpose, four physical nodes each having one CPU and 1024 MB memory are considered as the total available resources at cloud provider side. The number of leases is varied and readings are taken for the metrics described above. A lease has mainly four parameters — start time, duration, deadline and number of nodes. All the parameters are taken randomly and manually such that half of the leases of a particular set are scheduled directly without requiring rescheduling and half will require rescheduling of previously accommodated deadline sensitive leases or finding multiple slots. The lease files used to perform the experiments can be downloaded from http://web.lnmiit.ac.in/gaurav/researchresult/PolicyBasedResourceAllocationinIaaSCloud.zip

Accepted leases

30

20

10

0 10

20

30 40 Submitted leases

50

Fig. 12. Accepted leases.

4.2. Experiment 1: accepted leases, rejected leases and system utilization

Rejected leases 25

The experiment is performed by considering four sets of 13, 22, 33 and 43 leases respectively. In this experiment, we measure number of leases accepted, number of leases rejected and system utilization for both proposed and existing algorithm.

20 Rejected leases

4.2.1. Results of experiment 1 Tables 4–7 show the number of leases accepted, rejected and system utilization for existing and proposed algorithms. The graphs shown in Figs. 12–14 are plotted based on the average readings shown in Tables 4–7 respectively. As shown in figures, the average number of deadline sensitive leases accepted and average system utilization are more in case of proposed algorithm and the average number of deadline sensitive leases rejected by proposed algorithm is less than that of existing algorithm. The proposed algorithm applies the concepts of finding multiple slots and swapping in addition to the methods used by existing algorithm. Finding multiple slots concept can schedule a

Existing Algorithm Proposed Algorithm

15

10

5

0 10

20

40 30 Submitted leases Fig. 13. Rejected leases.

50

A. Nathani et al. / Future Generation Computer Systems 28 (2012) 94–103

Leases requiring rescheduling of other leases

Table 8 Leases requiring rescheduling of other leases.

13

Algorithm

Existing Proposed Existing Proposed Existing Proposed Existing Proposed

22 33 43

20

Leases requiring rescheduling Set 1

Set 2

Set 3

Set 4

Avg

4 3 9 10 10 9 15 16

3 2 8 7 13 14 10 6

2 2 6 65 5 3 23 16

5 4 8 8 11 10 17 15

3.5 2.75 7.75 7.75 9.75 9 16.25 13.25

16 14 12 10 8 6 4 2

Utilization [%] 100

0 10

Existing Algorithm Proposed Algorithm

90

20

30 40 Submitted leases

Leases rescheduled to schedule a new lease

80 175 70

Existing Algorithm Proposed Algorithm

150

60

50 10

50

Fig. 15. Leases requiring rescheduling.

20

30 40 Submitted leases

50

Leases rescheduled

Utilization [%]

Existing Algorithm Proposed Algorithm

18 Leases requiring rescheduling

No. of deadline leases

101

100 75 50

Fig. 14. System utilization.

lease in parts. Swapping concept can bring idle resources towards requested time slot of a new lease. Thus, they increase the chance of a new lease getting accepted. The existing algorithm just applies preemption to reschedule already accommodated leases to make space for a new lease. Due to this, more number of new leases are getting rejected in the case of existing algorithm. Figures in Figs. 12–14 also conclude that sometimes only preemption is not enough, the order in which leases are rescheduled to make space for this new lease is also important to schedule this new lease.

125

25 10

20

Table 9 Total rescheduled leases. No. of deadline leases

Algorithm

13

Existing Proposed Existing Proposed Existing Proposed Existing Proposed

22 33 43

4.3.1. Results of experiment 2 Table 8 shows number of leases requiring rescheduling of other leases to get scheduled. Rescheduling previously accommodated leases to make space for a newly arrived lease is the main overhead for proposed and existing scheduling algorithms. Average number of leases requiring rescheduling of other leases is more in case of existing algorithm. Whenever a new deadline sensitive lease arrives, it will try to find a single slot for that lease. If single slot is not found then it will try to reschedule other leases to make space for a new lease. Several new leases which require rescheduling of already accommodated leases to be accepted in case of existing algorithm, will be scheduled by finding multiple slots in case of the proposed algorithm. Thus, these leases will not require rescheduling of already accommodated leases to be accepted in case of proposed algorithm. Therefore, the average number of leases which require rescheduling of other leases is less

50

Fig. 16. Total number of leases rescheduled to make space for new deadline leases.

4.3. Experiment 2: leases requiring rescheduling The experiment is performed for four sets of 13, 22, 33 and 43 leases. In this experiment, we have found how many deadline sensitive leases amongst the total deadline sensitive leases require rescheduling of previously accepted deadline sensitive leases.

30 40 Submitted leases

Total number of rescheduled leases Set 1

Set 2

Set 3

Set 4

Average

26 24 68 38 123 38 240 74

15 17 51 36 83 122 143 27

14 7 36 21 77 10 74 84

18 21 21 33 29 44 79 110

18.25 17.25 44 32 78 53.5 134 73.75

in case of proposed algorithm. It can be seen from Fig. 15. The graph shown in Fig. 15 is plotted based on the average readings shown in Table 8. 4.4. Experiment 3: total number of leases rescheduled The experiment is performed for four sets of 13, 22, 33 and 43 leases. It is performed to find the number of deadline sensitive leases which must be rescheduled to make space for new leases.

4.4.1. Result of experiment 3 The graph shown in Fig. 16 is plotted based on the average readings shown in Table 9. If the algorithm needs to reschedule

102

A. Nathani et al. / Future Generation Computer Systems 28 (2012) 94–103

other leases to make space for a new lease, then it first finds the leases to be rescheduled. For this, the existing algorithm finds the leases which start or end after start time of new lease. It considers a lot of leases, which will not affect new lease’s requested slot. But the procedure used in proposed algorithm finds more relevant leases which will be rescheduled to make space for a new lease. Fig. 16 indicates that the procedure used in proposed algorithm will consider less number of leases which should be rescheduled to make space for a new lease compared to the existing algorithm. 5. Related work In multiprocessor systems we have the problem of when and where to place the task. Here, if uni-processor real time scheduling algorithm such as earliest deadline first [10,11] or rate monotonic algorithm [12] are used then it will give low performance. Mainly two strategies are there to handle scheduling on multiprocessor. They are partitioning and non-partitioning (global) [13,14]. In partitioning, each task will be allocated to a processor based on bin packing algorithm. This task then executes exclusively on that machine. In non-partitioning strategy, tasks can execute on any machine. The remaining problem is of assigning tasks to processor. This can be handled by bin packing algorithm. This bin packing problem is NP hard. So, most of the scheduling algorithms to handle real time scheduling in multiprocessors apply heuristics for bin packing problem [15–17]. In these algorithms, periodic tasks were considered and they also assumed that information about the tasks was known a priori but it is not the case in grid and cloud computing. Grid computing manages a large number of heterogeneous resources owned by various organizations. It supports various scheduling and admission control policies. At the same time, grid computing must also provide various quality of service parameters. Scheduling in grid is mainly based on various policies supported by grid. Various Grid scheduling algorithms have been proposed based on static and dynamic policies, objective functions, applications models, adaptation, QoS constraints [18]. Advance reservation is one of the policies supported by grid to provide several quality of service parameters. To schedule advance reservation with laxity is known to be NP Hard problem [19]. Algorithms are proposed in [9,20] to schedule advance reservation with laxity but these algorithms considers only non-preemptive tasks while rescheduling to admit a new request in system. [21,22] and [23] discuss the scheduling of best effort and advance reservation jobs but they use job as a resource provisioning abstraction instead of leasing resources directly. Job as an abstraction of resource provisioning ties the job execution with resource provisioning. Therefore, the consumers cannot use the resources directly. They can just submit the jobs. It was not able to handle the application which are not expressible as a collection of jobs or where direct access to the resources was required [8]. In [24], it is shown that resource allocation for a set of tasks in a cloud is an NP complete problem. An approximation algorithm is proposed in [24] which minimizes the number of allocated resources which need to be reserved for a batch of tasks. Authors in [24] are trying to find out the optimal resource allocation for a set of tasks. 6. Conclusion and future work The proposed algorithm finds multiple slots in addition to finding single slot while scheduling a deadline sensitive lease. It also applies two concepts (swapping and backfilling) in addition to preemption, while rescheduling already accommodated leases to make space for a newly arrived lease. Swapping uses the information available about leases to be rescheduled, to decide

the order in which they should be rescheduled. When swapping and preemption both fails to schedule a lease, the proposed algorithm applies the concept of backfilling. Backfilling can fill up the idle resources, which cannot be filled up by consecutive lease. Backfilling has a disadvantage of requiring more preemption, which increases overall overhead of the system. By applying rescheduling when an advance reservation or immediate lease gets rejected, it tries to increase acceptance of leases. The results show that by applying swapping and multiple slots concepts, the number of accepted leases increases compared to the existing algorithm. It also shows that the proposed algorithm requires rescheduling of fewer leases compared to the existing algorithm of Haizea. An algorithm can be developed to enhance the response time of best-effort leases. We can also extend the algorithm to provide soft deadline for best-effort leases, which can be converted to hard deadline as starvation reaches up to certain level. An admission control policy for best-effort leases can be developed depending on the queue size. The backfilling algorithm proposed is not implemented and tested and it can be considered as a part of future work. Acknowledgment The authors would like to thank Dr. Srikrishnan Divakaran, DAIICT for suggestions and views given during this work. References [1] B. Sotomayor, R. Montero, I. Llorente, I. Foster, An Open Source Solution for Virtual Infrastructure Management in Private and Hybrid Clouds, IEEE Internet Computing, 2009, pp. 5–8. [2] Amazon EC2, http://aws.amazon.com/ec2/. [3] Nimbus, http://www.nimbusproject.org/. [4] D. Nurmi, R. Wolski, C. Grzegorczyk, G. Obertelli, S. Soman, L. Youseff, D. Zagorodnov, The eucalyptus open-source cloud-computing system, in: Cloud Computing and Applications 2008 (CCA08), 2008. [5] B. Sotomayor, K. Keahey, I. Foster, Overhead Matters: A Model for Virtual Resource Management, IEEE Computer Society, 2006, pp. 1–8. [6] B. Sotomayor, R. Montero, I. Llorente, I. Foster, Resource leasing and the art of suspending virtual machines, in: IEEE International Conference on HPCC-09, June 2009, pp. 1–9. [7] B. Sotomayor, R.S. Montero, I.M. Llorente, I. Foster, Capacity leasing in cloud systems using the opennebula engine, in: Cloud Computing and Applications 2008 (CCA08), 2008, pp. 1–5. [8] B. Sotomayor, K. Keahey, I. Foster, Combining Batch Execution and Leasing Using Virtual Machines, in: HPDC, Manchester, 2008, pp. 1-9. [9] U. Farooq, S. Majumdar, E.W. Parsons, Efficiently Scheduling Advance Reservations in Grids, Technical Report SCE-05-14, Dept. of Systems & Computer Engineering, Carleton University, Ottawa, Canada, pp. 1-9, 2005. [10] J. Stankovic, M. Spuri, K. Ramamritham, G. buttazzo, Deadline Scheduling for Real-Time Systems: EDF and Related Algorithms, Kluwer, London, 1998, pp. 1–150. [11] G.C. Buttazzo, J.A. Stankovic, S. Superiore, S. Anna, RED: Robust Earliest Deadline Scheduling, in: Proceedings of the 3rd International Workshop on Responsive Computer Systems, 1993, pp. 1–20. [12] C.L. Liu, J. Layland, Scheduling algorithms for multiprogramming in a hard realtime environment, Journal of the ACM (1973) 47–61. [13] J. Carpenter, S. Funk, P. Holman, A. Srinivasan, J. Anderson, S. Baruah, A categorization of real time multiprocessor scheduling problems and algorithms, in: J. Y.-T. Leung (Ed.), Handbook of Scheduling: Algorithms, Models, and Performance Analysis, Chapman Hall/CRC Press, 2004, pp. 1–27. [14] S. Lauzac, R. Melhem, D. Mosse, Comparison of Global and Partitioning Schemes for Scheduling Rate Monotonic Tasks on a Multiprocessor, IEEE Computer Society, 1998, pp. 1–8. [15] J. Lopez, M. Garcia, J. Diaz, D. Garcia, Utilization bounds for multiprocessor rate monotonic scheduling, Real-Time Systems (2003) 1–12. [16] G. Manimaran, C. Siva Ram Murthy, An efficient dynamic scheduling algorithm for multiprocessor real-time systems, IEEE Transactions on Parallel and Distributed Systems (1998) 1–8. [17] S. Dhall, C. Liu, On a real-time scheduling problem, Operations Research (1978) 1–15.

A. Nathani et al. / Future Generation Computer Systems 28 (2012) 94–103 [18] F. Dong, S.G. Akl, Scheduling Algorithms for Grid Computing: State of the Art and Open Problems. Technical Report, School of Computing, Queens University, Kingston, Ontario, 2006, pp. 1–31. [19] G. McMahon, M. Florian, On scheduling with ready times and due dates to minimize maximum lateness, Operations Research (1975) 475–482. [20] U. Farooq, S. Majumdar, E.W. Parsons, Impact of Laxity on Scheduling with Advance Reservations in Grids, IEEE, 2005, pp. 1–4. [21] W. Smith, I. Foster, V. Taylor, Scheduling with Advanced Reservations, IEEE/ACM, 2000. [22] I. Foster, C. Kesselman, C. Lee, R. Lindell, K. Nahrstedt, A. Roy, A distributed resource management architecture that supports advance reservations and co-allocation, in: Proceedings of the International Workshop on Quality of Service, 1999, pp. 1–9. [23] Q. Snell, M.J. Clement, D.B. Jackson, C. Gregory, The performance impact of advance reservation meta-scheduling, in: Proceedings of the Workshop on Job Scheduling Strategies for Parallel Processing, 2000. 2007, pp. 1–8. [24] F. Chang, J. Ren, R. Viswanathan, Optimal resource allocation in clouds, IEEE 3rd International Conference on Cloud Computing (2010) 1–8.

Amit Nathani completed M.Tech (ICT) from Dhirubhai Ambani Institute of Information and Communication Technology in the year 2010. He is working as a software developer.

103

Sanjay Chaudhary is a Professor at Dhirubhai Ambani Institute of Information and Communication Technology (DA-IICT), Gandhinagar, India. His research areas are Distributed Computing, Service-Oriented Computing, Multicore Architectures Programming, and ICT Applications in Agriculture. He has authored four books and a number of book chapters. He has published a number of research papers in international conferences, workshops and journals. He has served on many programme committees of International conferences and workshops and he is also a member of review committees of leading journals. Three Ph.D. candidates have completed Ph.D. under his supervision. He holds a doctorate degree in computer science from Gujarat Vidyapeeth. Prior to joining DA-IICT, he worked with Gujarat University. He has worked on various large-scale software development projects for corporate sector, co-operative sector, and government organizations. He is actively involved in various consultancy and enterprise application development projects. He has received research grants from IBM and Microsoft in the area of Innovations and High Performance Computing. Sanjay Chaudhary has provided his services to committees, formed by Gujarat Government, India. Details about Sanjay Chaudhary are available at the following URL:http://intranet.daiict.ac.in/˜sanjay/. Gaurav Somani is a faculty member at LNM Institute of Information Technology, Jaipur, India. His research interests include cloud computing, virtualization, ad hoc networks and distributed computing. He has published in many reputed conferences like IEEE CLOUD 2009, IC3 2010, IEEE PDGC 2010. A monograph has been published on his recent works by VDM Publishers on Scheduling and Isolation in Virtualization. More details about Gaurav Somani can be found at his home page http://www.lnmiit. ac.in/People/GauravSomani/Gaurav.aspx.