<<
Recently, my friend Liu Xin’s website successfully launched and went live, achieving hundreds of millions of daily PVs. The front end uses an HAProxy+Keepalived dual-machine setup for load balancing/reverse proxy, and the entire site is very stable. This reinforces my confidence in HAProxy+Keepalived as the go-to load balancer architecture for the web front end. I want to clarify one point here: many friends worry about the stability of software-level load balancers under high concurrent traffic. In reality, through numerous websites we have successfully launched, we’ve found that HAProxy’s stability as a front-end load balancer is excellent, with negligible chances of downtime. Since we often use HAProxy for Layer 7 load balancing, we do notice some CPU consumption under heavy traffic; I recommend using DELL 710 or 910 servers here. Additionally, HAProxy isn’t limited to Layer 7 load balancing—it can also do Layer 4 load balancing. Because, like LVS, it is dedicated purely to load balancing, its traffic forwarding and processing efficiency is certainly superior to Nginx. Nowadays, there’s a plethora of information about LVS and Nginx online, so they naturally draw more attention. HAProxy is also very capable, so friends with load balancing needs should consider trying it out. For a dual-machine high-availability solution, I recommend HAProxy+Keepalived.
LVS has almost become synonymous with load balancing, with its functions and capabilities constantly mythologized. But is LVS really that magical? Some time ago, I was in charge of upgrading an e-commerce website. Due to business and monitoring requirements, each backend web server had over a dozen static routes plus two VLANs. LVS couldn’t meet these needs, whereas Nginx/HAProxy had no issues. As a load forwarder, HAProxy’s performance is superior to Nginx. Also, as many know, due to ARP suppression issues, deploying and maintaining LVS isn’t very simple, but HAProxy/Nginx don’t have these problems. Because LVS still has some shortcomings, Taobao’s tech team has been continuously improving it. In 2012, I had the honor of attending Taobao’s Technology Carnival and listening to Mr. Wu Jiaming’s (Pukong from Taobao) lecture on LVS improvements, where he mentioned LVS’s FULLNAT mode. This is a new forwarding mode that enables cross-VLAN communication between real backend physical servers behind LVS, with both IN/OUT traffic passing through LVS. Moreover, the new FULLNAT has significant improvements in defending against DDOS attacks. Interested friends can check out Mr. Wu Jiaming’s PPT.
Let me give another work example. For an advertising-type website, I was responsible for improving its overall architecture design. To ensure high availability, the company boss initially instructed using F5 as the LB. However, after careful analysis, I found that the initial traffic wasn’t particularly large—daily PVs were under a million—and the site was mainly open during daytime hours, with plenty of monitoring staff (ops and operations personnel were basically all present during the day). So I handled it using DNS round-robin, which proved quite effective and met the goal of saving costs in the early stage. In the later planning stages, I also firmly chose HAProxy over F5 and LVS.
Nowadays, HAProxy has a wide variety of algorithms, not fewer than specialized F5/LVS algorithms. The commonly used ones are the following 8:
1. roundrobin, which means simple round-robin, recommended;
2. static-rr, which means weight-based, recommended;
3. leastconn, which means the server with the fewest connections handles the request first, recommended;
4. source, which means based on the request source IP, similar to Nginx’s ip_hash algorithm, recommended;
5. uri, which means based on the requested URI;
6. url_param, which means based on the requested URL parameters;
7. hdr(name), which means locking each HTTP request based on an HTTP request header;
8. rdp-cookie(name), which means locking and hashing each TCP request based on a cookie(name).
The newer versions of HAProxy are getting more and more powerful, now starting to support HTTPS. I recommend checking the official HAProxy website.
The purpose of writing this article is to promote the use of HAProxy. Tech professionals shouldn’t blindly follow others or rely on hearsay; we should base our arguments on our own production environments and data. I also welcome everyone to discuss the real-world application of HAProxy through my blog and