FAWN: Fast Array of Wimpy Nodes
Developed By
D. G. Andersen, J. Franklin, M. Kaminsky, A. Phanishayee, L. Tan, V. Vasudevan
Presented
by
Peter O. Oliha
Chengyu Zheng
UCL Computer Science
COMPM038/COMPGZ06
Motivation
• Can we reduce energy use by a factor of ten?
• Still serve the same workloads.
• Avoid increasing capital cost.
Power Consumption and Computing
• High amount of energy is required for large amounts
of data processing
• “Energy consumption by data centers could nearly
double ...(by 2011) to more than 100 billion kWh,
representing a $7.4 billion annual electricity cost”
[EPA Report 2007]
FAWN System
• FAWN-KV is a key/value store with per-node
datastore built on flash storage.
• Desires to reduce energy consumption
• Each node: Single core 500MHz AMD
processor, 256MB RAM, 4GB CompactFlash
device
FAWN -Components
•FAWN
–Flash
–FAWN-DS
•Log structured data
store
–FAWN-KV
• Key/value system
• Put()/get() interface
FAWN Approach: Why use
“wimpy” nodes
•Match CPU-I/O processing times
•Using wimpy processors reduce I/O-induced idle
cycle while maintaining high performance
•Fast CPU’s consumes more power
•Spends longer time idle, so less utilization
FAWN Approach: Why use Flash
Storage
•Fast Random Reads
–<<1ms upto 175 times faster than random reads
on magnetic disks
•Efficient I/O
–Consumes less than 1W even under heavy load
•Slow Random writes
–influences design of the FAWN-DS
•Suitable for desired workload; random-access,
read-intensive.
FAWN-DS: Datastore
Functions: Lookup, store ,delete, merge, split, compact
Designed specifically for flash characteristics
–Sequential writes, single-random-access reads
FAWN-DS: Store, Delete
Store:
-Appends an entry to
the log
-Updates hash table
entry to point to the
offset within the data
log
-Set valid bit to 1
- If the key written
already exists, the old
value is now orphaned.
Delete:
-Invalidates hash entry
corresponding to the key
-Clears the valid bit
-Writes “delete entry” at
the end of the file
-Delete operations are not
applied immediately to
avoid random writes.
-Deletes are carried out
on compact operations
FAWN-DS: Maintenance
Split, Merge, Compact
Split & Merge



Parses the Data log sequentially
Splits single DS into two, one for
each key range
Merge writes every log entry from
one DS to the other
Compact



Cleans up entries to the data
store
It Skips

Entries outside data store
key range

Orphaned entries

Delete entries corresponding
to the above
Writes all other valid entries to
the output data store
FAWN-KV: The key-value system
Client Front-end
Services client requests through standard put/get
interface.
Passes request to the back-end
Back-end
Satisfies requests using its FAWN-DS
Replies front-end
FAWN-KV: Consistent hashing
•Consistent hashing used
to organize FAWN-KV
virtual ID’s (similar to
Chord DHT)
•Uses 160-bit circular ID
space
•Does not use DHT routing
FAWN-KV: Replication and
Consistency
•Items stored at successor and R-1 virtual ID’s
•Put()’s are successful when writes are
completed on all virtual nodes.
•Get()s are directly routed to the tail of the chain
FAWN-KV: Joins and Leaves
•Joins occur in 2 phases
–Datastore pre-copy
•New node gets data from current tail
–Chain insertion, log flush
•Leaves
–Replicas must merge key range owned by departed node
–Add a new replica to replace departed node: equivalent to a join
FAWN-KV: Failure Detection
• Nodes are assumed to be fail-stop
• Each front-end exchanges heartbeat messages with nodes
FAWN: Evaluation
1. Individual Node Performance
2. FAWN-KV 21-Node System
•Single core 500MHz AMD processors, 256MB
RAM, 4GB CompactFlash device
•Workload targets small objects that are readintensive( 256 byte and 1KB)
FAWN: Single Node Lookup and Write Speed
• 80% lookup Speed of raw
flash systems
• Insert rate
23.2MB/s(~24Kentries/s)
is 96% write Speed of raw
Flash Systems
FAWN: Read-intensive vs. Write-intensive workload
FAWN: Semi-Random Writes
FAWN: System Power Consumption
•Measurements shown at peak performance
FAWN: Node Joins and Power
•Measurements shown at
max and low loads
•Joins take longer to
complete at max load
FAWN: Splits and Query Latency
•For purely get()
workloads
•Split increases query
latency
FAWN Nodes vs. Conventional
Nodes
•Traditional systems still have sub-optimal
efficiency.
TCO: FAWN vs. Traditional
Architecture
FAWN: When to use FAWN?
•FAWN-Based system can provide lower cost
per (GB, QueryRate)
Related Work
• JouleSort: energy efficiency benchmark developed
for disk-based low-power CPU.
• CEMS, AmdahlBlades, Microblades: advocates
low-cost, low-power components as building blocks
for Datacenter systems
• IRAM Project: CPU's and memory into a single unit.
IRAM-based CPU could use quarter of the power
of conventional system for same workload.
• Dynamo: distributed hashtable structure providing
availability to certain workloads
Future Work
• Consider more failure scenarios
• Management node replication
• Use in computationally intensive/large
dataset workloads
• Decrease impact of split on query latency
FAWN: Conclusion
•Fast and efficient processing of random readintensive workloads.
• More work done with less power
•FAWN-DS balances read/write throughput
•FAWN-KV balances workload while maintaining
replication and consistency
•Splits and Joins affect latency at high workload
•Can it be used for computational intensive
workloads?