MORPHOSYS: Efficient Colocation of QoS-Constrained Workloads in the Cloud

12/02/2019 ∙ by Vatche Ishakian, et al. ∙ Bentley University Boston University 0

In hosting environments such as IaaS clouds, desirable application performance is usually guaranteed through the use of Service Level Agreements (SLAs), which specify minimal fractions of resource capacities that must be allocated for use for proper operation. Arbitrary colocation of applications with different SLAs on a single host may result in inefficient utilization of the host's resources. In this paper, we propose that periodic resource allocation and consumption models be used for a more granular expression of SLAs. Our proposed SLA model has the salient feature that it exposes flexibilities that enable the IaaS provider to safelya transform SLAs from one form to another for the purpose of achieving more efficient colocation. Towards that goal, we present MorphoSys: a framework for a service that allows the manipulation of SLAs to enable efficient colocation of workloads. We present results from extensive trace-driven simulations of colocated Video-on-Demand servers in a cloud setting. The results show that potentially-significant reduction in wasted resources (by as much as 60



There are no comments yet.


page 1

page 2

page 3

page 4

This week in AI

Get the week's most popular data science and artificial intelligence research sent straight to your inbox every Saturday.

1 Introduction

Motivation: Cloud computing in general and Infrastructure as a Service (IaaS) in particular have emerged as compelling paradigms for the deployment of distributed applications and services on the Internet due in large part to the maturity and wide adoption of virtualization.

From the perspective of an IaaS customer, this paradigm shift presents both an opportunity and a risk. On the one hand, deploying applications in the cloud is attractive because it enables efficiency through elastic scaling. On the other hand, deploying applications in the cloud implies relinquishing QoS monitoring and control to the cloud. Mitigating that risk requires the establishment of a “contract” – a Service Level Agreement (SLA) – between the provider and the customer, which spells out minimal resource allocations that the customer believes would satisfy desirable QoS constraints, while also being verifiable through measurement or auditing of allocated resources. Indeed, providing trustworthy accountability and auditing features have been cited as key attributes that would increase cloud adoption Haeberlen (2010); Sripanidkulchai et al. (2010).

From the perspective of an IaaS provider, the cloud value proposition is highly dependent on efficient resource management Wood et al. (2009); Podzimek et al. (2015), reduced operational costs Cardosa et al. (2009) and on improved scalability Xiaoqiao Meng and Zhang (2010). Such efficiencies need to be achieved while satisfying the aforementioned contractually-binding customer SLAs. This necessitates that SLAs be spelled out in such a way so as to expose potential flexibilities that enable efficient mapping of physical resources to virtualized instances.

Given the wide range of applications currently supported in an IaaS setting, it would be impractical for an IaaS provider to support special-purpose SLAs that are tailor-made for each such application and service, and which can be efficiently audited. Rather, a more practical approach calls for the development of a common language for expressing SLAs – a language that would cater well to the widely different types of applications that are likely to be colocated on an IaaS infrastructure.

Currently, the de-facto language for expressing SLAs mirrors how virtual machines are provisioned – namely through the specification of resource capacities to be allocated on average, over fairly long time scales. While appropriate for many applications, such coarse SLAs do not cater well to the needs of applications that require resource allocations at a more granular scale. To elaborate, recent studies have documented the often unacceptable or degradable performance of a number of application classes in a cloud setting. Examples include latency-sensitive, interactive, web applications Li et al. (2014), image acquisition applications, IP telephony and streaming applications Barker and Shenoy (2010); Babcock (2011). A culprit for the degraded performance is lack of any guarantee associated with the time-scale of resource allocation in a virtualized environment Baset (2012). Indeed, to provide QoS features, which are becoming the differentiating elements between cloud computing environments, there is the need for finer-grain SLA specifications that enable applications to spell out their resource needs over arbitrary time scales, as well as any tolerable deviations thereof (flexibilities).

Recognizing this need, in this paper we propose an expressive periodic resource allocation model for the specification of SLAs – a model that on the one hand provides customers with a larger degree of control over the granularity of resource allocation, and on the other hand enables providers to leverage flexibilities in customers’ SLAs for the efficient utilization of their infrastructures. Our SLA model is equally expressive for traditional cloud application as well as for the aforementioned QoS-constrained applications; it enables providers to cater to a wider customer base while providing them with the requisite measurement and auditing capabilities.

Scope and Contributions: Given a set of applications (workloads), each of which specified by minimal resource utilization requirements (SLAs), the problem we aim to address is that of colocating or mapping these workloads efficiently to physical resources. To achieve efficient mapping, we need to provide workloads with the ability to express potential flexibilities in satisfying their SLAs. Recognizing that there could be the case where there are multiple, yet functionally equivalent ways to express the resource requirements of a QoS-constrained workload. Towards that end, we propose a specific model for SLAs that makes it possible for providers to rewrite such SLAs as long as such rewriting is safe. By safety, we indicate that we can substitute the original SLA by the rewritten SLA without violating the original SLA, and that the resources allocations that satisfy the rewritten SLA would also provably satisfy the original SLA. The ability to make such safe SLA transformations enables providers to consider a wider range of colocation possibilities, and hence achieve better economies of scale. In that regard, we present MorphoSys:222MorphoSys can be seen as catalyzing the “morphosis” of a set of SLAs – namely, morphing SLAs to enable more efficient colocation. the blueprints of a colocation service that demonstrates the premise of our proposed framework. Results from extensive trace-driven simulations of colocated Video-on-Demand (VOD) servers in a cloud setting show that potentially-significant reduction in wasted resources (by as much as 60%) are possible using MorphoSys.

Paper Overview: The remainder of this paper is organized as follows. In Section 2 we present some background and illustrative examples that motivate the need for an expressive safe SLA model. In Section 3 we introduce our basic type-theoretic model for periodic resource supply and demand with necessary notation, basic definitions, and a series of safe transformations as exemplars of our notion of safe SLA rewrite rules. In Section 4, we extend our SLA model for QoS-constrained resource supply and demand. In section 5, we present the basic elements of our MorphoSys framework. In Section 6, we present experimental results that demonstrate the promise from using MorphoSys to manage colocated streaming servers. We review related work in Section 7, and provide a conclusion in Section 8.

2 background and illustration

Recall that an important consideration for efficient colocation is the ability of a provider to evaluate whether a given set of customers can be safely colocated. To do so, a provider must be able to decide whether the capacity of a given set of resources (e.g., a host) can satisfy the aggregate needs of a set of customers (namely, the composition of the SLAs for that set of customers). Given our adopted periodic model for SLA specification, it follows that evaluating the feasibility of colocating a set of customer workloads on a given host can be viewed as a “schedulability” problem: given the capacity of a host, are a set of periodic real-time tasks schedulable?

Different models and schedulability analysis techniques have been proposed in the vast real-time scheduling theory, including Earliest Deadline First, Rate Monotonic Analysis (RMA) Liu, and Layland, (1973), among others Davis and Burns (2009). While similar in terms of their high-level periodic real-time task models, these approaches differ in terms of the trade-offs they expose vis-a-vis the complexity of the schedulability analysis, the nature of the underlying resource manager/scheduler, and the overall achievable system utilization. Without loss of generality, we assume that RMA Liu, and Layland, (1973) is the technique of choice when evaluating whether it is possible to co-locate a set of periodic workloads on a fixed-capacity resource.333While the analysis and transformations we provide in this paper are based on RMA, we emphasize that our framework and many of our results naturally extend to other types of schedulers.

Liu and Layland Liu, and Layland, (1973) provided the following classical result for the schedulability condition of tasks (SLAs), each of which requiring the use of a resource for out of every units of time, under RMA:

Follow-up work, by Lehoczky et al Lehoczky et al. (1989) showed that by grouping tasks in clusters such that the periods of tasks in each cluster are multiples of each other (i.e., harmonic), a tighter schedulability condition is possible – namely:

