Bug 1042438

Summary: [RFE][neutron]: Support for multiple agents to manage a single backend loadbalancer
Product: Red Hat OpenStack Reporter: RHOS Integration <rhos-integ>
Component: RFEsAssignee: RHOS Maint <rhos-maint>
Status: CLOSED UPSTREAM QA Contact:
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: unspecifiedCC: markmc, yeylon
Target Milestone: ---Keywords: FutureFeature
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
URL: https://blueprints.launchpad.net/neutron/+spec/lbaas-ha-agent
Whiteboard: upstream_milestone_none upstream_status_needs-code-review upstream_definition_obsolete
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-03-19 17:18:59 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

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