as well as the server Nikhil Handigol Stanford University Joint work with Nick McKeown and Ramesh Johari Datacenter Widearea Enterprise Cant choose path LOADBALANCER Client ID: 620019
Download Presentation The PPT/PDF document "Should a load-balancer choose the path" is the property of its rightful owner. Permission is granted to download and print the materials on this web site for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.
Slide1
Should a load-balancer choose the pathas well as the server?
Nikhil Handigol
Stanford University
Joint work with Nick
McKeown
and
Ramesh
JohariSlide2
Datacenter
Wide-area
EnterpriseSlide3
Can’t choose path :’(
LOAD-BALANCER
Client
ServersSlide4
Outline and goalsA new architecture for distributed load-balancing
joint (server, path) selection
Demonstrate a nation-wide prototype
Interesting preliminary resultsSlide5
Data Path (Hardware)
Control Path
OpenFlow
OpenFlow
Controller
OpenFlow Protocol (SSL)
Control PathSlide6
Custom Hardware
Custom Hardware
Custom Hardware
Custom Hardware
Custom Hardware
OS
OS
OS
OS
OS
Network OS
Feature
Feature
Software Defined Networking
Feature
Feature
Feature
Feature
Feature
Feature
Feature
Feature
Feature
Feature
6Slide7
Load Balancing is just Smart RoutingSlide8
Custom Hardware
Custom Hardware
Custom Hardware
Custom Hardware
Custom Hardware
Network OS
Load-balancing logic
Load-balancing as a network primitive
Load-balancing decision
Load-balancing decision
Load-balancing decision
Load-balancing decision
Load-balancing decision
8Slide9
Aster*
x
ControllerSlide10Slide11
http://www.openflow.org/videosSlide12
So far…
A new architecture for distributed load-balancing
joint (server, path) selection
Aster*
x
– a nation-wide prototypePromising results that joint (server, path) selection might have great benefits Slide13
What next?Slide14
How big is the pie?
Characterizing and quantifying the performance of joint (server, path) selectionSlide15
Load-balancing Controller
MININET-RTSlide16
Internet
Load-balancing ControllerSlide17
Clients
CDN
ISP
ModelSlide18
Parameters
Topology
Intra-AS topologies
BRITE (2000 topologies)
CAIDA (1000 topologies)
Rocketfuel
(~100
topos
.)
20-50 nodes
Uniform link capacitySlide19
Parameters
Servers
5-10 servers
Random placement
Service
Simple HTTP service
Serving 1 MB file
Additional server-side computationSlide20
Parameters
Clients
3-5 client locations
Random placement
Request pattern
Poisson process
Mean rate: 5-10
req
/secSlide21
Load-balancing strategies?Slide22
Simple but suboptimal
Complex but optimal
Design space
Disjoint-Shortest-Path
Joint
Disjoint-Traffic-EngineeringSlide23
Anatomy of a request-response
Client
Load-Balancer
Server
Response Time
Deliver
Retrieve
Choose
Request
Response 1
st
byte
Response last byte
Last byte
ackSlide24
Disjoint-Shortest-Path
CDN selects the least loaded server
Load = retrieve + deliver
ISP independently selects the shortest pathSlide25
Disjoint-Traffic-Engineering
CDN selects the least loaded server
Load = retrieve + deliver
ISP independently selects path to minimize max load
Max bandwidth headroomSlide26
Joint
Single controller jointly selects the best (server, path) pair
Total latency = retrieve + estimated deliverSlide27
Disjoint-Shortest-Path
vs
Joint
Disjoint-Shortest-Path
performs ~2x worse than
JointSlide28
Disjoint-Traffic-Engg. vs Joint
Disjoint-Traffic-Engineering
performs almost as well as
JointSlide29
Is Disjoint truly disjoint?
Client
Load-Balancer
Server
Response Time
Deliver
Retrieve
Choose
Request
Response 1
st
byte
Response last byte
Last byte
ack
Server response time contains network informationSlide30
The bottleneck effect
A single bottleneck resource along the path determines the performance.Slide31
Clients
CDN
ISP
The CDN-ISP gameSlide32
The CDN-ISP gameSystem load monotonically decreases
Both push system in the same directionSlide33
Summary of observations
Disjoint-SP is ~2x worse than Joint
Disjoint-TE performs almost as well as Joint
(despite decoupling of server selection and traffic engineering)
Game theoretic analysis supports the empirical observationSlide34
Conclusion
A new architecture for distributed load-balancing
joint (server, path) selection
Aster*
x
- a nation-wide prototypeInteresting preliminary resultsFuture – application to
other contexts and applicationsSlide35
Let’s chat more!Slide36
Extra slides…Slide37
Sample topologies
BRITE
CAIDA