Hi Willy,

Currently, we're moving away from appliances that do everything we
need (A10 Networks) due to migrating to a cloud environment. We've got
6 years of experience with SLB (Alteon->Nauticus->A10), so to some
degree yes no solution can be everything. But inbound SLB l3/l4 TCP &
UDP + l7 TCP is what we've come to expect as the toolset for our load
balancers.

To adapt our infrastructure design to the cloud environment, we're
moving away from a pair of SLB appliances handling SLB between every
tier. Instead, we're putting (in this case) HAProxy on each server on
a localhost address thereby handling SLB locally and avoiding
necessitating the more complex network design we have now. Given the
number of HAProxy instances needed for that setup, I'd prefer not to
have to run both HAProxy and LVS. More moving parts...more to
break...more to health check.

Frankly, HAProxy appears to be better written and more solid than LVS
which is the reason we're going forward with it.

-J

On Fri, Jun 4, 2010 at 11:39 AM, Willy Tarreau <[email protected]> wrote:
> On Fri, Jun 04, 2010 at 11:06:52AM -0600, Jason J. W. Williams wrote:
>> Dang. We've already started the implementation of HAProxy, and would
>> prefer to only have one SLB solution.
>
> You see, there's never an absolute *one* SLB solution :
>
>  - you may have layer2 load balancing (etherchannel, bonding, ...) at
>    several places on your network ;
>
>  - you may have layer 3/4 load balancing on several systems (dedicated
>    LBs, firewalls, servers, outgoing link load balancing)
>
>  - you may have proxy-based L4 load balancing for some services which
>    may be offered by a variety of solutions.
>
>  - you may have HTTP load balancing on some systems and performed by
>    different products (pound, haproxy, nginx, ...)
>
>  - you may have non-HTTP L7 load balancing on other systems assured
>    by very different products.
>
>  - you may even be using DNS load balancing for multi-site or faster
>    page loading in your visitors' browser.
>
> In fact you can run load balancing everywhere with many different tools.
> Trying to centralize everything on one single solution for the sole purpose
> of running only one solution is the worst thing to do, as you are certain
> not to be 100% satisfied, whatever the solution.
>
>     "The right tool to get the job done right"
>
> If you look at commercial offerings, you'll see that up to 2-3 products
> are combined to get the job done right. Exceliance's ALOHA Load balancer
> involves haproxy for layer 4-7 and LVS for layer 3-4. Loadbalancer.org's
> appliances uses the same and adds pound into the mix. Yes there is a big
> intersection area between these tools. But in the end the overall quality
> benefits from these choices and that's less stress for the admin because
> each tool does its job right and is used where it performs best.
>
> So don't be afraid of combining two simple solutions to perform two
> different things, that will simplify your configurations, architecture
> and troubleshooting.
>
> Last, keep in mind that most products will generally score more than 2/4 on
> the following criteria, which means that you can hardly improve one without
> degrading the other ones :
>
>   - simplicity
>   - features integration
>   - reliability
>   - efficiency
>
> Haproxy is no exception, version 1.3 got more bugs than the more limited
> version 1.1, configurations for new versions are harder to understand than
> old ones, and the optimisations bringing its efficiency has definitely
> impacted reliability a few times.
>
> Thus, make your choice, but if I were you I'd pick the tools I need and
> not the tool that does everything.
>
> Regards,
> Willy
>
>

Reply via email to