Spec: Octavia
The Octavia service provides scalable, resilient load balancers that are deployed into virtual machines in the OpenStack data plane. This spec proposes work to create a new Octavia role. Change-Id: I4c4462c885b62a53a9a9ee1e1ae54edf2266ab5a
This commit is contained in:
Major Hayden
parent
ff628380f8
commit
03211ed1fb
|
|
@ -0,0 +1,161 @@
|
|||
Octavia
|
||||
#######
|
||||
:date: 2016-11-01 00:00:00
|
||||
:tags: lbaas, octavia, load balancer, neutron
|
||||
|
||||
Blueprint: Deploy Octavia (LBaaS) with OpenStack-Ansible
|
||||
Link: https://blueprints.launchpad.net/openstack-ansible/+spec/octavia
|
||||
|
||||
The `Octavia <https://wiki.openstack.org/wiki/Octavia>`_ project deploys load
|
||||
balancers that are more scalable and resilient than the original neutron-lbaas
|
||||
agent-based load balancers. Octavia has a few daemons that handle the build-
|
||||
out, configuration, and tear-down of load balancers.
|
||||
|
||||
Problem description
|
||||
===================
|
||||
|
||||
There are two main load balancer offerings in OpenStack right now:
|
||||
|
||||
* LBaaSv2 w/agent: Uses the neutron-lbaasv2 agent with haproxy running in a
|
||||
namespace
|
||||
* LBaaSv2 w/Octavia: Deploys load balancers into virtual machines and manages
|
||||
them using the LBaaSv2 API
|
||||
|
||||
Agent-based load balancers have scalability and reliability limitations since
|
||||
the haproxy instances only run in one place without failover.
|
||||
|
||||
Octavia offers some helpful improvements for load balancing:
|
||||
|
||||
* Load balancers are deployed into virtual machines, which allows them to be
|
||||
sized appropriately and segregates them from the control plane.
|
||||
* Putting load balancers into the virtual machines brings them closer to the
|
||||
resources that they are balancing. This increases load balancer performance,
|
||||
especially in clouds where the control plane is deployed on weaker hardware
|
||||
than the data plane (hypervisors).
|
||||
* Octavia can deploy load balancers in a highly available configuration
|
||||
(currently active/passive) which helps with failures as well as
|
||||
patching/updates.
|
||||
|
||||
Proposed change
|
||||
===============
|
||||
|
||||
The proposed changes would include:
|
||||
|
||||
* Create a role for Octavia (possibly `openstack-ansible-os_octavia``)
|
||||
* Add Ansible code to deploy Octavia within an OpenStack-Ansible environment
|
||||
* Add centralized tests for the Ansible role
|
||||
* Add documentation to the role itself
|
||||
* Integrate the role with OpenStack-Ansible without dislodging the existing
|
||||
neutron-lbaasv2 + agent support
|
||||
* Allow deployers to choose LBaaSv2+agent or LBaaSv2+Octavia
|
||||
* Add documentation to OpenStack-Ansible's main docs to explain how to deploy
|
||||
Octavia as part of the integrated build
|
||||
|
||||
Optionally, work could be done to enable SSL offloading support, which requires
|
||||
a deployment of Barbican.
|
||||
|
||||
Alternatives
|
||||
------------
|
||||
|
||||
We could keep using LBaaSv2 with the agent architecture until that code is
|
||||
deprecated. This is not ideal.
|
||||
|
||||
Playbook/Role impact
|
||||
--------------------
|
||||
|
||||
Playbooks will need to be added to OpenStack-Ansible to deploy Octavia, but
|
||||
this would be very similar to the existing work done for other services, like
|
||||
Neutron.
|
||||
|
||||
Upgrade impact
|
||||
--------------
|
||||
|
||||
Octavia hasn't been deployed previously, so there's nothing to upgrade here.
|
||||
However, deployers who are currently using LBaaSv2+agent will have the option
|
||||
of changing the backend LBaaSv2 driver to use Octavia instead. They will need
|
||||
to delete all existing load balancers prior to making this change and recreate
|
||||
them.
|
||||
|
||||
Security impact
|
||||
---------------
|
||||
|
||||
The main security concern is that the Octavia load balancer virtual machines
|
||||
will need to be on some type of management network that can be reached by
|
||||
Octavia services that are running within the control plane. Those virtual
|
||||
machines will have one network connection into a tenant network and one
|
||||
connection into a management network.
|
||||
|
||||
This could allow an attacker to move from a compromised load balancer VM into
|
||||
the control plane. We will need to determine some ways to mitigate those types
|
||||
of attacks. This could be done with iptables or other network filtering.
|
||||
|
||||
Performance impact
|
||||
------------------
|
||||
|
||||
Load balancing performance should be better with Octavia-based load balancers.
|
||||
However, we will need to generate or download a VM image for the load balancer
|
||||
virtual machines. This could take time and it will need to be optimized.
|
||||
|
||||
End user impact
|
||||
---------------
|
||||
|
||||
End users that already use the LBaaSv2 API won't notice a change. The API
|
||||
contract and endpoints remain the same. Only the backend LBaaSv2 driver will
|
||||
be changed.
|
||||
|
||||
Deployer impact
|
||||
---------------
|
||||
|
||||
Deployers will need to enable Octavia deployments if they choose to use them.
|
||||
Octavia will not be deployed by default. Deployers will also need to do their
|
||||
capacity planning a little differently since load balancer virtual machines
|
||||
will take up space within the data plane that would normally be occupied by
|
||||
tenant virtual machines.
|
||||
|
||||
Developer impact
|
||||
----------------
|
||||
|
||||
The new Octavia role will follow the same deployment/testing patterns as other
|
||||
roles. It should be just as approachable as other OpenStack-Ansible independent
|
||||
roles.
|
||||
|
||||
Dependencies
|
||||
------------
|
||||
|
||||
The work for the Octavia role has no dependencies that are unsatisfied.
|
||||
|
||||
Implementation
|
||||
==============
|
||||
|
||||
Assignee(s)
|
||||
-----------
|
||||
|
||||
Primary assignee:
|
||||
Major Hayden (IRC: mhayden)
|
||||
|
||||
Work items
|
||||
----------
|
||||
|
||||
See the **Proposed change** section above for an itemized list.
|
||||
|
||||
Testing
|
||||
=======
|
||||
|
||||
The Octavia role should use the standard centralized testing repository as
|
||||
other roles. Octavia will need keystone, nova, neutron, glance deployed for
|
||||
proper testing.
|
||||
|
||||
Barbican will be required for SSL offloading if that feature is enabled.
|
||||
|
||||
Documentation impact
|
||||
====================
|
||||
|
||||
Documentation will be needed for the role itself, as well as in the integrated
|
||||
repository. This documentation should match up with the docs written for other
|
||||
services, like neutron or nova.
|
||||
|
||||
References
|
||||
==========
|
||||
|
||||
Octavia wiki: https://wiki.openstack.org/wiki/Octavia
|
||||
Octavia roadmap: https://wiki.openstack.org/wiki/Octavia/Roadmap
|
||||
Loading…
Reference in New Issue