Create a load balancer

Last update: April 16 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 control panels from the top menu, press Products and select Cloud servers.

2. Go to the section Balancers → tab Balancers.

3. Click Create a balancer.

4. Select region and pool in which the balancer will be created.

5. Select configuration depending 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 have access to the balancer's logs If logging is not enabled, enable logging. Logging uses a portion of the balancer's computational resources.

   8.1 Check the checkbox Collect technical logs of the balancer.

   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 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 it has 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 on which you create the balancer must be prepared for connecting a public IP address.

12. Click Further.

2. Create a task force⁠

1. Open the tab Servers.

2. Optional: to change the name target group, press , enter a name and press .

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 Optionally, to direct traffic to a server only when other servers in the group are unavailable, check the checkbox Reserve.

7. Open the tab Algorithm.

8. Select query distribution algorithm — Round Robin or Least connections.

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

10. Open the tab Accessibility checks.

11. Select type accessibility checks. Once a group is created, the type of check cannot be changed.

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, tap Add a target group and set it up.

18. Click Further.

3. Create rules and HTTP policies⁠

1. Select protocol receiving traffic on the balancer — TCP, UDP, HTTP or HTTPS. Prometheus option is also available for customization 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 mask /32. 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 has been created.

   If the field is absent, the balancer network is turned off traffic filtering (port security).

4. Select a target group. Groups are available to which you can balance traffic on the selected one protocols receiving traffic.

5. Optional: expand unit Advanced rule settings 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, press Add rule and repeat steps 1-5. The number of rules is unlimited.

7. Check the total cost of the balancer.

8. Click Create a 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 have selected the HTTPS protocol, select a certificate to terminate HTTPS traffic on the balancer — select a certificate from the Secrets Manager or download a new one. Read more in the instructions TLS(SSL)-certificates of the load balancer.

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 mask /32. 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 has been created.

   If the field is absent, the balancer network is turned off traffic filtering (port security).

5. Optional: check mark HTTP request headers that will be transmitted to the servers.

6. Select the default target group — this is where traffic that does not fall under the HTTP policy.

7. Create HTTP Policies.

8. Optional: change connection settings To do this, open the block Advanced rule settings 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, press Add rule and repeat steps 1-8. The number of rules is unlimited.

10. Check the total cost of the balancer.

11. Click Create a balancer.

OpenStack CLI

1. Create a balancer.
2. Create a rule, HTTP policy, and 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 by load balancer type and determine the number of vCPUs, RAM, and the number of 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 flavors can be viewed using the command openstack loadbalancer flavor list -c id -c name or in a table List of load balancer flavorings in all pools;
   • <loadbalancer_name> — balancer's name.

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

   openstack loadbalancer show <loadbalancer>

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

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 ID of the balancer port 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 rule:

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

   Specify:

   • <listener_name> — NAME OF RULE;
   • <protocol> — title protocols: TCP or UDP;
   • <port> — port number on the balancer;
   • optional: --allowed-cidr <allowed_cidr> — The IP address from which traffic is allowed to be received, where <allowed_cidr> — subnet in CIDR format or single IP address with mask /32. If you want to specify several addresses, specify each address in a separate parameter --allowed-cidr. In order for the restriction to work, the balancer network must have the following enabled traffic filtering (port security). You can specify the allowed IP addresses in the rule after the balancer has been created;
   • <loadbalancer> — ID or name of the load balancer. You can view the list using the command openstack loadbalancer list.

2. Create target group:

   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> — title algorithm: ROUND_ROBIN or LEAST_CONNECTIONS;
   • <listener_name> — the name of the rule you created in step 1;
   • <protocol> — title protocols: 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 accessibility check for the task force:

   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 time to wait for a response in seconds;

   • <max_retries> — the number of successful consecutive requests 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 the record TCP — type PING, TCP;
     • for the record UDP — type UDP_CONNECT, PING;
     • for the record PROXY — type TLS_HELLO, HTTP, PING, TCP;

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

     • --http-method <http_method> — method of verification: GET, POST, DELETE, PUT, HEAD, OPTIONS, PATCH, CONNECT, TRACE;
     • --url-path <url_path> — query path without a 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 target group which will serve as the default group, where traffic that does not fall under the HTTP Policies in the rule:

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

   Specify:

   • <pool_name> — the name of the target group;
   • <algorithm> — title algorithm: ROUND_ROBIN or LEAST_CONNECTIONS;
   • <loadbalancer> — The ID or name of the balancer that you previously created 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 accessibility check for the task force:

   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 time to wait for a response in seconds;

   • <max_retries> — the number of successful consecutive requests 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> — type of verification: HTTP, PING, TCP;

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

     • --http-method <http_method> — method of verification: GET, POST, DELETE, PUT, HEAD, OPTIONS, PATCH, CONNECT, TRACE;
     • --url-path <url_path> — query path without a 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 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> — NAME OF RULE;
   • <protocol> — title protocols: HTTP or TERMINATED_HTTPS;
   • <port> — port number on the balancer;
   • --default-tls-container=<certificate_uuid> — ID of the TLS(SSL)-certificate for HTTPS traffic termination on the balancer. Specify if you selected the protocol TERMINATED_HTTPS. You can copy it into control panels: from the top menu, press Products → The manager of secrets → tab Certificates → in the menu of the certificate, select Copy UUID. Read more about TLS(SSL)-certificates of the load balancer;
   • <default_pool> — The ID or name of the default target group you created in step 1, the list can be viewed using the command openstack loadbalancer pool list;
   • optional: --allowed-cidr <allowed_cidr> — The IP address from which traffic is allowed to be received, where <allowed_cidr> — subnet in CIDR format or single IP address with mask /32. If you want to specify several addresses, specify each address in a separate parameter --allowed-cidr. In order for the restriction to work, the balancer network must have the following enabled traffic filtering (port security). You can specify the allowed IP addresses in the rule after the balancer has been created.

5. Create 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 — to target the target group;
     • REJECT — dismiss;

   • where the traffic needs to be directed:

     • --redirect-url <url> — the full URL to redirect to. 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 using the command openstack loadbalancer pool list. If you don't already have a target group, create it;

   • --position <position> — the position of the policy in the rule. Indicate if there will be more than one policy with the same action in the rule, the policy with position 1 will be the first to apply;

   • <policy_name> — L7-policy name;

   • <listener> — ID or name of the rule you created in step 4. You can view the list using 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 — is a match;
     • STARTS WITH — begins with;
     • ENDS WITH — ends in;
     • 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 you created in step 5.

Terraform

Use the instructions in the Terraform documentation:

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