Learn OpenStack - Octavia (Load Balancer as a Service / LBaaS)

#Introduction

A single instance serving all traffic is a single point of failure — and a scalability ceiling. When your application starts getting busy, the answer isn't a bigger instance, but more instances behind a single front door. That front door, which distributes traffic, is a load balancer, and in OpenStack it's provided by Octavia.

Episode 13 covers Octavia from concept to complete configuration: what load balancing is and why it matters, the VM-based Amphora architecture, and the practice of creating load balancers, listeners, pools, members, and health monitors with selectable algorithms.

#The Load Balancer Concept in OpenStack

#Distributing Traffic Automatically

A load balancer receives traffic from users, then automatically distributes it to several backends (instances). Its two main benefits: scalability — adding instances means adding capacity — and resilience — if one backend dies, traffic is redirected to other healthy backends.

Client → Load Balancer (public floating IP)
                   ↓
         Instance A ← health monitor
         Instance B ← health monitor
         Instance C ← health monitor

The mechanism that keeps backends healthy is the health monitor — periodic checks that remove backends that fail to respond.

#Octavia Object Hierarchy

Octavia organizes configuration in a standard hierarchy:

• Load Balancer: the main unit with a virtual IP.
• Listener: the port/protocol it listens on, e.g. HTTP/80.
• Pool: the collection of backends receiving traffic.
• Member: an instance inside the pool.
• Health Monitor: the pool's health checks.

All these objects are created in order — understand the hierarchy and configuration becomes easy.

#Octavia Architecture

#Amphora: The Load Balancer VM

Octavia implements each load balancer as an Amphora — a dedicated VM instance running load-balancing software (HAProxy). Every load balancer you create means one Amphora VM that Octavia spawns, configures, and manages automatically.

openstack loadbalancer list
openstack loadbalancer amphora list

The output of openstack loadbalancer amphora list shows the Amphora VMs supporting your load balancers. Because an Amphora is a VM, its failover is automatic — if one amphora fails, Octavia creates a replacement.

#Control Plane Architecture

Octavia consists of a controller handling the API and API workers, plus amphorae handling the data plane. The controller translates APIs into configuration, workers write the configuration to amphorae via ssh, and traffic then flows through the amphora without involving the controller. This separation keeps the data plane fast even when the control plane is busy.

#Configuring Octavia LBaaS

#Creating a Load Balancer and Listener

openstack loadbalancer create --name lb-web --vip-subnet-id subnet-aplikasi
openstack loadbalancer listener create --protocol HTTP --protocol-port 80 lb-web
openstack loadbalancer list -c name -c provisioning_status

openstack loadbalancer create requires a subnet for the VIP (virtual IP). Provisioning takes time because Octavia must create an Amphora VM — wait until provisioning_status becomes ACTIVE before continuing.

#Creating a Pool and Members

openstack loadbalancer pool create --name pool-web --protocol HTTP \
  --lb-algorithm ROUND_ROBIN --listener web-listener
openstack loadbalancer member create --address 192.168.100.50 \
  --protocol-port 80 pool-web
openstack loadbalancer member create --address 192.168.100.51 \
  --protocol-port 80 pool-web

The openstack loadbalancer member create command adds two backend instances to the pool. Algorithm choices:

--lb-algorithm ROUND_ROBIN distributes requests in rotation — suitable for uniform workloads. For long-lived connections, LEAST_CONNECTIONS is wiser.

#Creating a Health Monitor

Without a health monitor, the load balancer keeps sending traffic to dead backends. Add one:

openstack loadbalancer healthmonitor create --delay 5 --timeout 4 \
  --max-retries 3 --type HTTP --url-path /health pool-web

openstack loadbalancer healthmonitor create checks /health every 5 seconds; after 3 consecutive failures, the member is removed from the pool until healthy again. This pattern is mandatory in production — without a health monitor, the LB just spreads failures around.

#Connecting a Floating IP to the Load Balancer

For public access, associate a floating IP with the load balancer's VIP:

openstack floating ip create public
openstack loadbalancer set --name lb-web
openstack floating ip set <ip-id> --port lb-web-vip-port

After openstack floating ip set, users can reach the application through the floating IP, and traffic is distributed to both members with automatic health checks.

#Summary

Episode 13 gives you production-grade load balancing skills: understanding the load balancer's role in scalability and resilience, the VM-based Amphora architecture managed by Octavia, and the complete configuration of load balancers, listeners, pools, members, and health monitors with round-robin, least-connections, and source-IP algorithms.

Key takeaways:

• A load balancer distributes traffic and removes failed backends.
• Octavia uses Amphora VMs that are spawned and managed automatically.
• Hierarchy: load balancer → listener → pool → member.
• A health monitor is mandatory so dead backends are removed automatically.
• Algorithms: round robin, least connections, source IP.
• A floating IP on the VIP opens the load balancer to the public.

In episode 14, we'll cover Production Deployment with Kolla-Ansible — why DevStack isn't suitable for production, an introduction to Kolla-Ansible, which packages every service into Docker and orchestrates it with Ansible, the all-in-one versus multi-node topologies, and the deployment process from globals.yml and inventory to kolla-ansible deploy.