Technology Integration: RSerPool
& Server
Load-balancing
Curt Kersey, Cisco Systems
Aron Silverton, Motorola Labs
Contents


Motivation
Background:




Unified approach:



Server Load-balancing
Server Feedback
RSerPool
Description
Sample Flows
Work Items
Assumptions / Terminology




All load-balancing examples will use TCP/IP as
the transport protocol. This could easily be any
other protocol (e.g., SCTP).
SLB = Server Load-Balancer.
Virtual Server = Virtual instance of application
running on SLB device.
Real Server = physical machine with application
instances.
Motivation


Highly redundant SLB.
More accurate server pooling.
Server Load-balancing
What does a SLB do?

Gets user to needed resource:


Server must be available
User’s “session” must not be broken


In order to do work, SLB must:



If user must get to same resource over and over, the SLB device
must ensure that happens (ie, session persistence)
Know servers – IP/port, availability
Understand details of some protocols (e.g., FTP, SIP, etc)
Network Address Translation, NAT:

Packets are re-written as they pass through SLB device.
Why to Load-balance?


Scale applications / services
Ease of administration / maintenance


Easily and transparently remove physical servers from
rotation in order to perform any type of maintenance
on that server.
Resource sharing

Can run multiple instances of an application / service
on a server; could be running on a different port for
each instance; can load-balance to different port
based on data analyzed.
Load-Balancing Algorithms

Most predominant:





least connections: server with fewest number of flows gets
the new flow request.
weighted least connections: associate a weight / strength for
each server and distribute load across server farm based on the
weights of all servers in the farm.
round robin: round robin thru the servers in server farm.
weighted round robin: give each server ‘weight’ number of
flows in a row; weight is set just like it is in weighted least
flows.
There are other algorithms that look at or try to predict
server load in determining the load of the real server.
How SLB Devices Make Decisions

The SLB device can make its load-balancing decisions based on
several factors.


Some of these factors can be obtained from the packet headers (i.e., IP
address, port numbers, etc.).
Other factors are obtained by looking at the data beyond the network
headers. Examples:





HTTP Cookies
HTTP URLs
SSL Client certificate
The decisions can be based strictly on flow counts or they can be
based on knowledge of application.
For some protocols, like FTP, you have to have knowledge of
protocol to correctly load-balance (i.e., control and data connection
must go to same physical server).
When a New Flow Arrives

Determine if virtual server exists.


If so, make sure virtual server has available resources.
If so, then determine level of service needed by that client to
that virtual server.


Pick a real server for that client.



If virtual machine is configured with particular type of protocol
support of session persistence, then do that work.
The determination of real server is based on flow counts and
information about the flow.
In order to do this, the SLB may need to proxy the flow to get all
necessary information for determining the real server – this will be
based on the services configured for that virtual server.
If not, the packet is bridged to the correct interface
based on Layer 2.
SLB: Architectures

Traditional


SLB device sits between the Clients and the
Servers being load-balanced.
Distributed

SLB device sits off to the side, and only
receives the packets it needs to based on flow
setup and tear down.
SLB: Traditional View with NAT
Server1
Client
SLB
Server2
Server3
SLB: Traditional View without NAT
Server1
Client
SLB
Server2
Server3
Load-Balance: Layer 3 / 4


Looking at the destination IP address and
port to make a load-balancing decision.
In order to do that, you can determine a
real server based on the first packet that
arrives.
Layer 3 / 4: Sample Flow
Server1
1: SYN
Client
5: SYN/ACK
SLB
Server2
2: SLB makes decision on Server
Server3
Rest of flow continues through HTTP GET and Server response.
Load-Balance: Layer 5+

The SLB device must terminate the TCP
flow for an amount of time BEFORE the
SLB decision can be made.

For example, the cookie value must be sent
by the client, which is after the TCP
handshake before determining the real server.
Layer 5+: Sample Flow
Server1
1: SYN
Client
3: SYN/ACK
4: ACK
SLB
Server2
5: GET w/ Cookie
2: SLB device determines it must proxy
flow before decision can be made.
Rest of flow continues with Server response.
Note: the flow can be unproxied at this point for efficiency.
Server3
SLB: Distributed Architecture
Client
FE: Forwarding Engines, which are
responsible for forwarding packets.
They ask the SLB device where to
send the flow.
FE
Server
FE
Server
FE
Server
SLB
Distributed Architecture: Sample Flow
Server1
1: TCP SYN
Client
4: flow goes to Server2.
FE
Server2
2: FE asks where to send flow.
Server3
3: Service Mgr tells it to use Server2.
SLB
Server4
Subsequent packets flow directly from Client to Server2 thru the FE.
The FE must notify the SLB device when the flow ends.
Server Feedback
Determining Health of Real
Servers

In order to determine health of real
servers, SLB can:



Actively monitor flows to that real server.
Initiate probes to the real server.
Get feedback from real server or third party
box.
Server Feedback


Need information from real server while it
is a part of a server farm.
Why?


Dynamic load-balancing based on ability of
real server.
Dynamic provisioning of applications.
Server Feedback: Use of
Information


Availability of real server is reported as a
‘weight’ that is use by SLB algorithms
(e.g., weighted round robin, weighted
least connections).
As weight value changes over time, the
load distribution changes with it.
How to Get Weights


Statically configured on SLB device –
never change.
Start with statically configured value on
SLB device for initial start-up, then get
weight from:


Real server
Third party box / Collection Point

