Distributed, Secure Load Balancing with Skew, Heterogeneity, and - - PowerPoint PPT Presentation
Distributed, Secure Load Balancing with Skew, Heterogeneity, and - - PowerPoint PPT Presentation
Distributed, Secure Load Balancing with Skew, Heterogeneity, and Churn Jonathan Ledlie and Margo Seltzer INFOCOM 2005 - March 16, 2005 Motivation - Why balance DHTs? Distributed hash tables (DHTs): Becoming off-the-shelf
3/16/2005 2 Jonathan Ledlie - INFOCOM 2005
Motivation - Why balance DHTs?
- Distributed hash tables (DHTs):
– Becoming “off-the-shelf” distributed data structures – Was: backup storage; now: ALM, resource discovery
- DHTs must be versatile:
– Handle variety of loads - low msg loss
- Allocate network capacity
– Realistic network conditions – Reasonably secure
- Numerous load balancing proposals in literature
– Unrealistic assumptions – Poor performance
3/16/2005 3 Jonathan Ledlie - INFOCOM 2005
Problematic Assumptions
Malicious participants Pick any ID Security Lots of Churn Stable Membership Hotspots (Skew) Uniform Workload Broad Heterogeneity Uniform Capacity Physical Nodes Reality Assumption
Current load balancing algorithms are insufficient
3/16/2005 4 Jonathan Ledlie - INFOCOM 2005
k-Choices Algorithm
- Support variation in skew, node
heterogeneity, and churn
- Make IDs verifiable
? ? ?
- 1. Sample
- 2. Cost fn
- 3. Join
3/16/2005 5 Jonathan Ledlie - INFOCOM 2005
Talk Outline
- Overview
- Preliminaries
– DHTs – Security – Network Characteristics
- k-Choices
- Prior Techniques
- Evaluation
- Conclusion
3/16/2005 6 Jonathan Ledlie - INFOCOM 2005
DHTs - Refresher
- Each node has one or more virtual servers (VSs).
- Each virtual server has an ID namespace (e.g., (0,1], (0,2160]).
- Msgs via O(log(N)) hops between any two VSs.
a (a,b,c) (d) (e,f) (g,h) d e g Chord-like routing
3/16/2005 7 Jonathan Ledlie - INFOCOM 2005
DHTs - Load
a (a,b,c) (d) (e,f) (g,h) d e g (i,j) b
Load
i f
3/16/2005 8 Jonathan Ledlie - INFOCOM 2005
Sybil Attacks
a (a,b,c) (d) (e,f) d Unsecured IDs>Take over portions of ring e (m) m g
3/16/2005 9 Jonathan Ledlie - INFOCOM 2005
Sybil Attack - Solution
- Central authority certifies each ID [Castro02]
- k-Choices uses similar scheme to generate
limited set of certified IDs.
3/16/2005 10 Jonathan Ledlie - INFOCOM 2005
Outline
- Overview
- Preliminaries
– DHTs – Security – Network Characteristics
- k-Choices
- Prior Techniques
- Evaluation
- Conclusion
3/16/2005 11 Jonathan Ledlie - INFOCOM 2005
Characteristics - Skew
- Skew: hotspots popular content
- Typically Zipf popularity
- E.g., Gnutella queries (log-log scale):
3/16/2005 12 Jonathan Ledlie - INFOCOM 2005
Characteristics - Churn
- Churn: pattern of participant join and departure.
- Pareto (memory-full) distribution (60 minute avg).
3/16/2005 13 Jonathan Ledlie - INFOCOM 2005
Characteristics - Heterogeneity
- Network bandwidths vary by five orders-of-magnitude.
- Routing capacity varies widely.
3/16/2005 14 Jonathan Ledlie - INFOCOM 2005
Outline
- Overview
- Preliminaries
– DHTs – Security – Network Characteristics
- k-Choices
- Prior Techniques
- Evaluation
- Conclusion
3/16/2005 15 Jonathan Ledlie - INFOCOM 2005
k-Choices - Steps
- 1. Probe
- 2. Evaluate Cost Function
- 3. Join
3/16/2005 16 Jonathan Ledlie - INFOCOM 2005
k-Choices - Sample
Discover load and capacity at each ID a c
k=3
Load Capacity Sample ID a: Learn succ(a) actual load, target load, and node capacity. Over target
b
Sample ID b: Learn succ(b) actual load, target load, and node capacity.
3/16/2005 17 Jonathan Ledlie - INFOCOM 2005
k-Choices - Cost Function
Load Capacity
Current + ID a =
Load Capacity
Future … + ID b = …
Choose ID that minimizes mismatch between target and load normalized by capacity.
3/16/2005 18 Jonathan Ledlie - INFOCOM 2005
k-Choices - Properties
- Incorporates workload skew and node
heterogeneity.
- Proactive load balancing - join time
- Reactive load balancing - reselect ID
- Verifiable IDs
3/16/2005 19 Jonathan Ledlie - INFOCOM 2005
Outline
- Overview
- Preliminaries
- k-Choices
- Prior Techniques
– log(N) virtual servers – Transfer – Proportion – Threshold
- Evaluation
- Conclusion
3/16/2005 20 Jonathan Ledlie - INFOCOM 2005
Prior Work - log(N) VS
- Namespace balancing (e.g. [Karger97])
- Central Limit Theorem
– Total namespace for each node approximately equal
Namespace balancing does not equal load balancing.
3/16/2005 21 Jonathan Ledlie - INFOCOM 2005
Prior Work - Transfer
- Overload:
a) >1 VS: attempt to transfer b) 1 VS: split first, then transfer
- Pros: Simple, Good Performance
- Cons: Unsecure
– Split to arbitrary ID (cut in half) – Transfer to anyone
[Rao03,Godfrey04]
3/16/2005 22 Jonathan Ledlie - INFOCOM 2005
Evaluation
- Trace Driven Simulation
- Results
– Determining k – Vary applied load – Vary churn – Vary skew
- Pastry Implementation
– Throughput – Heterogeneous real node bandwidths (Emulab)
3/16/2005 23 Jonathan Ledlie - INFOCOM 2005
Results - Choosing k
4k nodes, avg capacity=100 m/s, 60 min avg lifetime k=8 sufficiently reduced utilization.
3/16/2005 24 Jonathan Ledlie - INFOCOM 2005
Results - Trace
5508 nodes; median capacity: 191 msgs/sec k-Choices and Transfer performed equally well with skewed workloads.
3/16/2005 25 Jonathan Ledlie - INFOCOM 2005
Results - Implementation
Pastry; “lookup+download”; 64x4 nodes - last mile limited
k-Choices: 20% throughput improvement
3/16/2005 26 Jonathan Ledlie - INFOCOM 2005
Conclusion
- k-Choices:
– Approx. same performance as Transfer – Doesn’t change security properties – Not the final word - range queries
- Design for empirical system
– Namespace balancing? – Skew, wide capacity distribution, churn – Security: Sybil attacks
3/16/2005 27 Jonathan Ledlie - INFOCOM 2005
Questions?
- Thanks!
- Contact:
– Jonathan Ledlie – jonathan@eecs.harvard.edu
3/16/2005 28 Jonathan Ledlie - INFOCOM 2005
Prior Work - Threshold
- If our utilization has increased beyond
threshold
– Compare utilization to neighbors – Shift their IDs?
- Else
– Compare to set of log(N) random VSs – Move best to be our new predecessor
[Ganesan04]
3/16/2005 29 Jonathan Ledlie - INFOCOM 2005
Prior Work - Proportion
- Overload: shed VSs
- Underload: create them
- Pros: No communication
- Cons: