Load balancers

A cloud load balancer distributes incoming network traffic between cloud servers in a single pool. The 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 load balancer will redirect traffic to another suitable server.

The balancer works at L3-L4 (network load balancer) and L7 (application load balancer) levels. For HTTPS traffic balancing TLS(SSL)-certificates from the secret manager are used, see the TLS(SSL)-certificates of the load balancer instruction for details.

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

If you need the load balancer to work with a Managed Kubernetes cluster, use only kubectl to create and configure the load balancer. See the Configure a load balancer in the Managed Kubernetes section for more information.

To track load balancer metrics you can set up monitoring using Prometheus, learn more about the available metrics and how to set up monitoring in the Cloud Load Balancer Monitoring instructions.You can also collect load balancer logs.

Types of load balancer

	Basic without reservation	Basic with reservation	Advanced with reservation
Number of instances	One	Two	Two
Instance Configuration	2 vCPUs, 1 GB RAM	2 vCPUs, 1 GB RAM	4 vCPUs, 2 GB RAM
Fault tolerance and redundancy	Single mode only	Active-Standby Failover to a standby instance in the same pool	Active-Standby Failover to a standby instance in the same pool
What it's good for	For test environments or projects that do not require 24 / 7 service availability	For small and medium-sized projects for which service availability is critical	For projects with high load and requirement for constant service availability
Throughput	Up to 3 Gbps. Can be increased up to 5 Gbps — create a ticket	Up to 3 Gbps. Can be increased up to 5 Gbps — create a ticket	Up 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 simultaneous TCP connections)	~3,000 keep-alive connections (with 10,000 simultaneous TCP connections)	~9,000 keep-alive connections (with 10,000 simultaneous TCP connections)

If the types don't fit, you can order a custom balancer type — create a ticket.

Load balancer flavor list

The flavors correspond to load balancer types and define the number of vCPUs, RAM, and the number of load balancer instances.

Flavor IDs or names are used to create load balancers through the OpenStack CLI and Terraform. The IDs are different in pools.

note

For example, ac18763b-1fc5-457d-9fa7-b0d339ffb336 is the ID and AMPH1.ACT_STNDB.4-2048 is the name of the flavor that corresponds to the Advanced type with reservation in the ru-9 pool.

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

List of load balancer flavorings in all pools

ru-3
ru-1
ru-9

ID	Name
d4490352-a58a-44b7-b226-717cd7607c0e	AMPH1.SNGL.2-1024.
dbf2523f-39a5-4f34-be74-07eb3f111171	AMPH1.ACT_STNDB.2-1024
ea49b7dd-c126-4b22-8a2c-2eb65cbda662	AMPH1.ACT_STNDB.4-2048

ID	Name
10a221ac-f483-41c7-b9a8-79893317f5c6	AMPH1.SNGL.2-1024.
06731413-f866-4497-a804-2feba12455be	AMPH1.ACT_STNDB.2-1024
f6538882-a867-4156-9cfd-d2e629b005c4	AMPH1.ACT_STNDB.4-2048

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

ru-2
ru-7

ID	Name
e1613cc2-62b9-4cc8-b0fb-a30cf0cca3f3	AMPH1.SNGL.2-1024.
ac29a80a-c694-4861-a061-3a78cae0ccf9	AMPH1.ACT_STNDB.2-1024
1d25f453-41e8-48bb-9fc6-ffa235f03444	AMPH1.ACT_STNDB.4-2048

ID	Name
78dbe17b-0358-47db-a933-7f06e58307e4	AMPH1.SNGL.2-1024.
b93feeb9-6522-4dfa-9e08-38d03ac2448f	AMPH1.ACT_STNDB.2-1024
226d5473-2aa6-42da-b74e-529c6da7a12f	AMPH1.ACT_STNDB.4-2048

ID	Name
15be309a-62c8-4b1c-8896-345d5eb21b00	AMPH1.SNGL.2-1024.
c979a0d1-5558-4820-aed1-9990b66648f9	AMPH1.ACT_STNDB.2-1024
eed81b82-707b-488c-8142-47a9c1fb71e8	AMPH1.ACT_STNDB.4-2048

uz-1
uz-2

ID	Name
7d56905c-92ce-49e8-986e-f656f7b44cda	AMPH1.SNGL.2-1024.
ca85e2b6-456e-4118-a2db-0f4aa4f51528	AMPH1.ACT_STNDB.2-1024
5f8741d4-d6c6-438d-bf11-2ab0fbd926c5	AMPH1.ACT_STNDB.4-2048

ID	Name
74cb3ac7-5984-4612-b0f6-e43ee95bb495	AMPH1.SNGL.2-1024.
c20efedb-3ae0-4bd7-a80d-6d36f5120efd	AMPH1.ACT_STNDB.2-1024
64dcea94-32e7-4248-aa43-7ac56952c5ba	AMPH1.ACT_STNDB.4-2048

ID	Name
a082beed-caca-4722-b4cf-c261781224cf	AMPH1.SNGL.2-1024.
abe8a65d-371b-4157-8402-aa39611ebf9a	AMPH1.ACT_STNDB.2-1024
ad73fce9-8d22-40bc-8708-d5ddd7bf4067	AMPH1.ACT_STNDB.4-2048

ID	Name
c48873e3-06ef-4aa8-9537-b3050578cfdb	AMPH1.SNGL.2-1024.
458d379b-d6c3-4667-baf5-53fe05b33156	AMPH1.ACT_STNDB.2-1024
d95b0f5e-f727-45a0-9dd0-bbd014f64fbe	AMPH1.ACT_STNDB.4-2048

