Load Balancing in Structured P2P Systems

1
Load Balancing in Structured P2P Systems
Karthik Lakshminarayanan UC Berkeley

• Joint work with Ananth Rao (AP), Sonesh Surana,
  Prof. Richard Karp, Prof. Ion Stoica

2
Basic Assumptions

• P2P system offers a DHT interface, with 2
  operations put(id, item) and get(id).
• All the nodes co-operate to balance load.
• Loads are stable over the timescales of operation
  of the algorithms.
• Resource that we try to balance
• System has only one bottlenecked resource.
• No fundamental restriction on the nature of
  resource.

3
Motivation

• How is load-distribution achieved?
• Random choice of ids may still result in O(logN)
  imbalance.
• Currently choice of identifiers and
  load-balancing are intrinsically tied together.
• Applications may want to choose identifiers for
  objects.
• Eg.Complex queries in DHT-based P2P networks,
  Harren et al.
• Heterogeneity
• Capabilities of the end-hosts may differ by an
  order of magnitude.

4
Notion of Virtual Server s

• Looks like a single peer to the underlying DHT.
• Each node can be responsible for many virtual
  servers.
• With log N virtual servers per node, CFS achieves
  constant factor load balance.

Chord Ring
5
What about caching?

• Caching common solution proposed to alleviate
  the problem of hot-spots.
• Problems
• Does not work for some types of resources such as
  storage.
• Typical DB apps
• Large number of active small ranges.
• Need to push out a significant fraction of them
  for caching to be effective.
• Both orthogonal and complementary to the schemes
  that we would discuss.

6
Where we are

• Motivation
• Preliminaries
• Load balancing algorithms
• And the rest

7
Virtual server is the basic unit of load movement
in all our algorithms.

• Movement of virtual servers appears as a leave
  followed by a join hence supported by all DHTs.
• Pros
• Flexibility move load from any node to any other
  node in the DHT.
• Cons
• Overhead k virtual servers per node implies,
• size of routing tables increases by a factor of
  k.
• path length in the overlay increases by O(log k).

8
Some definitions

• Binary modeling
• Ti target load of a node.
• Li sum of loads on the virtual servers of a
  node.
• Node is light if Li lt Ti, heavy otherwise.
• Choice of target load
• Depends on application, and nature of resource.
• Eg. Average system load.

9
Metrics

• Goals of the abstract optimization problem
• Minimize load moved
• Get the load below target for all nodes
• Minimize fragmentation of id space
• Features needed
• Robust (no thrashing when loads are high)
• Responsive
• No oscillations
• Distributed algorithm

10
Virtual server transfer

• Given heavy node h, and light node l transfer
  lightest possible virtual server from h to l
  s.t.
• h becomes light, if possible.
• l does not become heavy.

Heavy!
Load 14, Target 10
7
5
2
1
3
Load 4, Target 10
Light
11
Virtual server transfer

• Given heavy node h, and light node l transfer
  lightest possible virtual server from h to l
  s.t.
• h becomes light, if possible.
• l does not become heavy.

Light
Load 9, Target 10
7
2
5
1
3
Load 9, Target 10
Light
12
Splitting of Virtual Servers

• Pros
• Improves convergence time, and total load
  transferred.
• Cons
• Fragmentation of id space, and consequently
  increasing overlay hop length, and routing table
  size.
• Complicate the algorithms, tradeoffs are not
  clear.
• To simplify things, splitting of virtual servers
  is outside the realm of our algorithms.

13
Where we are

• Motivation
• Preliminaries
• Load balancing algorithms
• And the rest

14
Scheme 1 One-to-One

• Algorithm
• Pick 2 nodes at random.
• Initiate transfer if one of them is heavy, and
  other is light.
• Implementation light node picks a random node
  and initiates a transfer if it is heavy.
• Extremely easy to implement.
• Heavy nodes are relieved of the job of probing.
• No danger of overloading or thrashing when most
  nodes are heavy.
• Works better if load is correlated with length of
  id-space a node is responsible for.

15
Scheme 2 One-to-Many

• Algorithm
• Each heavy node picks a random subset of light
  nodes.
• Choose the light node which enables the best
  possible transfer.
• Implementation
• Light node meta-data is maintained in d
  directories.
• Each light node hashes itself to one directory.
• Heavy nodes pick a random directory and probe.

