[openstack-dev] [Neutron][LBaaS] Neutron LBaaS, Libra and "managed services"

Eugene Nikanorov enikanorov at mirantis.com
Tue Mar 25 13:24:23 UTC 2014

> One example where the managed service approach for the HA proxy load
>>> balancer is different from the current Neutron LBaaS roadmap is around HA
>>> and resiliency. The 2 LB HA setup proposed (
>>> https://blueprints.launchpad.net/neutron/+spec/lbaas-ha-haproxy) isn't
>>> appropriate for service providers in that users would have to pay for the
>>> extra load-balancer even though it is not being actively used.
>> One important idea of the HA is that its implementation is
>> vendor-specific, so each vendor or cloud provider can implement it in the
>> way that suits their needs. So I don't see why particular HA solution for
>> haproxy should be considered as a common among other vendors/providers.
> [Susanne] Are you saying that we should create a driver that would be a
> peer to the current loadbalancer/ ha-proxy driver? So for example
>  loadbalancer/managed-ha-proxy (please don't get hung-up on the name I
> picked) would be a driver we would implement to get our interaction with a
> pool of stand-by load-and preconfigured load balancers instead of the 2 LB
> HA servers? And it would be part of the Neutron LBaaS branch?
No, I mean that haproxy driver would do it the way HA for haproxy is
typically setup, and driver for Libra will do it in the way you think it's
best for your deployment. User just asks for HA capability of the service.
If we need better distinction of HA methods, we could introduce it into
'flavors' (see https://wiki.openstack.org/wiki/Neutron/FlavorFramework )
Having different devices in HA pairs are not planned.

>> That for sure can be implemented. I only would recommend to implement
>> such kind of management system out of Neutron/LBaaS tree, e.g. to only have
>> client within Libra driver that will communicate with the management
>> backend.
> [Susanne] Again this would only be a short term solution since as we move
> forward and want to contribute new features it would result in duplication
> of efforts because the features might need to be done in Libra and not
> Neutron LBaaS.

That seems to be a way other vendors are taking right now. Regarding the
features, could you point to description of those?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140325/f8f84adb/attachment.html>

More information about the OpenStack-dev mailing list