ANGEL: Agent-Based Scheduling for Real-Time Tasks in...

0018-9340 (c) 2015 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. Seehttp://www.ieee.org/publications_standards/publications/rights/index.html for more information.

This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI10.1109/TC.2015.2409864, IEEE Transactions on Computers

IEEE TRANSACTIONS ON COMPUTERS, VOL. ×, NO. ×, 2015 1

ANGEL: Agent-Based Scheduling for Real-Time Tasks inVirtualized Clouds

Xiaomin Zhu, Member, IEEE, Chao Chen, Laurence T. Yang, Senior Member, IEEE, and Yang Xiang, SeniorMember, IEEE

Abstract—The success of cloud computing makes an increasing number of real-time applications such as signal processing andweather forecasting run in the cloud. Meanwhile, scheduling for real-time tasks is playing an essential role for a cloud providerto maintain its quality of service and enhance the system’s performance. In this paper, we devise a novel agent-based schedulingmechanism in cloud computing environment to allocate real-time tasks and dynamically provision resources. In contrast to traditionalcontract net protocols, we employ a bidirectional announcement-bidding mechanism and the collaborative process consists of threephases, i.e., basic matching phase, forward announcement-bidding phase and backward announcement-bidding phase. Moreover, theelasticity is sufficiently considered while scheduling by dynamically adding virtual machines to improve schedulability. Furthermore,we design calculation rules of the bidding values in both forward and backward announcement-bidding phases and two heuristicsfor selecting contractors. On the basis of the bidirectional announcement-bidding mechanism, we propose an agent-based dynamicscheduling algorithm named ANGEL for real-time, independent and aperiodic tasks in clouds. Extensive experiments are conductedon CloudSim platform by injecting random synthetic workloads and the workloads from the last version of the Google cloud tracelogsto evaluate the performance of our ANGEL. The experimental results indicate that ANGEL can efficiently solve the real-time taskscheduling problem in virtualized clouds.

Index Terms—agent-based scheduling, real-time, bidirectional announcement-bidding mechanism, virtualized cloud.

F

1 INTRODUCTION

Nowadays, cloud computing has become an efficient paradigm tooffer computational capabilities as services on a “pay-per-use” basis[1]. Meantime, the virtualization technology is commonly employedin clouds, e.g., the Amazon’s elastic compute cloud (EC2), to provideflexible and scalable services, which gives users the illusion of infiniteresources [2]. Running applications on virtual machines (VMs) hasbecome an effective solution [3]. Leveraging the server virtualizationtechnology, a single host can simultaneously run multiple virtualmachines (VMs). The VMs can be dynamically relocated by live VMoperations (e.g., creation, migration and deletion) to achieve fine-grained optimization of computing resources. This technology hasbrought ample opportunities for scalability, cost-efficiency, reliability,and high resource utilization [4], [5], [6].

It is worthwhile noting that many applications deployed on cloudshave the real-time nature in which the correctness depends not onlyon the computational results, but also on the time instants at whichthese results become available [7]. For some applications, it is evenmandatory to provide real-time guarantees. For example, weatherforecasting and medical simulations have strict deadlines which,once broken, make the result useless [8]. Therefore, it is critical forthese kinds of deadline-constrained applications to obtain guaranteedcomputing services within timing constraint.

In order to obtain high performance for running real-time ap-plications in clouds, scheduling plays an essential role, in whichreal-time tasks in these applications are mapped to machines such

• Xiaomin Zhu and Chao Chen are with the Science and Technology onInformation Systems Engineering Laboratory, National University of De-fense Technology, Changsha, Hunan, 410073 P. R. China. E-mail: {xmzhu,chenchao}@nudt.edu.cn.

• Laurence T. Yang is with the Department of Computer Science, St.Francis Xavier University, Antigonish, NS, B2G 2W5, Canada. E-mail:[email protected].

• Yang Xiang is with the School of Information Technology, Deakin University221, Burwood, VIC 3125, Australia. E-mail: [email protected]

that deadlines and response time requirements are satisfied. Efficientscheduling algorithms are able to facilitate the resources to contributethe whole system, and thus can significantly boost the system’sservice capability. To date, a handful of scheduling strategies onclouds have been investigated (e.g., [7], [9], [10], [11], [12], [13],[14]). Unfortunately, an important scheduling technology, i.e., agent-based scheduling technology that shows great advantages in dealingwith task allocation issue in distributed systems is not sufficientlyconsidered on the emerging clouds. The agent-based technology is de-rived from distributed artificial intelligence (DAI) domain. It has greatstrength in open, complex, dynamic, and distributed environment dueto the inherent nature that agents make decisions based on localinteractions, and good agent-based scheduling algorithms allow themto adapt, and enable them to coordinate through self-organization[15]. According to Wooldridge and Jennings [16], an agent is “a self-contained program capable of controlling its own decision makingand acting, based on its perception of its environment, in pursuit ofone or more objectives”, which provides a new way to allocate tasksin clouds.

In the scheduling process based on agent technique, multipleindividual agents are capable of composing a multi-agent system,in which these agents interact with each other to accomplish the goalof the system. Meanwhile, interaction technology among agents is ofgreat importance, and the corresponding rules in the interactions canbe designed by users, which makes agent-based technology flexibleenough to meet totally different requirements while scheduling.To facilitate interactions, the ability to cooperate, coordinate, andnegotiate with each other is required. Cooperation is the process whenseveral agents work together and draw on the broad collection of theirknowledge and capabilities to achieve a common goal. Coordinationis the process of achieving the state in which actions of agents fit inwell with each other. Negotiation is a process by which a group ofagents communicate with one another to try to come to a mutuallyacceptable agreement on some matter [17]. Agent-based schedulingis to employ these operations so as to finish task allocation on cloudresources.




Our work deviates from traditional scheduling algorithms in theliterature by designing and implementing a novel scheduling mech-anism based on an intelligent agent approach and then developa corresponding dynamic scheduling algorithm for real-time tasksexecuted in clouds.

Contributions. The major contributions of this work are summa-rized as follows:

• We designed a bidirectional announcement-biddiing mechanismbased on an improved contract net protocol.

• We developed an agent-based scheduling algorithm invirtualized clouds or ANGEL for independent, real-time tasks.

• We designed two selection strategies - MAX strategy and Pstrategy to determine the contractors.

• We investigated a dynamic scaling up method used for ourANGEL to further enhance the schedulability.

The rest of this paper is organized as follows. The related work inthe literature is summarized in Section 2. Section 3 formally modelsthe dynamic real-time scheduling problem in virtualized clouds. InSection 4, the agent-based scheduling mechanism is presented. This isfollowed by our proposed ANGEL algorithm and the main principlesbehind it in Section 5. The experiments and performance analysis aregiven in Section 6. Section 7 concludes the paper with a summaryand future directions.

2 RELATED WORK

Up to now, a great deal of scheduling strategies have been developedin a wide range of application domains. Scheduling algorithms canbe either static (i.e., off-line) or dynamic (i.e., on-line) [18]. In staticscheduling algorithms, assignments of tasks and the time at whichthe tasks start to execute are determined a priori. They are usuallydeveloped for periodic tasks [7]. Whereas the arrival time of aperiodictasks is not known a priori and with timing requirements (i.e., real-time), the tasks must be scheduled by dynamic scheduling strategies.

Specially, there exist many scheduling algorithms that were de-signed for cloud computing environment. For example, Zhang etal. developed a heterogeneity-aware framework that dynamicallyadjusts the number of machines to strike a balance between energysavings and service delay [19]. He et al. investigated the reductionof resource consumption by VM consolidation, and employed theGenetic Algorithm (GA) to solve the issue [5]. Kong et al. con-centrated on the uncertainties of both the availability of virtualizedservers and workloads, and utilized the type-I and type-II fuzzylogic systems to predict the resource availability and workloads toenhance the system’s availability and responsiveness performance[20]. Rodriguez and Buyya suggested a resource provisioning andscheduling strategy for real-time workflow on IaaS cloud, in whichthe particle swarm optimization technique was employed to mini-mize the overall workflow execution within timing constraint [21].Malawski et al. presented several static and dynamic schedulingalgorithms to enhance the guarantee ratio of real-time tasks whilemeeting QoS constraints such as budget and deadline. Besides, theytook the variant of tasks’ execution time into account to enhance therobustness of their methods [22]. Goiri et al. proposed an energy-efficient and multifaceted scheduling policy, modeling and managinga virtualized cloud, in which the allocation of VMs is based onmultiple facets to optimize the provider’s profit [23]. Graubner et al.suggested an energy-efficient scheduling algorithm that was basedon performing live migrations of virtual machines to save energy,and the energy costs of live migrations including pre-processingand post-processing phases were considered [24]. However, theaforementioned algorithms cannot efficiently address the large-scaledynamic scheduling issue. It should be noted that in clouds, both

tasks and resources are dynamically varied. To be specific, most oftasks arrive in an aperiodic mode and resources changed with thevariation of system workload. Thus, the scheduling algorithms thatare used to allocate tasks and adjust resources are very essential toenhance the system’s schedulability and utilization in dynamic cloudenvironment.

