OpenStack Octavia
This post analyzes OpenStack’s Octavia.
1. OpenStack Octavia
![[Figure 1] OpenStack Octavia Concept](/blog-software/docs/theory-analysis/openstack-octavia/images/octavia-concept.png)
[Figure 1] OpenStack Octavia Concept
Octavia is an OpenStack Service that provides LBaaS (Load Balancer as a Service). [Figure 1] shows the Concept of Octavia. A Load Balancer means one VIP (Virtual IP). A Listener means one Port. In [Figure 1], there is one Listener each in charge of Port A and Port B. A Pool means a set of Members, which are the Servers that become the destinations of Packets, and each Listener is mapped to a specific Pool. In [Figure 1], Listeners and Pools are mapped 1:1, but multiple Listeners can also share a single Pool. A Health Monitor is responsible for the Health Check of the Members in a Pool, and performs the role of preventing Packets from being load balanced to Members that fail the Health Check.
| |
These Concept Components of Octavia are managed as Octavia Resources. [Shell 1] shows the Shell that queries Octavia’s Resources using the openstack CLI. This Octavia Concept is identical to Neutron LBaaS V2, and Octavia also has the characteristic of supporting the Neutron LBaaS V2 API as is.
1.1. Architecture
![[Figure 2] OpenStack Octavia Architecture](/blog-software/docs/theory-analysis/openstack-octavia/images/octavia-architecture.png)
[Figure 2] OpenStack Octavia Architecture
[Figure 2] shows the Architecture of Octavia. The Octavia Service runs on the Controller Node, and Amphora, Octavia’s Load Balancer Instance, runs on the Compute Node. Amphora can be configured as a VM, PM, or Container. Communication between the Octavia Service and Amphora generally takes place through a dedicated Octavia Network created by the Provider.
When the Octavia Client requests LB creation from the API Controller of the Octavia Service, the API Controller creates an Amphora with the help of other OpenStack Services such as Nova and Neutron. When the Amphora creation is complete, the Controller Worker of the Octavia Service creates the HAProxy Config file through the Amphora’s Agent and starts HAProxy. The Health Check of Members is performed by HAProxy according to the Agent’s configuration. The Health status of Members collected by HAProxy is delivered to the Agent through a Unix Socket, and the Agent in turn delivers it to the Controller Worker.
The Controller Worker reflects the received Health status of Members in Octavia’s Member Resource. The Housekeeping Manager performs the role of completely removing deleted Resources from the Octavia DB and managing the Certificates of Amphora. Amphora operates as Standalone or as Active-Standby for HA. [Figure 1] shows Amphora operating in the Active-Standby form.
| |
[File 1] shows the Agent’s Config file. The HAProxy configuration, Health Manager configuration, and Amphora operation mode configuration can be found in it.
| |
HAProxy uses a dedicated HAProxy Network Namespace rather than the Amphora’s Network Namespace. [Shell 2] shows the Interface that holds the VIP in the HAProxy Network Namespace.
2. References
- OpenInfra Days Korea 2018 - Neutron LBaaS & Octavia : https://www.slideshare.net/openstack-kr/openinfra-days-korea-2018-track-2-neutron-lbaas-octavia
- Load Balancer as a Service (LBaaS) - OpenStack Docs : https://docs.openstack.org/mitaka/networking-guide/config-lbaas.html
- Introducing Octavia - OpenStack Docs : https://docs.openstack.org/octavia/queens/reference/introduction.html
- Octavia - Red Hat OpenStack Platform Networking Guide : https://access.redhat.com/documentation/en-us/red-hat-openstack-platform/13/html/networking-guide/sec-octavia