3 ms·

This article is a bit low on details, so it's hard to judge the quality of the proposed solution (without having tested a similar setup). We faced the choice o

This article is a bit low on details, so it's hard to judge the quality of the proposed solution (without having tested a similar setup). We faced the choice of either upgrading our aging Foundry load balancers or building our own solution a few years ago and came up with a very stable and scalable setup: 2+ load balances (old web servers sufficed) running Linux and: * wackamole for IP address failover (detects peer failure with very low latency, informs upstream routers; identical setup for all load balancers works, can be tuned to have particular IP addresses preferably on particular load balancer hosts) http://www.backhand.org/wackamole/ http://www.backhand.org/wackamole/ * Varnish for HTTP proxying and load balancing (identical setup on all load balancers) - www.varnish.org * Pound for HTTPS load balancing (identical configuration on all load balancers, can handle SNI, client certificates etc. ...) http://www.apsis.ch/pound/ http://www.apsis.ch/pound/ This scales pretty much arbitrarily, just add more load balancers for more Varnish cache or SSL/TLS handshakes/second. We also have nameservers on all load balancers (also with replicated configuration and IP address failover). Configuration is really easy, only Varnish required some tuning (larger buffers etc.) and Pound (OpenSSL really) was set up carefully for PFS and good compatibility with clients. The only drawback is that actual traffic distribution over the load balancers is arbitrary and thus unbalanced (wackamole assigns the IP addresses randomly unless configured to prefer a particular distribution), but the more IP addresses your traffic is spread out over, the less of a problem this becomes.

phil21 12y ago
This solution works, but as you point out balancing over your load balancers is a huge hack and relies basically on DNS. If you replaced wackamole/DNS RR with BGPd on your varnish/pound boxes, you would achieve the same goals but be able to fully direct your traffic flows yourself vs. a random RFC-busting DNS cache somewhere. The other big downside to this solution is being forced to run a l2 broadcast domain for failover to work. Fine at your scale here, but when you get into dozens or hundreds of switches and larger scale I firmly believe (if at all possible) dropping L3 down to the access port is the way to go. Debugging STP issues on such networks is about the last thing in the world I'd like to be doing on a friday night.
stock_toaster 12y ago
wackamole hasn't been updated in something like 7 years. I would assume it is abandoned at this point. Overlapping pairs (Primary1:Secondary2, Secondary1:Primary2) of keepalived (linux) or carp (bsd) "vrrp" clusters may be better supported these days.

phil21 12y ago

This solution works, but as you point out balancing over your load balancers is a huge hack and relies basically on DNS. If you replaced wackamole/DNS RR with BGPd on your varnish/pound boxes, you would achieve the same goals but be able to fully direct your traffic flows yourself vs. a random RFC-busting DNS cache somewhere. The other big downside to this solution is being forced to run a l2 broadcast domain for failover to work. Fine at your scale here, but when you get into dozens or hundreds of switches and larger scale I firmly believe (if at all possible) dropping L3 down to the access port is the way to go. Debugging STP issues on such networks is about the last thing in the world I'd like to be doing on a friday night.

stock_toaster 12y ago

wackamole hasn't been updated in something like 7 years. I would assume it is abandoned at this point. Overlapping pairs (Primary1:Secondary2, Secondary1:Primary2) of keepalived (linux) or carp (bsd) "vrrp" clusters may be better supported these days.