Академический Документы
Профессиональный Документы
Культура Документы
Contents
Motivation
Background:
Unified approach:
Server Load-balancing
Server Feedback
RSerPool
Description
Sample Flows
Work Items
Assumptions / Terminology
Motivation
Server Load-balancing
If user must get to same resource over and over, the SLB
device must ensure that happens (ie, session persistence)
Why to Load-balance?
Resource sharing
Load-Balancing Algorithms
Most predominant:
HTTP Cookies
HTTP URLs
SSL Client certificate
SLB: Architectures
Traditional
Distributed
Client
SLB
Server2
Server3
Client
SLB
Server2
Server3
Load-Balance: Layer 3 / 4
1: SYN
Client
5: SYN/ACK
SLB
CK
N/A
Y
4: S
Server2
Server3
Load-Balance: Layer 5+
1: SYN
Client
3: SYN/ACK
4: ACK
5: GET w/ Cookie
SLB
CK
N/A
Y
7: S
CK
ie
8: A
ook
C
/
w
ET
9: G
Server2
Server3
SLB: Distributed
Architecture
FE
Client
Server
FE
Server
FE
Server
SLB
Client
FE
Server2
2: FE asks where to send flow.
Server3
3: Service Mgr tells it to use Server2.
SLB
Subsequent packets flow directly from Client to Server2 thru the FE.
The FE must notify the SLB device when the flow ends.
Server4
Server Feedback
Server Feedback
Real server
Third party box / Collection Point
Pros:
Cons:
Client
SLB
Server2
Server3
Collection Point
Cons:
RSerPool
RSerPool: Architecture
ENRP
Servers
ASAP
PE
ASAP
PE
PU
PE
RSerPool: Overview
Unified: Component
Description
ASAP:
Unified: Component
Description
FE:
Unified: Component
Description
FE (continued):
Configuration:
Server Pools:
Protocol Table:
Unified: Component
Description
PE:
1: TCP SYN
Client
PU / FE
5: SYN/ACK
ASAP Pool
handle
resolution
&
subscriptio
n/polling.
ENRP Server
ENRP Server
4: SYN/ACK
PE1
PE2
PE3
Unified: PE Communication
How to Implement: To Do
List
How to Implement: To Do
List
Polling / Subscriptions.
Complete DFP IETF draft, so it can be
considered.
Everything else.