In agent-based scheduling, each agent can directly represent aphysical object such as a machine, a task, and an operator [25].Thus, agent-based scheduling algorithms have the ability to allocatetasks through negotiation, which brings great advantages for dealingwith dynamically arrived tasks in distributed systems (e.g., the cloudcomputing systems).

The agent-based scheduling algorithms can be classified into twocategories, i.e., threshold-based algorithms and market-based algo-rithms. In the first category, scheduling algorithms are developed fromthe threshold model in insect colonies. For example, Price evaluatedthe adaptive nature inspired task allocation against decentralizedmulti-agent strategies [26]. Campos et al. investigated the dynamicscheduling and division of labors in social insects [27]. Generally,the complexity of this kind of algorithms is high. Another categoryof agent-based scheduling algorithms derives from market-basedmechanism, in which the contract net protocol (CNP) is the mostlyused market-based mechanisms where groups of individuals employmarket-like approaches i.e., auction, to decide who realizes thesegoals, with bids based on the individual’s desire and the ability tofinish their goals. For example, Owliya et al. investigated a ring-likemodel as a competitor for the web-like CNP-based job allocationwithin the concept of holonic manufacturing systems and a newalgorithm was developed for scheduling and the assignment of tasksto resources based on the ring structure [28]. Later, Owliya et al.proposed four agent-based models for task allocation in manufactur-ing shop floor in which two of them employed the CNP. Besides,the prominent position of the agent-based scheduling within thebroad area of scheduling was discussed [29]. Lange et al. studieda new approach to modeling well scheduling processes in oil and gasindustry using the notion of virtual enterprise with intelligent agentsand contract net protocol in multi-agent systems technologies, whichefficiently assists in the scheduling of resources across the well lifecycle [30].

In this study, we investigated a novel agent-based schedulingmethod based on an improved CNP model to address the real-timetask scheduling issue in virtualized clouds. The proposed strategyadopts the bidirectional announcement-bidding mechanism where thetasks and resources are both announcers and bidders to improve thesystem’s schedulability.

3 MODELS AND PROBLEM FORMULATION

In this section, we introduce the system model, notation, and ter-minologies used throughout in this paper. For future reference, wesummarize the main notation used in this study in Table 1.

3.1 System modelIn this paper, the target systems is a virtualized cloud that is charac-terized by an infinite set H = {h1, h2, · · · } of physical computinghosts providing the hardware infrastructure for creating virtualizedresources to satisfy users’ requirements. The active host set ismodeled by Ha with n elements, Ha ⊆ H . For each host hk ∈ Ha,it contains a set Vk = {v1k, v2k, · · · v|Vk|k} of virtual machines(VMs). All the VMs constitute a VM set V = {V1, V2, · · ·V|Ha|}.In this study, a VM is a basic computing unit and its count isdynamically varied based on the system workload. Namely, VMscan be dynamically created if the system is under heavy workload




TABLE 1Definitions of Main Notation

Notation Definitionti The ith task in the task set T = {t1, t2, · · · }ai, li, di, pi ti’s arrival time, length/size, deadline, and priorityhk The kth host in the host set H = {h1, h2, · · · }Ha Active host set, Ha ⊆ Hvjk The jth VM on host hk

rjk, cjk vjk’s ready time and creating timesijk, eijk, fijk The start time, execution time, and finish time of ti on vjkxijk xijk is “1” if ti is assigned to vjk; otherwise, xijk is “0”tAi The ith task agent in the task agent set TA = {tAi , i = 1, 2, · · · , |T |}vAjk The jth VM agent in the VM agent set V A = {vAjk, j = 1, 2, · · · , |Vk|, k = 1, 2, · · · , |Ha|}mA The manager agentfbijk, bbijk The bidding value in forward bidding and backward bidding, respectivelyfpjk The finish time of ti’s preceding task tp on the same VM vjkani The ith announcer in the announcer set AN = {ani, i = 1, 2, · · · , n}biij The jth bidder for ani in the bidder set BIi = {biij , j = 1, 2, · · · ,m}bvij The bidding value of biij for ani

so as to meet users’ QoS; otherwise, VMs can be deleted if thesystem workload decreases to improve the system utilization, whichsufficiently embodies one of the most important characteristics ofclouds - elasticity. The fractions of CPU performance are defined byMillion Instructions Per Second (MIPS). For a given VM vjk, we userjk to denote the ready time of VM vjk and cjk to represent the finishtime of creating VM vjk. We consider a set T = {t1, t2, · · · } oftasks that are independent, non-preemptive, aperiodic and importantlywith deadlines. A task ti submitted by a user can be modeled by acollection of parameters, i.e., ti = {ai, li, di, pi}, where ai, li, diand pi are the arrival time, task length/size, deadline, and priority oftask ti, respectively. Let sijk be the start time of task ti on VM vjk.Similarly, fijk represents the finish time of task ti on vjk. Due tothe heterogeneity in terms of CPU processing capabilities of VMs,we let eijk be the execution time of task ti on VM vjk. In addition,xijk is employed to reflect a mapping of tasks to VMs at differenthosts in a virtualized cloud, where xijk is “1” if task ti is allocatedto VM vjk at host hk and is “0”, otherwise.

In this paper, we assume that each task cannot be preempted whileexecuting, thus one task can only be allocated to one VM that cannotbe shared by another task if these two tasks have overlap in terms ofexecution. Consequently, we have the following constraint C1.

C1 :

|Ha|∑k=1

|Vk|∑j=1

xijk = 1 or 0 i ∈ [1, |T |],

xpjk = 0 if(xijk = 1) ∧ ([spjk, fpjk]

∩ [sijk, fijk] = ∅) .

(1)The start time sijk of task ti on VM vjk is designed for its earliest

start time that is related to its arrival time ai and the ready time rjkof vjk.

sijk = max{ai, rjk}, (2)

where ready time rjk is the time instance at which the VM can beused. Consequently, we can calculate rjk according to the followingformula:

rjk =

