Hi,
I believe that we restricted to have a single solution only: Murano is an
Application Catalog now, and Catalog is the thing where multiple similar
solutions can be present, and the user makes the final decision on what to
pick for their environments.
So, I would suggest to bundle a solution based on OS::Neutron::LoadBalancer
- and have a blueprint describing that homemade HAProxy-based solution -
someone will implement it sooner or later, as the demand for such a service
clearly exists (and will definitely increase when we introduce the ability
to share a single VM for multiple applications).
--
Regards,
Alexander Tivelkov
2013/11/15 Serg Melikyan smelik...@mirantis.com
Murano has several applications which support scaling via load-balancing,
this applications (Internet Information Services Web Farm, ASP.NETApplication
Web Farm) currently are based on
Heat http://launchpad.net/heat, particularly on resource called
AWS::ElasticLoadBalancing::LoadBalancerhttp://docs.openstack.org/developer/heat/template_guide/cfn.html#AWS::ElasticLoadBalancing::LoadBalancer,
that currently does not
supporthttp://docs.openstack.org/developer/heat/template_guide/cfn.html#AWS::ElasticLoadBalancing::LoadBalancer-props
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::LoadBalancerhttp://docs.openstack.org/developer/heat/template_guide/cfn.html#AWS::ElasticLoadBalancing::LoadBalancer,
using another implementation of load balancing in Heat -
OS::Neutron::LoadBalancerhttp://docs.openstack.org/developer/heat/template_guide/openstack.html#OS::Neutron::LoadBalancer
or
via implementing own load balancing application (that going to balance
other apllications), for example based on HAProxy http://haproxy.1wt.eu/ (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
stackhttps://github.com/openstack/heat/blob/master/heat/engine/resources/loadbalancer.py#L24that
deploys and configures HAProxy. This resource requires specific image
with CFN Tools https://github.com/openstack/heat-cfntools 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::LoadBalancerhttp://docs.openstack.org/developer/heat/template_guide/openstack.html#OS::Neutron::LoadBalanceris
another Heat resource that implements load balancer. This resource is
based on Load Balancer as a Service feature in
Neutronhttps://wiki.openstack.org/wiki/Neutron/LBaaS.
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 http://haproxy.1wt.eu/. 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).
--
Serg Melikyan, Senior Software Engineer at Mirantis, Inc.
http://mirantis.com | smelik...@mirantis.com
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
