Load Balancer Online Manual

Overview

In the LoadBalancer architecture, the Backends is the component which describe balancing policies and algorithms, and groups servers with their options.

Best practice Don’t use backends when there is a “balanced service” for your application. Not only backends are considered an advanced feature, but you also loose integrated options and optimizations.

Index

The index page shows all backend currently configured and their current status. This list shows both the backends created by use and the backends created as component of a balanced service.

View backend

This page show all options currently configured for the backend, including the options sets by the “balanced application” and all servers.

This is the only page from where you can delete a backend or a server; this is made on purpose to prevent deletion by mistake.

Edit backend

This page allows you to edit the configuration of a backend. Although not all ettings can be configured here, you’ll find the most common configurations, and some of the advanced settings.

This is where you’ll add new servers and select the balance type.

Balance algorithm

Round robin
Round Robin (static)
Least connection
Source IP

Each server is used in turns, according to their weights. This is the smoothest and fairest algorithm when the server’s processing time remains equally distributed. This algorithm is dynamic, which means that server weights may be adjusted on the fly for slow starts for instance.

Best practice: use dynamic round robin for services which expect fast connections, like HTTP.

Same as round robin, but completely static. Changing weight on the fly will have no effect, until the balancer is restarted or the new configuration is applied.

The server with the lowest number of connections receives the connection. Round-robin is performed within groups of servers of the same load to ensure that all servers will be used. This algorithm is dynamic, which means that server weights may be adjusted on the fly for slow starts for instance.

Best practice: always use Least connection for SMTP, and for all services for which long sessions are expected (LDAP, SQL, RPC, …)

The source IP address is hashed and divided by the total weight of the running servers to designate which server will receive the request. This ensures that the same client IP address will always reach the same server as long as no server goes down or up. The main drawback is that is completely static and that when a server goes down, many – if not all – connection are reassigned to another server.

Use Source IP sparingly, as a lightweight alternative to round robin with sticky tables.

Stick table (session persistence)

Some service are stateless and can be assigned freely to the first available server, but other are not and there is the need of keeping track of sessions between requests. When enabling a stick table, the connection between source IP and server is remembered, and is used as long as the server is up.

This means that when this option is enabled the balance algorithm is used only for the first connection, and than it is remembered regardless of connection status and weight.