Bug 1042438 - [RFE][neutron]: Support for multiple agents to manage a single backend loadbalancer
Summary: [RFE][neutron]: Support for multiple agents to manage a single backend loadba...
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: RFEs
Version: unspecified
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
: ---
Assignee: RHOS Maint
QA Contact:
URL: https://blueprints.launchpad.net/neut...
Whiteboard: upstream_milestone_none upstream_stat...
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-12-12 22:17 UTC by RHOS Integration
Modified: 2015-12-10 20:03 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-03-19 17:18:59 UTC
Target Upstream Version:


Attachments (Terms of Use)

Description RHOS Integration 2013-12-12 22:17:15 UTC
Cloned from launchpad blueprint https://blueprints.launchpad.net/neutron/+spec/lbaas-ha-agent.

Description:

Currently, a single LBaaS agent manages a single loadbalancer backend.  It should be possible to have multiple agents manage a backend resource for both HA and horizontal scalability.

For those lbaas drivers that manage physical loadbalancer devices rather than processes (like HAProxy) it doesn't matter which exact agent will perform actual managing.  So such loadbalancer instances may be simply rescheduled to another agent in case current agent fails.

The proposed solution is to monitor agents states on plugin side with some periodic interval and reschedule loadbalancer instances if some agent becomes inactive. The only requirement for lbaas driver is to indicate whether its instances can be rescheduled to another agent on another host.
One possible improvement would be to save instances to some cache in case there are no active agents supporting needed device driver at the moment and try to schedule these instances once any new agent appears or down agent became active.

Other solution may be to have a common message queue for such drivers and to cast messages there so that the first active agent picks up the message and performs the action.

The advantage of agent monitoring and rescheduling is that we keep simplicity by having to handle only one message queue and to have one unified lbaas agent manager without any specific subagents. Also unlike common queue resheduling ensures that currently there are active lbaas agents supporting required device driver.

Specification URL (additional information):

https://etherpad.openstack.org/p/multiple_LBaaS_agents


Note You need to log in before you can comment on or make changes to this bug.