Neutron/LBaaS/Architecture
Scope
This document describes the architecture of LBaaS and introduces internal APIs
Modules Decomposition
LBaaS architecture is based on advanced services introduced into Quantum. The structure is following:
File:Quantum$$LBaaS$$Architecture$lbaas architecture new.png
- LBaaS Quantum Extension - is responsible for handling REST API calls
- LBaaS Quantum AdvSvc Plugin - is a core of service, it is responsible for:
- DB storage
- Request validation
- Scheduling of load balancing services (deployment to LB devices)
- LBaaS Agent - is stand-alone service that provides API for driver developers
- Driver - is a module that transforms LBaaS object model into vendor-specific model and deploys configuration onto load-balancing device
Sequence Diagram
LBaaS management is performed via REST API. If the call involves DB only (read, name update) then it is done in synchronous manner, all other calls (like status retrieval, write operations) are done asynchronously. See Quantum/LBaaS/REST API for more details.
Communicaion between AdvSvc Plugin and Agent is done via AMQP.
The diagram (#1) for update operation is following:
File:Quantum$$LBaaS$$Architecture$lbaas update sequence.png
Driver API
All vendor drivers implement base Driver API. The list of operations is following:
createVIP (vip: VIP) updateVIP (newVip: VIP, oldVip: VIP) deleteVIP (vip: VIP) createPool (pool: Pool, vip: VIP) updatePool (newPool: Pool, oldPool: Pool, vip: VIP) deletePool (pool: Pool, vip: VIP) createMember (member: Member, pool: Pool) updateMember (newMember: Member, oldMember: Member, pool: Pool) deleteMember (member: Member, pool: Pool) createHealthMonitor (healthMonitor: HealthMonitor, pool: Pool) updateHealthMonitor (newHealthMonitor: HealthMonitor, oldHealthMonitor: HealthMonitor, pool: Pool) deleteHealthMonitor (healthMonitor: HealthMonitor, pool: Pool) getPoolStats (pool: Pool) getVIPStatus (vip: VIP) getPoolStatus (pool: Pool) getMemberStatus (member: Member) getCapabilities ()
(?) For all update operations both old and new object are passed. The driver may decide to use new object only, or apply patch. Maybe we need to pass patch instead of old?
Appendix. Diagram #1 is created using http://www.websequencediagrams.com, source code:
title Update Request User -> +Extension: REST API Request activate User Extension --> +Plugin: Core API Request alt Valid Plugin --> Extension: Accepted Extension -> User: HTTP 202 else Invalid Plugin --> Extension: Error Message Extension -> -User: HTTP 40x end deactivate User Plugin --> +DB: Set W-Lock Plugin -> +Agent: AMQP Request Agent --> +Driver: Driver API call Driver -> +Device: Apply Change Device -> -Driver: Status Driver --> -Agent: Status Agent -> -Plugin: AMQP Response alt Success Plugin --> DB: Update DB else Failure Plugin --> DB: Store Last Error end Plugin --> DB: Clear W-Lock deactivate Plugin deactivate DB