FAWN: Fast Array of Wimpy Nodes
Click icon to add picture
A technical paper presentation in fulfillment of the requirements ofCIS 570 – Advanced Computer Systems – Fall 2013
Scott R. [email protected] 14-Nov-2013
2
Overview• Identify the problem space
• FAWN as a solution– Architecture principles– Unique key-value storage
• Evaluate and benchmark a 21-node FAWN cluster
• Identify when FAWN makes sense
3
Theoretical Problem Space• CPU I/O gap
– Modern processors are so efficient that a lot of time is spent idle
• CPU power consumption scales linearly– Increased caches to keep the superscalar pipelines fed is a driver
• Dynamic Voltage Frequency Switching (DVFS) is inefficient– Intel SpeedStep technology– CPU still operates generally at 50% power consumption
4
What’s the real problem?• Electricity is expensive!
– Home usage is measured in KW, data center usage in MW
• Facebook use up to $1 million a month in electricity– Only three data centers!
• Oregon, USA• Virginia, USA• Sweden
5
Facebook’s Not Playing Around• Fourth data center to be powered by renewable wind
– Iowa, USA
6
http://goo.gl/sFmmxz dtd 14-Nov-2013
Proposed Solution• Fast Array of Wimpy Nodes (FAWN)
– Bridge the I/O gap• Use slower CPUs and faster Flash storage
– Reduce power consumption per node• Embedded CPUs consume significantly less power
– Address distributed storage for the new architecture• New key-value storage system (FAWN-KV)
– Complementary per node data store (FAWN-DS)
7
8
System Architecture
9
Basic Functions
10
Replication & Consistency
Understanding Flash Storage• Fast random reads
– 175x faster than HDDs– Vary wildly between make/models
• Efficient I/O– Very low power– High query per Joule rate vs. HDDs
• Slow random writes– Expensive erase/write cycle– Motivation for log structured (i.e. sequential) data storage
11
Optimized Maintenance Functions• Split
– Used when adding a node to the cluster– Read, then sequential write to two new data stores if key is in range
• Merge– Used when deleting a node from the cluster– Mutually exclusive stores, so append one data store to the other
• Compact– Cleans up entries in a data store– Skip orphans, out-of-range, deleted and write to new data store
12
13
Optimized Sequential Read & Writes
14
Front-end Consistent Hashing
15
Node Join
Node Leave• Rather than split the data stores, nodes merge them
• In reality, this means…– Add a new replica into each chain the departing node belonged to– So, the processing is the same as a join event
16
Failure Detection• Nodes are assumed to be fail-stop
– Front-end and back-end nodes gossip at a known rate• If timeout, front-end initiates leave operation for failed node
• Current design only copes with node failures– Coping with network failures require future work
17
Single Node Evaluation• Performance almost entirely dependent on flash media
18
21-Node Evaluation• In general, the back-ends prove to be well-matched
19
21-Node Evaluation• Relatively responsive through maintenance operations
20
21-Node Evaluation• Slightly slower than production key-value systems
– Worst case response times on-par
21
21-Node Evaluation• Power draw is low and consistent across operations
22
21-Node Evaluation• Power draw is low and consistent across operations
– Query per Joule is an order of magnitude higher than traditional production distributed systems
• 1 billion instructions per Joule• 1/3 the frequency• 1/10 (or less) the power
23
When does FAWN matter?• It depends on the workload…
24
QUESTIONS?Thanks very much!
25
