fuel-dev team mailing list archive
-
fuel-dev team
-
Mailing list archive
-
Message #00037
Fwd: [openstack-dev] [Murano] Implementing Elastic Applications
FYI - Murano team needs LBaaS. Fuel does not currently deploy LBaaS plugin
for Neutron.
---------- Forwarded message ----------
From: Serg Melikyan <smelikyan@xxxxxxxxxxxx>
Date: Fri, Nov 15, 2013 at 3:56 PM
Subject: [openstack-dev] [Murano] Implementing Elastic Applications
To: OpenStack Development Mailing List <OpenStack-dev@xxxxxxxxxxxxxxxxxxx>
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::LoadBalancer<http://docs.openstack.org/developer/heat/template_guide/cfn.html#AWS::ElasticLoadBalancing::LoadBalancer>,
that currently does not
support<http://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::LoadBalancer<http://docs.openstack.org/developer/heat/template_guide/cfn.html#AWS::ElasticLoadBalancing::LoadBalancer>,
using another implementation of load balancing in Heat -
OS::Neutron::LoadBalancer<http://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
stack<https://github.com/openstack/heat/blob/master/heat/engine/resources/loadbalancer.py#L24>that
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::LoadBalancer<http://docs.openstack.org/developer/heat/template_guide/openstack.html#OS::Neutron::LoadBalancer>is
another Heat resource that implements load balancer. This resource is
based on Load Balancer as a Service feature in
Neutron<https://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 | smelikyan@xxxxxxxxxxxx
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@xxxxxxxxxxxxxxxxxxx
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Mike Scherbakov