Xs sho niboshi

17
Sho Niboshi Hitoshi Oi University of Aizu {nibo,hitoshi}@oslab.biz

Transcript of Xs sho niboshi

Sho NiboshiHitoshi Oi

University of Aizu{nibo,hitoshi}@oslab.biz

Research Objective

Conventional Approach

Idea of Resource Control

Methodology

Experiment

Results

Conclusion

2

Proposes effective resource management method in a virtualized system under dynamic workload

What is a good resource manager?

Maintains application performance with minimal resources

Balances performance between applications

3

Conventional method allocates resources based on each VM’s demand:

4

Resource Allocation

Performance

Resource Allocation

Performance

Allocate resources based on relative performance

5

Mail Domain App Domain Mail Domain App Domain

Keeps the performance balanced!

Resource Resource

Pe

rfo

rma

nc

e

Pe

rfo

rma

nc

e

6

Mail server

QoS Controller

Mail Domain

DT LR

Arbitration Controller

Control Domain

App server

QoS Controller

App Domain

TT

Allocates CPU time

Req Req

QoS controller

Purpose: determine the amount of resources to maintain acceptable performance

Method: utilizes the empirical relationship between the performance and the allocated resources

modeled by Fuzzy control theory which incorporates the experience of a human process in its control design

7

Arbitration Controller

Purposes : balances relative performance of domains

Method: adjusts to system capacity and builds resource capacity layout

8

Example:Domain A, Domain B

Request: 60% + 90% = 150%Allocation:40% + 60% = 100%

Xen Summit AMD 2010 9

Cap-none

Cap-all

Resource Utilization

Resourc

e S

epara

tion

※Q1=QoS in domain1

Q2=QoS in domain2

Resource separation takes some overheads (unused resources)

Select most efficient capacity layout

Cap-some

Reqtotal < 100%

Q1 ≠ Q2

Q1 ≠ Q2

Q1 ≠ Q2

Reqtotal < 100%

10

System Specification

CPU AMD Athlon x2 (Dual Core) 2.0 GHz

Main Memory 4GB

HDD SATA 7200rpm x2

OS CentOS 5.2 (kernel 2.6.18)

VirtualizationSoftware

Xen hypervisor 3.2.2

Domain QoS indicator Workload

Mail domain Delivery TimeLogin Rate

SPECmail2001

Java app domain Transaction Time SPECjbb2005

Control CPU time

Experiments with two workload scenarios

Compare

WRC (With Proposed Resource Manager)

Default (Default Scheduler in Xen)

11

Intervals Scenario ↑Mail Scenario ↑Java

Sec Mail Java Mail Java

1-399 Medium Medium Medium Medium

400-1199 High Medium Medium High

1200-1600 Medium Medium Medium Medium

12

0

10

20

30

40

50

Delivery Time (sec)

Default WRC

0

0.05

0.1

0.15

0.2

0.25

Transaction Time (msec)

Default WRC

Mail increase Mail increase

13

0

1

2

3

4

5

6

Delivery Time (sec)

Default WRC

0

0.05

0.1

0.15

0.2

0.25

Transaction Time (msec)

Default WRC

Java increase Java increase

Resource Request follows QoS states

Adaptation delay occurs occasionally

In low priority domain, some requests don’t take account of QoS state Request is based on

current CPU consumption

Xen Summit AMD 2010 14

QoS Controller

Mail server

Arbitration Controller

App server

QoS Controller

0

10

20

30

40

50

60

0

0.05

0.1

0.15

0.2

0.25

0.3

0 200 400 600 800 1000 1200 1400 1600

% of total CPU (Request)

TransactionTime (msec)

Java - QoS vs. Request (↑Mail)

TransactionTime Request

0

10

20

30

40

50

60

70

80

0

10

20

30

40

50

60

0 200 400 600 800 1000 1200 1400 1600

% of total CPU (Request)

Delivery Time (sec)

Mail - QoS vs. Request (↑Mail)

DeliveryTime Request

The ratio between Consumption and Request is quite unstable

Different capacity layouts lead to different resource distributions

Xen Summit AMD 2010 15

QoS Controller

Mail server

Arbitration Controller

App server

QoS Controller

0.7

0.8

0.9

1

1.1

1.2

0.7 0.8 0.9 1 1.1 1.2Consumption / Request (Java)

Consumption / Request (Mail)

Consumption / Request Distribution

both Caps are 100

both caps are not 100

only Mail's Cap is 100

onlyJava's Cap is 100

0.8

0.9

1

1.1

1.2

0 500 1000 1500

ratio

Consumption / Request (↑Mail)

Ratio (Mail/Java)

• Proposed effective resource manager– Resource allocation reflecting application states

– Better performance than conventional method in one experiment

• However, worse performance in the other experiment

• Future work– Fast adaptation

– Uses variation of QoS state as control parameter– Dynamic rule construction

– Fair resource allocation– Needs more consideration about cap=100 (=0)

16

17