{cjk if ∀xpjk = 0|ap ≤ ai,

max{fijk} if ∃xpjk = 1|ap ≤ ai.(3)

The finish time fijk of task ti executed by vjk can be easilydetermined as follows:

fijk = sijk + eijk. (4)

The finish time is, in turn, used to determine whether the task’sdeadline can be satisfied. Therefore, we have the following deadlineconstraint C2 on a resource allocation:

C2 :

xijk = 0 if

∀j ∈ [1, |Vk|], ∀k ∈ [1, |Ha|],sijk + eijk > di

,

xijk = 1 or 0 if∃j ∈ [1, |Vk|], ∃k ∈ [1, |Ha|],

sijk + eijk ≤ di.

(5)

If task ti is executed by vjk, the vjk is unavailable to other tasksin this time slot. This comes to the following constraint:

C3 :(sijk ≥ fpjk)∨(fijk ≤ spjk)

if∀i = p, j ∈ [1, |Vk|], k ∈ [1, |Ha|],

xijk = xpjk = 1 (6)

From C3, we can easily get that if task ti and task tp are bothallocated to VM vjk, they cannot be executed at the same time,namely, sijk ≥ fpjk and fijk ≤ spjk.

3.2 Scheduling ObjectivesIn this work, we take task guarantee ratio and priority guarantee ratioas two main scheduling objectives. Regrading the real-time tasks, ourscheduling algorithm strives to finish as many tasks as possible beforetheir deadlines. Moreover, if the system cannot finish all tasks due toheavy workload, our scheduling algorithm tries to finish tasks withhigher priorities. Consequently, we have the objectives modeled asfollows:

(1) Task Guarantee Ratio (TGR)

max

|Ha|∑k=1

|Vk|∑j=1

|T |∑i=1

xijk

/|T |

. (7)

(2) Priority Guarantee Ratio (PGR)

max

|Ha|∑k=1

|Vk|∑j=1

|T |∑i=1

xijk · pi/ |T |∑

i=1

pi

. (8)

4 AGENT-BASED SCHEDULING MECHANISM DESIGN

On the design of our agent-based scheduling mechanism, we attemptto employ a kind of market-like mechanism - contract net protocol(CNP) to complete task scheduling in virtualized clouds. The CNPmodel allows agents to coordinate and produce desirable system-wide behavior. More importantly, we devise a novel bidirectionalannouncement-bidding mechanism within the CNP model to improvescheduling quality.




Task

Information

Matching

Result

VM Agent Set

Send VM Information to Manger

Agent

Receive Announcement Information

Calculate Bidding Values

Bid to Task Agents

Receive Awarded VM Information

Generate Task Agent

Send Task Agent Information

Receive Matching Result

Make Forward Announcement to VM

Agents

Receive VM Agents Bidding

Make Forward Awarding Contract for

VM Agents

VM Information

Generate VM

Information Board

Receive Task Agent

Information

Conduct Primary

Matching between

Tasks and VMs

Filtrate Matching

Result between

Tasks and VMs

Task Set

Task Agent Set Manager Agent

Send Awarded VMs to VM agents

VM Set

Make Backward Announcement to

Tasks Agents

Calculate Bidding Values

Receive Backward Announcement

Information

Make Backward Awarding Contract

for VM Agents Bid to VM Agents

Yield Contact between Tasks and

VMs

Forward

Announcement

Forward

Bidding

Awarded VMs

Backward

Announcement

Receive Task Agents Bidding

Generate or Update VM Agent

Backward

Bidding

Task

VM1

2

3

4

5

6

7

8

9

10

Fig. 1. Basic Interactions of Agents

4.1 Agent DesignIn this study, we design three kinds of agents, i.e., task agent, VMagent, and manager agent. Each of them works based on their ownrules and they cooperate with each other to finish the auction processof CNP. These agents are modeled as follows:

• TA = {tAi , i = 1, 2, · · · , |T |} is a task agent set, where tAirepresents the ith task agent in TA.

• V A = {vAjk, j = 1, 2, · · · , |Vk|, k = 1, 2, · · · , |Ha|} is a VMagent set, where vAjk donates the jth VM on hk.

• mA represents a manger agent.A task agent yields with the arrival of the task and disappears

with the finish of the task. A VM agent yields when the VM isestablished, and dies out when the VM is destroyed. However, themanger agent is always existent. The VM agents constantly updatetheir own information and release their information to the mangeragent.

4.2 Design of Bidirectional-Bidding Announcement Mech-anismTo facilitate understanding the bidirectional announcement-biddingmechanism, we firstly give two important definitions used in it, i.e.,the forward announcement-bidding and the backward announcement-bidding.

Definition 1. Forward Announcement-Bidding: An announcementthat is from the task’s perspective, namely, the task information istreated as the announcement information to announce towards VMs,and VMs bid to tasks.

Definition 2. Backward Announcement-Bidding: An announce-ment that is from the VM’s point of view, i.e., the VM information

is treated as the announcement information to tasks, and tasks bid toVMs.

The key point of task scheduling is to select a proper VM forone task to run on. On the arrival of a new task, it will choose thebest suited VM for execution as it likes. Note that in the forwardannouncement-bidding, it is probably to occur the phenomenon thatmultiple tasks have selected the same VM as their preference. Thus,the VM selects one of the tasks reversely to finish task allocation,which is taken place in the backward announcement-bidding phase.After the bidirectional announcement-bidding, the newly arrived taskwill be assigned to a VM or to be rejected according to the VMs’service capability. In the following part of this paper, we willdiscuss both the forward announcement-bidding and the backwardannouncement-bidding mechanisms in detail. Fig. 1 illustrates basicinteractions of the three kinds of agents.

In the process of interactions, the VM agent set constantly gen-erates or updates VM agents based on the real VM configuration.That is to say, if a new VM is created, then a new VM agent isbuilt; if a VM is cancelled, then the corresponding VM agent isremoved; if a VM’s performance such as CPU, RAM is varied, therelevant VM agent information is updated. Once VMs’ informationis changed, the VM agent set forwards it to the manager agent on itsboard. Now, we are in the position to discuss how the bidirectionalannouncement-bidding mechanism works. It basically includes threephases, i.e., basic matching phase, forward announcement-biddingphase, and backward announcement-bidding phase.

4.2.1 Basic Matching PhaseIn this phase, all the VMs satisfying the basic requirement of tasksare filtered to shrink the VM scope and thus reduce the interactions




between task agents and VM agents. The detailed process of basicmatching is described as follows:

• A new task agent is generated when the task arrives.• The task agent sends basic task requirement information to the

manager agent including task ID, task type, etc.• The manager agent receives the task requirement information

and then matches each task agent with VM agents from VMinformation board to choose those VMs that satisfy the basicrequirements posted by task agents.

• The manager agent sends the selected VMs’ information tocorresponding task agents.

4.2.2 Forward Announcement-Bidding PhaseIn the forward announcement-bidding phase, the task agents negotiatewith VM agents so as to select one or multiple VMs for a taskon condition that the VMs can guarantee the timing constraint. Theforward announcement-bidding phase is introduced as below:

• The task agent set receives the VMs’ information from themanager agent.

• Each task agent generates forward announcement informationincluding its arrival time, length, deadline, priority, etc, and thensends it to relevant VM agents.

• The VM agents receive the tasks’ announcement informationand calculate the corresponding bidding values based on somerules.

• The task agents receive the VM agents’ bidding values and makeforward awarding contracts for VM Agents.

Fig. 2 depicts an example of the first two phases, i.e., the basicmatching phase and the forward announcement-bidding phase. In thisexample, we assume there are three task agents - tA1 , tA2 , and tA3 ,and four VM agents vA11, vA21, vA12, and vA13 that are available at thebeginning.

Fig. 2(a) illustrates that task agents tA1 , tA2 , and tA3 firstly sendtheir basic requirements to the manager agent mA. Then the manageragent mA matches task agents and VM agents and send feedbackinformation to these task agents. From Fig. 2(a), it can be observedthat vA11 can meet the basic requirements of tA1 and tA2 ; vA12 canonly meet the basic requirement of tA1 ; vA13 can only meet the basicrequirement of tA3 ; vA12 cannot meet the basic requirements of anytask agents. The reason why only part of VMs can meet the basicrequirements of tasks maybe due to lacking the applications deployedon these VMs to run the tasks. Consequently, tA1 can only makeforward announcement to vA11 and vA12, and tA2 can only make forwardannouncement to vA11, which greatly reduces the interaction volume.After that, the VM agents bid to task agents. Later, each task agentselects a suitable VM agent and gives a forward contract. Fig. 2(a)shows that tA1 and tA2 both select vA11. It should be noted that tA3 doesnot make forward announcement to any VM agent because there isno VM agent that can meet the basic requirement of tA3 . From Fig.2(a) and Fig. 2(b), we can find that the difference between them liesin that in Fig. 2(b) tA3 makes forward announcement to vA13 but vA13does not bid to tA3 , which can be explained that vA13 cannot finishtA3 before its deadline, thus there is no bidding from vA13. It is easyto get from Fig. 2 that tA3 cannot be finished in the two cases. Toaddress this issue, we sufficiently consider the elasticity of cloudsand attempt to maximize the guarantee ratio of real-time tasks bydynamically adding VMs. An example of adding VMs is illustratedin Fig. 3.

Once a task cannot be finished before its deadline using currentVMs, the manager agent will apply for VMs from clouds. Followingby this operation, a new VM is dynamically created to run the task.After that, the VM agent set adds the new VM agent and then sends

Task Information

11

Av 21

Av

12

Av

13

Av

1

At 2

At 3

At

Am

11

Av

12

Av

1

At

2

At

11

Av

Matched VMs

Forward Announcement

Forward Bidding

Forward Awarding Contract

1

2

3

4

5

(a)

Task Information

11

Av 21

Av

12

Av

13

Av

1

At 2

At 3

At

Am

11

Av

12

Av

1

At

2

At

11

Av

Matched VMs


13

Av

Forward Bidding

Forward Awarding Contract

1

2

3

4

5

(b)

Fig. 2. An Example of The First Two Phases

the update information to the manager agent. From Fig. 3(a), we canfind that the manager agent mA sends the newly created VM agentvA14 to task tA3 as a matched VM agent. Then, tA3 makes forwardannouncement to vA14. After calculating the bidding value by vA14, itbids to tA3 using this value. Finally, vA14 is capable of finishing tA3 ,so tA3 makes forward contract with vA14. It is observed from Fig. 3(b)that vA14 does not bid to tA3 although it is a newly created VM agentbecause the VM agent still cannot finish the task due to its tightdeadline. Thereby, tA3 has to be rejected.

4.2.3 Backward Announcement-Bidding PhaseFrom the forward announcement-bidding phase, it can be found thatperhaps there exists the case that multiple task agents select the sameVM agent. Consequently, the backward announcement-bidding isneeded to realize one-to-one match. In the backward announcement-bidding phase, VM agents only make backward announcement tothose task agents that have forward awarding contracts with them. Ifa VM agent is selected only by one task agent, then the task agentand VM agent confirm a contract directly. The detailed process ofbackward announcement-bidding phase is listed as below:

• The VM agents send backward announcement to task agentsthat make forward contracts with them.

• The task agents receive the VM agents’ announcement infor-mation and calculate the corresponding bidding values based on




Task Information

11

Av 21

Av

12

Av

13

Av

1

At 2

At 3

At

Am

11

Av

12

Av

1

At

2

At

11

Av

Matched VMs


Forward Bidding

Forward Awarding

Contract

1

2

3

4

5

14

Av

14

Av

VM Request

VM Provision

6

7

8

9

11

3

At

10

(a)

Task Information

11

Av 21

Av

12

Av

13

Av

1

At 2

At 3

At

Am

11

Av

12

Av

1

At

2

At

11

Av

Matched VMs


Forward Bidding

Forward Awarding

Contract

1

2

3

4

5

14

Av

14

Av

VM Request

VM Provision

6

7

8

9

Rejected

Task

(b)

Fig. 3. An Example of Adding VMs

some rules.• The VM agents receive the task agents’ bidding values and make

backward awarding contracts.• If a bidirectional contract is built between a task agent and a

VM agent, the task is allocated to the VM.Fig. 4 shows an example of the backward announcement-bidding

on the basis of the example in Fig. 3(a).In Fig. 4, vA11 makes backward announcement to tA1 and tA2 . Then

tA1 and tA2 bid to vA11. The VM agent vA11 compares the backwardbidding values of tA1 and tA2 , and then selects the task agent tA2 toaward a contract. It should be noted that vA14 directly awards a contractwith tA3 because only one task agent tA3 gives a forward contract tovA14. Hence, there is no need in terms of announcement and biddingbetween tA3 and vA14.

As a result, based on the bidirectional announcement-biddingmechanism, task t2 is allocated to virtual machine v11, and task t3is allocated to a newly constructed virtual machine v14. For the taskt1, it will be scheduled in the next round announcement and bidding.

Noticeably, although the aforementioned bidirectionalannouncement-bidding mechanism adds the step that the manageragent deals with the VM information, it can prominently reduce

11

Av

1

At 2

At 3

At

1

At

2

At

Backward Announcement Backward Bidding

Backward Awarding Contract

1

14

Av

11

Av 14

Av

2

3

3

At

Fig. 4. An Example of Backward Announcement

the scheduling burden of the system. The manager agent filters allthe VMs meeting the basic task requirement, which shrinks thescope of forward announcement. Thus, the calculations of forwardannouncement values are only for the matched VM agents. Thosenon-matched VM agents will not receive the forward announcementinformation, and thus the calculation time is significantly decreased.

4.3 Bidding ValuesIn the aforementioned bidirectional announcement-bidding mecha-nism, the selections are based on the bidding values. Thus, howto calculate bidding values becomes an important issue. In theforward announcement-bidding phase, task agents prefer to select theVM agents that have more capability to run them. Whereas in thebackward announcement-bidding phase, VM agents are inclined toselect the task agents with tighter deadlines. In this study, the biddingvalues including forward bidding value and backward bidding valueare designed in the following subsections.

4.3.1 Forward Bidding ValueIn the forward announcement-bidding, task agents make announce-ments and those VM agents meeting the basic requirements of thetask agents start to bid. The forward bidding values reflect thecapabilities of VM agents. The calculation of bidding values inforward bidding is on the VM agents. We use fbijk to represent thebidding value in forward bidding and it can be calculated as follows:

fbijk = di − eijk − fpjk , (9)

where fpjk represents the finish time of task ti’ preceding task tpon the same VM vjk. The formula is mainly to show the laxity oftask ti on vjk, and the bigger value of fbijk means that ti has moreflexible time to run on vjk before its deadline. fbijk > 0 means thatthe VM vjk has the ability to finish the task ti before its deadlinewithout affecting the executions of other tasks allocated to vjk. Incontrast, fbijk < 0 indicates that VM vjk cannot finish ti before itsdeadline. Fig. 5 depicts an example of calculating fbijk.

4.3.2 Backward Bidding ValueIn the backward announcement-bidding, VM agents make announce-ments and task agents bid to VM agents. bbijk is used to representthe bidding value of task ti to vjk, and it is calculated according tothe formula as below:

bbijk =pθi · eijk

(di − fij) ·K∑

k=k1

J∑j=j1

fbijk

, (10)

where the parameter θ represents the weight of priority, J denotesthe count of VM agents that have bid to task agent tAi . K denotes the




>0ijk

fbA

pt

A

it

pjkf

ijks

A

qt

id

(a)

0ijk

fb

A

pt

A

it

pjkf

ijks

A

qt

id

(b)

Fig. 5. An Example of Calculating fbijk

count of hosts in which there exist VM agents that have bid to taskagent tAi in the forward announcement-bidding phase. This formulais based on the following considerations. Firstly, the higher priority,the stronger requirement to allocate the task. Secondly, the tightera task’s finish time approaches its deadline, the higher likelihoodthis task cannot be allocated successfully, thus it should be allocatedpreferentially. Thirdly, the smaller number of VMs to execute a task,the smaller feasibility to finish this task. Hence, the task should beallocated with higher preference.

4.4 Selection StrategiesBoth in the forward and backward announcement-bidding phases, anannouncer is responsible for selecting a bidder to award contract if thebidder has the ability to execute this task. It is noted that differentstrategies may lead to distinctive performances. In this study, wedesign two kinds of selection strategies, i.e., MAX strategy and Pstrategy.

We use AN = {ani, i = 1, 2...n} to denote an announcer set,BIi = {biij , j = 1, 2...mi} to represent the bidder set for announcerani. BV = {bvij , i = 1, 2...n, j = 1, 2...mi} is the biddingvalue set, in which bvij denotes the bidding value of bidder biijfor announcer ani.

4.4.1 MAX StrategyWhen more than one bidder simultaneously bid to one announcer,the announcer will choose the bidder with maximal bidding value.∀ani ∈ AN , if biik is selected, it must meet the constraint:∀bvij ∈ BV ⇒ bvik ≥ bvij |j = k.

4.4.2 P StrategyP strategy means probability selection strategy. When there existmore than one bidder bid to one announcer in the same round, theannouncer will select a bidder according to probability policy.∀ani ∈ AN , the winning probability prj of bidder brij can be

calculated as:

prj = bvij

/ mi∑k=1

bvik. (11)

Without loss of generality, we let pr0 = 0. In addition, we let prbe a random number, and pr ∈ (0, 1). If the randomly generatednumber satisfies the following formula (12), then the bidder brij isselected as a contractor.

j−1∑m=1

prm < pr ≤j∑

n=1

prn (12)

As there are two selections in the bidirectional announcement-bidding mechanism, four kinds of scheduling algorithms based onthe above selection strategies can be constructed, i.e., MAX-MAX ,MAX-P , P -MAX and P -P .

5 AGENT-BASED SCHEDULING ALGORITHM ANGELIn this section, we present a novel agent-based scheduling algo-rithm in virtualized clouds - ANGEL on the basis of our agent-based scheduling model for independent, aperiodic, real-time tasks.Specifically, the ANGEL integrates the aforementioned bidirectionalannouncement-bidding mechanism and the MAX & P strategies.Moreover, ANGEL efficiently considers the schedulability, priority,and load balancing. The ANGEL is detailedly described as follows.

The pseudocode of the algorithm for manager agent is presentedin Algorithm 1. The manager agent schedules the tasks that arriveat the same time instant as one batch. Lines 2-4 in Algorithm 1represent that the manager agent chooses those VMs that satisfy basicrequirements of task agents, and sends the selected VMs’ informationto those corresponding task agents. The announcement-bidding phaserepeats in Lines 5-7 until all the tasks are allocated or rejected.

Algorithm 1: The Algorithm for Manager Agent

1 Twaiting ← the tasks that arrive at the same time instant;2 foreach tAi in Twaiting do3 V A

i ← the VM agents that satisfy the basic requirements oftAi ;

4 Send the V Ai to task agent tAi ;

5 while Twaiting = ∅ do6 The task agents start the forward announcement-bidding

phase using Algorithm 2;7 The VM agents start the backward announcement-bidding

phase using Algorithm 3;

Algorithm 2 depicts the pseudocode of the algorithm for taskagents. In Line 3, each task agent generates forward announcementinformation to relevant VM agents. The VM agents return thecorresponding bidding values in Line 4. According to the Eq. (9),fbijk ≥ 0 means that the VM vjk has the ability to finish thetask before its deadline, while fbijk < 0 indicates that the VMcannot finish the task. Consequently, the algorithm only adds thefbijk that is larger than or equal to zero into the valueList. Afterthe VMs’ bidding, the task agent ti selects a bidder vselect based onthe values in valueList using the MAX Strategy or the P Strategy.If valueList = ∅, it means that none of the existing VMs is able tofinish the task, and as a result the function scaleUpResources() isinvoked to create a new VM to accommodate the task. If it still failsto finish the task before its deadline, the task will be rejected.

The pseudocode of the algorithm for VM agents is shown in Algo-rithm 3. In Lines 4-6, the VM agents send backward announcementto task agents that send the forward contract with them, and the taskagents return the corresponding bidding values. Then, the VM agentschoose a bidder using the MAX Strategy or the P Strategy, andmake backward awarding contracts. By now, a bidirectional contractis built in Line 8, and the task is allocated to the VM.

If a task cannot fit in any existing VMs, a new VM will be created.Function scaleUpResource() in Algorithm 4 depicts the procedureof adding a new VM. The algorithm first tries to allocate the new VMto an active host. If there is no suitable host, the VM migration willfunction to make room for the new VM. If it still fails, a turned-offhost will be turned on and added into Ha.

We now evaluate the time complexity of ANGEL. Suppose Nvm

denote the maximum number of items in V Ai among all the task

agents. For Lines 2-6, the time complexity is O(Nvm). The timecomplexity of Line 8 is O(Nbidder), where Nbidder is the number ofitems in valueList. The time complexity of scaleUpResources()is O(Nhost). As a result, the time complexity of the algorithm for




Algorithm 2: The Algorithm for Task Agent

1 valueList← ∅;2 foreach vAjk in Vi do3 Task agent tAi sends the announcement information to vAjk;4 fbijk ← VM agent vAjk calculates the forward bidding

value;5 if fbijk ≥ 0 then6 valueList.add(fbijk);

7 if valueList = ∅ then8 Task agent ti selects a bidder vselect based on the values in

valueList using the MAX/P Strategy;9 else

10 vnew ← scaleUpResources();11 if vnew = NULL then12 The new VM vnew generates a new VM agent vAnew

and sends the information to the manager agent;13 Allocate ti to vnew;14 Twaiting.remove(tAi );15 else16 Reject ti;17 Twaiting.remove(tAi );

Algorithm 3: The Algorithm for VM Agent

1 Tcandidate ← the task agents that send the forward contractwith the VM agent vAjk;

2 if Tcandidate = NULL then3 valueList← ∅;4 foreach tAi in Tcandidate do5 bbijk ← tAi ’s backward bidding value;6 valueList.add(bbijk);

7 VM agent vAjk selects a bidder tAselect based on the values invalueList using the MAX/P Strategy;

8 Build a bidirectional contract between the vAjk and thetAselect;

9 Twaiting.remove(tAi );

task agents is O(Nvm + max{Nbidder, Nhost}). Because Nvm islarger than Nbidder and Nhost, the time complexity of Algorithm 2is O(Nvm).

For Algorithm 3, suppose Ntask denotes the number of items inTcandidate. The time complexity of Lines 2-6 is O(Ntask). The timecomplexity of Line 7 is O(Nbidder), where Nbidder is the number ofitems in valueList. Therefore, the time complexity of the algorithmfor VM agents is O(Nvm+Nbidder). As Ntask is larger than Nbidder ,the time complexity of Algorithm 3 is O(Ntask).

Finally, suppose the announcement-bidding phase repeats Mrounds until all the tasks are scheduled. The time complexity of theannouncement-bidding (Lines 5-7) in Algorithm 1 is O(M(Nvm +Ntask)).

6 PERFORMANCE EVALUATION

As mentioned in Section 4, both the MAX strategy and P strategycan be employed in either the forward announcement-bidding phaseor the backward announcement-bidding phase. Thus, four kindsof scheduling algorithms can be generated by employing differentselection strategies. We use ANGEL-M-M, ANGEL-M-P, ANGEL-P-M, and ANGEL-P-P to denote the four scheduling algorithms

Algorithm 4: Function scaleUpResources()

1 Create newVM with processing power Pnew;2 find← FALSE; vnew ← NULL;3 foreach hk in Ha do4 if hk can accommodate newVM then5 Allocate newVM to hk;6 vnew ← newVM ; find← TRUE;7 break;

8 if find == FALSE then9 sourceHost← Migrate VMs among the hosts to make

room for newVm;10 if sourceHost = NULL then11 Allocate newVm to sourceHost;12 vnew ← newVM ; find← TRUE;

13 if find == FALSE then14 Turn on a host hnew in H −Ha;15 if the capability of hnew satisfies Pnew then16 Allocate newVM to hnew;17 vnew ← newVM ;

based on MAX-MAX , MAX-P , P -MAX , and P -P strategies,respectively. Besides, we compare them with an improved classi-cal scheduling algorithm - Improved Greedy (I-Greedy for short)scheduling algorithm as shown in Algorithm 5.

Algorithm 5: The I-Greedy Algorithm

1 T ← newly arrived tasks and tasks in the waiting queue;2 find← FALSE;3 foreach ti in T do4 foreach vjk in V do5 Calculate the bidding value fbijk;6 if fbijk > 0 then7 Allocate ti to vjk;8 find← TRUE;

9 if find == FALSE then10 Create a new VM vpq and calculate the bidding value fbipq;11 if fbipq > 0 then12 Allocate ti to vpq;

13 else14 Reject ti;

The performance metrics by which we evaluate the system perfor-mance include:

1) Task Guarantee Ratio (TGR) defined as: TGR=Total count oftasks guaranteed to meet their deadlines/Total count of tasks;

