Neutron/LBaaS/RadwareAlteon

Scope

This document describes Radware/Alteon driver for LBaaS. The feature scope is for the Open Stack Havana version.

Implementation Details

The driver is implemented according to Quantum/LBaaS/DriverAPI. The driver communicates with a management solution called Radware vDirect via a REST API. Radware vDirect is a virtual appliance running as part of an administrator project and tenant in OpenStack. The vDirect virtual appliance must be able to communicate with the OpenStack REST API and also needs to be accessible to the cloud operator.

Radware vDirect supports two elements of the LBaaS Driver implementation:

1. Managing the load balancer instances life-cycle (provisioning, reusing and decommissioning) via a mechanism called ADC service.
2. Managing the configuration life-cycle via a mechanism called ADC workflow.

The Radware LBaaS driver uploads ADC workflows on-demand into vDirect The ADC Workflows are composed from files which are located underneath the workflows directory. The workflows directory is part of the Radware LBaaS driver code included in OpenStack.

An ADC workflow is composed from

1. A mandatory file called workflow.xml which defines the different states and the transition flow between states as well as "linking" to the actual code that can be done on each state.
2. ADC Configuration Template files with file extension .vm
3. ADC Configuration Groovy script file extension .groovy

Features

• Protocols: HTTPS, HTTP, TCP
• LB algorithms: ROUND_ROBIN, LEAST_CONNECTIONS, SOURCE_IP
• Session persistence: SOURCE_IP, HTTP_COOKIE, APP_COOKIE
• Health monitoring: TCP, HTTP, HTTPS
• Stats retrieval

Network Topology

• One arm - VIP and Members on the same network.

Load Balancer

• Configuration - SNAT.
• Form Factor - virtual appliance (Alteon VA).

Config Life Cycle

Create Actions:

1. Create actions (Pool, Member, Health Monitor) is disregarded until the Vip is created.
2. Upon Vip creation an ADC service is selected (based on the needed networks of the Pool and Vip). If ADC service does not exists, a new ADC service is created.
3. An ADC workflow identified by the Pool ID is created and the Vip including all the configuration (Pools, Members, Health Monitors) is being created on the selected ADC service.
4. Additional creation actions such as create Member, locate an existing workflow (based on the Pool ID), and invoke the appropriate action of the ADC workflow.

Update Actions:

1. Any update action locates an existing workflow (based on the Pool ID) and invokes the appropriate action of the ADC workflow.
2. Updating Pool and Vip (sub-nets and sequentially networks) - out of scope for Havana
3. Re-parenting - if the reparenting will need to transfer configurations between instances an error will be raised.

1. Member moves to another Pool which is provisioned on a different ADC Service
2. Pool moves to another Vip which is provisioned on a different ADC Service. Vip is updated to point to another Pool which is provisioned on a different ADC Service.

Delete Actions:

1. Member delete action locates an existing workflow (based on the Pool ID) and invokes the appropriate action of the ADC workflow.
2. Pool delete action locates an existing workflow (based on the Pool ID) and invokes the appropriate action of the ADC workflow.
3. Vip delete action locates an existing workflow (based on the Pool ID) and invokes the appropriate action of the ADC workflow.