Jump to: navigation, search

Difference between revisions of "Neutron/ServiceAgent"

(Implementation Overview)
m (ThierryCarrez moved page Quantum/ServiceAgent to Neutron/ServiceAgent)
 
(One intermediate revision by one other user not shown)
Line 8: Line 8:
  
 
From deployment perspective appliance can be:
 
From deployment perspective appliance can be:
1) on-host process - ex. haproxy as process on network controller or dedicated node with running haproxy
+
# on-host process - ex. haproxy as process on network controller or dedicated node with running haproxy
2) VM running on compute node
+
# VM running on compute node
3) physical appliance
+
# physical appliance
  
  
Line 38: Line 38:
  
 
From code perspective the changes are:
 
From code perspective the changes are:
1. Introduce new type of agent (for lbaas we can base on reference implementation of lbaas-namespace-agent)
+
# Introduce new type of agent (for lbaas we can base on reference implementation of lbaas-namespace-agent)
2. Introduce new scheduling algorithm that takes into account capabilities of appliance, their load, etc.
+
# Introduce new scheduling algorithm that takes into account capabilities of appliance, their load, etc.
3. Introduce reporting protocol between agent and agent scheduler
+
# Introduce reporting protocol between agent and agent scheduler
4. Introduce API for service agent just like it is done for l3-agent and dhcp-agent. This API may support operations for managing list of devices.
+
# Introduce API for service agent just like it is done for l3-agent and dhcp-agent. This API may support operations for managing list of devices.
  
 
The architecture is following:
 
The architecture is following:

Latest revision as of 15:54, 21 June 2013

Scope

There are two more service agents planned to be added in Havana release. The goal of this blueprint is to specify common architecture for all service agents and show how existing agent-scheduler framework may be used. The new service agent will be used as a base for lbaas, vpnaas, fwaas agents.

Use Cases

Note. Here and below the term 'resource object' means the root object of service model (e.g. VIP in case of LBaaS, vpn_connections in case of VPNaaS). Term 'appliance' represents machine/process where service runs.

From deployment perspective appliance can be:

  1. on-host process - ex. haproxy as process on network controller or dedicated node with running haproxy
  2. VM running on compute node
  3. physical appliance


Figure 1. Service agent deployment

Service agent deployment.png

In this deployment user has 1 network controller, 2 dedicated hosts where haproxy-namespace agent run, 1 host with F5 agent and 2 HW LBs managed by F5 agent.


Use case 1. Load balancing using 3 nodes with HAProxy processes

  • Enable 'lbaas-haproxy-namespace-agent' on every host
  • Configure the scheduler (similar to what is done for L3 and DHCP agents)
  • Register agents
  • Create LB logic objects. Once VIP is created the agent scheduler picks the agent and binds them. The agent compiles logic model into haproxy configuration and launches process (the way it is done in Grizzly reference implementation)

Use case 2. Load balancing using F5 hardware balancers

  • Enable 'lbaas-f5-agent' on network controller (here instead of specific lbaas-f5-agent we may have lbaas-agent with f5 driver). The agent is configured with the list of devices. The configuration may be static (via conf file) or exposed via API (like that for l3-agent and dhcp-agent)
  • Configure the scheduler. Here a specific scheduler may be chosen - the one that is aware of devices state and their capacity.

Use case 3. VPN tunnel is created

  • Enable 'vpnaas-agent' on network node
  • Configure the scheduler with specific VPNaaS-aware scheduler

Implementation Overview

The agent scheduler framework already introduces parts needed for implementation: pluggable scheduling algorithm, API extensions, l3-agent and dhcp-agent may be used as reference point.

From code perspective the changes are:

  1. Introduce new type of agent (for lbaas we can base on reference implementation of lbaas-namespace-agent)
  2. Introduce new scheduling algorithm that takes into account capabilities of appliance, their load, etc.
  3. Introduce reporting protocol between agent and agent scheduler
  4. Introduce API for service agent just like it is done for l3-agent and dhcp-agent. This API may support operations for managing list of devices.

The architecture is following:

Figure 2. Plugin and agent architecture

Service agent architecture.png

Note. There are options on agent implementation: mixin with specific service implementations or extension-per-service.

Data Model Changes

Introduce new tables for storing binding between resource object and agent. As an option we may think of refactoring existing NetworkDhcpAgentBinding and RouterL3AgentBinding into common model.

Configuration variables

  • quantum.conf: variable to configure scheduler for service agent.
  • service-agent.conf

API's

API to configure list of devices for device-oriented service agent. But this is not top priority for the first version as devices may be configured statically.

CLI Requirements

CLI for device configuration (optional)

Horizon Requirements

'tbd'