2) Priority Guarantee Ratio (PGR): PGR=Sum of priorities oftasks that are finished before their deadlines/Sum of priorities of alltasks.

6.1 Simulation SetupIn order to ensure the repeatability of the experiments, we choosethe way of simulation to evaluate the performance of aforementionedalgorithms. In our simulations, the CloudSim toolkit [31] is chosenas a simulation platform. Based on the characteristics of cloudcomputing, we add some new settings to conduct our experiments.The detailed setting and parameters are given as follows:




TABLE 2Parameters for Simulation Studies

Parameter Value (Fixed)-(Varied)Task count (5000)-(1000∼9000)bathsizeLower (500)-(100,300,500,700,900,1100)intervalT imeLower (s) (50)-(10,30,50,70,90,110,130)theta (1)-(1,2,3,4,5,6)

1) Each host is modeled to have one CPU core and the CPUperformance can be 1000 MIPS, 1500 MIPS, or 2000 MIPS;

2) Each VM requires one CPU core with 250, 500, 750, 1000MIPS, 128 MB of RAM and 1 GB of storage;

3) The start-up time of a host is 30s and the creation time of aVM is 30s;

4) Tasks arrive dynamically in batch mode. In our experiment,the task count batchtaskCount in each batch is selected to be anuniformly distributed random variable between bathsizeLower andbathsizeLower + 200. The initial value of bathchsizeLower is300;

