Cloud Docs Home > F5 OpenStack LBaaSv1 Index
Attention
End of Technical Support for F5 OpenStack LBaaS version 1
F5 announces the End of Technical Support (EoTS) for the F5 OpenStack LBaaS version 1 integration. This announcement is in compliance with the OpenStack community deprecation of the OpenStack Neutron LBaaS version 1 plugin. Customers are encouraged to move to OpenStack LBaaS version 2.
F5 ceased to repair defects and perform maintenance on the F5 OpenStack LBaaS version 1 integration as of the Openstack Ocata release in April 2017.
For additional information, please refer to the F5 End of Life policy.
Architecture¶
Neutron LBaaSv1¶
When Neutron LBaaSv1 API calls are issued to your Neutron controller, the community LBaaSv1 plugin attempts to use either a designated service provider driver or the default service provider driver to provision LBaaSv1 resources.
F5® LBaaSv1 Plugin¶
The F5® LBaaSv1 service provider driver runs within the Neutron controller processes. It utilizes Neutron RPC messaging queues to issue provisioning tasks to F5® LBaaSv1 agent processes.
When an LBaaSv1 API interface is invoked, the F5® LBaaSv1 driver schedules tasks to an F5® agent based on the agent’s availability (determined from the standard Neutron agent status messages). The agent starts, and communicates with, a configured BIG-IP®, then registers its own named queue where it will receive tasks from the Neutron controller(s).
The The F5® agent makes callbacks to the F5® drivers to query additional Neutron network, port, and subnet information; allocate Neutron objects (for example, fixed IP addresses); and report provisioning and pool status. These callback requests are placed on an RPC message queue processed by all listening F5® drivers in a round robin fashion. Since all Neutron controller processes are working transactionally off the same backend database, it doesn’t matter which of the available Neutron controller processes handles the requests.
Fig. 2 F5® LBaaSv1 Plugin Architecture
F5® LBaaSv1 Driver and Agent Placement¶
The F5® LBaaSv1 driver should be installed on at least one Neutron controller. Installing drivers on additional controllers scales out communications to Neutron.
The F5® LBaaSv1 agent should be installed on at least on Neutron controller. Installing additional agents on different hosts in the same BIG-IP® environment (in other words, hosts that have the same BIG-IP® environment_prefix and iControl® endpoint settings) adds scheduled redundancy to the provision process. See BIG-IP® Environments for more information.
Neutron Agent Binding¶
Neutron LBaaSv1 binds pools to specific agents for the life of the pool. The redundancy allows other agents running in the same environment to handle requests if the bound agent is not active.
Note
If the bound agent is inactive, it’s expected that it will be brought back online. If an agent is deleted, all pools bound to it should also be deleted. Run neutron lb-pool-list-on-agent <agent-id> to identify all pools associated with an agent.
BIG-IP® Environments¶
Two agents which have different iControl® endpoint settings (in other words, agents that are provisioning different sets of BIG-IP® devices) can not be configured with the same environment_prefix.
The scheduler uses the environment_prefix as a unique identifier for the agent process. If you use the same environment_prefix for two agents that are managing separate BIG-IP® devices, the scheduler will confuse them, most likely resulting in errors.
See Running Multiple Agents on the Same Host for more information.
Tip
You can check the status of all running Neutron agent processes via the Neutron API agent interfaces, or by using the commands shown below in the CLI client.
# neutron agent-list
# neutron agent-show <agent_id>