Skip to main content

General information about load balancers

Cloud load balancer distributes incoming network traffic between cloud servers in the same pool. A load balancer can be used to improve service availability—it will optimally distribute requests between servers and reduce the load. If one server fails, the balancer will redirect traffic to another suitable server.

The load balancer operates at L3-L4 (network load balancer) and L7 (application load balancer) layers. To balance HTTPS traffic, TLS(SSL) certificates from the secrets manager are used; for details, see the Load balancer TLS(SSL) certificates instructions.

You can work with the load balancer in the control panel, via the OpenStack CLI, or using Terraform.

Cloud load balancers support user types and roles.

Records of operations with the cloud load balancer are saved in audit logs.

If you need a load balancer for working with a Managed Kubernetes cluster, use only kubectl to create and configure it. For more details, see the Configure a load balancer section in Managed Kubernetes.

To track load balancer metrics, you can configure monitoring using Prometheus; for details on available metrics and monitoring setup, see the Cloud load balancer monitoring instructions. You can also collect load balancer logs.

Load balancer types

Basic non-redundantBasic redundantAdvanced redundant
Number of instancesOneTwoTwo
Instance configuration2 vCPU, 1 GB RAM2 vCPU, 1 GB RAM4 vCPU, 2 GB RAM
Fault tolerance and redundancySingle mode onlyActive-Standby Failover to a standby instance in one pool *Active-Standby Failover to a standby instance in one pool *
Use caseFor test environments or projects that do not require 24/7 service availabilityFor small and medium-sized projects where service availability is criticalFor high-load projects requiring constant service availability
ThroughputUp to 3 Gbps. Can be increased to 5 Gbps — create a ticketUp to 3 Gbps. Can be increased to 5 Gbps — create a ticketUp to 3 Gbps. Can be increased to 5 Gbps — create a ticket
Number of HTTP requests per second (RPS)~19 500~19 500~34 000
Number of HTTPS requests terminated at the balancer per second (RPS)~3 000 keep-alive connections (with 10 000 concurrent TCP connections)~3 000 keep-alive connections (with 10 000 concurrent TCP connections)~9 000 keep-alive connections (with 10 000 concurrent TCP connections)

* If a redundant load balancer is in a multi-zone pool, its instances are located in different availability zones. If one availability zone fails, the instance in the other zone will continue to distribute traffic between servers.

If the types do not suit you, you can order a custom load balancer type — submit a ticket.

List of load balancer flavors

Flavors correspond to load balancer types and determine the number of vCPUs, RAM, and load balancer instances.

To create load balancers via the OpenStack CLI and Terraform, flavor IDs or names are used. IDs differ across pools.

note

For example, ac18763b-1fc5-457d-9fa7-b0d339ffb336 is an ID, and AMPH1.ACT_STNDB.4-2048 is the name of a flavor corresponding to the Advanced redundant type in the ru-9 pool.

You can view a list of load balancer flavors in all pools in a table or view a list of load balancer flavors in a specific pool through the OpenStack CLI.

List of load balancer flavors in all pools

IDName
7d56905c-92ce-49e8-986e-f656f7b44cdaAMPH1.SNGL.2-1024
ca85e2b6-456e-4118-a2db-0f4aa4f51528AMPH1.ACT_STNDB.2-1024
5f8741d4-d6c6-438d-bf11-2ab0fbd926c5AMPH1.ACT_STNDB.4-2048

Where:

  • ID — load balancer flavor ID;
  • Name — flavor name that corresponds to the load balancer type:
    • AMPH1.SNGL.2-1024 — Basic non-redundant type;
    • AMPH1.ACT_STNDB.2-1024 — Basic redundant type;
    • AMPH1.ACT_STNDB.4-2048 — Advanced redundant type.

