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. Important The information in this section applies only to the amphora load-balancing provider, unless indicated otherwise. Additional resources Section 2.2, "Load-balancing service (octavia) feature support matrix" 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 octavia that Red Hat OpenStack Platform (RHOSP) 16.2 supports and in which maintenance release support for the feature began. Note If the feature is not listed, then RHOSP 16.2 does not support the feature. Table 2.1. Load-balancing service (octavia) feature support matrix Feature Support level in RHOSP 16.2 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 Technology Preview only 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 Section 2.1, "Load-balancing service provider drivers" 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. Important 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 Section 4.2, "Enabling active-standby topology for Load-balancing service instances" 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: 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. Note Custom amphora images are not supported. Additional resources Section 4.1, "Deploying the Load-balancing service"

Commands:
sudo dnf install octavia-amphora-image-x86_64.noarch