LVS introduction and usage

I. What is LVS?

The full name of LVS is Linux Virtual Server, that is, Linux Virtual Server. It is an open-source project of Dr. Zhang Wenyu from our country. In linux memory 2.6, it has become a part of the kernel, and earlier kernel versions need to be re-compiled.
Ii. What can LVS do?

LVS is mainly used for multi-server load balancing. It works at the network layer to implement high-performance and high-availability server cluster technology. It is cheap and can combine many low-performance servers to form a super server. It is easy to use, easy to configure, and has a variety of load balancing methods. It is stable and reliable, and does not affect the overall effect even if a server in the cluster fails to work normally. In addition, the scalability is also very good.

Iii. Working Principle

 

For example, LVS can be divided into three parts:

1. Load Balancer: this is the core part of LVS. It is like the Controller of the MVC model of our website. It distributes customer requests to different servers in the next layer according to certain algorithms and does not process specific services on its own. In addition, this layer can monitor the status of the next layer. If a server in the next layer cannot work normally, it will automatically remove it and add it after recovery. This layer consists of one or more ctor servers.

2. Server Array: This layer is responsible for specific services. It can be composed of WEB Server, mail Server, FTP Server, and DNS Server. Note that the Director Server on the upper layer can also be used as the Real server.

3. Shared Storage: Improves the data on the previous layer and maintains data consistency on the previous layer.

Iv. Load Balancing Mechanism
We mentioned above that LVS works at the network layer. Compared with other Server Load balancer solutions, such as DNS domain name rotation resolution, application layer load scheduling, and client scheduling, the efficiency is very high. LVS implements Load Balancing by controlling IP addresses. IPVS is its specific implementation module. IPVS is mainly used to install Director Server and Virtualize an IP address (VIP) for external access on Director Server ). When a user accesses the VIP address and arrives at the Director Server, the Director Server selects a Real Server Based on certain rules, and then returns the data to the client after the processing is complete. These steps cause some specific problems, such as how to select a specific Real Server, and how to return Real Server data to the client. IPVS has three mechanisms:

1.VS/NAT(Virtual Server via Network Address Translation), that is, the Network Address Flip technology implements Virtual Server. When the request arrives, the program processed on the TOR tor server changes the destination address (virtual IP address) in the data packet to a specific Real Server, and the port is also changed to the Real Server port, then, send the packet to the Real Server. After the Real Server processes the data, it needs to return it to the Diretor Server. Then, the Diretor server changes the source address and source port in the data packet to the VIP address and port, and finally sends the data. It can be seen that user requests and responses must go through the TOR tor Server. If there is too much data, the Diretor Server will be overwhelmed.

2.VS/TUN(Virtual Server via IP Tunneling), that is, the IP Tunneling technology implements Virtual servers. It is basically the same as VS/NAT, but the Real server directly returns data to the client without going through the TOR tor server, which greatly reduces the pressure on the Diretor server.

3.VS/DR(Virtual Server via Direct Routing), that is, using Direct Routing technology to implement Virtual servers. Compared with the previous two methods, VS/DR uses different packet forwarding methods to rewrite the MAC address of the request message and send the request to the Real Server, the Real Server directly returns the response to the customer, eliminating the overhead of IP tunneling in VS/TUN. This method has the highest performance among the three Load Scheduling Mechanisms, but both the Director Server and the Real Server must have a network card connected to the same physical network segment.
5. Load Scheduling Algorithm
We all know that Director Server should select different Real servers. If Real server is selected to achieve load balancing, IPVS implements eight scheduling methods, you can view the specific algorithms on the official website or Baidu. Here we will not list them one by one. Official Website: www.linuxvirtualserver.org.
Vi. Specific configuration operations

First, we have three hosts with IP addresses 192.168.132.30 (Diretor server), 192.168.132.64 (Real server 1), and 192.168.132.68 (real server 2 ). The web service has been configured on real server 1 and 2, and we assume there is another external access virtual IP address 192.168.132.254 (VIP ). In addition, ipvsadm has been installed on the Diretor server.
Next we will introduce the detailed configuration process in VS/DR.
The configuration above the TOR tor server:

// First, bind a virtual IP address (also called VIP) to the Director Server to provide external services: Ifconfig eth0: 0 192.168.132.254 broadcast 192.168.132.254 netmask 255.255.255.255 up // to the device eth0: 0 specify a route add-host 192.168.132.254 dev eth0: 0 // enable the system's packet forwarding function echo "1">/proc/sys/net/ipv4/ip_forward // clear the previous settings of ipvsadm-C // Add a new virtual IP record 192.168.132.254, the service duration is 120 seconds between ipvsadm-A-t 192.168.132.254: 80-s rr-p 120 // two new real server records are added to the new virtual IP record, -g is used in VS/DR mode. ipvsadm-a-t 192.168.132.254: 80-r 192.168.132.64: 80-g1_sadm-a-t 192.168.132.254: 80-r 192.168.132.68: 80-g // enable the LVS service ipvsadm

 

Configurations on two real servers:

/* A virtual IP address is bound to the loopback device, and the subnet mask is set to 255.255.255.255, which is used to communicate with the virtual IP address on the ctor Server */ifconfig lo: 0 192.168.132.254 broadcast 192.168.132.254 netmask 255.255.255.255 uproute add-host 192.168.132.254 dev lo: 0 // disable local ARP request echo "1">/proc/sys/net/ipv4/conf/lo/arp_ignoreecho "1">/proc/sys/net/ipv4/ conf/all/arp_ignoreecho "2">/proc/sys/net/ipv4/conf/lo/arp_announceecho "2">/proc/sys/net/ipv4/conf/all/ arp_announce

Then, access http: // 192.168.132.254/on other client hosts. The result is displayed.

Finally, I wrote the SHELL script, which can be downloaded and used.