View a list of load balancer flavors in a specific pool

  1. Open the OpenStack CLI.

  2. View the list of flavors:

    openstack loadbalancer flavor list -c id -c name

    Example response for the ru-9 pool:

    +--------------------------------------+------------------------+
    | id                                   | name                   |
    +--------------------------------------+------------------------+
    | 3265f75f-01eb-456d-9088-44b813d29a60 | AMPH1.SNGL.2-1024      |
    | d3b8898c-af94-47f8-9996-65b9c6aa95e2 | AMPH1.ACT_STNDB.2-1024 |
    | ac18763b-1fc5-457d-9fa7-b0d339ffb336 | AMPH1.ACT_STNDB.4-2048 |
    +--------------------------------------+------------------------+

    Where:

    • id — load balancer flavor ID;
    • name — flavor name that corresponds to the load balancer type:
      • AMPH1.SNGL.2-1024 — Basic non-redundant type;
      • AMPH1.ACT_STNDB.2-1024 — Basic redundant type;
      • AMPH1.ACT_STNDB.4-2048 — Advanced redundant type.

How a load balancer works

The load balancer uses the OpenStack Octavia model, which includes:

  • instance (amphora) — performs load balancing. It runs on a cloud server and uses HAProxy (High-Availability Proxy) — software for proxying traffic. In redundant balancers (types Basic redundant and Advanced redundant), two instances are created, and in non-redundant ones, one is created;
  • target group (pool) — a group of servers to which a rule redirects requests according to the protocol specified for the group;
  • servers (members) — servers that handle traffic in the pool. They are available via the IP address and port specified for the server within the target group;
  • availability checks (health monitor) — the process of monitoring the health of all servers in the target group;
  • rule (listener) — listens to the incoming traffic stream to the load balancer using the protocols and ports specified in the rule. Then routes traffic to the required group of servers;
  • HTTP policy (L7 Policy) — additional conditions in a rule for routing HTTP traffic with specific parameters.

Target groups

A target group is a group of servers to which traffic from the load balancer is distributed. A server can be part of several target groups of the same balancer if different ports are specified for the server in these groups.

For a target group, you can configure:

Availability checks

You can enable availability checks for a target group. The balancer will monitor the state of the servers—if any server is down, the balancer will redirect connectivity to another.

Inspection parameters:

  • inspection type. Depending on the target group protocol, the following types are available:

    • TCP group — TCP, PING;
    • PROXY group — TLS-HELLO, HTTP, TCP, PING;
    • UDP group — UDP-CONNECT, PING;
    • HTTP group — HTTP, TCP, PING;

  • for the HTTP inspection protocol, you can configure URL invocation and expected response codes;

  • inspection interval — the interval in seconds at which the balancer sends inspection requests to servers;

  • connection timeout — the response waiting time;

  • success threshold — the number of consecutive successful attempts after which the server is set to operational status;

  • failure threshold — the number of consecutive unsuccessful attempts after which server operations are suspended.

Rules

A rule is a set of load balancer settings that handle a traffic stream with a specific port and protocol and distribute this traffic to the required group of servers.

In a rule, you can configure:

There is no limit to the number of rules in a balancer.

HTTP policies

HTTP policy — an addition to a rule that allows you to route specific HTTP and HTTPS traffic separately from other traffic:

  • redirect to another target group (REDIRECT_TO_POOL);
  • redirect to a URL — completely replace the request URL, including the protocol, domain name, path, and request parameters (REDIRECT_TO_URL);
  • redirect to a URL prefix — replace the protocol and domain name in the request URL (REDIRECT_PREFIX);
  • reject (REJECT).

A request is redirected according to the first matching policy. The order of policy application depends on the policy action: REJECT policies are applied first, followed by REDIRECT_TO_URL and REDIRECT_PREFIX, and then REDIRECT_TO_POOL. If a rule has multiple policies with the same action, they are applied according to the policy's position in the rule. You can change the policy application order.

An HTTP policy consists of a set of conditions; there is no limit to the number of conditions in a policy. For a request to match a policy, it must meet all policy conditions. A condition specifies:

  • request parameter to check: HOST_NAME or PATH. When configuring a policy via the OpenStack CLI, you can also create a condition based on the COOKIE, FILE_TYPE, and HEADER parameters;
  • comparison value for inspection — an exact value or a regular expression;
  • match type against the control value: EQUAL TO, STARTS WITH, ENDS WITH, CONTAINS, REGEX.

There is no limit to the number of HTTP policies in a rule.

Load balancer ports

A balancer occupies several ports in a subnet; the number depends on the balancer type: three ports for a non-redundant balancer, and five ports for redundant balancers (Basic redundant and Advanced redundant types).

