Jump to: navigation, search

Neutron/LBaaS/Architecture

< Neutron‎ | LBaaS
Revision as of 14:31, 26 October 2012 by Ilya (talk)

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