Top Banner
Sho Niboshi Hitoshi Oi University of Aizu {nibo,hitoshi}@oslab.biz
17
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Page 1: Xs sho niboshi

Sho NiboshiHitoshi Oi

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

Page 2: Xs sho niboshi

Research Objective

Conventional Approach

Idea of Resource Control

Methodology

Experiment

Results

Conclusion

2

Page 3: Xs sho niboshi

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

Page 4: Xs sho niboshi

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

4

Resource Allocation

Performance

Resource Allocation

Performance

Page 5: Xs sho niboshi

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

Page 6: Xs sho niboshi

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

Page 7: Xs sho niboshi

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

Page 8: Xs sho niboshi

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%

Page 9: Xs sho niboshi

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%

Page 10: Xs sho niboshi

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

Page 11: Xs sho niboshi

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

Page 12: Xs sho niboshi

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

Page 13: Xs sho niboshi

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

Page 14: Xs sho niboshi

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

Page 15: Xs sho niboshi

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)

Page 16: Xs sho niboshi

• 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

Page 17: Xs sho niboshi

17