As motivated above, there may be multiple yet functionally-equivalent ways to satisfy a given SLA. This flexibility could be leveraged by a provider for efficient colocation. In particular, given a set of periodic tasks (SLAs), it might be possible to obtain clusters of tasks with harmonic periods by manipulating the period or the periodic allocation of some of the tasks (SLAs) in the set. For such a transformation to be possible, we must establish that it is safe to do so.

Figure 1: Illustration: Reducing the allocation period may result in missed deadlines.

To illustrate why a transformation may not be safe (even if it results in an increase in the fraction of the resource alloted to the task), consider a workload that requires time units of the resource every period time units. While reducing the allocation period for this task from to would result in that task being alloted the resource for a larger fraction of time (25% as opposed to 20%), as shown in Figure 1, it is possible for that task to miss its original deadlines. The figure shows a sequence of allocation intervals of size and , where a box represents a single allocation period. The upper row shows the periodic boundaries as originally specified , whereas the lower row shows a periodic allocation with , with “X” marking the times when the resource is allocated. One may observe that an entire period of size is missing its required allocation.

In the above example, the fact that the transformation we considered resulted (or may result) in missed deadlines does not mean that it cannot be used. In particular, if the SLA associated with the workload in question allows for some percentage of deadline misses, then if one is able to bound the deadline misses resulting from the transformation – and consequently show that the SLA is not violated – then the transformation is indeed safe. Thus the need for a concise workload model along with a formalism for studying such safe transformations.

3 SLA Model: Basics

As we established earlier, SLAs can be seen as encapsulators of the resources supplied by hosts (producers) and demanded by tasks (consumers). While this concept is generic enough for a wide variety of resources, in this section, we provide a specific model for SLAs – namely, one that supports periodic, real-time resource supply and demand.444Legal implications that specify how penalties are associated with SLA violations are considered to be out of scope of our work. We also provide the basic type-theoretic-inspired definitions that allow us to establish subtyping relationships between SLAs.

Although our SLA formulation and subtyping relationships is abstract enough to reflect an aggregated set of resources – in a public or private IaaS setting – such as a single rack in the datacenter, throughout this paper, we assume that our SLAs reflect the resources provided by a single physical host.

3.1 Periodic Supply/Demand SLA Types

This section presents the formal definition of SLA types for resources supplied and demanded for a specific allocation interval. It also denotes the maximum number of missed allocations over multiple intervals.

Definition 1.

A Service Level Agreement (SLA) type is defined as a quadruple of natural numbers , , , and , where denotes the resource capacity supplied or demanded in each allocation interval , and is the maximum number of times such an allocation is not possible to honor in a window consisting of allocation intervals.

As is common in the real-time literature, the above definition assumes that the periodic capacity could be allocated as early as the beginning of any interval (or period) and must be completely produced/consumed by the end of that same interval (i.e., allocation deadline is T units of time from the beginning of the period).

The concept of SLA types is general enough to capture the various entities in a resource allocation. The following are illustrative examples.

An SLA of type could be used to characterize a uniform, unit-capacity supply provided by a physical host. An SLA of type , could be used to characterize the fractional supply provided under a General Processor Sharing (GPS) model to processes. In the above examples, the SLA type does not admit missed allocations (by virtue of setting ).

An SLA of type could be used to represent a task that needs a unit capacity over an allocation period and cannot tolerate any missed allocations. An SLA of type is similar in its periodic demand profile except that it is able to tolerate missed allocations as long as there are no more than such misses in any window of consecutive allocation periods.

3.2 Satisfaction and Subtyping of SLAs

We begin by providing basic definitions of what it means to satisfy a schedule for SLAs of the type (i.e., those that do not admit missed allocations), which we denote using the shorthand . Next, we generalize these definitions for general SLA types of the form .

Definition 2.

A schedule is a function from to as

A schedule satisfies (denoted by ) an SLA type if the resource is allocated for units of time in non-overlapping intervals of length .

Definition 3.

iff for every where and every we have

There are multiple ways for an allocation to satisfy a particular schedule. Thus, we define the set to consists of all schedules that satisfy .

Definition 4.

We are now ready to introduce SLA subtyping relationships (denoted by ) as follows:

Definition 5.


We generalize the above definitions for SLAs of the type , which allow missed allocations. The definitions are conceptually similar to SLAs of type (C,T), though considerations of missed allocations require more elaborate notations.

To calculate the number of missed allocations over intervals, we need to identify whether a single interval of size is satisfied. Formally,

Definition 6.

is a function from to . such that:

A schedule satisfies an SLA type if the resource is allocated for units of time in at least out of every intervals of length .

Definition 7.

iff for every where and every

The set is defined as comprising all schedules that satisfy . Formally:

Definition 8.


A generalized notion of subtyping for SLAs of the form is presented as follows:

Definition 9.

iff .

3.3 SLA Subtyping and Transformations

In this section, we present a set of SLA transformations that exemplify the range of scheduling results that could be “coded into” the MorphoSys framework. Each one of the transformations presented in this section is cast within a subtyping theorem. Intuitively, establishing a subtyping relationship between two SLAs implies that we can safely substitute one for the other In general, transformed SLAs will require more of the underlying physical resources than the original SLA. Nevertheless, such a transformation may be advantageous to the IaaS provider as it may result in a more efficient colocation of customer workloads – e.g., by making such workloads harmonic and hence subject to looser schedulability bounds Lehoczky et al. (1989).

Given an SLA of type , it is possible to safely transform it into another SLA of type , where is larger or smaller than .

Theorem 1.
555Most of the proofs in this paper were verified using the theorem prover of Ishakian et al. (2011).

iff one of the following conditions holds:

  1. and where .

  2. and .

  3. and .


Condition 1: [If] implies that . According to Lemma 9 (see appendix), an interval of length must overlap with at least fixed intervals of length . These intervals provide an allocation of , enough for interval . Thus, and .

Condition 2: [If] Consider any interval of length . Since , either will be completely overlapped by an interval of length , or it will be overlapped by two intervals , of length (as shown in Figure 3). For any interval of length , denote the left and right boundaries of using and , respectively.

Figure 2: is overlapped by two intervals of size
Figure 3: is overlapped by three intervals of size

Let be the offset of from and be the offset of from . We observe that , leading to and as a sufficient condition.

Condition 3: [If] Consider any interval of length . Since , will overlap with either two or three intervals of length . The case in which overlaps two intervals of length follows from Condition 2, resulting in . The case in which overlaps three intervals , , and of length is shown in Figure 3.

Let be the offset of from and be the offset of from . We observe that . Thus, a sufficient condition is and . Thus a bound for both cases is the maximum of the two bounds, namely .

Condition 1: [Only If] Suppose . This implies that for every and every : . Given that and , we have and . Given that , we get: Therefore .

Condition 2: [Only If] Suppose . This implies that for every and every : . Consider for . In the worst case, it will will be overlapped by two intervals of length . Thus we have where and are the left overs from both intervals. Therefore Therefore .

Condition 3: [Only If] Suppose . This implies that for every and every : . Consider for . In the worst case, it will will be overlapped by three intervals of length . Thus we have where and are the left overs from both intervals. Therefore Therefore . ∎

We extend results from Theorem 1 to provide safe transformations of SLAs of the type . Theorem 2 outline the necessary conditions to safely transform an SLA of type into .

Theorem 2.

if one of the following conditions holds:

  1. ( and ) and and where .

  2. ( and ) and and where .

  3. ( and ) and and .


We use the fact from Lemma 10 (see appendix) that is a necessary condition.

Condition 1: The proof for the bracketed part of the conjuntion is identical to that under Condition 1 of Theorem 1. For the remaining part, we note that since missed deadlines might be stacked at the end of one window and at the beginning of the next contributing to a window of size W, it follows that . Also, since consecutive intervals of length will span one interval of length , it follows that every missed interval of length out of intervals will result in missing an interval of length . Thus, must hold.

