Difference between revisions of "Neutron/LBaaS/Architecture/Scheduler"
< Neutron | LBaaS | Architecture
| Line 42: | Line 42: | ||
'''Another option''' | '''Another option''' | ||
| − | + | Scheduling component can use it's own device management logic. | |
For example, scheduler may use preconfigured device list rather than device DB. | For example, scheduler may use preconfigured device list rather than device DB. | ||
| + | |||
| + | This still requires different schedulers to be interchangeble, e.g. common infrastructure which makes scheduling logic to be configurable. | ||
Revision as of 14:27, 20 December 2012
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.
- Scheduler stores mapping between device_id and pool_id in its DB. This mapping will be used in latter requests
- 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 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.
Important note: Agent is common for all services. It delegates processing to drivers[service_type][device_type][version].
See also Scheduler API
Whole component diagram:
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.
Another option
Scheduling component can use it's own device management logic. For example, scheduler may use preconfigured device list rather than device DB.
This still requires different schedulers to be interchangeble, e.g. common infrastructure which makes scheduling logic to be configurable.