The subnet must always have free IP addresses to recreate the load balancer: in case of a malfunction, it automatically creates a new instance and only then deletes the old one. Recreating a load balancer without redundancy requires one free IP address, while a load balancer with redundancy requires two. If no free IP address is available, the load balancer will enter the ERROR status.

If you plan to place the load balancer and servers in the same subnet, choose a subnet size of at least /28. We recommend choosing a private subnet of size /24 with a public IP address (the address is required for internet access) — in this case, free IP addresses will always be available for recreating the instance. Traffic balancing will be performed within the private network.

The following ports are created for each balancer:

  • uplink port—a virtual port where the VIP (virtual IP address) is placed. A rule listens for incoming traffic on this port. It is allocated when a load balancer is created and is located in its subnet. For redundant balancers, the VIP is reserved via the VRRP protocol;
  • service VRRP ports—when a basic load balancer is created, one service port is allocated in its subnet. When a redundant balancer is created, two service ports are allocated for the primary and standby instances, and VRRP is configured between them;
  • downlink service ports. If servers are not located in the balancer subnet, ports are allocated for instances in the subnets with the servers when the balancer is created: one port for a basic balancer, and two ports (primary and standby) for redundant balancers.

Protocols

The following protocol combinations are available:

  • TCP–TCP — classic L4-balancing;
  • TCP–PROXY — client information is not lost and is transmitted in a separate connection header;
  • UDP–UDP — the UDP protocol is faster than TCP but less reliable;
  • HTTP–HTTP — L7-balancing;
  • HTTPS–HTTP — L7-balancing with encryption and SSL certificate termination at the balancer.

Request distribution algorithms

A rule distributes requests according to the selected algorithm. Two algorithms are available:

  • Round Robin — a circular service algorithm. The first request is transmitted to one server, the next request to another, and so on until the last server is reached. Then the loop starts over. Requests are distributed to servers in accordance with the specified weight.
  • Least connections — the algorithm accounts for the number of connections to servers. A new request is transmitted to the server with the fewest active connections; the server weight is not considered.

Sticky Sessions

Additionally, you can enable Sticky Sessions. This method is necessary when the end application maintains a long connection with each client and saves internal data state, which is not synchronized between servers in a rule.

New requests will be distributed according to the selected algorithm, and then the session will be pinned to the server that started processing the requests. All subsequent requests of this session will be distributed to that server, ignoring the selected algorithm. If the server is unavailable, the request will be redirected to another.

Session definition parameters can be configured—you can balance sessions or balance a single client to a single server. You can identify a session:

  • by APP-cookie — an already existing cookie specified in the application code;
  • by HTTP-cookie — a cookie created and attached to the session by the balancer;
  • by Source IP — the client IP address is hashed and divided by the weight of each server in the target group—this determines the server that will process the requests.

Connection settings

You can specify the settings for connections passing through the balancer—between incoming requests and the balancer, and between the balancer and servers.

Connection settings:

  • connection timeout — the response waiting time;
  • maximum connections — the maximum number of active connections;
  • inactivity timeout — the time during which a connection is considered active, even if no data is transmitted;
  • TCP packets waiting timeout — the time during which the balancer waits for data transmission for inspection over an already established connection.

HTTP request headers

In normal operation mode, the balancer transmits only the original HTTP request body to the server, replacing the client IP address with its own.

Include the necessary types of additional headers in the request so that servers receive this information for correct operation or analysis:

  • X-Forwarded-For — the IP address from which the request originated;
  • X-Forwarded-Port — the load balancer port to which the request was sent;
  • X-Forwarded-Proto — the original connection protocol;
  • X-SSL-Client-Verify — whether the client used a secure connection;
  • X-SSL-Client-Has-Cert — whether the client has a certificate;
  • X-SSL-Client-DN — identification information of the owner;
  • X-SSL-Client-CN — the host name for which the certificate was issued;
  • X-SSL-Issuer — the certificate authority that issued the certificate;
  • X-SSL-Client-SHA1 — SHA1 fingerprint of the client certificate;
  • X-SSL-Client-Not-Before — the certificate start date;
  • X-SSL-Client-Not-After — certificate expiration date.

Cost

Load balancers are billed according to the Cloud Platform billing model.

You can view the load balancer prices at servercore.com.