FAWNdamentally Power-efficient Clusters David Andersen, for: Vijay - - PowerPoint PPT Presentation

▶
fawndamentally
SMART_READER_LITE
LIVE PREVIEW

FAWNdamentally Power-efficient Clusters David Andersen, for: Vijay - - PowerPoint PPT Presentation

Dec 19, 2022 180 likes •535 views

FAWNdamentally Power-efficient Clusters David Andersen, for: Vijay Vasudevan, Jason Franklin, Amar Phanishayee, Lawrence Tan, Michael Kaminsky*, Iulian Moraru Carnegie Mellon University, *Intel Research Pittsburgh 1 Monthly energy

slide-1
SLIDE 1

1

FAWNdamentally

Power-efficient Clusters

David Andersen, for: Vijay Vasudevan, Jason Franklin, Amar Phanishayee, Lawrence Tan, Michael Kaminsky*, Iulian Moraru Carnegie Mellon University, *Intel Research Pittsburgh

slide-2
SLIDE 2

2

Monthly energy statement considered harmful

  • Power is a limiting factor in computing
  • 3-year TCO soon to be dominated by

power cost [EPA 2007]

  • Influences location, technology choices
slide-3
SLIDE 3

3

Approaches to saving power

Infrastructure Efficiency

Power generation Power distribution Cooling

Dynamic Power Scaling

Sleeping when idle Rate adaptation VM consolidation

Computational Efficiency FAWN

Goal of computational efficiency: Reduce the amount of energy to do useful work

slide-4
SLIDE 4

4

FAWN

Fast Array of Wimpy Nodes

Improve computational efficiency

  • f data-intensive computing using

an array of well-balanced low- power systems.

AMD Geode 256MB DRAM 4GB CompactFlash

slide-5
SLIDE 5

5

Target: Data-intensive computing

  • Large amounts of data
  • Highly-parallelizable
  • Fine-grained, independent tasks

Workloads amenable to “scale-out” approach

slide-6
SLIDE 6

6

Outline

  • What is FAWN?
  • Why FAWN?
  • When FAWN?
  • Challenges (How FAWN?)
slide-7
SLIDE 7

7

  • 1. Fixed power costs dominate

Figure adapted from Tolia et. al HotPower 08

70% of peak power at 0% utilization!

}

Fixed power costs

Ideal

Power (W)

slide-8
SLIDE 8

8

  • How do we

balance?

  • Big CPUs

clocked down?

  • Embedded

CPUs?

  • Why not use

more disks with big CPUs?

  • 2. Balancing to save energy

Year

CPU-to-Disk seek Speed Ratio

slide-9
SLIDE 9

9

Speed vs. Efficiency

  • 3. Targeting the sweet-spot in

efficiency

Fast processors mask memory wall at the cost of efficiency Fixed power costs can dominate efficiency for slow processors FAWN targets sweet spot in processor efficiency when including fixed costs

slide-10
SLIDE 10

10

  • 4. Reducing peak power

consumption

  • Provisioning for peak power requires:
  • 1. worst case cooling requirements
  • 2. UPS systems upon power failure
  • 3. power generation and substations

investment

slide-11
SLIDE 11

11

What is FAWN good for?

  • Random-access workloads (Key-value Lookup)
  • Scan-bound workloads (Hadoop, Data Analytics)
  • CPU-bound workloads (Compression, Encryption)
slide-12
SLIDE 12

12

Performanc e Efficiency Density Cost

Important metrics

Work time Perf Watt Perf $ Perf Volume

slide-13
SLIDE 13

14

FAWN + CF (4W) Traditional + HD (87W) Traditional + SSD (83W)

Random access workloads

slide-14
SLIDE 14

15

Random access workloads

424.25 2.03448 69.8795

50 100 150 200 250 300 350 400 450 Queries/Joule

Performance Efficiency FAWN is 6-200x more efficient than traditional systems

slide-15
SLIDE 15

16

CPU-bound encryption

0.73 0.365 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 Encryption Efficiency (MB/J)

AES encryption/decryption of a 512MB file with a 256-bit key FAWN is 2x more efficient for CPU-bound operations! Performance Efficiency

slide-16
SLIDE 16

17

When to use FAWN for random access workloads?

  • Total cost of ownership
  • Capital cost + 3 year power @