It is assumed that if a third party box is being
used, it would be used for all the real servers in a
server farm.
Direct Host Feedback

Description: Have “agents” running on
host to gather data points. That data is
then sent to SLB device just for that
physical server.


Note: agent could report for different
applications on that real server.
Agent could be based on available memory,
general resources available, proprietary
information, etc.
Direct Host Feedback

Pros:


Have some way to dynamically change physical
server’s capability for SLB flows.
Cons:


SLB device must attempt to normalize data for all real
servers in a server farm. If have heterogeneous
servers, it is difficult to do.
Difficult for real server to identify itself in SLB terms
for case of L3 vs. L4 vs. L5, etc SLB scenarios.
Third Party Feedback: Network
Server1
Client
SLB
Server2
Server3
Collection Point
Host to Third Party Feedback


Description: Real servers report data to a ‘collection
point’. The ‘collection point’ system can normalize the
data as needed, then it can report for all physical servers
to the SLB device.
Pros:


Have a device that can analyze and normalize the data from
multiple servers. The SLB device can then just do SLB
functionality.
Cons:

Requires more communication to determine dynamic weight –
could delay the overall dynamic affect if it takes too long.
RSerPool
RSerPool: Architecture
ENRP
Servers
ASAP
PE
ASAP
PE
PU
PE
RSerPool: Overview




RSerPool protocols sit between the user application and
the IP transport protocol (session layer).
The application communication is now defined over a
pair of logical session layer endpoints that are
dynamically mapped to transport layer addresses.
When a failure occurs at the network or transport layer,
the session can survive because the logical session
endpoints can be mapped to alternative transport
addresses.
The endpoint to transport mapping is managed by
distributed servers providing resiliency.
RSerPool / SLB: Unified Approach
(A Work in Progress)
Unified View: Overview

Preserve the RSerPool architecture:



Utilize SLB distributed architecture:


Any extensions or modifications are backwards compatible with current
RSerPool.
SLB extensions at ENRP Server and PE are optional based on pool policy
chosen / implemented.
Introduce FE when using SLB pool policies.
Add SLB technology to the ENRP Server:

SLB-specific versions of pool policies.


SLB-<pool_policy>: example SLB-WRR takes into account additional host
feedback such as number of flows on each PE.
Add server feedback:


Enable delivery of host feedback from PEs to home ENRP Server.
Enable delivery of host feedback to FE from ENRP Server.
Unified: Component Description

ASAP:

Between PE and ENRP Server is extended to include additional host
feedback such as current number of flows on PE.



Subscription service and/or polling between ENRP Server and PU allows
delivery of host feedback (membership, weights, flows, etc).




Encapsulation of host feedback protocol in pool element parameter.
Information will be replicated among peer ENRP Servers.
Subscription is between PU and current ENRP Server (not replicated).
PU must be re-register subscription upon selection of new ENRP Server.
Subscription and polling service previously discussed in design team as an
addition to core ASAP functionality.
Make decision on flow destination based on SLB-specific pool policy
(i.e., load-balancing algorithm).
Unified: Component Description

FE:

RSerPool enabled application (PU):

Uses RSerPool API for sending flows to PE.



Must know which pools support which applications (SLBtypes).



Add parameter to SLB-enabled PEs?
Choose pool handle based on incoming client requests and
supported SLB-types (SLB-L4, SLB-HTTP, SLB-SIP, etc).


ASAP control plane for PE selection.
Bearer plane uses flow-specific protocol (e.g., HTTP, SIP, etc)
and corresponding transport (e.g., TCP, SCTP).
If no other SLB-type matches, the SLB-L4 will be used.
NAT, reverse NAT.
Proxy service.
Unified: Component Description

FE (continued):

Configuration:

Server Pools:




Static configuration of pool handles – pool names are resolved
upon initialization.
Static configuration of pool handles and PE detail, including
initial/default weights.
Automagic configuration?
Protocol Table:

Maps supported SLB-types to pool handles by looking for best
match in incoming packet, e.g.,
 SLB-L4 (must implement).
 SLB-HTTP.
 SLB-SIP.
Unified: Component Description

PE:

SLB-enabled PEs must support dynamic host
feedback.
Unified: Layer 3/4 Example
2: Correlate request to SLB-type; then
choose pool handle. Then do a send to
that pool handle.
3: TCP SYN is sent to PE2
1: TCP SYN
Client
PU / FE
5: SYN/ACK
4: SYN/ACK
ASAP Pool
handle
resolution &
subscription/
polling.
ENRP Server
PE1
ENRP Server
PE2
PE3
ASAP with host feedback
Server Feedback: How to
Implement with RSerPool
Unified: PE Communication

PEs will send their weights to ENRP server via ASAP
protocol.


Server agent on host provides weight to PE application.
There are some protocols that exist for reporting this
information. The current list:

Server/Application State Protocol, SASP:



Joint IBM / Cisco Protocol.
IETF draft is currently available.
Dynamic Feedback Protocol, DFP:


Cisco developed Protocol.
IETF draft is in progress.
Design Team Work Items
How to Implement: To Do List


Details, Details, Details .....
Reconcile design with pool policy draft:





Determine what information needs to be passed.
Determine what algorithms need to be added where.
Define SLB-<pool policies>.
Determine best method for implementation of
host feedback.
Complete Layer 5 example with session
persistence mechanism at FE.
How to Implement: To Do List



Polling / Subscriptions.
Complete DFP IETF draft, so it can be
considered.
Everything else.