Sidebar navigationMain contentFooter
HomeNetworkLoad BalancersReference Content
Configuring backends
Jump toUpdate content

Configuring your Load Balancer's backend

Reviewed on 21 September 2023 • Published on 05 June 2023

Backend overview

Each Load Balancer is configured with one or several backends. A backend represents a set of backend servers that the Load Balancer’s frontend(s) forwards requests to using the specified configuration (port, protocol, proxy protocol etc.).

You can create and configure frontends and backends while creating a Load Balancer or choose to create an “empty” Load Balancer and add frontends and backends later on.

You have access to the same configuration settings for your backend whether you create it with the Load Balancer, or later. Any of these settings can be edited thereafter. Read on to find out more about the different configuration settings available for your backend.

Configuring basic settings

Backend name

You can use an automatically-generated random name suggested by the console, or choose your own name for the backend

Protocol and port

The Load Balancer initiates connections to its backend servers using the protocol and port you define, and can therefore leverage the selected protocol’s capabilities to manage traffic.

  • HTTP protocol (typically port 80, or port 443 if also using TLS): The Load Balancer forward HTTP connects to backend servers. Traffic will be forwarded without encryption.
  • TCP protocol: The Load Balancer connects to backend servers using TCP, and forwards TCP payloads with no modification (other than encryption/decryption, where configured).

The port number must be between 1 and 65535.

You may also be interested in reading about choosing protocols (and TLS encryption settings, below) for different offloading / passthrough / bridging configurations.

TLS encryption

You can choose to activate or deactivate TLS. Activating TLS encrypts connections between the Load Balancer and the backend server(s). Note that the backend server should have its own SSL/TLS certificate.

Verify Certificate

If you activate TLS encryption, you are prompted to choose a Verify Certificate setting.

When the Load Balancer initiates an encrypted connection to a backend server, the backend server presents its certificate.

  • When Verify Certificate is selected, the Load Balancer checks the backend server’s certificate and only connects if it is valid.
  • When Verify Certificate is unselected, the Load Balancer does not check the backend server’s certificate, connecting to the backend server regardless of the certificate’s validity.

This setting mostly concerns those using self-signed certificates on the backend server/s.

Note that the same Verify Certificate setting you select here will also be used for health checks, and cannot be overridden.

Proxy protocol

Proxy protocol enables the original client IP address to be passed to the backend server in a standardized way. However, in order to work, the backend server must support the selected proxy protocol.

If you choose to activate proxy protocol, the following versions are available:

  • Proxy protocol v1: Version one (text format).
  • Proxy protocol v2: Version two (binary format).
  • Proxy protocol v2-ssl: Version two with SSL information extension added, which provides information on SSL connection settings originally sent by the client.
  • Proxy protocol v2-ssl-cn: Version two with SSL information extension added as above, as well as the common name from the subject of the client certificate (if any).

Configuring traffic management

Balancing method

Load Balancers support three different modes of balancing load (requests) between backend servers:

  • Round-robin: Requests are sent to each backend server in turn, with the Load Balancer acting like a turnstile. This is the most frequently used balancing method, and the easiest to implement. It is well-suited to infrastructures that have identical backend servers.
  • Least connections: Each request is assigned to the server with the fewest active connections. This method works best when it is expected that sessions will be long, e.g. LDAP, SQL TSE. It is less well-suited to protocols with typically short sessions like HTTP.
  • First available: Each request is directed towards the first backend server with available connection slots. Once a server reaches its limit of maximum simultaneous connections, requests are directed to the next server. This method uses the smallest number of servers at any given time, which can be useful if, for example, you sometimes want to power off extra servers during off-peak hours.

Server IPs (backend servers)

You can add one or more IP addresses, either IPv4 or IPv6, of the backend servers your Load Balancer’s backend will forward traffic to.

Sticky sessions

When activated, sticky sessions bind a user’s session to a specific server in the pool of backend servers. This ensures that all subsequent sessions from the user are sent to the same backend server while there is at least one active session. Sticky sessions can be cookie-based or IP based (aka table-based).

  • IP-based stickiness uses the source (client) IP address to stick sessions to backends. This is the only possible method for TCP backends.
  • Cookie-based stickiness uses an HTTP cookie to identify a session, and the server in the backend pool that it will stick to. For each incoming request without a stickiness cookie, the Load Balancer creates a cookie and selects a backend server for the session. Subsequent requests providing this cookie will land on the same backend server. You can customize the name of the cookie.

Configuring advanced settings

Recommended settings for all the parameters below are selected by default, however you can modify them if you wish.

Timeout

Timeout settings allow you to define the maximum time that backend servers should be given to establish connections and to process requests. The following timeout settings are available:

  • Tunnel timeout: Defines the maximum allowed tunnel inactivity time (in ms) between a client and a backend server after a Websocket is established. This value takes precedence over client and server timeout in determining when to close the connection. The default value is 900 000, the minimum value is 0 and the maximum value is 2 147 483 647.
  • Server timeout: Defines the maximum allowed time (in ms) that a backend server has to process a request. The default value is 300 000, the minimum value is 0 and the maximum value is 2 147 483 647.
  • Connection timeout: Defines the maximum allowed time (in ms) to establish a connection between a client and a backend server. The default value is 5 000, the minimum value is O and the maximum value is 2 147 483 647.

Backend protection

Backend protection settings define when the Load Balancer should view a backend server as having reached its maximum number of simultaneous connections / requests, and how to handle sticky sessions in this context.

  • Limit backend load: When this toggle is deactivated, the Load Balancer can send an unlimited number of simultaneous connections/requests to backend servers. Activate the toggle to set the following types of limitations:
  • Max simultaneous: Defines the maximum number of simultaneous requests (for HTTP) or simultaneous connections (for TCP) to any single backend server. A value of 5 means that each backend server will have a limit of 5 connections (even if, for example, there are only three servers in the backend). This setting is particularly relevant when using the First available balancing method. The default value is 3, the minimum value is 1, and the maximum value depends on the Load Balancer type.
  • Queue timeout: Defines the maximum length of time (in ms) to queue a request/connection for a given backend if stickiness is enabled. The default value for this setting is 5 000, the minimum value is 1 and the maximum value is 2 147 483 647.
    • If stickiness is enabled the request/connection is put in a dedicated queue for the selected backend server, and waits there for an available connection slot until the timeout is value is reached.
    • If stickiness is disabled, the Load Balancer does not queue requests/connections for backend servers that have reached their connection limit, and instead tries others that still have connection slots available.

Retries

Retry settings define how the Load Balancer should retry to establish a connection to the backend server if its initial attempt fails. The following settings are available:

  • Retry policy: Select whether the Load Balancer should try again on the same server (default) or redispatch and try different servers
  • Max. retries: Defines the maximum number of times to retry establishing a connection after the first attempt. A value of 3 for example means that an initial attempt is made, and if that fails then the Load Balancer will try three more times to establish a connection. The default value is 3, the minimum value is 0 and the maximum value is 32.

S3 failover

Activating the S3 failover feature allows you to redirect users to a static website hosted on Scaleway Object Storage, in the case that none of your Load Balancer’s backend servers are available. This website could be a simple, single webpage or else something much more complex: you build it according to your own requirements.

Note that when entering the S3 link to redirect to, the URL of the bucket endpoint is not sufficient. The bucket website URL is specifically required (e.g.https://my-bucket.s3-website.nl-ams.scw.cloud). See our dedicated documentation for further help.

Health checks

See our dedicated documentation on configuring health checks.