Create a load balancer

Last update: May 28 2025

Create a load balancer

Control panel

1. Select the configuration and network.
2. Create a task force.
3. Create rules and HTTP policies.

1. Select the configuration and network⁠

1. In the Control panel, on the top menu, click Products and select Cloud Servers.

2. Go to Balancers → Balancers tab.

3. Click Create Balancer.

4. Select the region and pool where the balancer will be created.

5. Select a configuration based on the project load.

6. Enter the name of the balancer.

7. Optional: enter a comment — any additional information about the balancer, it will only be displayed in the control panel.

8. Optional: To access the balancer logs, enable logging. Logging uses part of the balancer's computational resources.

   8.1 Check the Collect balancer technical logs checkbox.

   8.2 Select a log group or create a new group.

   8.3 If you have selected a new group, enter its name.

9. Select a subnet:

   • private — traffic balancing will be performed only within the subnet. You can connect a public IP address to a private address — the balancer will be accessible from the Internet via NAT;
   • or public — the load balancer will be accessible from the Internet and will be able to proxy requests from the public subnet to cloud servers on the private subnet. If you will be hosting cloud servers on the same subnet, choose a network of /28 or larger, or make sure there is a free IP address for the load balancer port.

10. Specify the IP address in the subnet, a free address that will be assigned to the balancer.

11. Optional: Connect a public IP address. If there is no free public IP address available, create a new IP address. The private subnet in which you create the balancer must be prepared to connect a public IP address.

12. Press Next.

2. Create a task force⁠

1. Open the Servers tab.

2. Optional: To change the name of the target group, click , enter a name, and click .

3. Select the traffic assignment protocol that the balancer uses to send traffic to the target group. The following combinations of protocols are available for accepting traffic on the balancer and assigning traffic to the target group:

   • 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.

4. A default port will be automatically selected for the selected protocol — change it if necessary. The port value will be common to all servers in the group.

5. Mark the servers to be added to the target group.

6. Specify settings for each marked server:

   6.1 Select the IP address.

   6.2 Optional: change the port.

   6.3 Specify the server weight — this is a proportional measure, denotes the share of requests that the server handles. If the weights are the same, the servers serve the same number of requests. If, for example, there is one server in a group with a weight of "2" and two servers with a weight of "1", the first server will receive 50% of all requests and the other two will each receive 25%. The maximum weight value is 256.

   6.4 Optional: To direct traffic to a server only when other servers in the group are unavailable, check the Backup checkbox.

7. Open the Algorithm tab.

8. Select either Round Robin or Least connections as the query distribution algorithm.

9. Optional: To enable the Sticky Sessions method, check the Sticky sessions checkbox and select a session ID. For APP-cookie ID, enter a cookie name.

10. Open the Availability Checks tab.

11. Select the type of availability check. Once the group is created, you cannot change the check type.

12. If you selected the HTTP validation type, specify the request parameters — method, path, and expected response codes.

13. Specify the check interval — the interval in seconds at which the balancer sends check requests to servers.

14. Specify the connection timeout — the maximum time to wait for a response in seconds, must be less than the interval between checks.

15. Specify the success threshold — the number of successful accesses in a row, after which the server is put into a working state.

16. Specify the failure threshold — the number of unsuccessful requests in a row, after which the server is suspended.

17. Optional: To add another target group, click Add Target Group and customize it.

18. Press Next.

3. Create rules and HTTP policies⁠

1. Select the protocol for receiving traffic on the load balancer — TCP, UDP, HTTP, or HTTPS. The Prometheus option is also available for configuring load balancer monitoring.

TCP or UDP traffic

2. For the selected protocol, the default port on which the balancer will listen to traffic will be automatically selected — change it if necessary.

3. Optional: Enter the allowed CIDR — IP addresses from which the balancer will accept traffic with the selected protocol and port. You can enter a subnet in CIDR format or a single IP address with a /32 mask. If you leave the field blank, the balancer will accept traffic from any IP addresses. You can specify the allowed IP addresses in the rule after the balancer is created.

   If this field is absent, port security is disabled on the balancer's network.

4. Select a target group. Groups are available to which you can balance traffic using the selected traffic reception protocol.

