Chapter 2. Considerations for implementing the Load-balancing service

The Red Hat OpenStack Services on OpenShift (RHOSO) Load-balancing service (octavia) supports enabling multiple provider drivers by using the Octavia v2 API. You can choose to use one provider driver, or multiple provider drivers simultaneously.

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.

The Red Hat OpenStack Services on OpenShift (RHOSO) Load-balancing service (octavia) provides two load-balancing providers, amphora and Open Virtual Network (OVN).

Amphora is a full-featured load-balancing provider that requires a separate haproxy VM and an extra latency hop.

OVN runs on every node and does not require a separate VM nor an extra hop. However, OVN has far fewer load-balancing features than amphora.

The following table lists features in the Load-balancing service that 18.0 supports and in which maintenance release support for the feature began.

The Red Hat OpenStack Services on OpenShift (RHOSO) Load-balancing service (octavia) requires that you configure the following core OpenStack components:

If the controller service abruptly shuts down during creation, modification, deletion, or failover of an amphora load balancer, the 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). For more information, see the optional steps in Deploying the Load-balancing service.

When you deploy the Red Hat OpenStack Services on OpenShift (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.