5) The simulation interval is set by the total task count, varyingfrom 1000 to 10000. And each group of tasks are divided into batchesaccording to the value of batchtaskCount aforementioned;

6) The interval time between two batches isin uniform distribution, the distribution interval is(intervalT imeLower, intervalT imeLower + 90). The initialvalue of intervalT imeLower is 50;

7) The priority of each task is an uniformly distributed randomvariable number between 1 and 10;

8) The computing length of each task is defined as a uniformlydistributed random value between 5× 104 MI and 15× 104 MI.

9) We use parameter baseDeadline to control a task’s deadlinethat can be calculated as:

di = ai + baseDeadline, (13)

where parameter ai denote the arrival time of task, andbaseDeadline is in uniform distribution U(baseT ime, a ×baseT ime) and we set a = 8;

10) The value of θ is set to 1 when calculating the bidding valuein backward announcement;

11) As the VMs in cloud computing environment can be con-structed dynamically, we establish 50 VMs in the initialization. Whenthe VMs cannot satisfy the requirements of tasks, new VMs will becreated. In the contrary, when there exists any VM that has been idlefor a given time, it will be turned off by the system.

The values of parameters are listed in Table 2.

6.2 Performance Impact of Random SequenceThe scheduler schedules the tasks that arrive at the same time instantas one batch. It is very essential to determine which task in thebatch should be firstly scheduled and which parameter is supposed tohave a considerable impact on the performance of algorithms. In thisgroup of experiment, the scheduling sequence of tasks in one batchis random determined in ANGEL-M-M, ANGEL-M-P, ANGEL-P-M, ANGEL-P-P and I-Greedy. Fig. 6 shows the performances of thefive algorithms in terms of TGR and PGR.

It can be observed from Fig. 6(a) that the TGRs of ANGEL-M-M, ANGEL-M-P, ANGEL-P-M and ANGEL-P-P are much higherthan that of I-Greedy because the ANGELs employ the bidirec-tional announcement-bidding mechanism which considers both theconditions of tasks and VMs. As a result, they are able to reach

1000 3000 5000 7000 900075

80

85

90

95

Task Count

Tas

k G

uara

ntee

Rat

io (

%)

ANGEL−M−MANGEL−M−PANGEL−P−MANGEL−P−PI−GREEDY

(a)

1000 3000 5000 7000 900075

80

85

90

95

Task Count

Prio

rity

Gua

rant

ee R

atio

(%

)


(b)

Fig. 6. Performance Impact of Random Sequence

better global solutions. In contrast, I-Greedy does not employ thebidirectional announcement-bidding mechanism, so the tasks areallocated on a proper VM directly without the consideration of thecondition of VMs. In this way, the performance among the wholesystem cannot be guaranteed, and the scheduling solutions may be notoptimized. In addition, an interesting phenomenon can be observedfrom Fig. 6(a) that the TGRs almost keep stable when the task countin one batch varies. This is can be attributed to the fact that there areinfinite resources in the cloud. When the task count increases, thesystem can satisfy the new request by creating new VMs to finishtasks before their deadlines. Despite of the infinite resources in thecloud, some tasks still cannot be accepted because it takes additionaltime to create a new VM and turn on a new host, which causesthat tasks cannot start timely, and thus miss their deadlines. Thescalable resource is a main advantage of clouds, which makes it bea perfect platform to process real-time tasks. Besides, we can findthat ANGEL-P-M performs better than others, which demonstratesthat using P strategy in the forward bidding phase and MAXstrategy in the backward bidding phase will provide the best systemperformance.

From Fig. 6(b), we can observe that ANGEL-M-M, ANGEL-M-P, ANGEL-P-M and ANGEL-P-P exhibit a better performancethan I-Greedy in terms of PGR because I-Greedy dose not takethe task priority into consideration during the scheduling. However,when ANGEL-M-M, ANGEL-M-P, ANGEL-P-M and ANGEL-P-Pcalculate the bidding value in the backward announcement-biddingphase, the priority is taken into account. Therefore, a task with higherpriority is more likely to be allocated successfully even under therandom sequence, which makes ANGELs achieve higher PGRs.