Condition 2: The proof for the bracketed part of the conjuntion is identical to that under Condition 2 of Theorem 1. For the remaining part, in the worst case, missing an interval of length results in missing up to intervals, where . Thus must hold as well as . However, since missed deadlines might be stacked at the end of one window and at the beginning of the next contributing to a window of size W, it follows that must hold.

Condition 3: The proof for the bracketed part of the conjuntion is identical to that under Condition 3 of Theorem 1. For the remaining part, the proof is similar to that in Condition 2 by taking and consequently . Thus, must hold. ∎

Having characterized some basic notions of subtyping, we present additional transformations that allow for safe rewriting of such types.

Theorem 3.

Let be an SLA type for some and be a host-provided SLA type. Then .


One can observe that one interval of will contain intervals of with each interval providing computation time. Thus is satisfied. ∎

Next we present transformations that allow for missed allocation, but unlike arbitrary SLA modifications, These transformations provide a bound on the number of missed deadlines over a specific number of intervals, which deemed to be acceptable to satisfy a customer’s SLAs. We begin by presenting the definition of bounds on missed deadlines.

Definition 10.

where is the bound on the missed deadlines over intervals of length .

Theorems 4 and 5 provide bounds on the number of missed deadline as we modify the allocation interval .

Theorem 4.

Let be an SLA type, and be a host-provided SLA type, where for some then:

  1. If then , where and . Moreover in such a case, will miss at least one allocation deadline every intervals.

  2. For every , if

    then , where and

  3. For , if

    then .


Condition 1: Since , we have intervals. No matter how the distribution of is going to be over the intervals, it is always the case that the resource allocation will be less that the units needed over the intervals. Thus we conclude that the schedule will always include at least one interval with a missed allocation.
Condition 2: Consider the left inequality in the conjunction, i.e., . Assume that there are unsatisfied intervals with at most allocation units. Thus, there should be satisfied intervals containing at least allocation units. Therefore we have: .

Since is the total time in all the satisfied intervals, it follows that the total time in the satisfied interval is strictly less than the allocations in the satisfied interval – a contradiction. Therefore,

Now, consider right inequality in the conjunction, i.e., . If , then there exists a schedule such that the number of satisfied interval is strictly less than . Let . We can simply distribute allocation units over intervals such that none of the intervals are satisfied. Furthermore, we distribute allocation units over windows, thus completely filling intervals with allocation units. Thus, we end up with at least satisfied intervals.
Condition 3: To guarantee all intervals, in the worst case, we need to have intervals filled with allocation units. In addition, we need to have at least allocation units in the last interval. By substituting for in the above equation we get: therefore, .

Theorem 5.

Let be an SLA type and be a host-provided SLA type, where and . If , and where lcm is the least common multiple, then

  1. We can guarantee at least satisfied intervals out of total intervals.

  2. We can guarantee at least satisfied intervals out of the total intervals.

We can bound the number of missed deadlines every intervals to be . Therefore where and .


Condition 1: Since , we observe that the number of satisfied intervals of length is at least equal to the number of completely overlapping intervals of length . Let be the number of completely overlapped unique intervals of in , then

where is the greatest common divisor of and . Thus and are prime with respect to each other. Let , then . Furthermore .666For simplicity, we choose to enumerate from 1 to instead of from 0 to . Since the remainders in are unique, let us mark the remainders on a circle starting from and ending at . We observe that every remainder that is marked at the region starting from 1 to will not pass the cycle ending at because . In addition, the interval that starts at position will also not pass the cycle, therefore the total number of overlapping intervals is:

Condition 2: Since , the first interval will always be satisfied. To bound the number of missed allocations, we assume an adversary whose purpose is to maximize the number of missed allocations by allocating the resource to intervals that are already satisfied. Under such conditions, we prove that every intervals of length will contain at least one satisfied interval.

Consider any schedule, assume it has a sub-sequence of unsatisfied intervals of length denoted by where . Exactly intervals of length are completely contained in denoted as . Let start at and end at . The total computation time in is at most equal to the total computation time in . The total computation time scheduled in . Since all the intervals in are unsatisfied, the total computation time scheduled for each interval of length can be at most . Therefore the total computation time in . Contradiction. must contain some satisfied intervals.

Figure 4: Adversary trying to miss maximum possible deadlines

To generalize, we have intervals of length . Since every intervals of length will contain at least one satisfied interval, we can bound the number of missed allocations to be at most equal to . ∎

We also define a two step transformation of an SLA type by applying the transformation in Theorem 4 the transformation in Theorem 5.

Theorem 6.

Let , and such that by applying the transformation in Theorem 4. Let such that by applying the transformation in using Theorem 5. Then where and .


will miss at most allocations over intervals. will miss at most allocations over intervals. Every missed allocation in corresponds to the failure of satisfying an entire window in , and every satisfied window in corresponds to missing at most allocations in . Thus at most, the total number of missed allocations over a window is the sum of all possible missed allocations . ∎

Theorem 7.

Applying the transformations in Theorems 4 and 5, in this order, is equivalent to applying the transformations in Theorems 5 and 4, in this order. That is, the two transformations commute.


Theorem 6 highlights results of applying Theorem 4 followed by Theorem 5. We would like to show that the results for Theorem 5 followed by Theorem 4 are equal.

will miss at most allocations over of intervals. will miss at most allocations over intervals. Every missed allocation in corresponds to the failure of satisfying an entire window in , and every satisfied window in corresponds to missing at most allocations in . Thus at most, the total number of allocations over a window is the sum of all possible missed allocations . ∎

4 SLA Model: Fluidity

As we alluded before, we believe that a periodic resource allocation model is appropriate for expressing SLAs in an IaaS setting. Thus, in this section we extend the periodic SLA model for the purpose of expressing general SLAs of IaaS customer workloads – which may not be inherently “real time”. In particular, we extend the SLA model to allow for the modeling of “fluid” workloads.

A fluid workload is one that requires predictable periodic allocation of resources (i.e. not best effort), but has flexibility in terms of how such periodic allocations are disbursed (i.e. not real-time). For instance, a fluid workload may specify a periodic need for resources as long as the disbursement of these cycles is guaranteed over some acceptable range of periods. For example, a fluid workload may specify the need for 10K cycles per second as long as these cycles are disbursed over a fixed period in the range between 100msec and 10 secs. Thus, a disbursement of 1K cycles every 100 msecs is acceptable as is a disbursement of 100K cycles every 10 secs. But, a disbursement of 200K cycles every 20 secs would be unacceptable as it violates the upper bound imposed on the allocation period, and so would an allocation of 100 cycles every 10 msecs as it violates the lower bound.

It is important to highlight that our periodic allocation is less stringent than what a “real-time” workload may require, but more stringent than what typical IaaS virtualization technologies are able to offer. Unlike real-time systems, there is no notion of deadlines, but rather an expectation of resource allocations at a prescribed predictable rate.

Definition 11.

An SLA is defined as a tuple of natural numbers , such that , , , and , where denotes the resource capacity supplied or demanded during each allocation interval , and are lower and upper bounds on , and is the maximum number of times that the workload could tolerate missing an allocation in a window consisting of allocation intervals.

According to the above definition, an SLA of type represents a fluid workload which requires an allocation of every interval , where can vary between and as long as the ratio is consistent with the original SLA type. The following are illustrative examples

An SLA of type represents a fluid workload that demands a capacity every allocation interval , however the original SLA would still be satisfied if its gets a capacity every allocation interval since the ratio is equal to .

An SLA of type is similar in its demand profile except that it is able to tolerate missed allocations as long as there are no more than such misses in any window of consecutive allocation periods.

Fluid Transformations: In addition to the transformations defined in Section 3, we introduce the following transformation for fluid workloads.

Theorem 8.

A fluid SLA of type satisfies an SLA of type if and .