$0.10/kWh

  • What is the cheapest architecture for

serving random access workloads?

  • Traditional + {Disks, SSD, DRAM}?
  • FAWN + {Disks, SSD, DRAM}?
slide-17
SLIDE 17

18

Architecture with lowest TCO

for random access workloads FAWN-based systems can provide lower cost per {GB, QueryRate}

Ratio of query rate to dataset size informs storage technology

slide-18
SLIDE 18

19

Challenges

  • Algorithms and Architectures at 10x scale
  • Dealing with Amdahl’s law
  • High performance using low performance

nodes

  • Today’s software may not run out of the box
  • Manageability, failures, network design,

power cost vs. engineering cost

“Each decimal order of magnitude increase in parallelism requires a major redesign and rewrite of parallel code” - Kathy Yelick

slide-19
SLIDE 19

20

But it’s possible...

  • Example: FAWN-KV high-performance

key-value store

slide-20
SLIDE 20

FAWN-KV

Requests Responses

slide-21
SLIDE 21

Using BerkeleyDB on ext3

  • Initially implemented using BDB on ext3
  • BDB uses B-tree indexing structure
  • Files stored on CompactFlash
  • Benchmarked:
  • Inserts (BDB file creation)
  • Splits
  • Merges
slide-22
SLIDE 22

DB Mgmt on Flash

Creating 1.8GB BDB File Split/Merge Operations

Number of Files Insertion Time 1 12 hours 50 min 8 3 hours 18 min 32 2 hours 26 min

B-Tree does many small, random writes. Flash does not like.

slide-23
SLIDE 23

Flash...

  • Setting a bit to 1 is free
  • Setting a bit to zero requires clearing a

128--256KB erase block

  • Practical consequence:
  • Seq reads fast; seq writes pretty fast;
  • rand reads decent; rand writes awful
  • Almost everything on flash becomes log

structured

slide-24
SLIDE 24

FAWNDB

  • Key-Value storage
  • Inserts written sequentially to end
  • Deletions/Appends require periodic compaction

In memory

Log-like behavior is free: DB already tracks location for key-value at byte granularity Filesystem or device can do so at block granularity, higher overhead Wimpy memory limits size

  • f DB.

Wimpies have little DRAM.

Key frag (15 bits) Offset (32 bits)

slide-25
SLIDE 25

FawnDB Performance

Creating 1.8GB BDB File

Number of Files Insertion Time 1 9.63 min 8 9.83 min 32 9.93 min

Creating 1.8GB FAWNDB File

Number of Files Insertion Time 1 12 hours 50 min 8 3 hours 18 min 32 2 hours 26 min

slide-26
SLIDE 26

Tackling other challenges

  • Limited DRAM
  • Good progress on developing new

“massive multi-grep” (given 1M strings, find if any of them occur in massive dataset) with low memory requirements

  • and more! :)
slide-27
SLIDE 27

28

Conclusion

  • FAWN improves the computational efficiency of

datacenters

  • Informed by fundamental system power trends
  • Challenges: programming for 10x scale, running today’s

software on yesterday’s machine, dealing with flash, ...

Thanks to: Google, Intel, NetApp http://www.cs.cmu.edu/~fawnproj/

slide-28
SLIDE 28

29

slide-29
SLIDE 29

21-node FAWN Cluster

2 Gb/s of small k-v queries @ 90W from 80GB dataset (on 4 year old hardware) 891µs median access time

slide-30
SLIDE 30

Cleaning & Merging: Not bad!

  • LFS traditional weak link: Cleaning...

Max load Low load

slide-31
SLIDE 31

More Design

  • Reliability: Chain replication
  • FAWN-DS is log structured
  • stream log tail to next replica
  • Load balancing
  • Front-ends have small cache;
  • working on: read from any replica, load

balancing across workers

slide-32
SLIDE 32

Database distribution

H G F A C B D E Requirements: 1) Spread data and queries uniformly 2) Handle node joins and departures without affecting many nodes

slide-33
SLIDE 33

(H,B]

Hash Index Values

H G F D C B

Consistent hashing

slide-34
SLIDE 34

(H,B]

Hash Index Values

H G F D C B A E

Node Addition

slide-35
SLIDE 35

splits and joins

(H,B]

Keys Values

(H,A] (A,B]

Split

At :

(H,A]

1 2 Transfer B A B