OpenStack Octavia load balancing implementation

The core of an Octavia deployment is a chain of calls that starts with a tenant and ends with a running load balancer. When a tenant creates a load balancer through the Octavia API, the Octavia controller does not forward traffic itself. It asks Nova to boot a dedicated virtual machine called an amphora, using an image registered in Glance and a flavor defined by the operator. Neutron then attaches that amphora to the networks it needs: one path for tenant traffic to the back-end members, and one management path that the controller uses to reach the amphora's API. Once the amphora is up, the controller pushes configuration to it and keeps watching its health. Each of these steps depends on a different OpenStack service, so a failure in any one of them looks like a load balancer that never becomes active.

The amphora image and the flavor are operator-managed resources. Tenants do not choose them through the normal self-service path, and the operator decides which image version, disk size and memory each amphora receives. This matters for capacity planning because the flavor sets how many amphorae a compute host can carry and how much headroom remains for tenant workloads. It also matters for upgrades, since a new amphora image version changes the software on every load balancer that is rebuilt or failed over. Ask your team who owns the image build, how new versions are tested before they are published to Glance, and which flavor is referenced in the Octavia configuration for each availability zone you plan to use.

The management network path is the most common source of failures we see in these deployments. The controller must reach the amphora's management address, and the amphora must reach the controller's health and statistics endpoints. Typical problems include a management subnet that is not routed to the controller network, security group rules that allow the wrong port or direction, DHCP that does not hand out an address on the management network, and a firewall between the control plane and the compute nodes. Plan this network before the first load balancer is created, and test it by booting a test amphora and confirming that the controller can reach it and receive heartbeats from it.

Confirm the exact boot and networking flow for your release before you write runbooks or capacity models. Check the Octavia documentation for your OpenStack version, including how the amphora is requested from Nova, which Neutron networks are passed at creation, and whether your deployment tool configures the management network in the same way. Also confirm which Glance image properties the amphora driver expects and how your release handles image tags and flavors across availability zones. The steps described here are general; the parameters, defaults and resource names in your environment are the ones that govern real behavior, so record them in your design document and validate them in a non-production cloud first.

TLS termination in Octavia depends on keeping certificate material out of the load balancer configuration and in Barbican, where it is stored as a secret. A TLS listener holds a reference to that secret, not the certificate or private key itself. Before building the listener, the team should decide how the certificate, its private key and any intermediate chain will be packaged for Barbican, and confirm with the vendor documentation for their release which certificate and secret formats the TLS container accepts. Octavia's service account reads the referenced material when it configures the listener on the amphora, so the reference must resolve before the listener is created or updated.

Issuance and renewal ownership should be assigned in writing before the first listener goes live. The choice of certificate authority sets most of the renewal workload. An internal certificate authority gives the platform team control over lifetimes and automation, but the team must run the issuance and renewal pipeline itself. A corporate PKI shifts issuance to a security or infrastructure group, so the handoff for each renewal must be defined, including who places the new material into Barbican. A public CA reduces internal key management work but makes renewal dependent on the CA's tooling, billing and validation steps. Ask the certificate owner to document the renewal calendar, the approver and the notification path for each listener.

Renewal is more than issuing a new certificate. The team needs a procedure for storing the renewed material in Barbican, pointing the listener at the new reference, and confirming that the amphora serves the new certificate without dropping established connections. Confirm in your release whether a listener can be updated in place to reference a new secret, or whether recreation is required, because that changes the outage risk. Keep the previous secret available until the new listener is verified, and test the rollback path in a non-production environment. Add certificate expiry to your monitoring so that an approaching renewal is visible to the owner well before it becomes urgent.

Access policy determines which projects can read the secret references and the underlying material. Barbican secrets should be owned by the project that operates the load balancer, and read access should be granted only to the Octavia service account and to named operators with a documented need. Tenant projects should not be able to read the secret that terminates another tenant's TLS traffic. Use Keystone project and role scoping to limit who can create or read secrets, and verify the policy with a test identity from each project that should be excluded. Review secret access logs as part of routine operations, and treat any unexpected read of a private key as an incident.

The Barbican deep dive, including secret store back ends and the full access policy model, is covered in a separate module, so this section stays focused on the Octavia listener workflow. Before you commit to a design, confirm the supported certificate and secret formats for your OpenStack release, the expected behavior when a listener's secret reference changes, and how your chosen certificate authority integrates with your renewal process. Ask the implementation partner to document each of these confirmations in the design record, along with the named owner for issuance, storage, renewal and access review.

Every Octavia load balancer draws on the rest of the cloud, so capacity planning starts from its dependencies rather than from the load balancer itself. Each load balancer runs as one or more amphora, which are Nova compute instances built from an image stored in Glance. Each amphora needs a port on the tenant network where client traffic arrives and a port on the management network where the Octavia controllers reach it. Each one also needs an IP address on each network. Before you size anything, write down which networks carry this traffic, which Nova flavor the amphorae use, and which Glance image they boot from, because every later number depends on those three choices.

Demand multiplies quickly. Topology is the first multiplier: an active-standby load balancer runs two amphorae where a single-amphora load balancer runs one, so compute, ports and addresses roughly double for that listener set. The flavor is the second: a larger amphora flavor reserves more vCPU, memory and disk per instance on the hypervisors that host it. The third is the number of load balancers itself, which multiplies both. Build a table in your capacity plan with one row per load balancer class, listing the flavor, topology, expected amphora count, ports on each network and the Nova resources each amphora consumes. Then total the table against your Nova quotas for the project and domain, your Neutron quotas for ports and floating IPs, and the free capacity on the hypervisors that will host the amphorae.

Quotas and hypervisor capacity usually limit growth before the load balancer software does. A project can hit its Nova instance, core or RAM quota, or its Neutron port quota, while the cloud still has idle capacity elsewhere. Confirm the quota values with your cloud operators and decide whether amphorae live in a dedicated project with their own quota, since that separates load balancer growth from tenant growth. Also confirm how much headroom the hypervisor pool keeps for failover, because a host failure moves amphorae to other hosts and needs room there. Ask the operators to show you the scheduler behavior for the amphora flavor, including any host aggregates or anti-affinity rules you plan to use for active-standby pairs.

Storage affects two things: how fast a new amphora starts and how quickly you can replace a failed one. If Glance stores images on Ceph, image delivery to a hypervisor depends on the Ceph cluster's read performance and on the network path between them, and a Nova boot waits on that transfer. If Glance uses a different backend, measure the same path with that backend. Ceph can also back Nova guest disks, which lets amphorae boot from Ceph rather than from local hypervisor storage, but that choice moves the boot path onto the storage network and adds a dependency on Ceph availability during failover. Record the boot time you observe in a test and use it as the basis for your failover expectations rather than assuming it.

Validate every number with your own load tests before you commit hardware or quota. Run a representative amphora flavor, topology and listener mix, measure throughput, connection rate and CPU use on the amphora, and then trigger an amphora failover to time the replacement, including image fetch and boot. Repeat the test with the number of load balancers you expect at peak. The results give you the sizing inputs this page does not provide. Keep the capacity plan, the quota table and the test results together so that an upgrade of the amphora image, a new flavor or a change in Ceph configuration starts from a recorded baseline.