Placing Octavia Amphorae Across Neutron Availability Zones

Your OpenStack load balancer passes every pre-launch check, yet a single compute availability zone failure makes the VIP unreachable. The backend application instances are healthy in another zone, but Octavia’s amphorae—the virtual appliances that terminate client connections and forward traffic to pool members—all live on compute hosts in the failed zone. There is no standby to take over the VIP.

The practical takeaway is to schedule amphorae across Neutron availability zones before you create the load balancer, then prove active/standby failover with a controlled compute-host test. This post walks through placement, status checks, a failover drill, and the trade-offs you should accept before pointing production traffic at a multi-AZ Octavia deployment.

What an amphora is and where AZs fit in

An amphora is the Octavia load-balancer instance: a virtual machine that runs the proxy and health-checking services for a load balancer. Neutron availability zones group compute hosts, usually through host aggregates. When Octavia schedules amphorae, it places them on compute hosts in those zones. If every amphora for a load balancer sits in one zone, that zone becomes a single point of failure for the VIP even when pool members are spread elsewhere.

Active/standby failover means Octavia promotes a standby amphora to active and updates networking so the virtual IP (VIP) is reachable through the new amphora. Established TCP connections are typically not preserved; clients must reconnect or retry. Treat failover as a recovery mechanism, not a zero-drop connection migration.

Design before you create the load balancer

• Keep the VIP network, subnet, and pool members in the same availability zones as the amphorae where possible. This reduces cross-AZ traffic and failover latency.
• Do not stretch one Layer 2 network across availability zones just to keep a VIP stable. Asymmetric routing and traffic black holes can appear during an AZ failure.
• Plan for standby amphora capacity in each zone. Multi-AZ Octavia consumes extra compute, floating IP addresses, and amphora quota; one active replica is not enough.
• Use health monitors at the pool-member level and combine them with amphora AZ spread so a single zone failure does not remove the whole load balancer.

Worked example: create, verify placement, and drill failover

Run these commands from a workstation or controller with the OpenStack client installed and an RC file or clouds.yaml loaded. You need a role that can manage load balancers; amphora listing may require the Octavia client or OpenStackClient Octavia plugin. Replace placeholders in angle brackets with your own IDs.

1. Confirm compute availability zones

openstack availability zone list --compute

Expected output: a list of zones such as zone1 and zone2 mapped to compute hosts. If you see only one zone, multi-AZ amphora placement is not possible until your cloud operator adds hosts to another zone.

2. Create the load balancer and check core status

openstack loadbalancer create --name  --vip-subnet-id openstack loadbalancer show  -c provisioning_status -c operating_status -f value

Expected check: provisioning_status is ACTIVE and operating_status is ONLINE. If either is ERROR or DEGRADED, investigate before adding listeners or production traffic.

3. Verify amphorae are in different zones

openstack loadbalancer amphora list --loadbalancer  -c id -c compute_id -c availability_zone -c status

Expected check: at least two amphorae with different availability_zone values. If they share a zone, your scheduler did not spread them; check your deployment’s AZ hint support and Octavia release notes before relying on cross-AZ failover.

4. Run a controlled failover drill

Identify the compute host running the active amphora, then disable that compute service. This is state-changing: it can move or stop instances and will interrupt traffic through the active amphora.

openstack compute service list --host openstack compute service set --disable 

Wait for at least one health-monitor cycle. Then confirm:

• The standby amphora’s status moves to active/online.
• The VIP remains reachable from a client instance after the client retries or reconnects.
• openstack loadbalancer show still reports ACTIVE / ONLINE.

Restore the host when the drill ends:

openstack compute service set --enable 

Risk: established connections through the active amphora will drop. Measure successful reconnects, not zero packet loss.

5. Tune health monitors to your recovery goal

openstack loadbalancer healthmonitor create --delay 5 --timeout 3 --max-retries 2 --type HTTP 

Lower delay and max-retries detect failure faster but increase the chance of flapping a healthy member. Align these values with your application’s acceptable recovery time rather than assuming instant cutover.

Limitations and how to check the result

Multi-AZ Octavia is not free. You pay for extra amphorae, compute capacity, and floating IPs in each zone. Failover time depends on health-monitor delay, timeout, and retry counts, so a zone failure can still cause seconds to minutes of disruption. Security-group or allowed-address-pair misconfiguration on the VIP port can mimic an Octavia failure; verify port rules separately from load-balancer status.

Practical verification after any change:

1. Run openstack loadbalancer show and confirm ACTIVE and ONLINE.
2. Run the amphora list command and confirm zones differ.
3. From a client instance, curl the VIP before and after the failover drill; confirm the client can reconnect and receive a successful response.
4. Compare status values and AZ behavior against your installed OpenStack release notes, because CLI object names and scheduling behavior change between releases.

Closing

Do not wait for an availability-zone failure to discover that all your amphorae are in the same rack. Check amphora placement today, schedule a failover drill in staging, tune health monitors to your recovery objective, and only then direct production traffic to the load balancer.