implies the ratio of . implies that is an acceptable allocation period for fluid workload (based on the definition). Therefore satisfies

5 MOrphoSYs: The Framework

In this section, we exploit the theorems defined in Sections 3 and 4 as building blocks in our MorphoSys framework. We consider an IaaS setting consisting of any number of homogeneous instances (servers), to which we refer as “Physical Machines” (PM).777Again, we emphasize that while we present our framework in the context of computational supply and demand – using terminologies such as physical and virtual machines – MorphoSys is equally applicable to other types of resources. Each workload (served with a virtual machine instance) is characterized by an SLA that follows the definition above – namely . The MorphoSys colocation framework consists of two major services: a Workload Assignment Service (WAS) and a Workload Repacking Service (WRS). WAS assigns workloads to PMs in an on-line fashion using a prescribed assignment policy. WRS performs workload redistribution across PMs to optimize the use of cloud resources.

5.1 Workload Assignment Service (WAS)

Figure 5

provides an overview of the main elements of WAS. WAS is invoked upon the arrival of a request for a Virtual Machine (VM) allocation, in support of a workload specified by an SLA. The WAS service uses one of two heuristics to select the PM that could potentially host the VM: First Fit (FF) and Best Fit (BF). FF assigns the VM to the first PM that can satisfy the VM’s SLA, whereas BF assigns the VM to the fullest – most utilized – PM that can still satisfy the VM SLA.

If it is not possible for WAS to identify (using FF or BF) a PM (currently in use) that could host the newly-arriving VM, then WAS attempts to rewrite the SLA of the VM (safely) in the hopes that it would be possible to assign the VM (subject to the transformed SLA) to an existing PM. To do so, WAS proceeds by generating a safe SLA transformation and attempts to use either FF or BF to find an assignment. This process is repeated until either one of the safe SLA transformations results in a successful assignment of the VM to a PM, or WAS runs out of possible safe SLA transformations. In the latter case, WAS may invoke the WRS repacking service to repack already utilized hosts in an attempt to assign the workload, or alternatively WAS can simply instantiate a new PM to host the newly-arriving PM.

In the worst case, the complexity of WAS is where is the largest number of possible task transformations per task across all possible tasks, and is the number of hosts in the system. Although its possible for to be the dominant factor in the complexity, based on experimental observations (inferred by traces from real-workloads), , which implies that in practice, WAS scales linearly with the number of hosts.

5.2 Workload Repacking Service (WRS)

Repacking is an essential service that allows the remapping/reclustering of workloads. This service is needed because IaaS environments may be highly dynamic due to the churn caused by arrival and departure of VMs, and/or the need of customers to change their own resource reservations. Over time, such churn will result in under-utilized hosts which could be managed more efficiently if workloads are repacked.

Figure 5: The WAS Component of MorphoSys.

Repacking Heuristic: Remapping a set of workloads to multiple hosts efficiently is the crux of the problem. We say “efficient” as opposed to optimal because multi-processor real-time scheduling has been shown to be NP-Hard Garey and Johnson (1979) (and our problem by reduction is also NP-Hard), and thus we resort to heuristics. Many such heuristics (approximations) have been proposed in the literature (e.g., based on the use of a bin packing or greedy strategy) Baruah et al. (1990); Londoo and Bestavros (2008).

Our safe SLA transformations provide us with another degree of freedom (

i.e., another dimension in the search space): Rather than finding the best packing of a set of tasks with fixed SLA requirements (the original NP-hard problem), we have the flexibility of safely manipulating the SLAs with the hope of achieving a better packing. Towards that end, we have implemented heuristic algorithms that utilize Breadth First Search (BFS) and Depth First Search (DFS) techniques to explore the solution search space.

1:   BestSolSoFar size(HostList)
2:   for all Host in HostList do
3:       for all Tasks in Host do
4:           TransTaskList Gen_Trans(Task) {Generate a list of transformations for the particular task}
5:           CandTaskList[TaskID] TransTaskList
6:       end for
7:   end for
8:   SortTaskList(CandTaskList) {Sort Tasklist ascending}
9:   Tree EmptyNode
10:   repeat
11:       Task SortTaskList.Remove(0)
12:       AddNodeToTree(Task) {Add original task and transformations as nodes in the tree.}
13:       UtilizationOk(Tree) {Prunes tree branches}
14:   until SortTaskList
15:   BestSol = GetBestSolution(Tree)
16:   return BestSol
Procedure 1 Repack(HostList): WRS Repack Heuristic

Our (BFS or DFS) heuristic starts with a preprocessing stage, in which we generate all possible transformations for each task (using our arsenal of safe transformations). Next, it proceeds by setting up the search space (tree or forest) of all the alternative task sets that could be colocated. Finally, it proceeds to explore that search space with the aim of finding a feasible transformation.

In the worst case, our heuristic may end up searching the entire solution space, which is obviously impractical. To manage the exponential nature of the search space, our heuristic utilizes two optimization (pruning) strategies.

Our first optimization strategy adopts an early-pruning approach: at each stage of our search, if the aggregate utilization (demanded SLA) of the tasks under consideration thus far (whether these tasks are transformed or not) is greater than the capacity of the host (supplied SLA), then we prune that branch of the tree on the assumption that a feasible solution cannot exist down that path. We initially set the “best” solution to be the total number of hosts used prior to repacking.

Our second optimization adopts a smaller-degree-first approach: we build the search space (tree) by greedily starting with tasks that have the smallest number of transformations. This ensures that when pruning is applied (using the above strategy) we are likely to maximize the size of the pruned subspace. This optimization strategy has been shown to be quite effective in reducing the solution search space for network embedding problems Londoo and Bestavros (2008). For practical purposes, we set an upper-bound on the execution time of the repacking heuristic, which we take to be 5 minutes for services operating on hourly “pay-as-you-go” reservations.

Procedure 1 illustrates our repacking process. Given a set of candidate hosts, we proceed to generate transformations for each task on a particular host (lines 2-7). We sort the candidates based on the number of transformations, which is a precursor for applying the first optimization strategy. Lines 9-14 construct the tree by adding each task and its transformations at the leafs of the tree, Then prunes the branches of the tree where solutions exceed the current best solution. Finally, the best solution is returned (lines 15-16).

Repacking Policies:

Our WRS service could be instantiated based on one of three possible repacking policies: No Repacking (NR), Periodic Repacking (PR), and Forced Repacking (FR). NR is used to disable WRS, PR allows repacking to run at designated epochs/periods based on a system defined parameter. FR allows repacking to be applied in a “on line” fashion (triggered by the WAS).

1:   if NM then
2:       for all i in AllHosts do
3:           Repack() {repack a single host}
4:       end for
5:   else
6:       if CM then
7:           Hostlist GetCandidateHosts() {Constrained migration: find the set of suitable candidate hosts}
8:       else
9:           Hostlist AllHosts {Unconstrained migration select all hosts}
10:       end if
11:       Repack(Hostlist)
12:   end if
Procedure 2 SelectHosts(): WRS Host Selection

Migration Policies: The effectiveness of the repacking policy depends on the ability to migrate workloads from one host to another. However, adding hosts increases the total number of workloads to be repacked which in turn results in an increase in the total service turnaround time. Thus we model three types of migration policies: No Migration (NM), Constrained Migration (CM), and Unconstrained Migration (UM). NM policy allows for repacking on the condition that workloads will not migrate from the host to which they are assigned. This approach will naturally consider one host at a time, and is suitable for running WAS in an “online” fashion. In particular, under a NM policy, as the framework receives a new request for task assignment, it attempts to apply transformations on tasks assigned to that particular host as well as the candidate request. The goal of applying the transformations is to assign all tasks to the host. CM and UM policies allow for workloads to migrate from one host to another as long as it results in a more efficient repacking of these workloads. This is suitable when WAS is run in an “offline” fashion. The difference between CM and UM is in the host selection criteria: UM considers all system hosts, whereas CM considers hosts that satisfy a host selection condition.