5. Optional: expand the Advanced Rule Settings block and specify connection settings:

   • for incoming requests to the balancer — specify the connection timeout and maximum connections;
   • for requests from the balancer to servers — specify the connection timeout, inactivity timeout and TCP packet waiting timeout.

6. Optional: To add another rule, click Add Rule and repeat steps 1-5. The number of rules is unlimited.

7. Check the total cost of the balancer.

8. Click Create Balancer.

HTTP or HTTPS traffic

2. For the selected protocol, the default port on which the balancer will listen to traffic will be automatically selected — change it if necessary.

3. If you selected the HTTPS protocol, select a certificate to terminate HTTPS traffic on the load balancer — select a certificate from the Secrets Manager or download a new one. See the TLS(SSL)-Certificates for Load Balancer instructions for more information.

4. Optional: To restrict access to the balancer, enter the allowed CIDRs — IP addresses from which the balancer will accept traffic with the selected protocol and port. You can enter a subnet in CIDR format or a single IP address with a /32 mask. If you leave the field blank, the balancer will accept traffic from any IP addresses. You can specify the allowed IP addresses in the rule after the balancer is created.

   If this field is absent, port security is disabled on the balancer's network.

5. Optional: mark the HTTP request headers to be passed to the servers.

6. Select the default target group — traffic that is not covered by the HTTP policy will be directed there.

7. Create HTTP policies.

8. Optional: change the connection settings, to do this, open the Advanced Rule Settings block and specify:

   • for incoming requests to the balancer — specify the connection timeout and maximum connections;
   • for requests from the balancer to servers — specify the connection timeout, inactivity timeout and TCP packet waiting timeout.

9. Optional: To add another rule, click Add Rule and repeat steps 1-8. The number of rules is unlimited.

10. Check the total cost of the balancer.

11. Click Create Balancer.

OpenStack CLI

1. Create a balancer.
2. Create a rule, an HTTP policy, and a target group.

Create a balancer⁠

1. Open the OpenStack CLI.

2. Install the Octavia component to work with cloud load balancers — Yoga release version 3.4.0 is required for compatibility with the release version:

   pip3 install python-octaviaclient===3.4.0

3. Create a load balancer:

   openstack loadbalancer create \
     --vip-subnet-id <subnet_uuid> \
     --vip-address <loadbalancer_ip_address> \
     --flavor <flavor> \
     --name <loadbalancer_name>

   Specify:

   • <subnet_uuid> — The ID of a private or public subnet can be viewed with the command openstack subnet list;
   • <loadbalancer_ip_address> — The IP address that will be allocated to the load balancer is one of the free ones in the subnet;
   • <flavor> — The ID or name of the flavor. The flavors correspond to load balancer types and determine the number of vCPUs, RAM, and the number of load balancer instances. For example, ac18763b-1fc5-457d-9fa7-b0d339ffb336 — ID to create a balancer with type Advanced with reservation in the ru-9 pool. The list of flavorors can be viewed using the command openstack loadbalancer flavor list -c id -c name or in the table List of load balancer flavors in all pools;
   • <loadbalancer_name> — balancer name.

4. Verify that the balancer is in the statuses ONLINE ( operating_status parameter in the command output) and ACTIVE ( provisioning_status):

   openstack loadbalancer show <loadbalancer>

   Specify <loadbalancer> — balancer ID or name, the list can be viewed with the openstack loadbalancer list command.

5. Optional: If you specified a private subnet in step 3, connect the public IP address to the balancer:

   openstack floating ip set --port <loadbalancer_port_uuid> <floating_ip>

   Specify:

   • <loadbalancer_port_uuid> — The balancer port ID can be viewed with the command openstack loadbalancer show <loadbalancer> value vip_port_id;
   • <floating_ip> — public IP address.

Create a rule, HTTP policy and target group⁠

For TCP or UDP traffic

1. Create a rule:

   openstack loadbalancer listener create \
     --name <listener_name> \
     --protocol <protocol> \
     --protocol-port <port> \
     [--allowed-cidr <allowed_cidr>] \
     <loadbalancer>

   Specify:

   • <listener_name> — rule name;
   • <protocol> — protocol name protocol: TCP or UDP;
   • <port> — port number on the balancer;
   • optional: --allowed-cidr <allowed_cidr> — IP address from which it is allowed to receive traffic, where <allowed_cidr> — subnet in CIDR format or single IP address with mask /32. If you need to specify multiple addresses, specify each address in a separate --allowed-cidr parameter . For the restriction to work, port security must be enabled on the balancer network . You can specify the allowed IP addresses in the rule after the balancer is created;
   • <loadbalancer> — The ID or name of the load balancer. The list can be viewed with the command openstack loadbalancer list.

