Octavia is currently missing any documentation designed to help new developers and operators understand what we're doing with the project or how to get started using and contributing to it. This patch set aims to correct this problem. Co-Authored-By: Michael Johnson <johnsomor@gmail.com> Co-Authored-By: Leslie Lundquist <llundquist@us.ibm.com> Closes-Bug: #1558368 Change-Id: Idaa37277bd342b644a463d4a0884ea40c2e8d4f5
7.4 KiB
Introducing Octavia
Welcome to Octavia!
Octavia is an open source, operator-scale load balancing solution designed to work with OpenStack.
Octavia was borne out of the Neutron LBaaS project. Its conception influenced the transformation of the Neutron LBaaS project, as Neutron LBaaS moved from version 1 to version 2. Starting with the Liberty release of OpenStack, Octavia has become the reference implementation for Neutron LBaaS version 2.
Octavia accomplishes its delivery of load balancing services by managing a fleet of virtual machines, containers, or bare metal servers—collectively known as amphorae— which it spins up on demand. This on-demand, horizontal scaling feature differentiates Octavia from other load balancing solutions, thereby making Octavia truly suited "for the cloud."
Where Octavia fits into the OpenStack ecosystem
Load balancing is essential for enabling simple or automatic delivery scaling and availability. In turn, application delivery scaling and availability must be considered vital features of any cloud. Together, these facts imply that load balancing is a vital feature of any cloud.
Therefore, we consider Octavia to be as essential as Nova, Neutron, Glance or any other "core" project that enables the essential features of a modern OpenStack cloud.
In accomplishing its role, Octavia makes use of other OpenStack projects:
- Nova - For managing amphora lifecycle and spinning up compute resources on demand.
- Neutron - For network connectivity between amphorae, tenant environments, and external networks.
- Barbican - For managing TLS certificates and credentials, when TLS session termination is configured on the amphorae.
- Keystone - For authentication against the Octavia API, and for Octavia to authenticate with other OpenStack projects.
- Glance - For storing the amphora virtual machine image.
- Oslo - For communication between Octavia controller components, making Octavia work within the standard OpenStack framework and review system, and project code structure.
- Taskflow - Is technically part of Oslo; however, Octavia makes extensive use of this job flow system when orchestrating back-end service configuration and management.
Octavia is designed to interact with the components listed previously. In each case, we’ve taken care to define this interaction through a driver interface. That way, external components can be swapped out with functionally-equivalent replacements— without having to restructure major components of Octavia. For example, if you use an SDN solution other than Neutron in your environment, it should be possible for you to write an Octavia networking driver for your SDN environment, which can be a drop-in replacement for the standard Neutron networking driver in Octavia.
It is important for you to know that Octavia is not necessarily designed as a complete replacement for the Neutron LBaaS project. That is to say, Octavia is designed to "plug in" to Neutron LBaaS in the same way that any proprietary vendor solution would: through a Neutron LBaaS version 2 driver interface. You could think of Octavia as an "open source vendor" for Neutron LBaaS, rather than as a substitute for Neutron LBaaS. For this reason, we recommend that tenants configure load balancing services with Octavia through the Neutron LBaaS version 2 CLI and API.
Soon, Octavia will supplant Neutron LBaaS as the load balancing solution for OpenStack. At that time, third-party vendor drivers that presently "plug in" to Neutron LBaaS will plug in to Octavia instead. For end-users, this transition should be relatively seamless, because Octavia supports the Neutron LBaaS v2 API and it has a similar CLI interface.
Octavia terminology
Before you proceed further in this introduction, please note:
Experience shows that—within the subsegment of the IT industry that
creates, deploys, and uses load balancing devices or services—
terminology is often used inconsistently. To reduce confusion, the
Octavia team has created a glossary of terms as they are defined and
used within the context of the Octavia project and Neutron LBaaS version
2. This glossary is available here: glossary
If you are familiar with Neutron LBaaS version 1 terms and usage, it is especially important for you to understand how the meanings of the terms “VIP," "load balancer," and "load balancing," have changed in Neutron LBaaS version 2.
Our use of these terms should remain consistent with the glossary
throughout Octavia's
documentation, in discussions held by Octavia team members on public
mailing lists, in IRC channels, and at conferences. To avoid
misunderstandings, it's a good idea to familiarize yourself with these
glossary definitions.
A 10,000-foot overview of Octavia components
Octavia version 0.9 consists of the following major components:
- amphorae - Amphorae are the individual virtual machines, containers, or bare metal servers that accomplish the delivery of load balancing services to tenant application environments. In Octavia version 0.8, the reference implementation of the amphorae image is an Ubuntu virtual machine running HAProxy.
- controller - The Controller is the "brains" of
Octavia. It consists of four sub-components, which are individual
daemons. They can be run on separate back-end infrastructure if desired:
- API Controller - As the name implies, this subcomponent runs Octavia's API. It takes API requests, performs simple sanitizing on them, and ships them off to the controller worker over the Oslo messaging bus.
- Controller Worker - This subcomponent takes sanitized API commands from the API controller and performs the actions necessary to fulfill the API request.
- Health Manager - This subcomponent monitors individual amphorae to ensure they are up and running, and otherwise healthy. It also handles failover events if amphorae fail unexpectedly.
- Housekeeping Manager - This subcomponent cleans up stale (deleted) database records, manages the spares pool, and manages amphora certificate rotation.
- network - Octavia cannot accomplish what it does without manipulating the network environment. Amphorae are spun up with a network interface on the "load balancer network," and they may also plug directly into tenant networks to reach back-end pool members, depending on how any given load balancing service is deployed by the tenant.
For a more complete description of Octavia's components, please see
the ../design/version0.5/component-design
document within
this documentation repository.