1. Introduction to LVS
LVS stands for Linux Virtual Server. It is a free software project initiated by Dr. Wensong Zhang. Its official website is www.linuxvirtualserver.org. LVS is now part of the standard Linux kernel. Before the Linux 2.4 kernel, you had to recompile the kernel to support the LVS functional modules. However, since Linux kernel 2.4, all LVS functional modules have been fully built-in. You can directly use the various functions provided by LVS without applying any patches to the kernel.
The goal of using LVS technology is to achieve a high-performance, high-availability server cluster through the load balancing technology provided by LVS and the Linux operating system. It offers good reliability, scalability, and operability, thereby achieving optimal service performance at a low cost.
Since its inception in 1998, LVS has developed into a relatively mature technology project. LVS technology can be used to implement highly scalable and highly available network services, such as WWW, Cache, DNS, FTP, MAIL, and video/audio on-demand services. Many well-known websites and organizations use cluster systems built with LVS, such as the Linux portal site (www.linux.com), Real (the company famous for providing audio and video services to RealPlayer) (www.real.com), and the world’s largest open-source site (sourceforge.net).
2. LVS Architecture
A server cluster system built using LVS consists of three parts: the front-end load balancing layer, represented by the Load Balancer; the middle server array layer, represented by the Server Array; and the bottom data shared storage layer, represented by Shared Storage. To users, all internal applications are transparent; they are simply using a high-performance service provided by a virtual server.
The LVS architecture is shown in Figure 1:
Figure 1 LVS Architecture
Below is a detailed introduction to the various components of LVS:
飦?Load Balancer Layer: Located at the very front of the entire cluster system, it consists of one or more load schedulers (Director Servers). The LVS module is installed on the Director Server. The main role of the Director is similar to that of a router; it contains the routing tables set to complete the LVS functions. Through these routing tables, user requests are distributed to the application servers (Real Servers) in the Server Array layer. Meanwhile, a monitoring module for Real Server services, Ldirectord, must also be installed on the Director Server. This module monitors the health status of each Real Server service, removing it from the LVS routing table if it becomes unavailable and re-adding it upon recovery.
飦?Server Array Layer: This consists of a group of machines actually running application services. Real Servers can be one or more WEB servers, MAIL servers, FTP servers, DNS servers, or video servers. Each Real Server is connected via high-speed LAN or WAN connections distributed in different locations. In practical applications, the Director Server can also simultaneously act as a Real Server.
飦?Shared Storage Layer: This provides shared storage space and content consistency for all Real Servers. Physically, it typically consists of disk array devices. To provide content consistency, data is usually shared via the NFS network file system. However, NFS performance is often poor in busy business systems. In such cases, cluster file systems can be used, such as Red Hat’s GFS or Oracle’s OCFS2 file system.
From the overall LVS architecture, it is clear that the Director Server is the core of LVS. Currently, the operating systems used for the Director Server can only be Linux and FreeBSD. Linux kernel 2.6 supports LVS functions without any settings, while the application of FreeBSD as a Director Server is not widespread, and its performance is not very good.
For Real Servers, almost all system platforms are supported, including Linux, Windows, Solaris, AIX, and various BSD series.
3. LVS Cluster Features
3.1 IP Load Balancing and Load Scheduling Algorithms
1. IP Load Balancing Technology
There are many implementation schemes for load balancing technology, including methods based on DNS round-robin domain name resolution, client-driven scheduling access, application-layer system load scheduling, and IP address-based scheduling. Among these load scheduling algorithms, the most efficient is the IP load balancing technology.
LVS’s IP load balancing technology is implemented through the IPVS module. IPVS is the core software of the LVS cluster system. Its main function is: installed on the Director Server, it also virtualizes an IP address on the Director Server. Users must access services through this virtual IP address, generally referred to as the LVS VIP (Virtual IP). Access requests first arrive at the load scheduler via the VIP, and then the load scheduler selects a service node from the Real Server list to respond to the user’s request.
How the scheduler sends the request to the Real Server node providing the service after the user’s request arrives, and how the Real Server node returns data to the user, are the key technologies implemented by IPVS. IPVS implements three load balancing mechanisms: NAT, TUN, and DR, detailed as follows:
飦?VS/NAT (Virtual Server via Network Address Translation)
This implements a virtual server using network address translation technology. When a user request arrives at the scheduler, the scheduler rewrites the destination address of the request packet (i.e., the virtual IP address) to the selected Real Server address, and also changes the destination port of the packet to the corresponding port of the selected Real Server. Finally, the packet request is sent to the selected Real Server. After the server processes the data, when the Real Server returns data to the user, it must pass through the load scheduler again to change the source address and source port of the packet back to the virtual IP address and corresponding port. The data is then sent to the user, completing the entire load scheduling process.
It is evident that in NAT mode, both user request and response packets must pass through the Director Server for address rewriting. As user requests increase, the processing capacity of the scheduler will become a bottleneck.
飦?VS/TUN (Virtual Server via IP Tunneling)
This implements a virtual server using IP tunneling technology. Its connection scheduling and management are the same as in VS/NAT mode, but its packet forwarding method differs. In VS/TUN mode, the scheduler uses IP tunneling technology to forward user requests to a specific Real Server, and this Real Server responds directly to the user’s request without going through the front-end scheduler. Furthermore, there are no geographical location requirements for the Real Server; it can be in the same network segment as the Director Server or on an independent network. Therefore, in TUN mode, the scheduler only handles user request packets, greatly improving the throughput of the cluster system.
飦?VS/DR (Virtual Server via Direct Routing)
This implements a virtual server using direct routing technology. Its connection scheduling and management are the same as in VS/NAT and VS/TUN, but its packet forwarding method is different again. VS/DR sends requests to the Real Server by rewriting the MAC address of the request packet, and the Real Server returns the response directly to the client, eliminating the IP tunneling overhead found in VS/TUN. This method offers the highest and best performance among the three load scheduling mechanisms, but it requires that both the Director Server and the Real Servers have a network card connected to the same physical network segment.
2. Load Scheduling Algorithms
As discussed above, the load scheduler dynamically selects a Real Server to respond to user requests based on the load conditions of each server. How is this dynamic selection implemented? This relates to the load scheduling algorithms we will discuss here. Based on different network service requirements and server configurations, IPVS implements the following eight load scheduling algorithms. Here, we detail the four most commonly used ones; please refer to other materials for the remaining four.
飦?Round Robin
The “Round Robin” scheduling algorithm, also known as 1:1 scheduling, allocates external user requests sequentially in a 1:1 ratio to each Real Server in the cluster. This algorithm treats every Real Server equally, regardless of the actual load status and connection status on the servers.
飦?Weighted Round Robin
The “Weighted Round Robin” scheduling algorithm dispatches access requests based on the different processing capabilities of the Real Servers. Different scheduling weights can be set for each Real Server. Relatively better-performing Real Servers can be set with higher weights, while those with weaker processing capabilities can be set with lower weights. This ensures that servers with stronger processing capabilities handle more access traffic, fully and reasonably utilizing server resources. Additionally, the scheduler can automatically query the load status of Real Servers and dynamically adjust their weights.
飦?Least Connections
The “Least Connections” scheduling algorithm dynamically dispatches network requests to the server with the fewest established connections. If the real servers in the cluster system have similar system performance, using the “Least Connections” scheduling algorithm can achieve better load balancing.
飦?Weighted Least Connections
“Weighted Least Connections” is a superset of “Least Connections.” Each service node can have a corresponding weight representing its processing capability, and system administrators can dynamically set these weights (default weight is 1). When assigning new connection requests, Weighted Least Connections scheduling tries to ensure that the number of established connections on a service node is proportional to its weight.
The other four scheduling algorithms are: Locality-Based Least Connections, Locality-Based Least Connections with Replication, Destination Hashing, and Source Hashing. The meanings of these four scheduling algorithms will not be described further in this article. If you wish to delve deeper into these remaining four scheduling strategies, you can visit the Chinese LVS site zh.linuxvirtualserver.org for more detailed information.
3.2 High Availability
LVS is a kernel-level application software, hence it possesses very high processing performance. A load balancing cluster system built with LVS offers excellent processing capabilities. The failure of any individual service node does not affect the normal operation of the entire system, while simultaneously achieving reasonable load balancing, providing the application with ultra-high load service capacity and supporting millions of concurrent connection requests. For example, with a 100Mbps network card and VS/TUN or VS/DR scheduling technology, the throughput of the entire cluster system can reach up to 1Gbits/s; with a Gigabit network card, the system’s maximum throughput can approach 10Gbits/s.
3.3 High Reliability
LVS load balancing cluster software has been widely adopted in enterprises, schools, and other industries. Many large, critical web sites both domestically and internationally use LVS cluster software, so its reliability has been well proven in practice. Many load balancing systems built with LVS have run for long periods without ever requiring a restart. This demonstrates the high stability and reliability of LVS.
3.4 Applicable Environments
LVS currently supports only Linux and FreeBSD systems for the front-end Director Server, but it supports most TCP and UDP protocols. Applications supporting the TCP protocol include: HTTP, HTTPS, FTP, SMTP, POP3, IMAP4, PROXY, LDAP, SSMTP, etc. Applications supporting the UDP protocol include: DNS, NTP, ICP, video/audio streaming protocols, etc.
LVS has no restrictions on the operating system of Real Servers. Real Servers can run on any operating system supporting TCP/IP, including Linux, various Unix systems (such