It can be concluded from Fig. 6 that ANGEL-M-M, ANGEL-M-P,ANGEL-P-M and ANGEL-P-P are superior to I-Greedy with regardsto both PGR and TGR. Our proposed algorithms can efficiently solvethe scheduling problem for real-time tasks and fully utilize the mainadvantage of clouds, namely, the scale of VMs can dynamically varyaccording to the current state of the system.

6.3 Performance Impact of Priority-Based Sequence

In this group of experiment, the newly arrived tasks in one batchare sorted by their priorities in a descent order, and then they arescheduled by ANGELs and I-Greedy. Fig. 7 shows the performancesof ANGEL-M-M, ANGEL-M-P, ANGEL-P-M, ANGEL-P-P and I-Greedy.

We can observe that, under the priority-based sequence, ANGEL-M-M, ANGEL-M-P, ANGEL-P-M and ANGEL-P-P still perform bet-ter than I-Greedy in terms of both PGR and TGR. By comparing Fig.6(a) and Fig. 7(a), we can see that there is little difference on TGR




1000 3000 5000 7000 900075

80

85

90

95

Task Count

Tas

k G

uara

ntee

Rat

io (

%)


(a)

1000 3000 5000 7000 900075

80

85

90

95

Task CountP

riorit

y G

uara

ntee

Rat

io (

%)


(b)

Fig. 7. Performance Impact of Priority-Based Sequence

under the two scheduling sequences. This result indicates that thescheduling sequence has almost no impact on TGR because the VMsin a cloud can be dynamically created, and thus some parameters, e.g.,priority, deadline can determine if a task can be executed successfully.Nonetheless, the experimental results in Fig. 6(b) and Fig. 7(b)suggest that the PGR of I-Greedy under the priority-based sequenceis higher than that under the random sequence, while the PGRs ofANGELs show little difference under the two sequences. The reasonis that ANGEL-M-M, ANGEL-M-P, ANGEL-P-M and ANGEL-P-P adopt the bidirectional announcement-bidding mechanism, and thepriority is considered in the calculation of bidding values. In this way,the tasks with higher priorities have more possibility to be scheduledsuccessfully. However, I-Greedy pays no attention to the priority oftasks, and VMs accept any task that can be finished by it. When thetasks are sorted by their priorities, the tasks with higher priorities willbe scheduled earlier and are more likely to be executed successfully,which makes the I-Greedy achieve higher PGR under the priority-based sequence.

We can conclude from Fig. 6 and Fig. 7 that when schedulingreal-time tasks, ANGEL has the ability to achieve both higher TGRand PGR than I-Greedy. In addition, the scheduling sequence hasobvious impact on I-Greedy showing little influence on ANGEL. Theexperimental results reveal that ANGEL is with higher adjustabilityand stability by using the bidirectional announcement-bidding mech-anism.

6.4 Performance Impact of Arrival Rate

A group of experiments are conducted in this section to ob-serve the impact of arrival rate on the performance. ParameterintervalT imeLower that varies from 10 to 130 with an incrementof 20 determines the interval time between two consecutive batches.Again, the interval time further decides the task arrival rate. Theexperimental results are depicted in Fig. 8.

Fig. 8(a) demonstrates that when we increase the parameterintervalT imeLower from 10 to 130, the TGRs of all the al-gorithms increase with the explanation that the system workloadbecomes light gradually. Therefore, the possibility to accept moretasks enhances. An interesting observation is that in the period ofintervalT imeLower increasing from 10 to 30, the TGR of ANGELincreases greatly because more small-size tasks can be accepted.However, when we increase intervalT imeLower from 30 to 70,the increment of TGR is relatively slight. We can attribute the reasonto the fact that all small-size tasks have been accepted but somebig-size tasks still cannot be accepted because the system workloadis still heavy. Further, when the intervalT imeLower increasesfrom 70 to 130, the TGR of ANGEL increases obviously. We can

10 30 50 70 90 110 13075

80

85

90

95

100

intervalTimeLower

Tas

k G

uara

ntee

Rat

io (

%)


(a)

10 30 50 70 90 110 13075

80

85

90

95

100

intervalTimeLower

Prio

rity

Gua

rant

ee R

atio

(%

)


(b)

Fig. 8. Performance Impact of intervalT imeLower

attribute this result to the fact that the system workload becomeslight, thus more big-size tasks can also be accommodated. It is worthnoting that the TGR of ANGEL turns out to be higher than that ofother I-Greedy when intervalT imeLower varies. The reason is thatANGEL employs the bidirectional announcement-bidding mechanismand is able to adaptively add the VMs striving to accepting moretasks.

We can observe from Fig. 8(b) that ANGEL-M-M, ANGEL-M-P,ANGEL-P-M and ANGEL-P-P exhibit a better performance than I-Greedy with regard to PGR. The reason is similar to that in Fig. 8(a).Another observation is that some PGRs decrease when the parameterintervalT imeLower varies from 30 to 70 because although somebig-size tasks can be accommodated, their priorities may not veryhigh. Whereas some tasks with higher priorities cannot be acceptedbecause they cannot be finished before their deadlines. Consequently,some PGRs degrades. Besides, we can also see that the PGR ofANGEL (see Fig. 8(b)) is a little higher than TGR of ANGEL (seeFig. 8(a)) with the explanation that ANGEL sufficiently considerstasks’ priorities while scheduling.

6.5 Performance Impact of θ

In our experiments, the value of θ plays an important role todetermine the weight of priority. The goal of this group of experimentis to study the impacts of θ on the performance of ANGEL. Fig. 9illustrates the performance of ANGEL when varying the parameterfrom 1 to 6 with an increment of 1.

1 2 3 4 5 670

75

80

85

90

95

Theta

Tas

k G

uara

ntee

Rat

io (

%)

ANGEL−M−MANGEL−M−PANGEL−P−MANGEL−P−P

(a)

1 2 3 4 5 670

75

80

85

90

95

Theta

Prio

rity

Gua

rant

ee R

atio

(%

)


(b)

Fig. 9. Performance Impact of θ

It can be observed from Fig. 9(a) and Fig. 9(b) that our ANGELachieves higher PGR than TGR, which can be explained that ANGELsufficiently considers task priorities in its selection policy. This




inclination to take task priority into account is derived from thebidding value in the backward announcement-bidding phase.

Fig. 9(a) shows that with the increment of θ, the task guaranteeratio only varies in a very small scope, and almost keeps stable.However, the PGRs raise when the value of θ increases from 1 to 6(See Fig. 9(b)). The reason is that ANGEL sufficiently considers thetask priority while scheduling, i.e., it prefers to allocate tasks withhigher priorities. Consequently, the increasing of PGR is more distinctwhen the value of θ increases. The experimental results indicate thatANGEL has excellent performance to allocate tasks with priorities.

6.6 Performance Impact of Task Count in One Batch

Now we investigate the impact of the task count in one batch onthe performance of the ANGEL. The parameter batchSizeLowervarying from 100 to 1100 with an increment of 200 is used todetermine the number of tasks in a batch. The experimental resultsare shown in Fig. 10.

100 300 500 700 900 110070

75

80

85

90

95

batchSizeLower

Tas

k G

uara

ntee

Rat

io (

%)


(a)

100 300 500 700 900 110070

75

80

85

90

95

batchSizeLower

Prio

rity

Gua

rant

ee R

atio

(%

)


(b)

Fig. 10. Performance Impact of Task Count in One Batch

Fig. 10(a) demonstrates that when we increase thebatchSizeLower from 100 to 500, the TGR of ANGEL noticeablyincreases. This is due to the fact that ANGEL is capable of addingVMs to accommodate more tasks when the system workloadbecomes heavy with the increase of tasks in a batch. Thus, theTGR is improved correspondingly. Nevertheless, an interestingobservation from Fig. 10 (a) is that when we continue increasingbatchSizeLower from 500 to 1100, the TGR significantly degradesbecause when the task size in one batch is larger, more tasks surgeinto the systems at the same time making the tested system heavilyloaded, whereas the current active hosts are not enough to acceptthese tasks, thus more hosts will be started and VMs will be createdon the started hosts to accommodate these tasks. However, dueto the deadline constraints of tasks and the timing requirement ofcreating VMs, more tasks cannot be finished before their deadlineswhen constantly increasing the batch size. Consequently, the TGRdegrades inevitably. This result indicates that ANGEL can offerbetter system performance when selecting a suitable batch size.

Fig. 10(b) shows that the PGR has similar trend with TGR in Fig.10 (a). However, it is obvious that PGR is higher than TGR with thesimilar explanation in other groups of experiments.

6.7 Performance on a Real-World Trace

The aforementioned groups of experiments demonstrate the per-formance of the different algorithms in various random syntheticworkloads. To further evaluate the practicality and efficiency of ourproposed algorithms in practical use, in this subsection, we carry out

experiments on a real-world trace deriving from the latest version ofthe Google cloud tracelogs [32].