Host Selection Condition: A host is a candidate for repacking if it satisfies a condition on its utilization. Let be the average host utilization, which we define as , where is the utilization of host . Furthermore, let be the sum of the utilizations of the workloads on a specific host (based on the original workload SLA and not the transformed workload SLA). A host is a candidate for repacking if , where is a tunable parameter (CM reduces to UM, when ). The logic for all WRS variants is shown in Procedure 2.

6 MOrphoSYs: Evaluation

In this section we present results from extensive experimental evaluations of the MorphoSys framework. Our main purpose in doing so is to establish the feasibility of our proposed service by: (1) comparing the schedulability of QoS workloads, with and without applying our safe SLA transformations, (2) evaluating the effect from using different migration policies on the efficiency of colocation, (3) evaluating the effect of changes in the mix of fluid and non-fluid workloads, and (4) evaluating the effect of changing the flexibility of fluid workloads on the efficiency of colocation.

Simulation Setup: Our setting is that of a cloud storage service used to host a large number of streaming servers. This setting is general enough to represent different forms of applications, such as a cloud content provider streaming and other multimedia services. Typically for such applications, the disk I/O constitutes the bottleneck of the overall system performance Cherkasova and Staley (2003); Barker and Shenoy (2010). The maximum throughput delivered by a disk depends on the number of concurrent streams it can support without any SLA violation.

To drive our simulations, we utilize a collection of video traces from Van der Auwera et al. (2008). We assume that the underlying system of the provider is a disk I/O system that serves requests of different streaming servers using a fixed priority scheduling algorithm, which we take to be Rate Monotonic. The usage of fixed priority algorithms for disk scheduling was suggested by Daigle and Strosnider Daigle and Strosnider (1994), and Molano et al Molano et al. (2002).

The video traces Van der Auwera et al. (2008) provide information about the frames of a large collection of video streams under a wide range of encoder configurations like H.264 and MPEG-4. We conducted our experiments with a subset of 30 streams, with HD quality, and a total duration of one hour each. We initially identify the period for serving a video stream request as the period of the I frames (a.k.a., Group of Pictures, or GoPs). Overall, there were three unique periods in our collection of video traces.

We model the SLA associated with each stream as follows: The SLA specifies a periodic (disk I/O) demand over a periodic allocation time . For a given stream, the periodic demand is set as follows:

where is the volume in bytes of the stream in interval .The allocation period is set to be equal to , where is one of the three unique periods in our video traces and () models the tolerance of the client (the recipient of the stream) to burstiness in the allocation over time. In particular, for any given value of , it is assumed that the client is able to buffer (and hence absorb) up to seconds of the stream (i.e., GoPs). A large value for implies that the allocation is over a large number of GoPs, and hence a tolerance by the client for a bursty disbursement of periodic allocation. A small value for specifies a smoother disbursement over time. Each client request specifies a value for the parameter which is chosen at random between a lower bound and an upper bound . In our experiments we set and . To model the level of fluidity (flexibility) of an SLA, we allow the period to range from to , where () determines the allowable deviation from the nominal allocation period. A non-fluid SLA is one where .

We model churn in the system as follows. Client arrivals (requests for streams) are Poisson (independent) with a rate . Poisson arrival processes for VoD have been observed in a number of earlier studies (e.g., Veloso et al. (2006)

). A client’s session time is set to be the length of the entire stream served to the client. The specific stream requested by the client is chosen uniformly at random from among all streams in the system. Experiments with skewed distributions (

e.g., Zipf) and inhomogeneous poisson process resulted in results that are similar to those obtained using exponential preference,888This is expected given the relatively similar lengths of the streams in the trace. and thus are not reported.

In our experiments, our purpose is to evaluate the efficiency of computing a colocation configuration for our workloads, as opposed to the performance of system deployment. Thus, to measure the efficiency of a colocation strategy , we report the Colocation Efficiency (CE), which is defined as follows:

where is the amount of wasted (unallocated) resources when colocation strategy is used, and is the measure of wasted resources when our baseline First-Fit (FF) strategy is used. Thus, CE can be seen as the degree to which a strategy is superior to FF (the reduction in wasteds resources relative to FF, which according to theoretical bounds Liu, and Layland, (1973), can be up to 30%). All CE values are reported with 95% confidence.

Figure 6: Colocation Efficiency: Baseline Results

Relative Performance of Various Strategies: Recall that the assignment of an incoming workload (request) is done using WAC, which attempts various SLA transformations on an incoming request until the potentially transformed request is possible to assign to a host (disk) using either First-Fit or Best-Fit.

In a first set of experiments, we compared the performance of WAC with No Repacking under both FF and BF (namely FF-NR and BF-NR) to that of the plain FF and BF heuristics (i.e., without attempting any SLA transformations). Figure 6 shows the results we obtained when varying the arrival rate () for the different packing strategies: BF, FF-NR, and BF-NR.

In general, the performance of BF is only marginally better than FF, whereas both FF-NR and BF-NR show measurable (up to 20%) improvement over both FF and BF, with BF-NR performing slightly better than FF-NR. These results suggest that there is a measurable improvement in colocation efficiency even when minimal SLA transformations are allowed (namely the transformation of the SLA of the incoming request only).

      (a)       (b)
Figure 7: Effect of fluid SLAs when only fluid transformations are allowed, , (a) FF-NR. (b) BF-NR.
      (a)       (b)
Figure 8: Effect of fluidity level when only fluid transformations are allowed, , (a) FF-NR. (b) BF-NR.

To evaluate the benefit from repacking and migration, we ran a similar experiment with the repacking policy set to Forced Repacking (FR). Figure 6 shows the measured CE values for different arrival rates () and different repacking strategies. Our “online” repacking strategies with no migration – namely FF-NM and BF-NM – improved colocation efficiency significantly. For lower arrival rates, CE was around 0.4, implying a 40% reduction in wasted (unallocated) resources compared to FF. For moderate and higher arrival rates, the reduction is more pronounced around 50%.

      (a)       (b)
Figure 9: Combined benefit from applying both fluid and non-fluid transformations, (a) FF-NR. (b) BF-NR.
      (a)       (b)
Figure 10: Effect of fluidity level when both fluid and non-fluid transformations are allowed, : (a) FF-NR (b) BF-NR.

Figure 6 also shows results of experiments in which various migration policies are enabled – namely Constrained Migration (CM) and Unconstrained Migration (UM). Both approaches result in better performance compared to NM approaches, yielding CE values between 0.55 and 0.6.

To summarize, this initial set of experiments suggests that, even in the absence of any fluidity in the workload (SLA flexibility), a reduction of up to 60% in the wasted resources is to be expected through the use of SLA transformations and repacking.

Benefit from Fluid Transformations: To measure the effect of fluidity on the overall colocation efficiency, we performed experiments using the same setting as before, while allowing a certain percentage of the requests to be fluid (with ), and only allowing fluid transformations to be applied. In other words, non-fluid workloads were not subjected to any transformations.

Figures 8 (a) and (b) show the results we obtained using both FF-NR, and BF-NR, respectively, for various mixes of fluid and non-fluid workloads. As the result suggests, having a mix with even a small percentage of fluid workloads results in improvements (up to 20%) that are comparable to what we obtained when transformation of non-fluid workloads was allowed with no repacking (cf. Figure 6).

In the previous experiment, we fixed the fluidity level () and studied the effect of changes in the mix of fluid versus non-fluid SLAs. Figure 8 (a) and (b) show results of additional experiments in which we changed the level of fluidity (the parameter ) while keeping the value of , for various mixes of fluid and non-fluid workloads. The results show that only small levels of flexibility () provided most of the achievable improvements when only fluid transformations are considered.

