Choose between amphora and OVN provider drivers to match your load balancing requirements for feature richness or lightweight performance.

RHOSO provides two load-balancing providers, amphora and Open Virtual Network (OVN).

Amphora, the default, is a highly available load balancer with a feature set that scales with your compute environment. Because of this, amphora is suited for large-scale deployments.

The OVN load-balancing provider is a lightweight load balancer with a basic feature set. OVN is typical for east-west, layer 4 network traffic. OVN provisions quickly and consumes fewer resources than a full-featured load-balancing provider such as amphora.

Prevent load balancer operations from stalling indefinitely by configuring flow resumption to automatically reassign tasks when controllers fail.

If the controller service abruptly shuts down during creation, modification, deletion, or failover of an amphora load balancer, TaskFlow is interrupted and the instance remains in a PENDING_* state indefinitely.

You can avoid these situations by configuring the Load-balancing service (octavia) to use flow resumption, also known as TaskFlow JobBoard.

When flow resumption is configured, the Load-balancing service automatically re-assigns the flow to an alternate controller if the original controller shuts down unexpectedly.

You configure flow resumption by modifying the OpenStackControlPlane custom resource (CR).

Configure active-standby topology to achieve high availability for load balancers with automatic failover and health management.

When you deploy the RHOSO Load-balancing service (octavia), you can decide whether, by default, load balancers are highly available when users create them.

If you want to give users a choice, then after RHOSO deployment, create a Load-balancing service flavor for creating highly available load balancers and a flavor for creating standalone load balancers.

By default, the amphora provider driver is configured for a single Load-balancing service (amphora) instance topology with limited support for high availability (HA). However, you can make Load-balancing service instances highly available when you implement an active-standby topology.

In this topology, the Load-balancing service boots an active and standby amphora instance for each load balancer, and maintains session persistence between each. If the active instance becomes unhealthy, the instance automatically fails over to the standby instance, making it active. The Load-balancing service health manager automatically rebuilds an instance that fails.