The Google cloud tracelogs are make up of task events as well asresource demand and usage records for over 25 million tasks groupedin about 672 thousand jobs over a time span of 29 days. It is relativelydifficult to conduct an experiment based on all the tasks due to theenormous count of tasks in the tracelogs. As a result, the day 18,a representative day among the 29 days according to the analysisin [33], was selected as a testing sample. There were 955,626 taskssubmitted to the cloud system in day 18. To observe the change ofthe task count over the time, we depict the count of tasks submittedin every 100 seconds in Fig. 11, where we can easily observe thatthe task count fluctuates greatly over the time. In some time stamps,a great deal of tasks surge into the system, the resource demandis at a peak, whereas the resource demand decreases sharply at thetimes tamps where a few of tasks were submitted into the system,which brings a grant challenge for the system to schedule these taskssufficiently.

0 2 4 6 8

x 104

0

2000

4000

6000

8000

10000

12000

14000

time(s)

Task C

ount

Fig. 11. The Count of Tasks Submitted to the System.

Based on the task information in the day 18, the mean value of theexecution time (ET) of the tasks is 1,076 seconds, and the majorityof the tasks execute in less than 1,000 seconds. Additionally, we canobserve from Fig. 12 that the execution time follows a Lognormaldistribution where most of the tasks are with short execution time.The distribution of response time (RT), i.e., the time span from atask’s submission to the task’s completion is shown in Fig. 12, whichbasically follows a Lognormal distribution. On average, the ratiobetween a task’s response time and execution time is 2.75.

0 2 4 6 8

x 104

100

102

104

106

ET(s)

Task C

ount

0 2 4 6 8

x 104

100

102

104

106

RT(s)

Task C

ount

Fig. 12. The Distribution of Execution Time (ET in short) andResponse Time (RT in short).

The experimental results in the context of the Google cloudtracelogs are listed in the Table 3. The results argue that ANGELcan exhibit a good performance in practical use. Particularly, theTGR and PGR of ANGEL-M-M reach to 92.01%, and 92.25%,respectively, which indicates that in dynamic cloud environment




TABLE 3Performance on Google Cloud Workloads