Combined Benefit from Fluid and non-Fluid Transformations: Fixing the level of fluidity to a small value (), Figures 10 (a) and (b) show results from experiments in which all possible transformations are allowed in a No-Repacking setting (i.e., FF-NR and BF-NR) for different workload mixes. Figures 10 (a) and (b) show results of experiments with similar settings – all possible transformations are allowed in a No-Repacking setting – with , and varying fluidity level (the flexibility parameter). The results (also shown in Figure 12 for and ) show that the resulting performance is marginally better (by only a few percentage points) than applying either non-fluid transformations or fluid transformations.

Supporting Different SLA Policies: IaaS providers outline different SLA policies which reflect their commitment to providing different classes of resource availability defined in terms of “Uptime Percentage” (UP), which is typically defined as the percentage of time the resource is available during a five minute interval Amazon S3 Service Level Agreement (2014, 2014). These policy types can be represented in our SLA model using and and allow us to apply a wider range of transformation – compared to SLAs of type . Thus in our next experiment we measure the effect of supporting different SLA policy types. We use the same model described above to generate non-fluid workloads with and and set . We also set to be equivalent to the number of windows that correspond to a five minute interval, and to be equal to * W, where defines UP and ranges from 99.9% to 99.5%. We also vary the percentage of workloads colocated under a UP policy.

Figure 12 shows the result obtained using FF-NR. As expected, less uptime percentage leads to better CE. In addition, CE increases as we vary the the percentage of worloads colocated under a UP policy. The Figure highlights the use of additional transformation in providing us more flexiblity for colocation, and hence a better performance.

Figure 11: Effect of different types of transformations on the CE of FF-NR ().
Figure 12: Effect of additional SLA transformations on the CE of FF-NR ().

System Scalability: In our experiments, the WAS component of MorphoSys was able to handle large clusters of resources (disks) – up to . If migration of workloads is not enabled, WRS is able to handle even larger clusters in an “online” fashion. Enabling migration introduces significant computational overheads when dealing with large clusters. This makes the use of migration in WAS more practical for “off-line” (batch) use.

In a typical IaaS setting, there might be even more than a few thousand resources under management, which would be more than what a single WAS instance can handle. We note that in such cases, a practical solution would be to group the resources under management into separate clusters, each of which is managed by a single WAS.

We note that our measurement of scalability deals only with the computational aspect of MorphoSys (namely, computing efficient colocation configuration). In actual deployments, scalability will also depend on additional considerations due to system overheads that are dependent on the specific setting. For IaaS settings like the one considered in the experiments we presented in this paper (colocation of streaming servers), one would not expect much reconfiguration overheads except that of migrating and merging user stream requests. The effect of such overheads can be reduced using a number of ways including manipulation of stream playout rates or by inserting secondary content in the stream Basu et al. (1999) (e.g. as done in systems like Crackle Crackle (2013)). However, in other settings involving more significant overheads (e.g., the handling of large memory VM images to allow VM migration across hosts), the scalability of MorphoSys will depend on the efficient management of such aspects.

7 Related Work

Service Level Agreements (SLAs): There has been a significant amount of research on various topics related to SLAs. The usage of resource management in grids have been considered in Czajkowski et al. (2002); issues related to specification of SLAs have been considered in Keller and Ludwig (2003); and topics related to the economic aspects of SLAs usage for service provisioning through negotiation between consumers and providers are considered in Barmouta and Buyya (2003). A common characteristic (and/or inherent assumption) in the above-referenced body of prior work is that the customer’s SLAs are immutable. We break that assumption by recognizing the fact that there could be multiple, yet functionally equivalent ways of expressing and honoring SLAs. Our MorphoSysframework utilizes this degree of freedom to achieve significantly better colocation.

VM Colocation: VM consolidation and colocation are very active research topics that aim to minimize the operating cost of data centers in terms of hardware, energy, and cooling, as well as providing a potential benefit in terms of achieving higher performance at no additional cost. Much work has gone into studying the consolidation of workloads across various resources: CPU, memory, and network Cardosa et al. (2009); Ishakian et al. (2010b); Wood et al. (2009); Xiaoqiao Meng and Zhang (2010); Podzimek et al. (2015). Podzimek et al study the impact of CPU pinning on performance interference and energy efficiency Podzimek et al. (2015). Wood et al Wood et al. (2009) promote colocation as a way to minimize memory utilization by sharing portions of the physical memory between multiple colocated VMs. Ishakian et al Ishakian et al. (2010b) presented a colocation service which utilizes game theoretic aspects to achieve significant cost savings for its (selfish) users. Network-aware consolidations have been studied in Xiaoqiao Meng and Zhang (2010). Affinity aware VM Placement has been studied in Chen et al. (2016). Colocation has also been explored as a means of reducing the power consumption in data centers, for example by Cardosa et al Cardosa et al. (2009). We note that in all these works, the specification of the resource requirements for a VM is static and based on some fixed average requested capacities. In our work, the specification of resource needs is much more expressive as it allows VMs to control their resource allocation time-scale, as well as expose any flexibilities VMs may have regarding such timescale.

Real-Time Scheduling: Different scheduling algorithms were suggested to deal with scheduling of periodic/aperiodic hard real-time and soft-real time tasks Davis and Burns (2009) (and the references within). In addition, variants of proportional-share scheduling algorithms – based on the concept of Generalized Processor Sharing (GPS) have been suggested Duda and Cheriton (1999) – which allow the integration of different classes of applications. These approaches however do not take into consideration reservation of resources and fairness in allocating resources. The work by Buttazzo et al Buttazzo, et al. (1998) present an elastic task model based on a task defined using a tuple , where is the period that the task requires, and define the maximum and minimum periods that a task can accept. Our SLA model allows us to express classes of applications that are more general than the elastic task model. Moreover, the SLA transformations that we utilize allow us to serve workloads under completely different server supplied resources.

Hierarchical Scheduling: hierarchical scheduling (and in particular hierarchical CPU scheduling) has been a topic of research for over a decade because it allowed multiple scheduling mechanisms to co-exist on the same infrastructure – i.e., regardless of the underlying system scheduler. For example, Goyal et al Goyal et al. (1996) proposed a hierarchical scheduling framework for supporting different application classes in a multimedia system; Shin and Lee Shin and Lee (2005) further generalized this concept, advocating its use in embedded systems. Along the same lines, there has been a growing attention to building hierarchical real-time scheduling frameworks supporting different types of workloads Regehr, and Stankovic, (2001); Henzinger and Matic (2006).

A common characteristic (and/or inherent assumption) in the above-referenced, large body of prior work (which we emphasize is not exhaustive) is that the “clustering” (or grouping) of applications and/or schedulers under a common ancestor in the scheduling hierarchy is known a priori based on domain specific knowledge, e.g., all applications with the same priority are grouped into a single cluster, or all applications requiring a particular flavor of scheduling (e.g., periodic real-time EDF or RMS) are grouped into a single cluster managed by the desired scheduling scheme. Given such a fixed hierarchical structure, most of this prior body of work is concerned with the schedulability problem – namely deciding whether available resources are able to support this fixed structure.

Resource Allocation in Distributed Settings: Different approaches have been suggested to deal with resource allocation in distributed settings Podzimek et al. (2017); Netto et al. (2007); Foster et al. (2002); Buyya et al. (2000); Czajkowski et al. (1999) among many others. In these works, the main mechanisms used for providing QoS guarantees to users are through resource reservations. Such reservations can be immediate, undertaken in advance Foster et al. (2002), or flexible Netto et al. (2007). To achieve efficient allocation and increased resource utilization, these approaches model workloads as having a start time and end time. Under such approaches the resources allocated to a workload would still be based on a percentage reservation, which results in performance variability specifically for periodic workload requests. Our work complements these models by allowing for an expressive SLA model that admits the specification of constraint flexibilities. We believe that providing this capability is crucial for the deployment of QoS-constrained workloads while at the same time ensuring efficient utilization of resources.

