Distributed, Secure Load Balancing with Skew, Heterogeneity, and - - PowerPoint PPT Presentation

distributed secure load balancing with skew heterogeneity
SMART_READER_LITE
LIVE PREVIEW

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


slide-1
SLIDE 1

Distributed, Secure Load Balancing with Skew, Heterogeneity, and Churn

Jonathan Ledlie and Margo Seltzer INFOCOM 2005 - March 16, 2005

slide-2
SLIDE 2

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

slide-3
SLIDE 3

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

slide-4
SLIDE 4

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
slide-5
SLIDE 5

3/16/2005 5 Jonathan Ledlie - INFOCOM 2005

Talk Outline

  • Overview
  • Preliminaries

– DHTs – Security – Network Characteristics

  • k-Choices
  • Prior Techniques
  • Evaluation
  • Conclusion
slide-6
SLIDE 6

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

slide-7
SLIDE 7

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

slide-8
SLIDE 8

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

slide-9
SLIDE 9

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.

slide-10
SLIDE 10

3/16/2005 10 Jonathan Ledlie - INFOCOM 2005

Outline

  • Overview
  • Preliminaries

– DHTs – Security – Network Characteristics

  • k-Choices
  • Prior Techniques
  • Evaluation
  • Conclusion
slide-11
SLIDE 11

3/16/2005 11 Jonathan Ledlie - INFOCOM 2005

Characteristics - Skew

  • Skew: hotspots popular content
  • Typically Zipf popularity
  • E.g., Gnutella queries (log-log scale):
slide-12
SLIDE 12

3/16/2005 12 Jonathan Ledlie - INFOCOM 2005

Characteristics - Churn

  • Churn: pattern of participant join and departure.
  • Pareto (memory-full) distribution (60 minute avg).
slide-13
SLIDE 13

3/16/2005 13 Jonathan Ledlie - INFOCOM 2005

Characteristics - Heterogeneity

  • Network bandwidths vary by five orders-of-magnitude.
  • Routing capacity varies widely.
slide-14
SLIDE 14

3/16/2005 14 Jonathan Ledlie - INFOCOM 2005

Outline

  • Overview
  • Preliminaries

– DHTs – Security – Network Characteristics

  • k-Choices
  • Prior Techniques
  • Evaluation
  • Conclusion
slide-15
SLIDE 15

3/16/2005 15 Jonathan Ledlie - INFOCOM 2005

k-Choices - Steps

  • 1. Probe
  • 2. Evaluate Cost Function
  • 3. Join
slide-16
SLIDE 16

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.

slide-17
SLIDE 17

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.

slide-18
SLIDE 18

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
slide-19
SLIDE 19

3/16/2005 19 Jonathan Ledlie - INFOCOM 2005

Outline

  • Overview
  • Preliminaries
  • k-Choices
  • Prior Techniques

– log(N) virtual servers – Transfer – Proportion – Threshold

  • Evaluation
  • Conclusion
slide-20
SLIDE 20

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.

slide-21
SLIDE 21

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]

slide-22
SLIDE 22

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)

slide-23
SLIDE 23

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.

slide-24
SLIDE 24

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.

slide-25
SLIDE 25

3/16/2005 25 Jonathan Ledlie - INFOCOM 2005

Results - Implementation

Pastry; “lookup+download”; 64x4 nodes - last mile limited

k-Choices: 20% throughput improvement

slide-26
SLIDE 26

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

slide-27
SLIDE 27

3/16/2005 27 Jonathan Ledlie - INFOCOM 2005

Questions?

  • Thanks!
  • Contact:

– Jonathan Ledlie – jonathan@eecs.harvard.edu

slide-28
SLIDE 28

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]

slide-29
SLIDE 29

3/16/2005 29 Jonathan Ledlie - INFOCOM 2005

Prior Work - Proportion

  • Overload: shed VSs
  • Underload: create them
  • Pros: No communication
  • Cons:

– Large number of VSs created – New lowest common denominator – Cascading deletes

[Dabek01]