`````````MetricAlgorithm ANGEL-M-M ANGEL-M-P ANGEL-P-M ANGEL-P-P I-GREEDY

TGR 92.01% 84.04% 55.02% 51.46% 19.57%PGR 92.25% 84.41% 55.56% 51.87% 19.62%

with great fluctuation of task count, ANGEL-M-M yields the bestperformance in the practical context. An interesting observationfrom the experimental results is that ANGEL-P-M performs almostalways the best in all when using random synthetic workloadswhile ANGEL-M-M performs the best in all when using clouldtracelogs. We attribute this reason to the fact that when using theP strategy in the forward announcement-bidding phase, the taskscan be relatively evenly allocated to VMs, so more tasks can besuccessfully accepted. However, in the real-world trace, the situationis greatly changed. Sometimes, extensive amounts of tasks surge intothe system, employing the P can evenly allocate tasks to VMs, butthe capabilities of VMs with large laxity are not sufficiently utilized.Employing the Max strategy in the forward announcement-biddingphase can efficiently use the laxity by Eq. (9) especially when agreat deal of tasks surge into the system. Also, we can observe thatalthough clouds have nearly infinite resources, there are still sometasks that were rejected, which can be attributed to the restriction ofdeadlines in our experiment. It is straightforward that there are greatperformance differences among the five algorithms because in sometime stamps, extensive amounts of tasks surge into the system (themaximum amount of tasks submitted to the system in 100 seconds isover 13,000), which immediately incurs the system overloaded, andrequires much more active hosts to accommodate these tasks. Theactive hosts in the system are much more than those in the previoussynthetic workloads. It should be noted that starting hosts and creatingVMs need additional time, well-designed algorithms will exhibitbetter performance, especially in practice, it is more pronounced.Based on the Google cloud tracelogs, in terms of TGRs, ANGEL-M-M, ANGEL-M-P, ANGEL-P-M, and ANGEL-P-P outperformI-GREEDY 72.44%, 64.47%, 35.45%, and 31.89%, respectively.Regarding PGRs, ANGEL-M-M, ANGEL-M-P, ANGEL-P-M, andANGEL-P-P outperform I-GREEDY 72.63%, 64.79%, 35.94%, and32.25%, respectively. This outperforming can be explained that ourANGEL comprehensively employs the bidirectional announcement-bidding mechanism where the selection strategies (MAX strategyand P strategy) and dynamic scaling up method are integrated.

7 CONCLUSIONS AND FUTURE WORK

In this study, we investigated the problem of agent-based schedulingfor aperiodic, independent real-time tasks in virtualized clouds andproposed a novel dynamic scheduling algorithm - ANGEL. The AN-GEL employs a new bidirectional announcement-bidding mechanism,in which our contributions include designing the basic matchingpolicy, forward announcement-bidding and backward announcement-bidding, as well as their process flows. Besides, we devised thecalculation of bidding values in forward biding and backward bidding.What is more, two selection strategies, i.e., MAX strategy and Pstrategy were put forward to determine the contractors. Again, wesufficiently considered the elasticity of clouds and proposed a scaling-up policy to dynamically add VMs so as to enhance the systemschedulability. The extensive simulation studies by using randomsynthetic workloads as well as the workload from the last versionof the Google cloud tracelogs indicate that ANGEL is a feasible

scheduling algorithm designed for real-time tasks in virtualizedclouds.

Our ANGEL is the first of its kind reported in the literature,because ANGEL employs the agent-based approach and comprehen-sively addresses the issue of schedulability, priority, scalability, real-time in virtualized cloud environment. In our future studies, we planto address the following three issues: Firstly, we will implement anew scheduling mechanism in which communication and dispatchingtimes are taken into account. Secondly, we will integrate the scalingdown policy with our ANGEL to improve the resource utilization.Finally, we plan to run our ANGEL in a real cloud environment.

ACKNOWLEDGMENTS

This research was supported by the Program for Changjiang Scholarsand Innovative Research Team in University of China under grant No.IRT13014, the National Natural Science Foundation of China undergrant No. 91024030, the Project of Institute of Southwest Electronicsand Telecommunication Technology under grant No. 2013001 as wellas the Hunan Provincial Natural Science Foundation of China undergrant No. 2015JJ3023.

REFERENCES

[1] R. Buyya, C. S. Yeo, S. Venugopal, J. Broberg, I. Brandic, “CloudComputing and Emerging IT Platforms: Vision, Hype, and Reality forDelivering Computing as the 5th Utility,” Future Generation Comput.Syst., vol. 57, no. 3, pp. 599-616, 2009.

[2] M. Armbrust, A. Fox, R. Griffith, A. D. Joseph, R. Katz, A. Konwinski,G. Lee, D. Patterson, A. Rabkin, and I. Stoica, “A View of CloudComputing,” Commu. the ACM, vol. 53, no. 4, pp. 50-58, 2010.

[3] J. Rao, Y. Wei, J. Gong, and C. Xu, “QoS Guarantees and ServiceDifferentiation for Dynamic Cloud Applications,” IEEE Trans. Networkand Service Management, vol. 10, no. 1, pp. 43-55, 2013.

[4] A. Beloglazov, J. Abawajy, and R. Buyya, “Energy-Aware ResourceAllocation Heuristics for Efficient Management of Data Centers for CloudComputing,” Future Generation Comput. Syst., vol. 28, no. 5, pp. 755-768, 2012.

[5] L. He, D. Zou, Z. Zhang, C. Chen, H. Jin, and S. A. Jarvis, “DevelopingResource Consolidation Frameworks for Moldable Virtual Machines inClouds,” Future Generation Comput. Syst., vol. 32, pp. 69-81, 2014.

[6] M. Dong, H. Li, K. Ota, and H. Zhu, “HVSTO: Efficient PrivacyPreserving Hybrid Storage in Cloud Data Center,” Proc. 3rd Workshopon Communications and Control for Smart Energy Systems (CCSES ’14)- INFOCOM ’14 Workshop pp. 529-534, 2014.

[7] X. Qin and H. Jiang, “A Novel Fault-Tolerant Scheduling Algorithmfor Precedence Constrained Tasks in Real-Time Heterogeneous Systems,”Parallel Comput., vol. 32, no. 5, pp. 331-356, 2006.

[8] K. Plankensteiner, R. Prodan, T. Fahringer, A. Kertesz, and P. Kacsuk,“Fault-Tolerant Behavior in State-of-the-Art Grid Workflow ManagementSystems,” Technical Report TR-0091, Inst. On Grid Information, Resourceand Workflow Monitoring Services, CoreGRID-Network of Excellence,2007.

[9] H. M. Fard, R. Prodan, and T. Fahringer, “A Truthful Dynamic WorkflowScheduling Mechanism for Commercial Multicloud Environments,” IEEETrans. Parallel and Distributed Systems, vol. 24, no. 6, pp. 1203-1212,2013.

[10] L. F. Bittencourt, E. R. M. Madeira, and N. L. S. da Fonseca, “Schedul-ing in Hybrid Clouds,” IEEE Communications Magazine, pp. 42-47, 2012.

[11] B. Sotomayor, R. S. Montero, I. M. Liorente, and I. Foster, “VirtualInfrastructure Management in Private and Hybrid Clouds,” IEEE InternetComputing, pp. 14-22, 2009.




[12] M. Mishra, A. Das, P. Kulkarni, and A. Sahoo, “Dynamic ResourceManagement Using Virtual Machine Migrations,” IEEE CommunicationsMagazine, pp. 34-40, 2012.

[13] X. Liu, C. Wang, B. Zhou, J. Chen, T. Yang, and A. Y. Zomaya,“Priority-Based Consolidation of Parallel Workloads in the Cloud,” IEEETrans. Parallel and Distributed Systems, vol. 24, no. 9, pp. 1874-1883,2013.

[14] Y. Mei, L. Liu, X. Pu, S. Sivathanu, and X. Dong, “Performance Analysisof Network I/O Workload in Virtualized Data Centers,” IEEE Trans.Services Computing, vol. 6. no. 1, 2013.

[15] H. Goldingay and J. Mourik, “The Effect of Load on Agent-BasedAlgorithms for Distributed Task Allocation, Inf. Sci., vol. 222, pp. 66C80,Feb. 2013.

[16] Wooldrige, Jannings, “Intelligent Agents: Theory and Practice,” TheKnowledge Engineering Review, 1995.

[17] K M. Sim, “Agent-Based Cloud Computing,” IEEE Trans. ServecesComputing, vol. 5, no. 4, pp. 564-577, 2012.

[18] X. Zhu, X. Qin, and M. Qiu, “QoS-Aware Fault-Tolerant Scheduling forReal-Time Tasks on Heterogeneous Clusters,” IEEE Trans. Computers,vol. 60, no. 6, pp. 800-812, 2011.

[19] Q. Zhang, M. F. Zhani, R. Boutaba, and J. L. Hellerstein, “Harmony:Dyanmic Heterogneity-Aware Resource Provisioning in the Cloud,” Proc.33rd Int’l Conf. Distributed Computing Systems (ICDCS ’13), pp. 510-519, 2013.

[20] X. Kong, C. Lin, Y. Jiang, W. Yan, and X. Chu, “Efficient DynamicTask Scheduling in Virtualized Data Centers with Fuzzy Prediction,” J.Network and Computer Applications, vol. 34, no. 4, pp. 1068-1077, 2011.

[21] R. N. Calheiros and R. Buyya, “Meeting Deadlines of Scientific Work-flows in Public Clouds with Tasks Replication,” IEEE Trans. Parallel andDistributed Systems, vol. 25, no. 7, pp. 1787-1796, 2014.

[22] M. Malawski, G. Juve, E. Deelman, and J. Nabrzyski, “Cost -andDeadline-Constrained Provisioning for Scientific workflow Ensembles inIaaS Clouds,” Proc. Int’l Conf. High Performance Computing, Network-ing, Storage and Anal (SC ’12), pp. 1-11, 2012.

[23] I. Goiri, J. L. Berral, J. O. Fito, F. Julia, R. Nou, J. Guitart, R. Gavalda,and J. Torres, “Energy-Efficient and Multifaceted Resource Managementfor Profit-Driven Virtualized Data Centers,” Future Generation Comput.Syst., vol. 28, pp. 718-731, 2012.

[24] P. Graubner, M. Schmidt, and B. Freisleben, “Energy-efficient manage-ment of virtual machines in Eucalyptus,” Proc. IEEE 4th Int’l Conf. CloudComputing (CLOUD ’11), pp. 243-250, 2011.

[25] N. Liu, M. A. Abdelrahman, S. Ramaswamy “A Complete MultiagentFrame for Robust and Adaptable Dynamic Job Shop Scheduling,” IEEETrans. Systems, Man, and Cybernetics, vol. 37, no. 5, pp. 904-916, 2007.

[26] R. Price, “Evaluation of Adaptive Nature Inspired Task AllocationAgainst Alternate Decentralised Multiagent Strategies,” BSc Dissertation,University of Birmingham, 2004.

[27] M. Campos, E. Bonabeau, G. Theraulaz, and J. L. Deneubourg, “Dyan-mic Scheduling and Division of Labor in Social Insects,” AdaptiveBehavior, vol. 8, no. 2, pp. 83-94, 2001.

[28] M. Owliya, M. Saadat, R. Anane, and M. Goharian, “A New Agents-Based Model for Dynamic Job Allocation in Manufacturing Shopfloors,”IEEE Systems Journal, vol. 6, no. 2, pp. 353-361, 2012.

[29] M. Owliya, M. Saadat, G. G. Jules, M. Goharian, and R. Anane,“Agent-Based Interaction Protocols and Topologies for ManufacturingTask Allocation,” IEEE Transactions on Systems, Man, and Cybernetics:Systems, vol. 43, no. 1, pp. 38-52, 2013.

[30] G. Lange and F. Lin, “Modeling Well Scheduling as a Virtual Enterprisewith Intelligent Agents,” Proc. IEEE 17th Int’l Conf. ComputationalScience and Engineering (CSE ’14), pp. 89-96, 2014.

[31] R. N. Calheiros, R. Ranjan, A. Beloglazov, C. A. F. D. Rose, and R.Buyya, “CloudSim: A Toolkit for Modeling and Simulation of CloudComputing Environments and Evaluation of Resource Provisioning Al-gorithms,” Software: Practice and Experience, vol. 41, no. 1, pp. 23-50,2011.

[32] Google Cluster Data V2: http://code.google.com/p/googleclusterdata/wiki/ClusterData2011 1

[33] I. S. Moreno, P. Garraghan, P. Towend, and X. Jie, “An approach forcharacterizing workloads in Google cloud to derive realistic resourceutilization models,” in IEEE Int’l Symp. Service Oriented System En-gineering, pp. 49-60, 2013.

Xiaomin Zhu received the B.S. and M.S. de-grees in computer science from Liaoning Tech-nical University, Liaoning, China, in 2001 and2004, respectively, and Ph.D. degree in com-puter science from Fudan University, Shanghai,China, in 2009. In the same year, he won theShanghai Excellent Graduate. He is currently anassociate professor in the College of InformationSystems and Management at National Univer-sity of Defense Technology, Changsha, China.His research interests include scheduling and

resource management in green computing, cluster computing, cloudcomputing, and multiple satellites. He has published more than 60research articles in refereed journals and conference proceedings suchas IEEE TC, IEEE TPDS, IEEE TCC, JPDC, JSS, ICPP, CCGrid andso on. He is an editorial board member of the Journal of Big Data andInformation Analytics. He is a member of the IEEE.

Chao Chen received the B.S. degree in informa-tion systems from National University of DefenseTechnology, Changsha, China, in 2013. He iscurrently working toward the M.S. degree in theCollege of Information Systems and Manage-ment, National University of Defense Technolo-gy. His research interests include agent-basedscheduling, cloud computing, and mobile cloudcomputing.

Laurence T. Yang received the B.E. degreein computer science and technology from Ts-inghua University, China, and the Ph.D. degreein computer science from University of Victoria,Canada. He is a professor with the School ofComputer Science and Technology, HuazhongUniversity of Science and Technology, China,as well as with the Department of ComputerScience, St. Francis Xavier University, Cana-da. His research interests include parallel anddistributed computing, embedded and ubiqui-

tous/pervasive computing, big data. He has published more than 200papers in various refereed journals (about 40% in IEEE/ACM Trans-actions and Journals and the others mostly in Elsevier, Springer, andWiley Journals). His research has been supported by the NationalSciences and Engineering Research Council of Canada (NSERC) andthe Canada Foundation for Innovation.




Yang Xiang received his PhD in Computer Sci-ence from Deakin University, Australia. He iscurrently a full professor at School of InformationTechnology, Deakin University. He is the Directorof the Network Security and Computing Lab (N-SCLab). His research interests include networkand system security, distributed systems, andnetworking. In particular, he is currently lead-ing his team developing active defense systemsagainst large-scale distributed network attacks.He has published more than 150 research pa-

pers in many international journals and conferences, such as IEEE TC,IEEE TPDS, and IEEE TISF. Two of his papers were selected as the fea-tured articles in the April 2009 and the July 2013 issues of IEEE TPDS.He has served as the Program/General Chair for many internationalconferences such as ICA3PP 12/11, IEEE/IFIP EUC 11, IEEE TrustCom13/11, IEEE HPCC 10/09, IEEE ICPADS 08, NSS 11/10/09/08/07. Hehas been the PC member for more than 60 international conferencesin distributed systems, networking, and security. He serves as theAssociate Editor of IEEE TC, IEEE TPDS, Security and CommunicationNetworks (Wiley), and the Editor of Journal of Network and ComputerApplications. He is the Coordinator, Asia for IEEE Computer SocietyTechnical Committee on Distributed Processing (TCDP). He is a SeniorMember of the IEEE.

ANGEL: Agent-Based Scheduling for Real-Time Tasks in...

Documents

Transcript of ANGEL: Agent-Based Scheduling for Real-Time Tasks in...