A Detailed Guide to Load Balancers: Nginx vs. LVS vs. HAProxy Pros and Cons

            One approach is to use hardware-based load balancers, such as the relatively expensive commercial devices like F5 and Array. Their advantage is having a professional maintenance team to support these services, but the downside is the significant cost, making them unnecessary for smaller-scale network services for now. The other approach involves open-source, free load balancing software based on Linux, such as Nginx/LVS/HAProxy. These are implemented at the software level, so the cost is very low.

Currently, a relatively reasonable and popular architecture scheme for websites is: using Nginx/HAProxy + Keepalived as the load balancer on the front-end; and using a MySQL database architecture with one master and multiple slaves and read-write separation, employing LVS+Keepalived. Of course, the plan must be formulated based on the specific project requirements.
Below, let’s discuss their respective characteristics and applicable scenarios.

The advantages of Nginx are:

1. It operates above Layer 7 of the network, allowing for traffic distribution strategies tailored to HTTP applications, such as by domain name or directory structure. Its regular expression rules are more powerful and flexible than HAProxy’s, which is a major reason for its current widespread popularity. This capability alone makes Nginx applicable in far more scenarios than LVS.
2. Nginx has very low dependency on network stability. Theoretically, if a server can be pinged, Nginx can perform load balancing, which is another advantage. Conversely, LVS has a higher dependency on network stability; this is something I have deeply experienced firsthand.
3. Nginx installation and configuration are relatively simple, and testing is convenient. It basically prints errors to logs. LVS configuration and testing take considerably longer, as LVS relies heavily on the network.
3. It can handle high-load stress while remaining stable. With decent hardware, it can generally support tens of thousands of concurrent connections, and its load level is relatively lower than LVS.
4. Nginx can detect internal failures in servers through port checks, such as by monitoring the status codes returned by web pages or timeouts. It will resubmit failed requests to another node. However, a downside is that it does not support health checks via URL. For instance, if a user is uploading a file and the node handling that upload fails during the process, Nginx will switch the upload to another server to restart it. LVS, on the other hand, would simply drop the connection. If it were a very large or very important file, this could lead to user dissatisfaction.
5. Nginx is not only an excellent load balancer/reverse proxy software but also a powerful Web application server. The LNMP stack has also become a very popular web architecture in recent years, offering great stability even in high-traffic environments.
6. Nginx is increasingly maturing as a web reverse acceleration cache, being faster than traditional Squid servers. You can consider using it as a reverse proxy accelerator.
7. Nginx can be used as a middle-layer reverse proxy, a level where it essentially has no rivals. The only software comparable to Nginx here is lighttpd, but lighttpd has not yet achieved the full functionality of Nginx, its configuration is not as clear and readable, and its community resources are far less active than Nginx’s.
8. Nginx can also serve as a static web page and image server, where its performance is unrivaled. Additionally, the Nginx community is very active, and many third-party modules are available.

The disadvantages of Nginx are:
1. Nginx only supports HTTP, HTTPS, and Email protocols, which narrows its scope of application; this is a drawback.
2. Its health checks for backend servers only support detection via port, not via URL. It does not support direct Session persistence, but this can be resolved through ip_hash.

LVS: Utilizes the Linux kernel cluster to implement a high-performance, high-availability load balancing server, boasting excellent Scalability, Reliability, and Manageability.

The advantages of LVS are:
1. Strong load resistance, working above Layer 4 of the network solely for distribution purposes, generating no traffic of its own. This characteristic determines its position as the strongest performer among load balancing software, with relatively low consumption of memory and CPU resources.
2. Low configurability, which is both a disadvantage and an advantage. Since there isn’t much to configure, it requires less hands-on management, significantly reducing the chance of human error.
3. Stable operation. Because of its strong inherent load resistance, it has a complete dual-machine hot-standby solution, such as LVS+Keepalived. However, in our project implementations, the most used scheme is LVS/DR+Keepalived.
4. No traffic flow. LVS only distributes requests, and traffic does not flow out from it. This ensures that the IO performance of the balancer is not affected by large traffic volumes.
5. Wide application range. Because LVS operates at Layer 4, it can perform load balancing for almost all applications, including HTTP, databases, online chat rooms, and more.

The disadvantages of LVS are:
1. The software itself does not support regular expression processing and cannot perform dynamic/static content separation. Many modern websites have strong requirements in this area, which is where the advantage of Nginx/HAProxy+Keepalived lies.
2. If the website application is quite large, implementing LVS/DR+Keepalived can become complex, especially if there are Windows Server machines in the backend. The implementation, configuration, and maintenance process can be quite complicated; relatively speaking, Nginx/HAProxy+Keepalived is much simpler.

The characteristics of HAProxy are:>>
x;” />2. Advantages of HAProxy can supplement some of Nginx’s shortcomings, such as supporting session persistence and cookie-based guidance; it also supports detecting backend server status by fetching a specified URL.
3. HAProxy is similar to LVS in that it is purely a load balancing software; in terms of pure efficiency, HAProxy offers faster load balancing speeds than Nginx and also outperforms Nginx in concurrent processing.
4. HAProxy supports TCP protocol load balancing forwarding, which can balance the load for MySQL read operations, detect and balance backend MySQL nodes. You can use LVS+Keepalived to achieve load balancing for MySQL master-slave setups.
5. HAProxy offers a wide variety of load balancing strategies, with the following 8 algorithms currently available:
① roundrobin: simple round-robin, needless to say, this is a basic feature of almost all load balancers;
② static-rr: weight-based scheduling, recommended for attention;
③ leastconn: processes the server with the fewest connections first, recommended for attention;
④ source: based on the request source IP, similar to Nginx’s IP_hash mechanism; we use this as one method to solve session issues, recommended for attention;
⑤ ri: based on the request URI;
⑥ rl_param: based on the request URL parameter ’balance url_param’ requires an URL parameter name;
⑦ hdr(name): locks each HTTP request based on the HTTP request header;
⑧ rdp-cookie(name): locks and hashes each TCP request based on the cookie(name).

