Both LVS and Nginx can be used as multi-machine load balancing solutions. Each has its own advantages and disadvantages, and in production environments, careful analysis of the actual situation is needed to make good use of them.
First, a reminder: in technology, never blindly follow what others say, repeating what you hear without thinking. At the same time, don’t lean too conservative, overly trusting old methods while waiting for others to do the guinea pig testing for you. Developing a good habit of delving into every good thing you hear about immediately, thereby improving your understanding and expertise in technology, is essential.
Let’s analyze and compare the two:
I. Advantages of LVS:
1. Strong load resistance: LVS operates on a very simple logic, working at Layer 4 of the network only for request distribution, with no traffic passing through it. So efficiency is hardly a concern. In my hands, LVS has only had one issue: during a brief period of peak concurrency, the balancer experienced packet loss, which was determined to be a network problem — the NIC or the Linux 2.4 kernel had reached its capacity limit, while memory and CPU consumption were basically negligible.
2. Low configurability: This is usually a disadvantage but also an advantage. Because there aren’t many configurable options, except for adding or removing servers, you don’t need to touch it often, greatly reducing the chance of human error.
3. Stable operation: Because of its strong load resistance, high stability comes naturally. Additionally, various LVS implementations have complete dual-machine hot-standby solutions, so there’s no need to worry about the balancer itself having issues. If a node fails, LVS will automatically detect it, making the overall system very stable.
4. No traffic: As mentioned above. LVS only distributes requests, and traffic does not pass through it itself, so this can be used for line distribution. Having no traffic also ensures the balancer’s I/O performance is not affected by heavy traffic.
5. Supports virtually all applications: Since LVS works at Layer 4, it can perform load balancing for almost all applications, including HTTP, databases, chat rooms, and more.
Additional note: LVS cannot completely determine node failures either. For example, under WLC allocation, if one node in the cluster doesn’t have a VIP configured, the entire cluster becomes unusable. Using WRR allocation in this case would just drop one machine. This issue is still under further testing. So, one must remain cautious when using LVS.
II. Comparison Results between Nginx and LVS
1. Nginx works at Layer 7 of the network, so it can implement distribution strategies specific to HTTP applications, such as by domain name, directory structure, etc. In contrast, LVS doesn’t have such capabilities. So Nginx alone has far more applicable scenarios than LVS just on this point. However, Nginx’s useful features make it more adjustable than LVS, meaning it needs to be touched frequently. Looking at LVS’s 2nd advantage, more touching means a higher chance of human error.
2. Nginx has less dependency on the network. Theoretically, as long as you can ping through and web pages are accessible, Nginx can connect. Nginx can also distinguish between internal and external networks. If a node has both internal and external networks, it’s equivalent to having a backup line on a single machine. LVS is more dependent on the network environment. Currently, it seems that when servers are on the same subnet and LVS uses Direct routing for distribution, the results are more reliably achieved. Also note, 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 machine’s own IP as the VIP. To be a good LVS administrator, you really need to keep learning a lot about network communication — it’s no longer just about HTTP.
3. Nginx installation and configuration are relatively simple, and testing is convenient because it can basically print errors in logs. LVS installation, configuration, and testing take considerably longer because, as mentioned above, LVS is more dependent on the network. Many configuration failures are due to network issues rather than configuration issues, and troubleshooting is correspondingly much more troublesome.
4. Nginx can also withstand high loads and remain stable, but its load capacity and stability are several levels below LVS: Nginx handles all traffic, so it’s limited by machine I/O and configuration. Its own bugs are also hard to avoid. Nginx doesn’t have a ready-made dual-machine hot-standby solution, so running on a single machine carries higher risk — single-machine scenarios are always uncertain.
5. Nginx can detect internal server failures, such as based on HTTP status codes returned by the server, timeouts, etc., and will resubmit failed requests to another node. Currently, LVS’s ldirectord can also monitor internal server conditions, but LVS’s principle means it cannot resend requests. Regarding request retransmission: for example, if a user is uploading a file and the node handling the upload happens to fail during the process, Nginx will switch the upload to another server for reprocessing, while LVS would simply drop the connection. If it’s a large or very important file, the user would likely be quite frustrated.
6. Nginx’s asynchronous request handling can help reduce load on backend servers. If Apache is used directly for external service, many narrow-band connections will cause the Apache server to consume large amounts of memory without releasing it. Using an additional Nginx as an Apache proxy, these narrow-band connections will be blocked by Nginx, preventing excessive requests from piling up on Apache and thus reducing considerable memory usage. Using Squid achieves the same effect — even if Squid itself is configured not to cache, it still greatly helps Apache. LVS doesn’t have these capabilities, so no comparison can be made.
7. Nginx supports HTTP and email (the email feature is presumably rarely used). LVS supports more applications than Nginx in this regard.
In practice, the strategy generally adopted at the front end should be LVS, meaning DNS should point to the LVS balancer. LVS’s advantages make it very suitable for this task.
Important IP addresses are best managed by LVS, such as database IPs, web service server IPs, etc. Over time, the usage scope of these IP addresses grows larger, and replacing IPs would bring cascading failures. So entrusting these important IPs to LVS management is the safest approach, the only downside being that more VIPs are needed.
Nginx can be used as an LVS node machine, allowing you to leverage Nginx’s features on one hand and its performance on the other. Of course, Squid can also be used directly at this layer; Squid’s functionality is considerably weaker than Nginx’s, and its performance is somewhat inferior to Nginx as well.
Nginx can also serve as a middle-tier proxy, where it essentially has no rivals. The only one that could challenge Nginx would be lighttpd, but lighttpd has not yet achieved full feature parity with Nginx, and its configuration is not as clear and readable. Additionally, the middle-tier proxy’s IP is also important, so having the middle-tier proxy also equipped with a VIP and LVS is the most ideal solution.
Nginx can also serve as a static web server, though this goes beyond the scope of this article; just a brief mention.
Specific applications need specific analysis. For relatively small websites (daily PV <10 million), Nginx alone is perfectly sufficient. If you have many machines, DNS round-robin can be used. LVS consumes considerably more machines. For large-scale websites or important services, when machines aren’t a concern, consider making greater use of LVS.