Difference between revisions of "Neutron/LBaaS/Architecture/Scheduler"
< Neutron | LBaaS | Architecture
m (ThierryCarrez moved page Quantum/LBaaS/Architecture/Scheduler to Neutron/LBaaS/Architecture/Scheduler) |
|||
| (14 intermediate revisions by 3 users not shown) | |||
| Line 1: | Line 1: | ||
| − | + | = Overview = | |
| − | |||
| − | Scheduler is a separate Quantum | + | 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) | * 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: | '''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 |
| − | + | [[Image:device_creation.png]] | |
| − | + | * Creating device and deploy failure | |
| − | * | + | [[Image: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:''' | |
| + | |||
| + | [[Image: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. | ||
Latest revision as of 15:54, 21 June 2013
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
- Creating device and deploy failure
Important note: Agent is common for all services. It delegates processing to drivers[service_type][device_type][version].
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.
