L3LB - TCP/UDP Load Balancer

Latest version: 1.0.1

Supported in AppLogic 2.4.7+

	At a Glance
	Catalog	System
	Category	Switches
	User volumes	no
	Min. memory	64M
	OS	Linux
	Constraints	no
	Questions/Comments	Ask Forum

L3LB is a switch for distributing incoming TCP/UDP sessions to servers of the same or different type. TCP load balancing functionality is based on the HAProxy TCP/HTTP load balancing software package; UDP load balancing is based on Netfilter.

L3LB load-balances the incoming traffic using several different algorithms. For TCP traffic L3LB performs simple round-robin load-balancing, equalizing the load for the backend servers. For TCP L3LB also supports persistent sessions, binding the client to a particular backend server by using the request source IP address as a key. For UDP traffic, L3LB uses the round-robin algorithm (this is the only algorithm available for UDP traffic).

L3LB constantly monitors the health state of all backend servers. While in TCP mode, the health state checks conducted by L3LB consist of a simple TCP connect check. In the case of a server failure detected by L3LB using the parameterized health check method, L3LB switches the traffic to an alternate server. If the failed server eventually recovers, L3LB may switch the traffic back to the recovered server. For UDP mode an ICMP PING is used to verify availability of a backend server.

L3LB exposes a web service interface on its ctl terminal. This interface allows a user to programmically enable/disable output terminals out1 - out8 and also to retrieve the state of all terminals. This is useful in cases when there is some kind of backend failure (i.e., such as in a database or storage appliance) where the application itself can automatically disable traffic to a specific set of servers. Note that in this case, L3LB itself is unable to detect this type of failure; so it is up to the application to detect the failure and disable the corresponding set of backend servers.

L3LB is designed to be extremely fast using very few resources. Under regular conditions, L3LB consumes about 25KB of memory for every session, or 1GB for 40000 simultaneous sessions, and processes up to 6000 requests per second.

Boundary

Resources

The amount of memory given to L3LB does not increase the throughput or response time. L3LB is a CPU/bandwidth bound appliance.

Terminals

Properties

General properties

name	type	description
mode	String	Specifies the mode of operation. Valid values are: tcp_roundrobin - incoming TCP sessions are distributed across all connected and enabled backend servers in a roundrobin fashion. tcp_source - The source IP address of the TCP request is used to bind the session to a particular backend server. udp_roundrobin - L3LB operates in UDP load balancing mode. Default: tcp_roundrobin.
ports	String	A space or comma delimited list of ports and port ranges that L3LB forwards to backend servers. Port ranges are specified as a lower_port:higher_port with dash ("-") or colon (":") as a separator between them. Example: 80,81,90-99 110:120 140 141. Traffic received to unspecified port is dropped. Default: 80
max_connections	integer	The maximum number of concurrently active connections that L3LB can handle. When this number is reached, new connections are still accepted, but their processing is delayed until another connection is closed. Upon appliance start, L3LB automatically determines the maximum number of connections based upon available memory, compares it to the value of this property and uses the lowest value. If this property is 0 then the computed value is used. Note that neither the available memory nor an explicit setting of this property have a direct effect on the balancer's throughput or its maximum request rate - setting a low number (or having little memory) affects response only if the backend servers are performing lenghty operations for each request (e.g., database searches), causing many requests to remain open at the same time. This property is only valid for tcp_roundrobin and tcp_source modes of operation. Default: 0
backup_outputs	String	A space or comma delimited list of outputs ( out1 - out8 ) that are considered backup servers. Output ranges (out1-out3) are NOT supported. Traffic is directed to the backup servers only if all backend servers are unavailable. The purpose of these backup servers is to notify clients that something is wrong or redirect them, instead of throwing errors from unavailable backend servers or timing out. Example: out1,out2,out3. If empty, no backup servers are used. Default: "" (no backup servers are used).

Health check properties

Timeout properties

Web service interface properties

Custom Counters

The following counters belong to the L3LB counter group. X may have a value from 1 to 8.

