System Analysis and Optimization 1 1 Efficient Resource Provisioning in Compute Clouds via VM Multiplexing Xiaoqiao Meng, Canturk Isci, Jeffrey Kephart,

1 System Analysis and Optimization 1

Efficient Resource Provisioning in Compute Clouds via VM Multiplexing

Xiaoqiao Meng, Canturk Isci, Jeffrey Kephart, Li Zhang, Eric Bouillet, Dimitrios Pendarakis

IBM T.J. Watson Research Center

7th IEEE International Conference on Autonomic Computing, 2010


Credit

Modified version of conference presentation slides provided by Xiaoqiao Meng.

7th IEEE International Conference on Autonomic Computing


Outline Background VM multiplexing Related work Design

Performance constraint VM selection Joint-VM sizing

Applications Summary


Resource provisioning in cloud

Networkequipments

Servers Storage

Virtual machine pools

Cloud creates an illusion of “infinite” pool of resources

Cloud manages resources via creating and consolidating Virtual Machines

Efficiency of resource provisioningmeasured by overall resource utilization

Cloud resource provisioning: decisionon VM size and VM placement


VM sizing Static: fixed size upon VM creation

Easy to manage Lack of elasticity in resource reuse

Dynamic: size adapts to demand High resource utilization Avoiding over and under-provisioning is challenging

CPU utilization for a VM instance in 4 months

Peak-load as VM size

Chance for capacity violation < 1%


Traditional VM placement

CPU 8 cores

Memory 24 GByte

Physical host capacityVM size

VM 1

VM 3

VM 2

VM 4

CPU 12 cores

Memory 4 GByte

CPU 4 cores

Memory 12 GByte

CPU 4 cores

Memory 12 GByte

CPU 2 cores

Memory 8 GByte

CPU 2 cores

Memory 6 GByte

CPU 2 cores

Memory 4 GByte

VIR

TU

ALIZ

AT

ION

Placement is done separately from sizing VM size is fixed regardless of where it is placed

Target: minimize required physical servers or reduce energy cost Formulated as a multi-dimensional vector packing problem






VM workload multiplexing

Multiplex VMs’ workload on same physical server Aggregate multiple workload. Estimate total capacity need

based on aggregated workload Performance level of each VM be preserved

Separate VM sizing VM multiplexing

s1s2

s3

We expect s3 < s1 + s2. Benefit of multiplexing !


Example for VM multiplexing

Traditional method:Provision VMs separately.

Total capacity need= 1.04 cpu

Alternative method:Consolidate and provision three VMs as a whole

Total capacity need= 0.67 cpu

Gain from statistical multiplexing!


Potential Improvement by VM multiplexing

Test on servers in a Global Hosting Services 1325 physical hosts, 15000 VMs Based on 3-month CPU/memory utilization data

Average capacity saving per physical server = 39%






Related work Commercial capacity planning tools consider each VM’s need in

isolation IBM WebSphere CloudBurst, VMware capacity planner, Novell

PlateSpin Recon, Lanamark Suite Some research work stand on VM-by-VM basis

Low resource utilization. Some prior work consider inter-VM interaction and compatibility to

improve resource provisioning Hotcloud’09: co-place VMs not contending for same resource type OSDI’08, Hotcloud’09, VEE’09: co-place VMs with memory sharing MASCOTS’09. Eurosys’09: statistical multiplexing VM to save power NOMS’08: VM consolidation by formulating an optimization problem






Design of enabling VM multiplexing

Describe VM performance constraint Application performance as a function of VM capacity

Construct super-VM by multiplexing VMs Find VM combinations with complementary workload

Joint-VM sizing Determining total capacity needs for super-VM

1 2 3 4

5 6 7 8

Describe VM performance constraint (forecast)

Construct super-VM by multiplexing VMs

1 8 7 5

6 3 2 4

1 8 7 5

6 3 2 4

Sizing super-VM

2 cpu 3 cpu

1.5 cpu1 cpu

VM ConsolidationPlace super-VM on hostStandard VM placement techniques plugged in


Basis for computing VM size Parameters β, T adapt to various application types