2. Create a task force:

   openstack loadbalancer pool create \
     --name <pool_name> \
     --lb-algorithm <algorithm> \
     --listener <listener_name> \
     --protocol <protocol>

   Specify:

   • <pool_name> — the name of the target group;
   • <algorithm> — name algorithm name: ROUND_ROBIN or LEAST_CONNECTIONS;
   • <listener_name> — the name of the rule you created in step 1;
   • <protocol> — protocol name protocol: TCP, UDP, PROXY.

3. Add the server to the target group:

   openstack loadbalancer member create \
     --subnet-id <subnet_uuid> \
     --address <server_ip_address> \
     --protocol-port <port> \
     <pool_name>

   Specify:

   • <subnet_uuid> — The ID of the private or public subnet of the server can be viewed with the command openstack subnet list;
   • <server_ip_address> — The IP address of the server from the specified subnet;
   • <port> — port number on the server;
   • <pool_name> — the name of the target group you created in step 2.

4. Optional: create an availability check for the target group:

   openstack loadbalancer healthmonitor create \
     --delay <delay> \
     --timeout <timeout> \
     --max-retries <max_retries> \
     --max-retries-down <max_retries_down> \
     --type <type> \
     --http-method <http_method> \
     --url-path <url_path> \
     --expected-codes <codes> \
     <pool_name>

   Specify:

   • <delay> — the interval between checks in seconds;

   • <timeout> — the maximum timeout time in seconds;

   • <max_retries> — number of successful requests in a row, after which the server is brought back online;

   • <max_retries_down> — number of unsuccessful requests in a row, after which the server is suspended;

   • <type> — validation type. The available types depend on the target protocol you specified in step 2:

     • for TCP protocol — type PING, TCP;
     • for UDP protocol — type UDP_CONNECT, PING;
     • for PROXY protocol — type TLS_HELLO, HTTP, PING, TCP;

   • HTTP request parameters, if you selected the HTTP validation type:

     • --http-method <http_method> — validation method: GET, POST, DELETE, PUT, HEAD, OPTIONS, PATCH, CONNECT, TRACE;
     • --url-path <url_path> — request path without domain name;
     • --expected-codes <codes> — expected response codes separated by commas;
     • <pool_name> — the name of the target group you created in step 2.

For HTTP or HTTPS traffic

1. Create a target group that will serve as the default group — traffic that does not fall under the HTTP policies in the rule will be directed there:

   openstack loadbalancer pool create \
     --name <pool_name> \
     --lb-algorithm <algorithm> \
     --protocol HTTP \
     --loadbalancer <loadbalancer>

   Specify:

   • <pool_name> — the name of the target group;
   • <algorithm> — name algorithm name: ROUND_ROBIN or LEAST_CONNECTIONS;
   • <loadbalancer> — The ID or name of the load balancer you previously created earlier. The list can be viewed with the command openstack loadbalancer list.

2. Add the server to the target group:

   openstack loadbalancer member create \
     --subnet-id <subnet_uuid> \
     --address <server_ip_address> \
     --protocol-port <port> \
     <pool_name>

   Specify:

   • <subnet_uuid> — The ID of the private or public subnet of the server can be viewed with the command openstack subnet list;
   • <server_ip_address> — The IP address of the server from the specified subnet;
   • <port> — port number on the server;
   • <pool_name> — the name of the target group you created in step 1.

