[openstack-dev] [Neutron][LBaaS] Enterprise Ready Features

Stephen Balukoff sbalukoff at bluebox.net
Fri Feb 28 20:10:32 UTC 2014


Hi Brandon,

Glad to see more new blood in this project and discussion. (I've also only
recently gotten involved in the discussion here. And I've sent my ideas on
this front to this list in the last couple of weeks-- let me know if you'd
like me to send you links to this discussion.)

I think Jay covered what I understand to be the current state of affairs at
this point, but I would point out that largely the discussion so far has
been about the right way to implement Layer-7 features and SSL, and not
really about how HA and scalability play into this (though I've been trying
to foster the discussion in this direction. :) )

As such, I don't think it's fair to say that the Neutron LBaaS community
has fully considered the HA or scalability problems just yet, nor what
changes are going to need to happen to make these features available. And
given that, I don't get the impression that it's at all decided that HA and
scalability features will be solely delegated to the driver level--  that
is to say, the community may yet decide there are certain entities (like
the idea of a logical "load balancer" construct) that make sense to apply
to the Neutron LBaaS model which help both driver writers to implement HA
features, and help end users to write their applications without having to
navigate a minefield of optionally supported features of a given load
balancer implementation.  (I'm actually looking forward to seeing Jay's
fleshed out ideas which I understand counter this point which may make a
'loadbalancer' object unnecessary and thus allow a lot more flexibility in
implementation.)

Given we're still struggling to find consensus on the changes that will
enable L7 and SSL, it may be a bit premature to start talking about HA and
scalability (though, again, I would like it if we could be this
forward-thinking about the project. :) ) I'm really hoping we can make
significant progress on this at the Atlanta summit in May.

In any case, welcome to the discussion!

Stephen



On Fri, Feb 28, 2014 at 9:51 AM, Brandon Logan
<brandon.logan at rackspace.com>wrote:

> Thanks for your response Jay.  I'm not a big fan of the term enterprise
> either but its the best single word term I could come up with to describe
> large scale, multi tenant deployments.  I know these are things every
> project wants but I'm just gauging how important it is to accomplish these
> goals in this project.
>
> As for Atlas LB, it has been dead for a year or two now.  Unless it
> somehow got resurrected and we don't know about it.  I really liked the API
> and object models, it allowed for multiple vips and was planned to
> implement a form of "flavors" (or types), not exactly the same way
> obviously, but the idea was there.  I also like that it was a standalone
> project.  A big problem with that project, though, was that it was going to
> be written in Java.  There were also other political reasons for it dying
> but those will remain unsaid.
>
> The fragmentation is a bit of a concern but hopefully it will end up with
> the best ideas from all the projects going into one project that the
> community can agree on.
>
> We, Rackspace, are hoping to use Neutron LBaaS it but it does need to get
> into a more mature state.  The Cloud Load Balancing team (the team I am on)
> is looking to start contributing to this project to help get it to where we
> need it for this to happen. Obviously, we need some ramp up time to fully
> understand the project and get more involved in the discussions.  Hopefully
> we can contribute code and also share our experiences in what we learned in
> our successes and failures.  We are all looking forward to working with the
> community on this.
>
> Thanks,
> Brandon
> ________________________________________
> From: Jay Pipes [jaypipes at gmail.com]
> Sent: Thursday, February 27, 2014 8:52 PM
> To: openstack-dev at lists.openstack.org
> Subject: Re: [openstack-dev] [Neutron][LBaaS] Enterprise Ready Features
>
> On Wed, 2014-02-26 at 18:46 +0000, Brandon Logan wrote:
> > TL;DR: Are enterprise needed features (HA, scalability, resource
> > management, etc) on this project's roadmap.
>
> Yes. Although, due to my disdain for the term "enterprise", I'd point
> out that all of those features are things that most everyone wants, not
> just shops with stodgy, old, legacy IT departments -- I mean...
> "enterprises" ;)
>
> >  If so, how much of a priority is it?
>
> Not sure.
>
> > I've been doing some research on Neutron LBaaS to determine the
> > viability and what needs to be done to allow for it to become an
> > enterprise ready solution.
>
> Out of curiosity, since you are at Rackspace, what about Atlas LB?
>
> >  Since I am fairly new to this project please forgive me, and also
> > correct me, if my understanding of some of these things is false.
> > I've already spoken to Eugene about some of this, but I think it would
> > be nice to get everyone's opinion.  And since the object model
> > discussions are going on right now I believe this to be a good time to
> > bring it up.
>
> Ya, no worries. I'm new to the LBaaS discussions myself.
>
> > As of its current incarnation Neutron LBaaS does not seem to be HA,
> > scalable, and doesn't isolate resources for each load balancer.  I
> > know there is a blueprint for HA for the agent
> > (https://blueprints.launchpad.net/neutron/+spec/lbaas-ha-agent) and HA
> > for HaProxy
> > (https://blueprints.launchpad.net/neutron/+spec/lbaas-ha-haproxy).
> > That is only for HaProxy, though, and sounds like it has to be
> > implemented at the driver level.
>
> Right. Different drivers will enable HA in different ways.
>
> > Is that the intended direction for implementing these goals, to
> > implement them at the driver level?
>
> I *believe* that is the intended direction, yes. The ongoing
> conversations about Neutron "flavors" as well as the conversation about
> the future object model and API have really been about how to expose the
> capabilities of different drivers -- and match those capabilities to
> requested capabilities from the user -- without leaking any particular
> driver's implementation specifics into the public API. I think the hope
> is that in the coming few months and during the summit, the community
> will coalesce around a game plan for implementing "flavors" (or types,
> as I prefer to call them), and from that implementation, contributors
> will be able to work on adding these features to drivers and expose this
> functionality in a generic fashion.
>
> >  I can definitely see why that is the way to do it because some
> > drivers may already implement these features, while others don't.  It
> > would be nice if there was a way to give those features to drivers
> > that do not have it out of the box.
>
> Well, on the HA and scaling front, one solution is to run multiple
> instances of something like HA Proxy and have some healthcheck software
> that would fail over operations from one load balancer instance to
> another if a failure condition occurred. In fact, that is similar to
> what the Libra project does with its node pool manager [1].
>
> > Basically, I'd like this project to have these enterprise level
> > features to that it can be adopted in an enterprise cloud.  It will
> > require a lot of work to achieve these goals, and I believe it should
> > be something that is a goal.
>
> I don't think you'll get any disagreement from anyone on that :)
> Although there has certainly been a fragmentation of effort on the LBaaS
> front with Atlas, Libra and Neutron LBaaS, it seems that the community
> is now coming together a bit.
>
> Best,
> -jay
>
> [1] http://libra.readthedocs.org/en/latest/pool_mgm/index.html
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Stephen Balukoff
Blue Box Group, LLC
(800)613-4305 x807
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140228/8cb31c55/attachment.html>


More information about the OpenStack-dev mailing list