Small T and β for time-sensitive, critical applications Large T and β for time-elastic, long-running background jobs T=0, β=0 corresponds to peakload-based sizing

VM performance constraint

time

Workload

T

Size cPerformance constraint on VM size

Number of intervals with size violation

Total interval number< β


Performance constraint with VM multiplexing

Important feature :

Knowing individual VM’s performance constraint

Total capacity need for super-VM without decreasing individual VM performance

easily derive

Given n VMs with individual ,

Let

If super-VM size satisfies , each VM must satisfy

individual

),( iiT

i

i

ii

ii

i TTTT

minmin,min

),( iiT

),( T

Choose the most stringent performance constraint


Proof of theorem T: minimum among all Ti, all Ti is power of 2

Time interval [1, Ti] can be divided into shorter interval

Holds for [1, Ti ], [ Ti+1, 2 Ti ], [ 2 Ti +1, 3 Ti]….

iT

T


Proof (cont.) Because:

Thus,


Construct super-VM Key for multiplexing:

complementary workload patterns

Approximately measured by correlation coefficient

Solution Greedy search

Recursively find VM pairs with most strong negative correlation

Clustering Pairwise distance measured by

correlation coefficient

Complementary workload!Strong negative correlation

Not-so-complementary workload!Strong positive correlation

Reference: R.O. Duda, Pattern Classification, 2nd Edition, Wiley

Interscience, 2001


Greedy search

Three-step process Find the VM pair (i,j) giving the

highest correlation coefficient. Output (i,j) as a candidate for joint provisioning

Remove VM i and j

Repeat Step 1 and 2 until all input VMs are removed

Correlation coefficient matrix


Super-VM sizing

1. Aggregation

2. Workload forecasting

0 20 40 60 80 100 120-0.5

0

0.5

1

1.5

2

Time (day)

Wo

rklo

ad

0 10 20 30 40 500

0.5

1

VM 1

Time (day)

Wo

rklo

ad

0 10 20 30 40 500

0.5

1

VM 2

Time (day)

Wo

rklo

ad

0 10 20 30 40 500

0.5

1

1.5

2

Time (day)

Wo

rklo

ad

0 20 40 60 80 100 120-0.5

0

0.5

1

1.5

2

Time (day)

Wo

rklo

ad

3. Determine total size by super-VM performance constraint


Workload forecastingDecouple individual VM’s workload into fluctuating and regular components. Forecasting limited to aggregate fluctuating workload

Standard timeseries forecasting methods are applied. Choose the one with smallest forecasting error based on historical data


Modeling forecast error Modeling forecasting error to compensate for workload variability Applied to any forecasting method

With explicit error model Compute error statistical distribution by training error model with historical data

Without explicit error model Use Kernel-Density-Estimation (KDE) to estimate error statistical distribution

by historical data






Application to VM consolidation

Tested on performance data from four cloud hostsUse First-fit-decreasing for VM consolidation

Performance gainWith VM multiplexing, 28%-62% less physical hosts required compared to no-multiplexing


Consolidation with various perf. constraint

Assume each VM has same performance constraint Observations:

Maximum extra capacity saving is 45% for T=0, β=0 Correspond to peakload-based sizing

Saving shrinks when β increases Workload dynamics make less different in terms of VM capacity violation

With forecasting, VM consolidation slightly more aggressive Lead to higher actual β than expected on certain physical hosts Overall, 88%-96% of hosts have actual β less than expected


Application to providing VM resource guarantees

Apply VM multiplexing to providing resource guarantees

Define “joint reservations” instead of individual VM reservations

Enforce joint reservations with the “resource pool” abstraction:


Application to providing VM resource guarantees

16%-75% of more VMs admitted by enabling joint-reservations. Gain subject to performance constraint

Higher gain for more stringent performance constraint






Summary Multiplex VMs with complementary workload

patterns to save more overall resource

Three design components Performance constraint VM selection Joint-VM size estimation

Enormous capacity saving in applications


Documents

System Analysis and Optimization 1 1 Efficient Resource Provisioning in Compute Clouds via VM Multiplexing Xiaoqiao Meng, Canturk Isci, Jeffrey Kephart,