Chapter 2. Considerations for implementing the Load-balancing service
You must make several decisions when you plan to deploy the Red Hat OpenStack Platform (RHOSP) Load-balancing service (octavia) such as choosing which provider to use or whether to implement a highly available environment:
- Section 2.1, “Load-balancing service provider drivers”
- Section 2.2, “Load-balancing service (octavia) feature support matrix”
- Section 2.3, “Load-balancing service software requirements”
- Section 2.4, “Load-balancing service prerequisites for the undercloud”
- Section 2.5, “Basics of active-standby topology for Load-balancing service instances”
- Section 2.6, “Post-deployment steps for the Load-balancing service”
2.1. Load-balancing service provider drivers
The Red Hat OpenStack Platform (RHOSP) 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.
RHOSP 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.
On RHOSP deployments that use the neutron Modular Layer 2 plug-in with the OVN mechanism driver (ML2/OVN), RHOSP director automatically enables the OVN provider driver in the Load-balancing service without the need for additional installation or configuration.
The information in this section applies only to the amphora load-balancing provider, unless indicated otherwise.
Additional resources
2.2. Load-balancing service (octavia) feature support matrix
The Red Hat OpenStack Platform (RHOSP) 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 Red Hat OpenStack Platform (RHOSP) 16.1 supports and in which maintenance release support for the feature began.
If the feature is not listed, then RHOSP 16.1 does not support the feature.
Table 2.1. Load-balancing service (octavia) feature support matrix
| Feature | Support level in RHOSP 16.1 | |
| Amphora Provider | OVN Provider | |
| ML2/OVS L3 HA | Full support | No support |
| ML2/OVS DVR | Full support | No support |
| ML2/OVS L3 HA + composable network node [1] | Full support | No support |
| ML2/OVS DVR + composable network node [1] | Full support | No support |
| ML2/OVN L3 HA | Full support | Full support |
| ML2/OVN DVR | Full support | Full support |
| DPDK | No support | No support |
| SR-IOV | No support | No support |
| Health monitors | Full support | No support |
| Amphora active-standby | Full support—16.1 and later | No support |
| Terminated HTTPS load balancers (with barbican) | Full support—16.0.1 and later | No support |
| Amphora spare pool | No support | |
| UDP | Full support—16.1 and later | Full support |
| Backup members | Technology Preview only | No support |
| Provider framework | Technology Preview only | No support |
| TLS client authentication | Technology Preview only | No support |
| TLS back end encryption | Technology Preview only | No support |
| Octavia flavors | Full support | No support |
| Object tags - API only | Full support—16.1 and later | No support |
| Listener API timeouts | Full support | No support |
| Log offloading | Full support—16.1.2 and later | No support |
| VIP access control list | Full support | No support |
| Volume-based amphora | No support | No support |
[1] Network node with OVS, metadata, DHCP, L3, and Octavia (worker, health monitor, and housekeeping).
Additional resources
2.3. Load-balancing service software requirements
The Red Hat OpenStack Platform (RHOSP) Load-balancing service (octavia) requires that you configure the following core OpenStack components:
- Compute (nova)
- OpenStack Networking (neutron)
- Image (glance)
- Identity (keystone)
- RabbitMQ
- MySQL
2.4. Load-balancing service prerequisites for the undercloud
The Red Hat OpenStack Platform (RHOSP) Load-balancing service (octavia) has the following requirements for the RHOSP undercloud:
- A successful undercloud installation.
- The Load-balancing service present on the undercloud.
- A container-based overcloud deployment plan.
- Load-balancing service components configured on your Controller nodes.
If you want to enable the Load-balancing service on an existing overcloud deployment, you must prepare the undercloud. Failure to do so results in the overcloud installation being reported as successful yet without the Load-balancing service running. To prepare the undercloud, see the Transitioning to Containerized Services guide.
2.5. Basics of active-standby topology for Load-balancing service instances
When you deploy the Red Hat OpenStack Platform (RHOSP) 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 RHOSP 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 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.
Additional resources
2.6. Post-deployment steps for the Load-balancing service
Red Hat OpenStack Platform (RHOSP) provides a workflow task to simplify the post-deployment steps for the Load-balancing service (octavia). This workflow runs a set of Ansible playbooks to provide the following post-deployment steps as the last phase of the overcloud deployment:
- Configure certificates and keys.
- Configure the load-balancing management network between the amphorae and the Load-balancing service Controller worker and health manager.
Amphora image
On pre-provisioned servers, you must install the amphora image on the undercloud before you deploy the Load-balancing service:
$ sudo dnf install octavia-amphora-image-x86_64.noarch
On servers that are not pre-provisioned, RHOSP director automatically downloads the default amphora image, uploads it to the overcloud Image service (glance), and then configures the Load-balancing service to use this amphora image. During a stack update or upgrade, director updates this image to the latest amphora image.
Custom amphora images are not supported.
Additional resources
