Problem Formulation Elastic cloud infrastructures provision resources according to the current actual demand on the infrastructure while enforcing service level agreements (SLAs). Elasticity is the ability of the cloud to rapidly vary the allocated resource capacity to a service according to the current load in order to meet the quality of service (QoS) requirements specified in the SLA agreements. 1

Problem Formulation Problems: – When to release resources allocated to a service? Oscillations & increased costs if done prematurely as (de)allocation is costly. – Can we do better prediction for future demand to predict flash crowds and diurnal/periodical loads? – Which resources to release? Release cost is non-uniform (server consolidation, etc.) The elasticity engine should decrease the costs of operation for the cloud provider while not violating SLAs 2

Our solution -We start by trying to solve the problems one at a time starting with the problem of when to release the resources, i.e. we try to predict the when is it safe to release resources

Problem Formulation Prediction of load/signal/future is not a new problem It arises in a wide range of applications and scientific disciplines – Time series analysis, econometrics, stock markets, biology, control theory… There are solutions to the prediction problem – Neural networks, Kriging models, Fuzzy logic, adaptive control, regression,, etc.

Desired properties Fast – Limited lookahead control is quite accurate, but needs close to 0.5h for control of 15 physical machines and 60 VMs… Reliable (even when the load dynamics and operating conditions change) – PID-controllers reliable for certain load patterns, but breaks/become unstable once the load surges Should not also affect the reliability of the hardware – Reactive controllers are the best choice if you only look at the amount of allocated resources No resources are allocated until needed Resources are de-allocated once not needed But they cause large oscillations. Adaptive to changing workloads Scalable: A cloud will host hundreds of services on tens of thousands of VMs and physical machines. Simple: simplicity is a key to wide scale adoption

Our solution Build an adaptive P-Controller – P-Controllers are one of the simplest types of closed-loop controllers. – The error signal (the difference between the wanted output and the current output) is multiplied by a constant. – This constant changes according to the load dynamics (adaptive gain). – The rate of changing the constant is also adaptive according to the load dyanmics

Results (Fifa’98 traces) Reactive controller Our Controller

More results Regression based Controller Our Controller

Aggregate results PolicyNumber of servers not provisioned on time Number of servers over- provisioned Failure %Over- Provisioning % Reactive %2.2% Our Controller %3.6% Simulation using wikipedia traces from the wikibench project. As comparison, Rackspace SLA pays 10% of the bill back for availability=99.89% as a penalty.

Do we meet our constraints? The algorithm is very fast as the gain calculation depends on simple mathematical operations Adaptive according to load dynamics and thus reliable – Premature release of resources reduced significantly and thus hardware reliability is maintained Scalable: the calculations involved does not depend on the load of the volume or the number of VMs Simple: There is nothing simpler than a P- Controller ! – Except if you use thresholds Adaptive: Even the rate of changing the controller parameter changes