Resource Allocation in Cloud Settings: Efficient scheduling of workloads in the cloud settings is an active topic of research Ishakian et al. (2010a); Jennings and Stadler (2015) with central schedulers that focus on soft constraints such as data locality Zaharia et al. (2010), deadlines Yang et al. (2013); Delimitrou and Kozyrakis (2014), resource guarantees Curino et al. (2014) or fairness Ghodsi et al. (2011). Carvalho et al Carvalho et al. (2014) analyze historical cloud workload data and motivate for the introduction of a new class of cloud resource offerings. Curino et al. Curino et al. (2014) propose a reservation-based system with a declarative language similar to how EC2 resources are requested. In addition to resources requests, our SLA language incorporates predictable (timely) access to resources and allows for the customers to provide their flexibility. Yang et al Yang et al. (2013) developed an online scheme that detects memory pressure and finds colocations that avoid interference on latency-sensitive applications. Zaharia et al Zaharia et al. (2010) use delayed scheduling of tasks to capitalize on data locality. Results show decreased job turnaround times. Chen et al Chen et al. (2014)

proposed a long term load balancing VM migration algorithm based on finite-markov decision process with the goal of reducing SLA violations. The

MorphoSys framework uses safe transformations of workloads as a tool that complements these methods to enable efficient colocation while ensuring that the scheduled workloads have predictable access to resources.

8 Conclusion

The value proposition of virtualization technologies is highly dependent on our ability to identify judicious mappings of physical resources to virtualized instances that could be acquired and consumed by applications subject to desirable performance (e.g., QoS) bounds. These bounds are often spelled out as a Service Level Agreement (SLA) contract between the resource provider (hosting infrastructure) and the resource consumer (application workload). By necessity, since infrastructure providers must cater to very many types of applications, SLAs are typically expressed as fixed fractions of resource capacities that must be allocated (or are promised) for unencumbered use. That said, the mapping between “desirable performance bounds” and SLAs is not unique. Indeed, it is often the case that multiple SLA expressions might be functionally equivalent with respect to the satisfaction of these performance bounds. Having the flexibility to transform SLAs from one form to another in a manner that is safe would enable hosting solutions to achieve significant economies of scale.