16
Scheme 3 Many-to-Many (centralized version)

• Even with complete knowledge, it is a hard
  problem!
• Global pool logical place where extra baggage
  is placed before moving it around.
• Basic operations
• Unload greedily move out virtual servers from
  heavy nodes to a global pool.
• Insert empty the pool by inserting virtual
  servers back into light nodes, heaviest first.
• Dislodge swap a virtual server v (from the pool)
  with a lighter virtual server v (from a light
  node) such that the light node does not become
  heavy.

17
A Contrived Example!
Unload phase
LOAD
Target 20
6
7
13
4
10
6
1
17
6
4
11
8
23
19
Global Pool
6
10
8
24
18
18
A Contrived Example!
Insert phase
LOAD
Target 20
6
7
13
6
19
4
10
6
1
17
6
11
8
19
Global Pool
10
8
18
19
A Contrived Example!
Dislodge phase
LOAD
Target 20
6
7
6
19
4
10
6
1
17
4
20
1
11
8
19
Global Pool
10
8
18
20
A Contrived Example!
Insert phase
LOAD
Target 20
6
7
6
19
10
6
4
20
1
11
8
19
Global Pool
10
8
18
1
19
21
A Contrived Example!
We are done!
LOAD
Target 20
6
7
6
19
10
6
4
20
11
8
19
Global Pool
10
8
1
19
22
Scheme 3 Many-to-Many

• Implementation
• Each node chooses a random directory and sends
  its information both heavy and light nodes are
  hashed into directories.
• Nodes on which directories reside periodically
  run the algorithm, and report results to the
  necessary nodes.
• Actual movement of load takes place between the
  nodes later.
• Heavy nodes might require multiple probes before
  they fully shed the excess load.

23
Where we are

• Motivation
• Preliminaries
• Load balancing algorithms
• Some basic results

24
Simulation setup

• Goal understand basic tradeoffs and the
  limitations of our algorithms.
• Do not claim to have bullet-proof solutions that
  would work for all DHTs under all scenarios.
• Load distribution
• Exponential distribution for size of virtual
  server.
• Load on a virtual server
• Gaussian expected due to a large number of
  items whose loads are independent.
• Pareto heavy-tailed, a case that would stress
  the algorithms.
• Metrics
• Total load moved.
• Number of probes.

25
Scalability

• Average number of nodes per directory was fixed
  at 25, L/T 0.75.
• Fraction of load moved, and number of probes
  needed, is independent of number of nodes in the
  system.
• Pareto performs worse than Gaussian.
• Similar result for many-to-many and one-to-one.

26
Some Questions

• Useful transfers nothing moves out of a light
  node.
• Pros Lesser load moved around to achieve
  balance.
• Cons Might take more rounds.
• What if we perform only useful transfers?
• Best-fit heuristic
• Does this heuristic in scheme-3 make any
  significant difference? (remember that virtual
  servers are not split).
• Chances of a node with lot of slack being used
  up by a not-so-heavy node is higher in schemes 1
  and 2.

27
Efficiency Total load moved

• Pareto distribution,
• 50 nodes/directory
• Load moved depends only on distribution of loads,
  and the target to be achieved and not on the load
  balancing scheme
• Many-to-Many scheme works up to a factor of 0.94,
  whereas the other two are able to balance load up
  to a factor of 0.8

28
Total number of probes

• Pareto distribution,
• 50 nodes/directory.
• One-to-one scheme may be sufficient if
• Control traffic overhead does not affect the
  system adversely.
• Load remains stable over long time scales.

29
Effect of size of directory

• How many nodes do we need to look at before which
  control traffic can be reduced?
• Most heavy nodes shed their load by making only
  one probe, for N/d as low as 16.
• Initial number of heavy nodes for
• Gaussian1750
• Pareto 1450

• Number of probes as a function of expected size
  of a directory, L/T0.75

30
Dislodge One transfer too many?

• May perform moves that may not be useful.
• Performs better only when allowed imbalance is
  extremely small.
• Might not be a good idea to do this in practice.

Effect of dislodge on number of rounds with
Gaussian load distribution
31
Future work

• Study the system in a dynamic scenario.
• Objects inserted and deleted.
• Nodes joining and leaving the system.
• Develop theoretical underpinnings for the
  proposed schemes.
• Build a prototype of the load-balancing schemes.

32
Questions?