Portal

Load Balancers

About load balancers

The cloud load balancer allows you to automatically distribute incoming traffic across multiple servers in order to maximize your application or website performance. Effectively, a load balancer is one of the tools that support horizontal application scaling.

Before going into the details of a load balancer configuration, let's review the roles of its key components.

Load balancer creation

While common parameters like name and description are self-explanatory, networking aspect of load balancers worth considering a bit more.

The subnet that you chose during a load balancer creation defines the network and pool of fixed IPs where the load balancer's IP (Virtual IP) will be created, and where the members (endpoints, typically instances) will be located. Note that for load balancers created via portal, subnet for both load balancer and its members will be the same (load balancers created via API or command line can have different subnets there).

Most commonly the load balancers will be accessible from the Internet. Thus, you will need to acquire and then assign a floating IP to a load balancer. Also, the chosen network must be connected to a router with external gateways (see Routers section for more details)

Listeners

A listener defines ports and protocols the load balancer will listen on. When a listener is configured, the load balancer will be ready to open TCP connections for the incoming requests for these ports.

Load balancer supports several listener's protocol:

  • TCP is the most generic one. The incoming connection will be forwarded to the members "as is", without any parsing of the content. Generally, any protocol working over TCP can be configured as TCP.
  • HTTP is a recommended protocol for web servers, at it will parse incoming requests and can ensure consistency of connections and data being sent.
  • HTTPS is a secure (encrypted) version of HTTP. In general, load balancers can support two types of HTTPS - terminated (that means, the load balancer will do decryption and must provide the SSL certificate to the clients), and non-terminated (that means that traffic will be forwarded without decryption to the members, and the members must provide SSL certificates). Terminated HTTPS requires integration of certificate storing service (Barbican), which is not yet a part of the platform functionality. As a result, only non-terminated HTTPS is supported, which is effectively almost the same as generic TCP.

Pools

Pools are containers for members for a specific listener, which also define algorithm of incoming traffic distributions. The following algorithms are supported:

  • Round robin equally rotates new incoming requests between members.
  • Least connections sends the next incoming request to the member with the least number of (currently) active connections.
  • Source IP takes the client (source) IP into consideration, sending incoming request from the same source IP to the same member.

Members

Members are the endpoints (typically instances) working behind the load balancer. Members are created per pool and specified by its IP address (note that this IP must be on the same subnet as the load balancer's own VIP)

The weight defines how many connections (proportionally) the member can receive. For example, a member with weight of 10 will receive twice as many connections as a member with weight of 5. The value must be between 0 and 256; a value of 0 means that the member will not receive any new connections (but will continue to serve existing ones, if any)

Health monitors

Health monitor is a mechanism that can be used to verify members health. If a member is not responding to the requests as expected, the load balancer will stop sending requests to that member, however will continue to monitor it, until it will become healthy again. If monitors are not enabled, members health is not checked - they are always assumed healthy (the status will be "NO MONITOR")

There are following parameters to manage health monitors:

  • Pool - the pool for which you create a health monitor.
  • Timeout - how long (in seconds) to wait for a member to respond to the health check request.
  • Delay defines frequency of the health checks. For example, to run a health check every minute, specify delay=60.
  • Max retries - how many times a health check must report success before member is marked "online", if previously the member was in error. The value must be between 1 and 10. You'd typically set it to 1, unless you are troubleshooting an intermittently failing member.
  • HTTP Method - a string - the method used by the health check function. One of the CONNECT, DELETE, GET, HEAD, OPTIONS, PATCH, POST, PUT, or TRACE. By default, GET is used.
  • URL Path - the URL to retrieve during the health check. / by default.
  • Expected codes - HTTP codes that indicate health check was succesful. Default value of 200 is used; it can be a single number (like 200), list (201, 201) or a range (200-202)

Note that parameter max_retries_down which controls how many times the member must fail health check to be considered unhealthy is currently can't be set via UI, and default value of "3" is used.

Creating and managing load balancers

To create a load balancer, follow the following steps:

  • Navigate to the "Load balancers" in the "Networking" section, and then click "Create new load balancer" button.
  • Enter name for the new load balancer, select subnet where load balancer and its members will be located, load balancer IP address, and if desired, a description. Then click "Create". Once the new load balancer goes from "PENDING_CREATE" to "ACTIVE" state, you can manage it - for that, click on "Manage" in the action menu of the load balancer.
  • Now, go to the "Listeners" page and configure a listener, specifying protocol and port to work on. You can configure multiple listeners if required, for example one for HTTP port 80 and one for HTTPS port 443.
  • Now, go to the next tab, and create pool for the previously created listener(s).
  • Now, go to the "Members" tab, and add members by adding their IP addresses to the previously created pool(s).

At this point, your load balancer will start working. However, to make sure that it only sends traffic to the healthy members, and automatically excludes those members that stop functioning properly, it is recommended to configure health monitors for the pools.