Revision as of 20:40, 28 October 2013

Embrane Neutron LBaaS Driver

Scope

The present blueprint aims at the implementation of a Neutron LBaaS driver which allows users to provision heleos Load Balancers using Neutron LBaaS framework.

Use Cases

Cloud service providers who choose to adopt OpenStack and Neutron for their cloud orchestration, will also be able to provide load balancing through the Embrane heleos appliances still using the API and workflows they are comfortable with.

Implementation

The new added files are the following:

 neutron/services/loadbalancer/drivers/embrane/__init__.py
 neutron/services/loadbalancer/drivers/embrane/agent/__init__.py
 neutron/services/loadbalancer/drivers/embrane/agent/dispatcher.py
 neutron/services/loadbalancer/drivers/embrane/agent/lb_operations.py
 neutron/services/loadbalancer/drivers/embrane/config.py
 neutron/services/loadbalancer/drivers/embrane/constants.py
 neutron/services/loadbalancer/drivers/embrane/db.py
 neutron/services/loadbalancer/drivers/embrane/driver.py
 neutron/services/loadbalancer/drivers/embrane/models.py
 neutron/services/loadbalancer/drivers/embrane/poller.py

The Provisioning

While using the Embrane Neutron LBaaS driver, any operation which doesn't involve an active VIP model object will be simply managed and written in the DB, without changing the current network state. Whenever a VIP is associated to a pool, the heleos platform will create a Load Balancer appliance, taking care of establishing connectivity between it and the pool members, and configuring all the requested parameters.

Using existing plugins for L2 connectivity

The Embrane LBaaS driver and the core L2 plugin share information about the network implementation, which will be used by heleos to provide connectivity between the Load Balancer appliance and the existing pool members. This can be done in 2 ways:

Using Embrane's L3 Neutron Plugin

This will automatically share the information with the Embrane's LBaaS driver, without any need for further configuration.

Plugin Support

When the driver is used over any other core plugin implementation, the user shall configure "l2_support" from /etc/neutron/services/loadbalancer/embrane/heleos-conf.ini An L2 support is a module which, given a core plugin, returns all the information about the specific network implementation (e.g. VLAN id). A list of the available supports can be found in neutron/plugins/embrane/l2_base
At the time this wiki page was written, the support includes:

• neutron.plugins.embrane.l2_base.openvswitch.openvswitch_support.OpenvswitchSupport

-Instructions to build a new L2 plugin Support-

see examples from:

neutron.plugins.embrane.l2_base.openvswitch.openvswitch_support.OpenvswitchSupport

To build a new L2 support for the Embrane's Neutron plugin, you must first implement the specific l2base.

Create a new package under:

neutron.plugins.embrane.l2base

And name it with the specific plugin technology. Create a python module, and a class which extends support_base.SupportBase, implementing all its abstract methods.

@abstractmethod
def retrieve_utif_info(self, context, neutron_port=None, network=None):

Once the contract is fulfilled configure /etc/neutron/services/loadbalancer/embrane/heleos-conf.ini as follows:

[heleoslb]
l2_support=neutron.plugins.embrane.l2_base.new_vendor.new_module.NewClass

Asynchronous Calls

To avoid too much wait time on long operations, the calls to the Embrane LBaaS driver will be executed asynchronously and by a different thread "per VIP". This means that each request will be sent to the dispatcher (' neutron/services/loadbalancer/drivers/embrane/agent/dispatcher.py') which will serve each Load Balancer using a different thread, in which all the operations will be queued and executed sequentially, while the available database information on the specific resource will be returned to the user (Nova style). Moreover, the LB models state attributes are used to tell the user when a lb is busy with an operation:

Table 1. Status Values

So when the model is changed (via POST, PUT or DELETE for example) the call may return before the actual operation is executed on the virtual system, putting the vip and the related models in a 'PENDING_*' state. Subsequent GET operations will eventually reflect the current status of the virtual appliance itself.

State Synchronization

To keep consistency between the heleos state and the Neutron state, a poller has been defined within:

 neutron/services/loadbalancer/drivers/embrane/poller.py

The poller has a configurable polling interval (default: 60 sec, 0 for no polling) and will make sure that the states between the two "worlds" are consistent (some times fixing issues, some times just setting the actual state within the Neutron Model).

This approach has been preferred instead of the "sync on GET" to avoid long waiting times on multiple GET operations.

Configuration

The configuration file is stored in '/etc/neutron/services/loadbalancer/embrane/heleos-conf.ini', this section explains the meaning of each field (example are provided in the configuration class itself).

• esm_mgmt: management address of the ESM, the Embrane heleos module that is installed separately and which will actually provision the load balancers inside the cloud environment;
• admin_username: admin username for authenticating against the ESM api;
• admin_password: admin password for authenticating against the ESM api;
• lb_image: ID of the heleos load balancer image stored inside the ESM;
• *_id: a series of product specific resources that can be specified inside the plugin, or alternatively, from the product itself.
• l2_support: mandatory when the core plugin is NOT Embrane's, is the path to the plugin support as explained in the sections above.
• sync_interval: defines the polling interval for state synchronization, defaults to 60 seconds, set to 0 or less if no polling is required.

etc/neutron/neutron.conf example:

[DEFAULT]
...
service_plugins = neutron.services.loadbalancer.plugin.LoadBalancerPlugin
...
[service_providers]
...
service_provider=LOADBALANCER:Embrane:neutron.services.loadbalancer.drivers.embrane.driver.EmbraneLbaas:default
...

NOTE: Any mandatory parameter which is not overridden by this configuration file will be red from the existing Embrane's L3 plugin configuration files (if any).