Session-aware HTTP Load Balancer

Latest version: 1.0.2

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

HALB is a switch for distributing workload to multiple Web servers of the same or different type. HALB is based on the HAProxy TCP/HTTP load balancing software package; which is designed to be extremely fast while consuming little resources.

HALB performs load-balancing functions using several algorithms. It performs simple round-robin balancing, equalizing the load for backend servers. It also supports persistent sessions, binding the client to a particular backend web server with session cookies or by using the request source ip address as a key. While using session cookies, any new sessions that do not have session cookies are distributed using the round-robin algorithm. HALB supports sessions with multiple cookies and modifies and/or tracks only the necessary ones, leaving others intact. Any particular session or client may be tied to particular backend web server or application using cookie association. Existing cookies may be transparently modified by HALB for clients that do not support requests with multiple cookies.

HALB constantly monitors the health state of all backend web servers. The health state checks conducted by HALB may include a simple TCP connect check or a more complex HTTP request (specified on HALB's boundary). In the case of a server failure detected by HALB using the parameterized health check method, HALB switches the traffic to an alternate server. If the failed server eventually recovers, HALB may switch the traffic back to the recovered server.

HALB 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, HALB 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.

HALB maintains detailed statistics including backend state, number of requests processed per server, number of errors occured, etc. The statistics are reported through the mon terminal and separate counters are also exposed through the ui terminal as a GUI accessible with a browser.

HALB is designed to be extremely fast using very few resources. Under regular conditions, HALB 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 HALB does not increase the throughput or response time. HALB is a CPU/bandwidth bound appliance. Nonetheless, HALB requires sufficient memory to handle the expected maximum number of simultaneous sessions. If not enough memory is available, HALB may fail ungracefully. In this case, it has been observed that one or more of the out terminals fails (wget through the terminal from within HALB fails). To correct this problem, assign more memory to HALB and restart the appliance.

Terminals

Properties

General properties

Health check properties

Timeout properties

UI/Web service interface properties

Custom Counters

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

Performance

Request Rate

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

Data Throughput

HALB routes no less than 15 MBytes/second

Concurrent Connections

HALB 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 HTTP request in progress). Maximum amount of concurrent connections depends of available free memory and may be as high as 40000. HALB 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:

HALB 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:

HALB 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:

HALB 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 only, 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"   
   }
}

Web GUI

HALB exposes a statistics GUI through the ui terminal. Various runtime information is available through this GUI:

An example GUI is shown below:

Differences between HALB and HLB

HALB is designed to be compatible with HLB while overcoming some of HLB's limitations. The following table summarizes the differences between the two appliances:

Typical Usage

Load-balancing Slow Dynamic-content Applications

If your application requires a lot of computation to produce each page, it is naturally able to serve a limited amount of clients concurrently. However, if the data source is fast enough or can be replicated and served from multiple servers, HALB can be used to increase the number of connections that can be handled simultaneously. A typical example may be serving maps from a carthography database - the database is fast to read, but each pageload requires the map to be rendered as an image file.

The diagram below shows how HALB can be used to employ multiple CPUs to serve the same content, providing faster response under heavy load.

Configuration for a Server Keeping Sessions - Bugzilla

"Sticky" Load-balancing for Session-less Servers with use of cookies

For servers that do not have sessions, but keep some cached data and could benefit from a client being consistently directed to the same server, passive cookie monitoring does not work as there's no cookie to monitor. The insert mode is used in this case, as shown in the table:

"Sticky" Load-balancing for Session-less Servers without use of cookies with session persistence

Some clients do not support cookies, or disable them. In this case the example shown above is not the best solution, since the client ignores the cookie set. Much better solution is the source mode of HALB operation, that directs traffic to the web server based on request source ip address. Still, if the client uses multiple gateways simultaneously to access the Internet, it is possible for requests not to be directed to the same web server.

Load-balancing with infrastructure health check

A successfull health check of a backend web server does not guarantee that the data it returns is valid or the database that it depends on is still functional. One distinctive feature of HALB is the ability to use not only the conventional way of health checking (simply connect to port 80 of a web server), but also more advanced methods like http_head and http_get. Proper utilization of this ability ensures not only the availability of a backend web servers, but also their dependencies, database, application and storage servers. In this example two health check features of HALB are used. First, a special file health_check.php is created and it's complete URL is specified in the healthcheck_url property. When this file is accessed, it evaluates the availability of the database, application or NAS servers and returns a status document with the text "ALL_SERVICES_ARE_OK". This value is specified in the healthcheck_regexp property.

The HALB checks every output ( out1 - out8 ) with HTTP/1.1 GET requests, using "site" in the "Host:" HTTP header and "/health_check.php" as a document URL. These values are extracted from the healthcheck_url property (http://site/health_check.php). In the document, retrieved from each backend server, HALB searches for the value of healthcheck_regexp (ALL_SERVICES_ARE_OK). If this line is found, the server is considered to be functional/up, otherwise the output terminal is disabled. If the output is disabled and at a later time the HALB health check succeeds, the output is re-enabled.

When no virtual hosts are used, or backend server does not support HTTP/1.1 protocol, the healthcheck_url may be specified in a simple form (/health_check.php). In this case, HALB uses HTTP/1.0 protocol, and does not specify "Host:" HTTP header.

Using backup servers

Backup servers are used when all backend servers are unavailable, and a conscious message or a redirection page must be delivered to client, instead of errors or timeouts. In the example below, server backup is configured as a last-resort server, serving only a static page telling clients that a technical maintenance is being performed. Once all four srv1 - srv4 servers go down, the content from server backup is served.

Using the control web service interface

The control web service interface provides a way to dynamically and programmatically enable/disable output terminals of HALB. It can also be used to retrieve the current state of all of the output terminals. This interface is exposed through HALB's ctl terminal.

The diagram below shows a clustered environment with multiple web and database servers. Every web and database server has a feedback connection to the ctl terminal of HALB. If a web server detects a problem with database/connectivity/performance, it can disable the corresponding output terminal, thus ordering HALB to stop directing traffic to the web server. Similarly, any database server can disable the output terminals of HALB, thus disabling all incoming traffic. After the resolution of the problem, output terminals may be re-enabled.

Comments on this appliance can be found below and edited here? .

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.