Open Stack

On Fri, Nov 15, 2013 at 12:56 PM, Serg Melikyan <smelikyan at mirantis.com> wrote:
> Murano has several applications which support scaling via load-balancing,
> this applications (Internet Information Services Web Farm, ASP.NET
> Application Web Farm) currently are based on Heat, particularly on resource
> called AWS::ElasticLoadBalancing::LoadBalancer, that currently does not
> support specification of any network related parameters.
>
> Inability to specify network related params leads to incorrect behavior
> during deployment in tenants with advanced Quantum deployment configuration,
> like Per-tenant Routers with Private Networks and this makes deployment of
> our * Web Farm applications to fail.
>
> We need to resolve issues with our * Web Farm, and make this applications to
> be reference implementation for elastic applications in Murano.
>
> This issue may be resolved in three ways: via extending configuration
> capabilities of AWS::ElasticLoadBalancing::LoadBalancer, using another
> implementation of load balancing in Heat - OS::Neutron::LoadBalancer or via
> implementing own load balancing application (that going to balance other
> apllications), for example based on HAProxy (as all previous ones).
>
> Please, respond with your thoughts on the question: "Which implementation we
> should use to resolve issue with our Web Farm applications and why?". Below
> you can find more details about each of the options.
>
> AWS::ElasticLoadBalancing::LoadBalancer
>
> AWS::ElasticLoadBalancing::LoadBalancer is Amazon Cloud Formation compatible
> resource that implements load balancer via hard-coded nested stack that
> deploys and configures HAProxy. This resource requires specific image with
> CFN Tools and specific name F17-x86_64-cfntools available in Glance. It's
> look like we miss implementation of only one property in this resource -
> Subnets.
>
> OS::Neutron::LoadBalancer
>
> OS::Neutron::LoadBalancer is another Heat resource that implements load
> balancer. This resource is based on Load Balancer as a Service feature in
> Neutron. OS::Neutron::LoadBalancer is much more configurable and
> sophisticated but underlying implementation makes usage of this resource
> quite complex.
> LBaaS is a set of services installed and configured as a part of Neutron.
> Fuel does not support LBaaS; Devstack has support for LBaaS, but LBaaS not
> installed by default with Neutron.
>
> Own, Based on HAProxy
>
> We may implement load-balancer as a regular application in Murano using
> HAProxy. This service may look like our Active Directory application with
> almost same user-expirience. User may create load-balancer inside of the
> environment and join any web-application (with any number of instances)
> directly to load-balancer.
> Load-balancer may be also implemented on Conductor workflows level, this
> implementation strategy not going to change user-experience (in fact we
> changing only underlying implementation details for our * Web Farm
> applications, without introducing new ones).

Hi,

I would strongly encourage using OS::Neutron::LoadBalancer. The AWS
resource is supposed to mirror Amazon capabilities, so any extension,
while not impossible, is frowned upon. On the other hand the Neutron
load balancer can be extended to your need, and being able to use an
API gives you much more flexibility. It also in active development and
will get more interesting features in the future.

If you're having concerns about deploying Neutron LBaaS, you should
bring it up with the team, and I'm sure they can improve the
situation. My limited experience with it in devstack has been really
good.

Cheers,

-- 
Thomas