Summary Comparison of Nginx and LVS:
1. Nginx operates at Layer 7 of the network, so it can implement distribution strategies targeting the HTTP application itself, such as by domain name or directory structure. In contrast, LVS does not possess such capabilities, making Nginx alone usable in far more scenarios than LVS. However, these useful features make Nginx more tunable than LVS, which means frequent tinkering is often required, and more tinkering increases the chance of human error.
2. Nginx has less dependency on network stability; theoretically, as long as a ping goes through and web pages load normally, Nginx can connect—this is a major advantage! Nginx can also distinguish between internal and external networks. If a node has both internal and external network access, it’s like having a backup line for a single machine. LVS, on the other hand, is more dependent on the network environment. Currently, the best results are ensured when servers are within the same network segment and LVS uses the direct routing method. Also, note that LVS requires applying for at least one additional IP from the hosting provider to serve as the Virtual IP; it seems you cannot use the server’s own IP as the VIP. To be a good LVS administrator, one must continuously learn a lot about network communication, which goes far beyond just HTTP.
3. Nginx is relatively simple to install and configure, and testing is very convenient because it can basically log errors. LVS installation, configuration, and testing take significantly longer; LVS relies heavily on the network, and often configuration failures are due to network issues rather than configuration problems, making troubleshooting correspondingly more troublesome.
4. Nginx can also handle high loads and is stable, but its load capacity and stability are several levels below LVS: Nginx processes all traffic and is therefore limited by the machine’s IO and configuration; its own bugs are also inevitably hard to avoid.
5. Nginx can detect server internal failures, such as those based on the status code returned by the server processing a webpage, timeouts, etc., and will resubmit requests that return errors to another node. Currently, ldirectd in LVS also supports monitoring based on internal server conditions, but the principle of LVS prevents it from resending requests. For example, if a user is uploading a file, and the node handling the upload fails exactly during the upload process, Nginx will switch the upload to another server for reprocessing, whereas LVS would simply drop the connection. If the file being uploaded is very large or very important, this could frustrate the user.
6. Nginx’s asynchronous processing of requests can help reduce the load on backend servers. If Apache provides services directly to the outside world, many narrow-band links will cause the Apache server to occupy a large amount of memory that cannot be released. Using an additional Nginx as a reverse proxy for Apache will block these narrow-band links, preventing Apache from accumulating too many requests, thus saving considerable resources. Using Squid has a similar effect; even if Squid itself is configured not to cache, it still greatly helps Apache.
7. Nginx supports HTTP, HTTPS, and Email (the email function is rarely used). LVS supports a wider range of applications than Nginx in this regard. In practice, the strategy most commonly adopted at the very front-end should be LVS, meaning the DNS should point to the LVS load balancer. LVS’s advantages make it very suitable for this task. Important IP addresses are best entrusted to LVS, such as database IPs, webservice server IPs, etc. The usage scope of these IP addresses expands over time, and changing them will lead to cascading failures. Therefore, entrusting these important IPs to LVS is the most prudent approach, the only downside being the requirement for a larger number of VIPs. Nginx can be used as a node machine behind LVS, leveraging both Nginx’s features and its performance. Of course, Squid can also be used directly at this level, but Squid’s functionality is considerably weaker than Nginx’s, and its performance is also somewhat inferior. Nginx can also serve as a middle-layer proxy, where it is virtually unrivalled. The only contender that could shake Nginx is lighttpd, but lighttpd has yet to achieve full feature parity with Nginx, and its configuration is not as clear and readable. Additionally, the IP of a middle-layer proxy is also important, so the most perfect solution is for the middle-layer proxy to also have a VIP and LVS. Specific applications require specific analysis. For relatively small websites (daily PV < 10 million), Nginx alone is completely sufficient. If you have quite a few machines, you can also use DNS round-robin; LVS consumes relatively more machines. For large websites or critical services, when machine resources are not a concern, consider leveraging LVS more often.

The current use of network load balancing evolves with the growth of a website’s scale, employing different technologies at different stages:

Stage 1: Use Nginx or HAProxy for single-point load balancing. At this stage, the server scale has just moved beyond the single-server, single-database model and requires some load balancing, but the scale is still small, without a professional maintenance team or the need for large-scale website deployment. Using Nginx or HAProxy is the first choice here, as these tools are quick to learn and easy to configure, working at Layer 7 using the HTTP protocol. This is the first choice at this stage.

Stage 2: As network services further expand, a single-point Nginx is no longer sufficient. At this time, using LVS or a commercial solution like Array becomes the primary choice. Nginx then serves as a node behind LVS or Array. The specific choice between LVS or Array depends on the company’s size and budget. Array’s application delivery capabilities are very powerful; I have used it in a project, and its cost-performance ratio is far higher than F5, making it the top commercial choice! Generally speaking, at this stage, the relevant talent pool cannot keep up with business growth, making the purchase of commercial load balancing a necessary path.

Stage 3: At this point, network services have become a mainstream product. As the company’s visibility further expands, the capabilities and number of relevant talents also increase. Now, whether for developing custom solutions suited to one’s own products or for reducing costs, the open-source LVS becomes the first