Here:

ID — The ID of the load balancer flavor;
Name — The name of the flavor that corresponds to the The type of load balancer:
- AMPH1.SNGL.2-1024 — type Basic without reservation;
- AMPH1.ACT_STNDB.2-1024 — type Basic with redundancy;
- AMPH1.ACT_STNDB.4-2048 — type Advanced with redundancy.

View a list of load balancer flavorings in a specific pool

Open the OpenStack CLI.

Check out the list of flavors:

openstack loadbalancer flavor list -c id -c name

Example answer 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 |
+--------------------------------------+------------------------+

Here:

id — The ID of the load balancer flavor;
name — the name of the flavor, which corresponds to the type of load balancer:
- AMPH1.SNGL.2-1024 — type Basic without reservation;
- AMPH1.ACT_STNDB.2-1024 — type Basic with redundancy;
- AMPH1.ACT_STNDB.4-2048 — type Advanced with redundancy.

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 load balancers with redundancy (types Basic with redundancy and Advanced with redundancy) two instances are created, without redundancy — one;
target group (pool) — A group of servers to which the rule redirects requests using the protocol specified for the group;
servers (members) — servers that serve traffic in the pool. They are accessible by the IP address and port specified for the server within the target group;
availability checks (health monitor) — the process of checking the health of all servers in the target group;
rule (listener) — listens to the traffic flow coming to the load balancer using the protocols specified in the rule. protocols and ports. It then routes the traffic to the required server group;
HTTP Policy (L7 Policy) — additional conditions in the rule for routing HTTP traffic with certain parameters.

Target groups

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

You can customize for the target group:

protocols and ports to receive traffic from the load balancer;
algorithms by which requests are distributed;
availability checks to monitor the status of servers.

Accessibility checks

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

Validation Parameters:

validation type. Depending on the protocol of the target group, the types available are:
- 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 the URL invocation and expected response codes;
check interval — the interval in seconds with which the balancer sends check requests to the servers;
connection timeout — the time to wait for a response;
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.

Rules

A rule is a balancer setting that serves 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 ports of the load balancer's incoming traffic;
HTTP policies for additional routing of HTTP traffic;
connections passing through the balancer;
select the target server group.

The number of rules in the balancer is unlimited.

HTTP Policies

HTTP policy is an addition to a rule that allows certain HTTP and HTTPS traffic to be routed separately from the rest of the traffic:

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

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

HTTP policy consists of a set of conditions, the number of conditions in the policy is unlimited. For a request to fall under the policy, it must meet all the conditions of the policy. The condition specifies:

the query parameter to check: HOST_NAME or PATH. When configuring a policy through the OpenStack CLI, you can also create a condition on the COOKIE, FILE_TYPE, and HEADER parameters;
control value to check whether it is an exact value or a regular expression;
type of matching with the control value: EQUAL TO, STARTS WITH``, ENDS WITH, CONTAINS, REGEX.

The number of HTTP policies in a rule is unlimited.

Load Balancer Ports

Load balancer instances utilize multiple ports:

inbound port (uplink). This is a virtual port that hosts a VIP virtual IP address. The rule listens to incoming traffic on this port. It is allocated when creating a load balancer and is located in its subnet. In load balancers with redundancy (types Basic with redundancy and Advanced with redundancy) VIP is reserved using VRRP protocol;
service VRRP ports. When creating a basic load balancer, one service port is allocated on its subnet. When creating a redundant load balancer, two service ports are allocated for the primary and backup instances, and VRRP is configured between them;
service ports (downlinks). If the servers are not in the balancer's subnet, ports for instances are allocated in subnets with servers when the balancer is created: one port for a basic balancer, two ports (primary and backup) for redundant balancers.

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

If you chose a public subnet as the load balancer subnet when you created the load balancer and will be hosting servers on it, make sure it has an additional IP address, 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, a free IP address will always be available for recreating the instance. Traffic balancing will be performed inside the private network.

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 rule distributes queries according to the selected algorithm. Two algorithms are available:

Round Robin is a 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 again. Requests are distributed to servers according to the specified weight.
Least connections — the algorithm takes into account the number of connections to servers. A new request is passed to the server with the smallest number of active connections, the server weight is not taken into account.

Sticky Sessions

Additionally, Sticky Sessions can be enabled. The method is required when the end application keeps 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 selected algorithm, and then the session will be assigned to the server that started processing requests. All subsequent requests from 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 one.

You can customize the session definition options — balancing sessions or balancing one client per server. You can 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's IP address is hashed and divided by the weight of each server in the target group — this is how the server that will process the requests is determined.

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;
maximum connections — the maximum number of active connections;
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 — The IP address from which the request came;
X-Forwarded-Port — The port of the balancer to which the request came;
X-Forwarded-Proto — source protocol of the connection;
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 — owner identification information;
X-SSL-Client-CN — the name of the host for which the certificate is issued;
X-SSL-Issuer — The certification authority where the certificate was issued;
X-SSL-Client-SHA1 — SHA1 fingerprint of the client certificate;
X-SSL-Client-Not-Before — the beginning of certificate validity;
X-SSL-Client-Not-After — certificate expiration.

Cost

Balancers are paid under the cloud platform payment model.

The cost of balancers can be viewed at servercore.com.