Counter name	Description
outX_status	State of output terminal outX: 0 - enabled and up, 1 - enabled and down, 100 - disconnected.
outX_queue	Number of queued requests for terminal outX. This counter is not reported while in udp_roundrobin mode.
outX_queue_max	Historical maximum of simultaneously queued requests for terminal outX. This counter is not reported while in udp_roundrobin mode.
outX_sessions	Number of active sessions for terminal outX.
outX_sessions_max	Maximal number of active simultaneous sessions for terminal outX.
outX_sessions_total	Number of completed sessions for terminal outX. This counter is not reported while in udp_roundrobin mode.
outX_errors	Number of failed health checks for terminal outX.
queue	Current queue length, cumulative for out1 - out8. This counter is not reported while in udp_roundrobin mode.
queue_max	Historical maximum of simultaneously queued requests, cumulative for out1 - out8. This counter is not reported while in udp_roundrobin mode.
sessions_active	Number of active sessions, cumulative for out1 - out8.
sessions_max	Historical maximal number of active sessions, cumulative for out1 - out8.
sessions_total	Number of completed sessions, cumulative for out1 - out8. This counter is not reported while in udp_roundrobin mode.
errors	Total number of health check failures, cumulative for out1 - out8.

Performance

Request Rate

L3LB routes no less than 6000 transactions (request/response pairs) per second, subject to document size and network bandwidth available.

Data Throughput

L3LB routes no less than 15 MBytes/second

Concurrent Connections

L3LB supports no less than 2000 concurrently pending requests. (A "pending request" being an open TCP connection from the client, on which there is one or more un-completed TCP sessions in progress). Maximum amount of concurrent connections depends of available free memory and may be as high as 40000. L3LB was tested to support more than 15000 of simultaneous active transfers.

Error Messages

In case of appliance startup failure, the following errors may be logged to the system log:

Programmatic control of the output terminals

Overview

A control web service interface is exposed on the ctl terminal (on the configured port), allowing for the enabling and disabling of the output terminals (out1 - out8) and retrieving the current terminal state.

Protocol

The protocol only uses the GET HTTP method, as it only provides reading functionality. Thus, every supported type of protocol request can be defined by means of its URI and the output structure. Characters, that are considered special for the URI should be escaped via the standard %-encoding.

Below is a description of all supported URIs.

Control Calls

Disabling output terminals

There are two separate formats of the disable control call, based on how the output terminal is identified:

• specify the output terminal by name: out1 - out8
• specify the corresponding IP address of the backend web server

Request: /api/disable?channel=out3 (disables the output terminal out3)

Request: /api/disable?10.11.12.13 (disables the output terminal that is connected to the web server with the IP address of 10.11.12.13)

Response:

L3LB returns the following structure with a status code and optional status message:

{
   "status" :
   {
   "code": code_value,
   "message": "status_message"
   }
}

Possible status code values are listed below:

Enabling output terminals

There are two separate formats of the enable control call, based on how the output terminal is identified:

• specify the output terminal by name: out1 - out8
• specify the corresponding IP address of the backend web server

Request: /api/enable?channel=out3 (enables the output terminal out3)

Request: /api/enable?10.11.12.13 (enables the output terminal that is connected to the web server with ip address of 10.11.12.13)

Response:

L3LB returns the following structure with a status code and optional status message:

{
   "status" :
   {
   "code": code_value,
   "message": "status_message"
   }
}

Possible status code values are listed below:

Retreiving output terminal state

Request: /api/status (returns the state of all output terminals)

Response:

L3LB returns the following structure with a status code and optional status message:

{
   "status" :
   {
   "code": code_value,
   "message": "status_message",
   "terminal_id": "terminal_state",
   "terminal_id": "terminal_state",
   ...
   }
}

State is returned only for all connected terminals; state for disabled and disconnected terminals is not reported.

Possible status code values are listed below:

Possible terminal values are out1 - out8.

Possible state values are:

An example state output:

{
   "status" :
   {
   "code": 0,
   "message": "",
   "out1": "up",
   "out2": "up",
   "out3": "down",
   "out4": "up"   
   }
}

Typical Usage

Load-balancing Webmail cluster

Email has become an important part of the business processes nowadays, so webmail clusters must be available 24/7. The example below shows how HALB and L3LB can be used together to load balance and increase availability of webmail and smtp servers. In case of failure, servers can disable outputs of HALB or L3LB through the ctl interface. The L3LB tcp_roundrobin mode is used in this case.

Load-balancing application servers

Rarely a modern website serves only static content. Usually a lot of server-side processing occurs on the server side. This example diagram demonstrates a way to load balance uninterrupted access from a cluster of web servers to a number of application servers; Apache Tomcat in this case. tcp_source mode of operation ensures proper web server to application server session support.

Load-balancing Voice-over-IP service

Common voice-over-ip protocols use UDP as a main protocol; load balancing such traffic is a crucial task for easy scaling of a VoIP cluster. In this example, the udp_roundrobin mode of operation is used.

Notes and Links

Notes

• None

Related Documents

• Implementation Design
• Test Plan
• Release Notes

Links

• HAProxy home site

Questions and Comments

To post a question or comment on this appliance, visit our forum.