Jump to: navigation, search

Neutron/LBaaS/Architecture/Scheduler

Overview

Scheduler/Device Management is a separate Quantum component. It is responsible for:

  • Binding of service's logical models to devices (ex: schedule vip to load balancer)
  • Management of devices that implement advanced services (load balancers, firewalls, vpn gateways, etc). That includes REST API for CRUD operations on device database.

Workflow

Example 1. The typical workflow for vip creation:

Details:

  • The request to create pool is is received by LBaaS Plugin
  • LBaaS Plugin calls DB plugin to create model and store it to DB, pool_id is returned
  • LBaaS Plugin calls Scheduler and passes it service_type, pool_id, pool and other optional parameters.
  • Scheduler finds device that satisfies service_type and parameters, including those specified in pool.
  If no device could be found, scheduler creates new DB object representing tenant's private virtual HAProxy
  • Scheduler stores mapping between device_id and pool_id in its DB. This mapping will be used in latter requests
  it also increments device ref_counter.
  • Scheduler returns device_info to LBaaS plugin
  • LBaaS Plugin responds to API with "HTTP 202 Accepted". The rest of process is done asynchronously
  • LBaaS plugin sends rpc message to Agent, specifying command, service_type, logical object (pool) and physical object (device parameters)
  • Agent reads message and forwards it to driver.
  • Driver is responsible for booting up new device in case it is on-demand HAProxy
  • Driver is responsible to wire device to tenant network according to service insertion mode and deploy logical object to the device
  • Agent returns result to LBaaS plugin which updates state of corresponding DB object: pool, resource association and device.

The following diagrams represent two cases:

  • Creating new device

Device creation.png

  • Creating device and deploy failure

Pool deploy failure.png

Important note: Agent is common for all services. It delegates processing to drivers[service_type][device_type][version].

Whole component diagram:

Components diagramm.png

Where:

  • Dev handler - a part of device specific code which evaluates device of specific type against provided resource; pool in case of loadbalancer service)
  • Agent loads sets of drivers which responsible not only for service-specific device configuration, but also for device-management functions, e.g. code that configures VLANs on device, and other tasks needed to wire it to tenant network.