Skip to main content
Load balancers
Last update:

Load balancers

The load balancer distributes incoming network traffic among cloud servers in a single pool.

A cloud 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.

Traffic is distributed between servers according to the rules — the port and protocol of the balancer and servers, the algorithm of request distribution, availability checks and connection parameters are configured. There is no limit to the number of rules.

How the balancer works⁠

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

  • Amphorae (amphorae) — performs load balancing. Runs on a cloud server and uses HAProxy (High-Availability Proxy), a traffic proxying software. In balancers with redundancy (types Basic with redundancy and Advanced with redundancy) two amphorae are created, without redundancy — one.
  • Listener — listens to the traffic flow coming into the load balancer using the ports and protocols specified in the rule. Then routes traffic to the desired group of servers.
  • Pool — A group of servers to which the listener directs requests.
  • Members (servers) — Servers that serve traffic in the pool. Accessible by the IP address and port specified in the rule.
  • Health Monitor — the process of checking the health of all servers within the pool.

Balancer Ports⁠

Load balancer amphoras utilize multiple ports:

  • Incoming port (uplink). This is the virtual port that hosts the VIP — virtual IP address. On it, the listener listens to incoming traffic. It is allocated when the load balancer is created and is in its subnet. In redundant balancers (Basic redundant and Advanced redundant types), VIP is redundant via VRRP.
  • Service VRRP ports. When a basic load balancer is created, one service port is allocated on its subnet. When creating a redundant balancer, two service ports are allocated for the primary and backup amphora and VRRP is configured between them.
  • Service ports (downlinks). If the servers are not in the balancer's subnet, then when the balancer is created, ports are allocated in the subnets with servers for amphora: one port for the basic balancer, two ports (primary and backup) for the balancers with redundancy.

If the load balancer malfunctions, it automatically creates a new amphora (and only then deletes the old one) — it needs a free port to do this. If there is no free port, the balancer will go to ERROR status.

If you chose a public subnet as the load balancer subnet when creating the load balancer and will be hosting servers on it, make sure it has an additional port, or use a public network of /28 or larger.

We recommend choosing a private network with a public IP address (the address is needed to access the Internet) — in this case there will always be a free port available for recreating the amphora. Traffic balancing will be done within the private network.

Types of balancers⁠

Basic without redundancyBasic with redundancyAdvanced with redundancy
Fault tolerance and redundancySingle mode onlyActive-Standby Failover to redundant amphora in one poolActive-Standby Failover to redundant amphora in one pool
What it is suitable forFor test environments or projects, for which 24 / 7 service availability is not requiredFor small and medium-sized projects for which service availability is criticalFor projects with high load and requirement for 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 up to 5 Gbps — create a ticket
Number of HTTP requests per second (RPS)~19,500~19,500~34,000
Number of HTTPS requests with termination on 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)

You can order a custom balancer configuration — create a ticket.

View a list of types⁠

Types can be viewed in the control panel when creating a load balancer or through the OpenStack CLI.

  1. Open OpenStack CLI.

  2. Check out the list of available types:

    openstack loadbalancer flavor list -c id -c name

    A list will appear in the response (example 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 |
    +--------------------------------------+------------------------+

    The margins indicate:

    • id — Flavor ID, depends on pool. Flavor is a load balancer configuration in OrenStack terminology;
    • name — load balancer type:
      • AMPH1.SNGL.2-1024 — type Basic without redundancy;
      • AMPH1.ACT_STNDB.2-1024 — type Basic with redundancy;
      • AMPH1.ACT_STNDB.4-2048 — Type Advanced with redundancy.

Balancer's Rules⁠

A rule is a balancer setting that services a traffic flow with a specific port and protocol and distributes that traffic to the correct group of servers.

In the rule, you can customize:

  • protocols and inbound traffic ports of the load balancer and the servers that will serve the traffic;
  • algorithms by which requests are distributed;
  • availability-checks to monitor the status of servers;
  • connections passing through the balancer.

The number of rules in the balancer is unlimited.

Protocols⁠

Combinations of protocols are available:

  • TCP-TCP is 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 on the balancer.

Query Allocation Algorithms⁠

The listener distributes queries according to the chosen algorithm. Two algorithms are available:

  • Round Robin algorithm. The first request is passed to one server, the next request to another and so on until the last server is reached. Then the cycle starts all over again. Requests are distributed to the servers according to a given weight.
  • Least connections — the algorithm takes into account the number of connections to servers. The new request is passed to the server with the smallest number of active connections, server weight is not taken into account.

Sticky Sessions⁠

Additionally, Sticky Sessions can be enabled. The method is required when the end application holds a long connection to each client and stores internal data state that is not synchronized between servers in the rule.

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

The session definition settings can be customized — session balancing or balancing one client per server. It is possible to identify the session:

  • by APP-cookie — an already existing cookie that is set in the application code;
  • by HTTP-cookie — a cookie that is 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 rule — this is how the server that will process the requests is determined.

Accessibility checks⁠

You can enable availability checking for the balancer. The balancer will monitor the state of the servers — if any server is down, the balancer will redirect the connection to another.

Validation Parameters:

  • check type: HTTP, HTTPS, PING, TCP, TLS-HELLO, UDP-CONNECT;
  • the interval in seconds at which the balancer sends check requests to servers;
  • connection timeout — the time to wait for a response;
  • for HTTP and HTTPS inspection protocols, you can configure URL invocation and expected response codes;
  • success threshold — the number of successful requests in a row, after which the server is switched to the working state;
  • failure threshold — the number of unsuccessful accesses in a row, after which the server operation is suspended.

Connection settings⁠

You can configure the connections that pass through the balancer — between incoming requests and the balancer, the balancer and the servers.

Connection Settings:

  • connection timeout — the time to wait for a response;
  • number of connections — limited or not;
  • inactivity timeout — the time during which the 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 mode of operation, the balancer passes only the original body of the HTTP request to the server, replacing the client's 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,
  • X-Forwarded-Port,
  • X-Forwarded-Proto,
  • X-SSL-Client-Verify,
  • X-SSL-Client-Has-Cert,
  • X-SSL-Client-DN,
  • X-SSL-Client-CN,
  • X-SSL-Issuer,
  • X-SSL-Client-SHA1,
  • X-SSL-Client-Not-Before,
  • X-SSL-Client-Not-After.

Cost⁠

The cost of the load balancer is listed at selectel.ru.

Funds are deducted from the Cloud Platform balance every hour — learn more about cloud platform payment model.