3. Optional: create an availability check for the target group:

   openstack loadbalancer healthmonitor create \
     --delay <delay> \
     --timeout <timeout> \
     --max-retries <max_retries> \
     --max-retries-down <max_retries_down> \
     --type <type> \
     --http-method <http_method> \
     --url-path <url_path> \
     --expected-codes <codes> \
     <pool_name>

   Specify:

   • <delay> — the interval between checks in seconds;

   • <timeout> — the maximum timeout time in seconds;

   • <max_retries> — number of successful requests in a row, after which the server is brought back online;

   • <max_retries_down> — number of unsuccessful requests in a row, after which the server is suspended;

   • <type> — validation type: HTTP, PING, TCP;

   • HTTP request parameters, if you selected the HTTP validation type:

     • --http-method <http_method> — test method: GET, POST, DELETE, PUT, HEAD, OPTIONS, PATCH, CONNECT, TRACE;
     • --url-path <url_path> — request path without domain name;
     • --expected-codes <codes> — expected response codes separated by commas;
     • <pool_name> — the name of the target group you created in step 1.

4. Create a rule:

   openstack loadbalancer listener create \
     --name <listener_name> \
     --protocol <protocol> \
     --protocol-port <port> \
     [--allowed-cidr <allowed_cidr>]
     --default-tls-container=<certificate_uuid> \
     --default-pool <default_pool> \
     <loadbalancer>

   Specify:

   • <listener_name> — rule name;
   • <protocol> — protocol name protocol: HTTP or TERMINATED_HTTPS;
   • <port> — port number on the balancer;
   • --default-tls-container=<certificate_uuid> — ID of the TLS(SSL)-certificate for terminating HTTPS traffic on the balancer. Specify if you selected the protocol TERMINATED_HTTPS. Can be copied in control panel: in the top menu, click Products → Secrets Manager → tab Certificates → in the menu of the certificate, select Copy UUID. More about TLS(SSL)-based load balancer certificates;
   • <default_pool> -ID or the name of the default target group you created in step 1, the list can be viewed with the command openstack loadbalancer pool list;
   • optional: --allowed-cidr <allowed_cidr> — IP address from which it is allowed to receive traffic, where <allowed_cidr> — subnet in CIDR format or single IP address with mask /32. If you need to specify multiple addresses, specify each address in a separate --allowed-cidr parameter . For the restriction to work, port security must be enabled on the balancer network . You can specify the allowed IP addresses in the rule after the balancer is created.

5. Create an HTTP policy in the rule:

   openstack loadbalancer l7policy create \
     --action <action> \
     [--redirect-url <url> | --redirect-prefix <prefix_url> | --redirect-pool <pool> ]
     --position <position> \
     --name <policy_name> \
     <listener>

   Specify:

   • <action> — action to balance traffic:

     • REDIRECT_TO_URL — completely replace the request URL, including protocol, domain name, path, and parameters;
     • REDIRECT_PREFIX — replace the protocol and domain name in the request URL;
     • REDIRECT_TO_POOL — redirect to the target group;
     • REJECT — REJECT;

   • where the traffic needs to be directed:

     • --redirect-url <url> — The full URL for the redirect. Specify if the action is selected REDIRECT_TO_URL;
     • --redirect-prefix <prefix_url> — URL prefix to replace the protocol and domain in the request, e.g. https://example.com. Specify if the action is selected REDIRECT_PREFIX;
     • --redirect-pool <pool> — ID or name of the target group. Specify if the action is selected REDIRECT_TO_POOL. The list can be viewed with the command openstack loadbalancer pool list. If you don't already have a target group, create one;

   • --position <position> — position of the policy in the rule. Specify if there will be multiple policies with the same action in the rule, the policy with position 1 will be applied first;

   • <policy_name> — L7 policy name;

   • <listener> — The ID or name of the rule that you created in step 4. You can view the list with the command openstack loadbalancer listener list.

6. Create a condition in the HTTP policy:

   openstack loadbalancer l7rule create \
     --compare-type <compare_type> \
     --type <type> \
     --value <value> \
     <policy>

   Specify:

   • <compare_type> — type of match with the control value:

     • EQUAL TO — match;
     • STARTS WITH. — begins with;
     • ENDS WITH. — ends with;
     • CONTAINS — Contains;
     • REGEX — regular expression;

   • <type> — parameter in the query to check: HOST_NAME, PATH, COOKIE, FILE_TYPE, HEADER;

   • <value> — control value;

   • <policy> — The ID or name of the L7 policy that you created in step 5.

Terraform

Use the instructions in the Terraform documentation:

• Create a cloud-based load balancer;
• An example of building an infrastructure with a cloud load balancer.