Important

End of Software Development for F5 OpenStack LBaaS version 1

F5 announces the End of Software Development (EoSD) for the F5 OpenStack LBaaS version 1 integration, effective October 1, 2016. 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 will continue to repair defects and perform maintenance on the F5 OpenStack LBaaS version 1 integration until the Openstack Ocata release in April 2017.

For additional information, please refer to the F5 OpenStack Releases and Support Matrix.

Differentiated Services and Scale Out

F5 LBaaSv1 Plugin in Differentiated Service Environments

Fig. 4 F5® LBaaSv1 Plugin in Differentiated Service Environments

The F5® LBaaSv1 plugin supports deployments where multiple BIG-IP® environments are required. In a differentiated service environment, the F5® driver for each environment has its own messaging queue. The tenant scheduler for each environment can only assign tasks to agents running in that environment.

Tip

The first section of the F5® agent config file - /etc/neutron/f5-oslbaasv1-agent.ini - provides information regarding the configuration of multiple environments.

To configure differentiated LBaaSv1 provisioning:

  1. Install the agent and driver on each host that requires LBaaSv1 provisioning.
  2. Assign an environment-specific name to the F5® agent in /etc/neutron/f5-oslbaasv1-agent.ini.
  3. Create a service provider entry corresponding to each agent’s unique name in /etc/neutron/neutron_lbaas .

Warning

A differentiated BIG-IP® environment can not share anything. This precludes the use of vCMP for differentiated environments because vCMP guests share global VLAN IDs.

Default Environment Options

The F5® OpenStack LBaaSv1 plugin allows for the use of three default environment names - test, dev, and prod. As shown in the excerpt from /etc/neutron/f5-oslbaasv1-agent.ini below, the service provider entries in /etc/neutron/neutron_lbaas correspond to each agent’s unique environment_prefix.

# For a test environment:
#
# Set your agent's environment_prefix to 'test'
#
# and add the following line to your LBaaS service_provider config
# on the neutron server:
#
# service_provider = LOADBALANCER:TEST:f5.oslbaasv1driver.drivers.plugin_driver.F5®PluginDriverTest
#
# For a dev environment:
#
# Set your agent's environment_prefix to 'dev'
#
# and add the following line to your LBaaS service_provider config
# on the neutron server:
#
# service_provider = LOADBALANCER:DEV:f5.oslbaasv1driver.drivers.plugin_driver.F5®PluginDriverDev
#
# For a prod environment:
#
# Set your agent's environment_prefix to 'prod'
#
# and add the following line to your LBaaS service_provider config
# on the neutron server:
#
# service_provider = LOADBALANCER:PROD:f5.oslbaasv1driver.drivers.plugin_driver.F5®PluginDriverProd

After making changes to /etc/neutron/f5-oslbaasv1-agent.ini and /etc/neutron/neutron_lbaas, restart the neutron-server process.

# service neutron-server restart

Run neutron agent-list to view the list of active agents on your host to verify that the agent is up and running. If you do not see the f5-oslbaasv1-agent listed, you may need to restart the service.

# service f5-oslbaasv1-agent restart

Custom Environments

You can use a driver-generating module to create custom environments. On each Neutron controller which will host your custom environment, run the following command:

# python -m f5.oslbaasv1driver.utils.generate_env.py provider_name environment_prefix

Example: Add the custom environment ‘DFW1’.

# python -m f5.oslbaasv1driver.utils.generate_env.py DFW1 DFW1

The command creates a driver class and a corresponding service_provider entry in /etc/neutron/neutron_lbaas.

# service_provider = LOADBALANCER:DFW1:f5.oslbaasv1driver.drivers.plugin_driver_Dfw1.F5®PluginDriverDfw1

Remove the comment (#) from the beginning of the new service_provider line to activate the driver.

Then, restart the neutron-server service.

# service neutron-server restart

Capacity-Based Scale Out

When using service differentiated environments, the environment can be scaled out to multiple BIG-IP® device service groups by providing an environment_group_number`. Each agent associated with a specific device service group should have the same ``environment_group_number. When environment grouping is configured, the service provider scheduler will consider the grouping along with an environment_capacity_score reported by the agents. Together, the agent grouping and the capacity score allow the scheduler to scale out a single environment across multiple BIG-IP® device service groups.

###############################################################################
#  Environment Settings
###############################################################################
...
# When using service differentiated environments, the environment can be
# scaled out to multiple device service groups by providing a group number.
# Each agent associated with a specific device service group should have
# the same environment_group_number.
#
# environment_group_number = 1
#
...

Each agent measures its group’s capacity. The agent reports a single environment_capacity_score for its group every time it reports its status to the Neutron controller.

The environment_capacity_score value is the highest capacity recorded on several collected statistics specified in the capacity_policy setting in the agent configuration. The capacity_policy setting is a dictionary, where the key is the metric name and the value is the max allowed value for that metric. The score is determined by dividing the metric collected by the max specified for that metric in the capacity_policy setting. An acceptable reported environment_capacity_score is between zero (0) and one (1). If an agent in the group reports an ``environment_capacity_score`` of one (1) or greater, the device is considered to be at capacity.

When multiple environment_group_number-designated groups of agents are available, and a service is created where the services’ tenant is not already associated with a group, the scheduler will try to assign the service to the group with the last recorded lowest environment_capacity_score. If the services’ tenant was associated with an agent where the environment_group_number for all agents in the group are above capacity, the new service will be associated with another group where capacity is under the limit.

Warning

If you set the capacity_policy and all agents in all groups for an environment are at capacity, services will no longer be scheduled. When pools are created for an environment which has no capacity left, the pools will be placed in the error state.

The following metrics implemented by the iControl® driver can be configured in /etc/neutron/f5-oslbaasv1-agent.ini. These settings are used to manage your environment groups / BIG-IP® device service groups.

###############################################################################
#  Environment Settings
###############################################################################
...
# throughput - total throughput in bps of the TMOS devices
# inbound_throughput - throughput in bps inbound to TMOS devices
# outbound_throughput - throughput in bps outbound from TMOS devices
# active_connections - number of concurrent active actions on a TMOS device
# tenant_count - number of tenants associated with a TMOS device
# node_count - number of nodes provisioned on a TMOS device
# route_domain_count - number of route domains on a TMOS device
# vlan_count - number of VLANs on a TMOS device
# tunnel_count - number of GRE and VxLAN overlay tunnels on a TMOS device
# ssltps - the current measured SSL TPS count on a TMOS device
# clientssl_profile_count - the number of clientside SSL profiles defined
#
# You can specify one or multiple metrics.
#
# capacity_policy = throughput:1000000000, active_connections: 250000, route_domain_count: 512, tunnel_count: 2048
#