trace-driven analysis of power proportionality in storage systems

Post on 24-Feb-2016

37 Views

Category:

Documents

0 Downloads

Preview:

Click to see full reader

DESCRIPTION

Trace-Driven Analysis of Power Proportionality in Storage Systems. Sara Alspaugh and Arka Bhattacharya. Why trace-driven analysis. Lots of published proposals Giant design space. Some r elated work. Method. Laboratory. Production. - PowerPoint PPT Presentation

TRANSCRIPT

Trace-Driven Analysis of Power Proportionality in Storage SystemsSara Alspaugh and Arka Bhattacharya

Why trace-driven analysis

• Lots of published proposals

• Giant design space

Some related workScheme Block

Device / RAID Level

File System Level

Fixed Thresh-hold

Pred-ictive

Erasure Codes (RAID5)

Mirror-ing (RAID1)

Write Logging

Access Freq.-Based Layout

Solid State Devices

Multi-speed Disks

Hybrid / Tiered

DIV-ACC X X X X

EERAID1 X X X X

EERAID5 X X X X X

RIMAC X X X X

PARAID X X X X

PDC X X X

PA-LRU X X X

PB-LRU X X X X

HIBERN X X X X X X

DPRM X X X X

WOL X X X X X X

MAID X X X X

SSD-RAID X X X X X X

EED X X X X X X

SIERRA X X X X

RABBIT X X X X X

Method

EvaluationLaboratory Production Implementation is

infeasible when considering many system types.

AnalysisComponents

Traces

Algorithms

?

Trace Type Citation

Wikipedia HTTP SOCC ‘10NetApp, Harvard NFS USENIX ‘08, LISA ‘03MSR Cambridge Block Device FAST ‘08Facebook Analytics Hadoop MapReduce EuroSys ‘11Google Web Search ISCA ‘11

AnalysisComponents

Traces

Algorithms

CharacteristicsRequest RateInterarrival TimesRead-Write Mix...

Quantifying Inherent Opportunity• gain =

diff(peak x length, sum(bandwidth)) /peak x length

• waste factor = peak x length / sum(bandwidth)

• waste factor = peak:avg

time

band

widt

h

time

band

widt

h

data set size (B)

band

widt

h re

quire

men

ts

(B/s

)

data set size (B)

band

widt

h re

quire

men

ts (B

/s)

data set size (B)ba

ndwi

dth

requ

irem

ents

(B

/s)

data set size (B)

band

widt

h re

quire

men

ts

(B/s

)

bw_app >> bw_componentcap_app < cap_component

bw_app <= bw_{components}cap_app >> cap_component

unit = disks

Band

widt

h (b

ytes

/ se

c )

Capacity (bytes)

partition

replicate

~ 500 GB

~ 50 MB/s

laptop NFS filer

DB server

unit = servers

band

widt

h

bytes

partition

replicate

~ 12 TB (disk)

memory cache

DFS

~ 32 GB (RAM)

DB server

~ 200 MB/s

~ 1 GB/s

data set size (B)ba

ndwi

dth

requ

irem

ents

(B/s

)

data set size (B)

band

widt

h re

quire

men

ts

(B/s

)

data set size (B)

band

widt

h re

quire

men

ts

(B/s

)

NAS / NFS (NetApp), disk arrays

web farms (Wikipedia)

data analytics, DFS (Hadoop)

data set size (B)

band

widt

h re

quire

men

ts

(B/s

)

data set size (B)

band

widt

h re

quire

men

ts (B

/s)

data set size (B)ba

ndwi

dth

requ

irem

ents

(B

/s)

data set size (B)

band

widt

h re

quire

men

ts

(B/s

)

bw_app >> bw_componentcap_app < cap_component

bw_app <= bw_{components}cap_app >> cap_component

Challenges• Case 1: writes• Case 2: latency to inactive

components• Case 3: both of the above, set cover

problem

write through: to all components (even if requires waking some)

write offloading: to active components only (propagate on wake)

write log: propagate when ~full reaper: to all components but only wake when queue is full

time

band

widt

h

requests

active units write-offloading

active units write-through

Next steps• data not pictured

here– latencies– ramp times– unit sizes– etc.

• ways to slice it• how to visualize it

• more workloads• go back to related

work to compare• case 3– object popularity

QUESTIONS?The End.

top related