Willy, > I think you shouldn't try that hard to adapt the tools to your needs.
You are correct. Clearly, HAProxy is among the best at load balancing and I definitely need a load balancer. NGINX is among the best at web serving and I definitely need a web server. Varnish is among the best at web cacheing and I definitely need a static content web cache. HAProxy has most of what I want in letting the backend server communicate back to the load balancer. I'm not so sure whether I can adjust MAXCONN for the front end from a backend server, but this feature would be just a nice thing to have and not essential. I can live with a static MAXCONN. My problem also came that I also need SSL Termination and I need to do this in the load balancer. I'm a bit hesitant to use HAProxy for SSL since it is a new feature. I've used NGINX for SSL and it seems very stable. I also think NGINX can probably scale to use more CPU cores on a server but may CPU isn't the bottleneck and both NGINX and HAProxy will saturate my networking link to the internet before running out of CPU. Anyway, do I put NGINX on my load balancers too? My need for a load balancer is very simple in the frontend load balancers and NGINX has enough support for my needs with ip_hash balancing. On the other hand, I really like the stats page of HAProxy and maybe that is enough of a feature to get me to choose HAProxy for the load balancers (and SSL). As for the backend servers, I only need HAProxy as a "guard" to keep the particular backend server from never getting overloaded (never exceeding MAXCONN) no matter how many load balancers send requests to it. It would be nice to have NGINX provide this guard. One way to provide this "guard" is to use HAProxy to use "first" load balancing algorithm. Maybe I can figure out how to use NGINX to do this too. If NGINX has a variable that says how many requests are being processed by a server and I can access that variable in deciding how to process a new request, then I can eliminate HAProxy for "guard" purposes. I still might need HAProxy for MySQL to copy session data to the local sessionDB if the load balancers needed to change the backend server for a user request. But, I may be able to handle this in PHP just as well. Anyway, thanks for your thoughts. I have a couple of months to get this all figured out, but I can already see that good solutions and tools exist already to do what I want to do. But, it is still very tempting to minimize the number of software packages in the system just to keep the complexity of administration low. Kevin On Jan 5, 2013, at 3:19 AM, Willy Tarreau <[email protected]> wrote: > Kevin, > > On Fri, Jan 04, 2013 at 03:44:40PM -0500, KT Walrus wrote: >> HAProxy also does all this stuff too (more or less). I plan on using HAProxy >> if NGINX doesn't support everything I need done. >> >> I have a preference to use as few software packages as possible so I keep the >> system as simple and maintainable as possible. Being able to eliminate >> HAProxy would be a plus for me. I already need NGINX to handle basic web >> serving, so I think I just need a few new features in the load balancing area >> to go without HAProxy. > > I think you shouldn't try that hard to adapt the tools to your needs. > Many large scalable websites use haproxy+varnish+nginx together and > are very happy with that combination. Each one has a separate clearly > identified role. All 3 perform extremely well and they try to address > different needs, so in general what you don't find in one of them is > doable with the other two. And at least each of them is better than > the two others at something. So why try to ditch any of them for the > sake of package reduction ? This means you'll give up some capabilities. > > Focusing on reducing the number of packages only means that your system > is not yet ready for deployment because you're managing everything by > hand, and that does not scale. > > So I think you should definitely start by deciding how you want to > manage your system, packages and configurations, and once you're done > with that, simply install the 3 and try to build your scalable and > manageable architecture. There are many people on these products' > mailing lists who have a lot of experience (good and bad) with various > models and who can probably suggest what to do and what not to do > depending on your needs. > > Regards, > Willy >
