Skip to content

Load Balancers

A load balancer distributes incoming network or application traffic across backend servers to ensure no single server becomes overwhelmed, optimizing resource use and improving response times. It also enhances reliability by rerouting traffic to available servers if one fails, ensuring continuous service availability.

The Load Balancer uses Listeners to receive and categorize incoming requests based on protocol and port. These requests are then directed to the appropriate Pool of backend servers (Pool Members). Each pool has a specific load balancing method and contains pool members that process the incoming requests. Health Monitors continually assess the health of the pool members, ensuring that only healthy members receive traffic.

Pool

In Octavia, a pool is a collection of backend servers (referred to as members) that the load balancer forwards traffic to. Each pool associates with a listener and uses a specific load balancing algorithm (for example, round robin, least connections) to determine how traffic gets distributed among members of the pool.

Pool Members

Pool members are the individual instances or servers within a pool that handle the application traffic. The load balancer identifies these members by their IP addresses and ports, then distributes incoming requests to them based on the algorithm specified in the pool.

Health Monitoring

Health monitors are used to check the health status of pool members. A health monitor regularly sends requests (such as ping, HTTP, or HTTPS requests) to each pool member to determine if they are responsive and performing correctly. If a pool member fails the health check, it is marked as “down” and is temporarily removed from the pool, ensuring that traffic goes to healthy servers.

Providers

The load balancer service (Octavia) is available with two provider types. The provider is selected when the load balancer is created and can not be changed afterwards.

  • Amphora (amphorav2): each load balancer is implemented as a virtual machine (amphora) running the load balancing software.
  • OVN (ovn): load balancers are implemented natively in the OVN software-defined network and distributed across all hypervisors. The OVN provider is currently in Early Access and only available in the regions DUS2, HAM1 and FES.

Features

Feature Amphora (amphorav2) OVN (ovn)
Implementation Virtual machine (amphora) running the load balancing software Native OVN load balancer, distributed across all hypervisors
Supported protocols TCP, HTTP, HTTPS, TERMINATED_HTTPS TCP
TLS termination Yes No
L7 policies Yes No
Health monitors HTTP, HTTPS, PING, TCP, TLS-HELLO TCP
Session persistence Yes Source IP only
Load balancing methods Source IP, Round Robin, Least Connections Source IP Port
PROXY protocol support Yes No (not needed because client IP will be handed to the backend)
Header insertion (X-Forwarded-For etc.) Yes No
High availability Active/backup amphorae Distributed across all hypervisors
Compute resources One virtual machine per load balancer No additional virtual machines
Provisioning time Higher (virtual machine provisioning) Lower

For a full feature comparison between amphorav2 and ovn use this page.

For the complete documentation of a provider type see

States

Every load balancer has two independent states. The provisioning status tells you which lifecycle operation (create, update or delete) is currently running on the load balancer. The operating status tells you whether the load balancer is actually able to distribute traffic to your servers right now. Together they let you distinguish between "a change is still in progress" and "the load balancer is (not) serving traffic".

Provisioning status

The provisioning status reflects the progress of an administrative operation you (or an automation) started on the load balancer. As long as the state is not ACTIVE, the load balancer is still processing a request, so its configuration may be in flux and changes can take a short while to take effect. You do not need to act on the transitional PENDING_* states — they clear on their own once the operation finishes. If the state becomes ERROR, the operation has failed and the change was not applied; check what went wrong and retry, or contact support.

ACTIVE The load balancer was provisioned successfully and is in a stable state. No create, update or delete operation is currently running.
PENDING_CREATE The load balancer is being created. The create operation has been initiated and has not finished yet.
PENDING_UPDATE The load balancer is being updated. A change to the load balancer is currently being applied.
PENDING_DELETE The load balancer is being deleted. The delete operation has been initiated and has not finished yet.
ERROR Provisioning failed. The load balancer could not be created, updated or deleted and entered an error state.

Operating status

The operating status reflects the runtime health of the load balancer and its resources. It is the most important indicator for whether your application is reachable: ONLINE means your traffic is being distributed as usual, DEGRADED means you still have service but with reduced capacity and redundancy because some backend members are unavailable, and OFFLINE means the load balancer can no longer forward traffic at all, so your service is interrupted. A load balancer can be ACTIVE (provisioning status) while at the same time DEGRADED or OFFLINE (operating status), because the two states track different things.

ONLINE All resources of the load balancer (listeners, pools and pool members) are up and running and traffic is distributed normally.
DEGRADED One or more pool members are down, but the load balancer is still providing service by distributing traffic to the remaining healthy members.
OFFLINE One or more critical resources are down and the load balancer is no longer providing service.