Skip to content

Latest commit

 

History

History
162 lines (97 loc) · 5.59 KB

octavia.rst

File metadata and controls

162 lines (97 loc) · 5.59 KB

Octavia

Introduction to Octavia

Octavia is known as an operator-scaled load balancing service, whose primary goal is to distribute incoming network traffic, destined for a single VM, across multiple VMs instead; thus preventing overloading the VM and improving the overall performance of the VM's outbound service.

For more information on Octavia, please refer to the official documentation.

Deploying Octavia

Much like any other Kolla managed service, the method of deploying Octavia is as simple as:

  1. Enabling kolla_enable_octavia: true within the chosen environment's kolla.yml.

  2. Check octavia_net_interface is configured in ${KAYOBE_CONFIG_PATH}/inventory/group_vars/ (often in controllers/network-interfaces.yml).

    • IF NOT CONFIGURED

      2.1. Check if a bond_interface has been configured, still within network-interfaces.yml.

      2.2. Check whether other network interfaces, such as internal_interface, are configured to use {{ bond_interface }} and/or {{ .._vlan }}.

      2.3. If they are, then octavia_net_interface: "{{ brbond0_interface }}.{{ octavia_net ± _vlan }}".

    • IF CONFIGURED

      2.1. Continue to step 3.

  3. Check that the {{ .._net_.. }} network configured for octavia_net_interface exists in networks.yml.

    • IF NOT CONFIGURED

      3.1. Set octavia_net_name: octavia_net.

      3.2. Configure the Octavia network IP information, making sure to set octavia_net_vlan if using a VLAN.

    • IF CONFIGURED

      3.1. Continue to step 4.

  4. Dependencies if:

    • USING VLAN

      4.1. Set kolla_enable_neutron_provider_networks: true in kolla.yml.

    • USING AMPHORA

      4.1. Set octavia_loadbalancer_topology: "ACTIVE_STANDBY" in ${KAYOBE_CONFIG_PATH}/kolla/globals.yml.

  5. Run kayobe overcloud service configure.

By default Octavia will deploy an Amphora (a single Ubuntu VM running HAProxy) per load balancing service. Consequently, if using Amphora, this default behaviour should be changed to make them highly available so that there are two Amphora VMs per service. Achieved by step 4.2 above, this will ensure that if the master Amphora VM were to go down, the other would be able to take over the load balancing functions.

Further configuration options and details on installation can be found in the Octavia documentation.

Building and rotating amphora images

StackHPC kayobe config contains utility playbooks to build and rotate the amphora images. With your kayobe environment activated, you can build a new amphora image with:

kayobe playbook run ${KAYOBE_CONFIG_PATH}/ansible/octavia-amphora-image-build.yml

The resultant image is based on Ubuntu. By default the image will be built on the seed, but it is possible to change the group in the ansible inventory using the amphora_builder_group variable.

To rotate the image, first activate an openrc file containing the credentials for the octavia service account, e.g:

. $KOLLA_CONFIG_PATH/octavia-openrc.sh

You can then run the playbook to upload the image:

kayobe playbook run ${KAYOBE_CONFIG_PATH}/ansible/octavia-amphora-image-register.yml

This will rename the old image by adding a timestamp suffix, before uploading a new image with the name, amphora-x64-haproxy. Octavia should be configured to discover the image by tag using the amp_image_tag config option. The images are tagged with amphora to match the kolla-ansible default for octavia_amp_image_tag. This prevents you needing to reconfigure octavia when building new images.

To rollback an image update, simply delete the old image. The next newest image with a tag matching amp_image_tag will be selected.

Manually deleting broken load balancers

Sometimes, a load balancer will get stuck in a broken state of PENDING_CREATE or PENDING_UPDATE. When in this state, the load balancer cannot be deleted; you will see the error Invalid state PENDING_CREATE of loadbalancer resource. To delete a load balancer in this state, you will need to manually update its provisioning status in the database.

Find the database password:

ansible-vault view --vault-password-file <path-to-vault-pw> $KOLLA_CONFIG_PATH/passwords.yml

# Search for database_password with:
/^database

Access the database from a controller:

docker exec -it mariadb bash
mysql -u root -p  octavia
# Enter the database password when prompted.

List the load balancers to find the ID of the broken one(s):

SELECT * FROM load_balancer;

Set the provisioning status to ERROR for any broken load balancer:

UPDATE load_balancer SET provisioning_status='ERROR' WHERE id='<id>';

Delete the load balancer from the OpenStack CLI, cascading if any stray Amphorae are hanging around:

openstack loadbalancer delete <id> --cascade

Sometimes, Amphora may also fail to delete if they are stuck in state BOOTING. These can be resolved entirely from the OpenStack CLI:

openstack loadbalancer amphora configure <amphora-id>
openstack loadbalancer amphora delete <amphora-id>