In this paper, we proposed a new SLA model for managing QoS-constrained workloads in IaaS settings. Our SLA model supports an expressive specification of the requirements for various classes of applications, thus facilitating auditability and performance predictability using simple measurement techniques. We presented the architectural and algorithmic blueprints of a framework for the deployment of dynamic colocation services. MorphoSys utilizes workload SLA transformations (exploiting any flexibility therein) for efficient management of QoS-constrained workloads in the cloud. We evaluated our framework by considering a cloud storage service scenario, and performed extensive evaluation using real video traces. The results reported in this paper – which suggest significant reduction in unallocated (wasted) resources of up to 60 percent – underscore the potential from deploying MorphoSys-based services.


  • Amazon EC2 Service Level Agreement (2014) Note: Cited by: §6.
  • Amazon S3 Service Level Agreement (2014) Note: Cited by: §6.
  • C. Babcock (2011) Cloud connect: netflix finds home in amazon ec2. Note:
    Cited by: §1.
  • S.K. Barker and P. Shenoy (2010) Empirical evaluation of latency-sensitive application performance in the cloud. In Proceedings of the first annual ACM SIGMM conference on Multimedia systems, Cited by: §1, §6.
  • A. Barmouta and R. Buyya (2003) In GridBank: A Grid Accounting Services Architecture (GASA) for Distributed Systems Sharing and Integration, IPDPS ’03, Washington, DC, USA. External Links: ISBN 0-7695-1926-1 Cited by: §7.
  • S. K. Baruah, R. R. Howell, and L. Rosier (1990) Algorithms and Complexity Concerning the Preemptive Scheduling of Periodic, Real-Time Tasks on One Processor. Real-Time Systems 2, pp. 301–324. Cited by: §5.2.
  • S. A. Baset (2012) Cloud slas: present and future. ACM SIGOPS Operating Systems Review 46 (2), pp. 57–66. Cited by: §1.
  • P. Basu, A. Narayanan, W. Ke, and T.D.C. Little (1999) Optimal scheduling of secondary content for aggregation in video-on-demand systems. In ICCCN, pp. 104–109. Cited by: §6.
  • G. C. Buttazzo,, G. Lipari,, and L. Abeni, (1998) Elastic Task Model for Adaptive Rate Control. In RTSS, Washington, DC. External Links: ISBN 0-8186-9212-X Cited by: §7.
  • R. Buyya, D. Abramson, and J. Giddy (2000) Nimrod/G: An Architecture For a Resource Management and Scheduling System in a Global Computational Grid. In The Fourth International Conference/Exhibition on High Performance Computing in the Asia-Pacific Region, Vol. 1. External Links: ISSN Cited by: §7.
  • M. Cardosa, M. Korupolu, and A. Singh (2009) Shares and Utilities Based Power Consolidation in Virtualized Server Environments. In Proc. of IFIP/IEEE Integrated Network Management, Cited by: §1, §7.
  • M. Carvalho, W. Cirne, F. Brasileiro, and J. Wilkes (2014) Long-term slos for reclaimed cloud computing resources. In Proceedings of the ACM Symposium on Cloud Computing, pp. 1–13. Cited by: §7.
  • J. Chen, Q. He, D. Ye, W. Chen, Y. Xiang, K. Chiew, and L. Zhu (2016) Joint affinity aware grouping and virtual machine placement. Microprocessors and Microsystems. Cited by: §7.
  • L. Chen, H. Shen, and K. Sapra (2014) Distributed autonomous virtual resource management in datacenters using finite-markov decision process. In Proceedings of the ACM Symposium on Cloud Computing, Cited by: §7.
  • L. Cherkasova and L. Staley (2003) Building a performance model of streaming media applications in utility data center environment. In CCGrid, Cited by: §6.
  • Crackle (2013) Note: Cited by: §6.
  • C. Curino, D. E. Difallah, C. Douglas, S. Krishnan, R. Ramakrishnan, and S. Rao (2014) Reservation-based scheduling: if you’re late don’t blame us!. In Proceedings of the ACM Symposium on Cloud Computing, pp. 1–14. Cited by: §7.
  • K. Czajkowski, I. Foster, and C. Kesselman (1999) Resource Co-allocation in Computational Grids. In The Eighth International Symposium on High Performance Distributed Computing, Cited by: §7.
  • K. Czajkowski, I. Foster, C. Kesselman, V. Sander, and S. Tuecke (2002) SNAP: A Protocol for Negotiating Service Level Agreements and Coordinating Resource Management in Distributed Systems. In Job Scheduling Strategies for Parallel Processing, Lecture Notes in Computer Science, Vol. 2537. Cited by: §7.
  • S.J. Daigle and J.K. Strosnider (1994) Disk Scheduling for Multimedia Data Streams. In Proceedings of the IS&T/SPIE, Cited by: §6.
  • R.I. Davis and A. Burns (2009) A Survey of Hard Real-Time Scheduling Algorithms and Schedulability Analysis Techniques for Multiprocessor Systems. techreport Technical Report YCS-2009-443, University of York, Department of Computer Science. Cited by: §2, §7.
  • C. Delimitrou and C. Kozyrakis (2014) Quasar: resource-efficient and qos-aware cluster management. In Proceedings of the 19th international conference on Architectural support for programming languages and operating systems, pp. 127–144. Cited by: §7.
  • K. J. Duda and D. R. Cheriton (1999) Borrowed-virtual-time (BVT) Scheduling: Supporting Latency-sensitive Threads in a General-purpose Scheduler. SIGOPS Oper. Syst. Rev. 33 (5), pp. 261–276. External Links: ISSN 0163-5980 Cited by: §7.
  • I. Foster, C. Kesselman, C. Lee, B. Lindell, K. Nahrstedt, and A. Roy (2002) A Distributed Resource Management Architecture That Supports Advance Reservations and Co-allocation. In IWQoS’99, Cited by: §7.
  • M.R. Garey and D.S. Johnson (1979) Computers and Intractability. A Guide to The Theory of NP-completeness. A Series of Books in the Mathematical Sciences. San Francisco. Cited by: §5.2.
  • A. Ghodsi, M. Zaharia, B. Hindman, A. Konwinski, S. Shenker, and I. Stoica (2011) Dominant resource fairness: fair allocation of multiple resource types.. In NSDI, Vol. 11, pp. 24–24. Cited by: §7.
  • P. Goyal, X. Guo, and H. M. Vin (1996) A Hierarchical CPU Scheduler for Multimedia Operating Systems. In OSDI, Cited by: §7.
  • A. Haeberlen (2010) A case for the accountable cloud. SIGOPS Oper. Syst. Rev. 44, pp. 52–57. External Links: ISSN 0163-5980 Cited by: §1.
  • T. A. Henzinger and S. Matic (2006) An Interface Algebra for Real-Time Components. In Proceedings of the 12th IEEE Real-Time and Embedded Technology and Applications Symposium, Washington, DC, USA. External Links: ISBN 0-7695-2516-4 Cited by: §7.
  • V. Ishakian, A. Bestavros, and A. Kfoury (2010a) A Type-Theoretic Framework for Efficient and Safe Colocation of Periodic Real-Time Systems. IEEE RTCSA. External Links: ISSN 1533-2306 Cited by: §7.
  • V. Ishakian and A. Bestavros (2012) MORPHOSYS: efficient colocation of qos-constrained workloads in the cloud. In 2012 12th IEEE/ACM International Symposium on Cluster, Cloud and Grid Computing (ccgrid 2012), pp. 90–97. Cited by: footnote 1.
  • V. Ishakian, A. Lapets, A. Bestavros, and A. Kfoury (2011) Formal verification of sla transformations. In Services (SERVICES), 2011 IEEE World Congress on, pp. 540–547. Cited by: footnote 5.
  • V. Ishakian, R. Sweha, J. Londoo, and A. Bestavros (2010b) Colocation as a Service. Strategic and Operational Services for Cloud Colocation. In IEEE NCA, Boston, USA. Cited by: §7.
  • B. Jennings and R. Stadler (2015) Resource management in clouds: survey and research challenges. Journal of Network and Systems Management 23 (3), pp. 567–619. Cited by: §7.
  • A. Keller and H. Ludwig (2003) The WSLA Framework: Specifying and Monitoring Service Level Agreements for Web Services. J. Netw. Syst. Manage. 11, pp. 57–81. External Links: ISSN 1064-7570 Cited by: §7.
  • J. P. Lehoczky, L. Sha, and Y. Ding (1989) Rate-Monotonic Scheduling Algorithm: Exact Characterization and Average Case Behavior. In Proc. of the 11th IEEE Real-time Systems Symposium, Cited by: §2, §3.3.
  • J. Li, Q. Wang, C. A. Lai, J. Park, D. Yokoyama, and C. Pu (2014) The impact of software resource allocation on consolidated n-tier applications. In Cloud Computing (CLOUD), 2014 IEEE 7th International Conference on, pp. 320–327. Cited by: §1.
  • C. L. Liu, and J. W. Layland, (1973) Scheduling Algorithms for Multiprogramming in a Hard-Real-Time Environment. J. ACM 20 (1). External Links: ISSN 0004-5411 Cited by: §2, §2, §6.
  • J. Londoo and A. Bestavros (2008) NETEMBED: A network resource mapping service for distributed applications. In IPDPS 2008., External Links: ISSN 1530-2075 Cited by: §5.2, §5.2.
  • A. Molano, K. Juvva, and R. Rajkumar (2002) Real-time Filesystems. Guaranteeing Timing Constraints for Disk Accesses in RT-Mach. In RTSS, pp. 155–165. External Links: ISBN 0818666005, ISSN 1052-8725 Cited by: §6.
  • M. A. Netto, K. Bubendorfer, and R. Buyya (2007) SLA-Based Advance Reservations with Flexible and Adaptive Time QoS Parameters. In 5th international conference on Service-Oriented Computing, External Links: ISBN 978-3-540-74973-8 Cited by: §7.
  • A. Podzimek, L. Bulej, L. Y. Chen, W. Binder, and P. Tuma (2015) Analyzing the impact of cpu pinning and partial cpu loads on performance and energy efficiency. In Cluster, Cloud and Grid Computing (CCGrid), 2015 15th IEEE/ACM International Symposium on, pp. 1–10. Cited by: §1, §7.
  • A. Podzimek, L. Bulej, L. Y. Chen, W. Binder, and P. Tuma (2017) Reprint of “robust partial-load experiments with showstopper”. Future Generation Computer Systems 72, pp. 81–104. Cited by: §7.
  • J. Regehr, and J. A. Stankovic, (2001) HLS: A Framework for Composing Soft Real-Time Schedulers. In Proceedings of the 22nd IEEE Real-Time Systems Symposium, Washington, DC, USA, pp. 3. External Links: ISBN 0-7695-1420-0 Cited by: §7.
  • I. Shin and I. Lee (2005) A Compositional Framework for Real-Time Embedded Systems. In Service availability: Second International Service Availability Symposium, Berlin, Germany. Cited by: §7.
  • K. Sripanidkulchai, S. Sahu, Y. Ruan, A. Shaikh, and C. Dorai (2010) Are clouds ready for large distributed applications?. SIGOPS Oper. Syst. Rev. 44, pp. 18–23. External Links: ISSN 0163-5980 Cited by: §1.
  • G. Van der Auwera, P.T. David, and M. Reisslein (2008) Traffic and Quality Characterization of Single-Layer Video Streams Encoded with the H.264/MPEG-4 Advanced Video Coding Standard and Scalable Video Coding Extension. IEEE Transactions on Broadcasting 54 (3). External Links: ISSN 0018-9316 Cited by: §6, §6.
  • E. Veloso, V. Almeida, W. Meira, A. Bestavros, and S. Jin (2006) A Hierarchical Characterization of a Live Streaming Media Workload. IEEE/ACM Transactions on Networking 14 (1). Cited by: §6.
  • T. Wood, G. Tarasuk-Levin, P. Shenoy, P. Desnoyers, E. Cecchet, and M. D. Corner (2009) Memory Buddies: Exploiting Page Sharing for Smart Colocation in Virtualized Data Centers. In VEE, Washington, DC. Cited by: §1, §7.
  • V. P. Xiaoqiao Meng and L. Zhang (2010) Improving the Scalability of Data Center Networks with Traffic-aware Virtual Machine Placement. INFOCOM. Cited by: §1, §7.
  • H. Yang, A. Breslow, J. Mars, and L. Tang (2013) Bubble-flux: precise online qos management for increased utilization in warehouse scale computers. In ACM SIGARCH Computer Architecture News, Vol. 41. Cited by: §7.
  • M. Zaharia, D. Borthakur, J. Sen Sarma, K. Elmeleegy, S. Shenker, and I. Stoica (2010) Delay scheduling: a simple technique for achieving locality and fairness in cluster scheduling. In Proceedings of the 5th European conference on Computer systems, pp. 265–278. Cited by: §7.

Appendix A

Lemma 0.

Given the periods and such that . Then an interval of length would contain at least intervals of length where .


Figure 14 highlights the existence of a schedule such that overlaps intervals where and and . Assume the existance of a schedule where overlaps only with intervals as shown in Figure 14.

Figure 13: Example of overlapping intervals
Figure 14: Schedule where overlaps with

We observe that . From the definition we have . Therefore, But by definition and – a contradiction. ∎

Lemma 0.

Given or , it is necessary for .


We provide counter-examples for all possible values of and .

  • and . Then unless , we could have or . Contradiction.

  • and Then unless , we could have or . where . Contradiction.

  • and Then unless , we could have or . Contradiction.