LVS concept (4 working models, 8 scheduling algorithms)

Overview

LVS, short for Linux Virtual Server, also known as Linux Virtual Server, is a free software project initiated by Dr. Zhang Wensong. LVS is composed of ipvsadm in user space and IPVS in kernel space. ipvsadm is used to define rules, and IPVS uses the rules defined by ipvsadm to work. Now LVS is part of the Linux standard kernel. Before the Linux 2.4 kernel, the kernel must be recompiled to support LVS function modules when using LVS. However, since the Linux 2.4 kernel, the various function modules of LVS have been completely built-in. Apply any patch to the kernel, you can directly use various functions provided by LVS.

The architecture and principle of LB cluster (Load Balance) is very simple, that is, when a user's request comes, it will be directly distributed to the Director Server, and then it will distribute the user's request to the back-end intelligently and evenly according to the set scheduling algorithm. On the real server. In order to avoid different data requested by users on different machines, shared storage needs to be used to ensure that the data requested by all users is the same.

Common concepts in LVS

1. DS: Director Server. Refers to the front-end load balancer node.
2. RS: Real Server. The real working server at the back end.
3. VIP: Request from the outside directly to the user as the target IP address of the user's request.
4. DIP: Director Server IP, the IP address mainly used to communicate with internal hosts.
5. RIP: Real Server IP, the IP address of the back-end server.
6. CIP: Client IP, the IP address of the access client.

LVS consists of 2 parts of programs, including ipvs and ipvsadm.

1. ipvs (ip virtual server): A piece of code that works in the kernel space, called ipvs, is the code that actually takes effect to implement scheduling.
2. ipvsadm: The other section is working in user space, called ipvsadm, responsible for writing rules for the ipvs kernel framework, defining who is the cluster service and who is the real server (Real Server)

The basic working principle of LVS

1. When a user initiates a request to the load balancing scheduler (Director Server), the scheduler sends the request to the kernel space.
2. The PREROUTING chain will first receive the user request, determine that the target IP is the local IP, and send the data packet to the INPUT chain.
3. IPVS works on the INPUT chain. When a user request arrives at INPUT, IPVS will compare the user request with the cluster service that it has defined. If the user request is the defined cluster service, then IPVS will forcibly modify it. The destination IP address and port in the data packet, and the new data packet is sent to the POSTROUTING chain.
4. After the POSTROUTING chain receives the data packet, it finds that the target IP address happens to be its own back-end server, then the data packet is finally sent to the back-end server through routing.

Regarding iptables links and tables, I have an introduction in another blog post: iptables links and tables

Principles and characteristics of NAT mode

Virtual Server via NAT (VS-NAT): Use address translation to implement a virtual server. The address translator has a legal IP address that can be accessed by the outside world. It modifies the address of the outgoing packet from the private network. The outside world looks like the packet comes from an address The converter itself, when an external packet is sent to the converter, it can determine which node on the intranet the packet should be sent to.

1. When a user request reaches the Director Server, the requested data message will first arrive at the PREROUTING chain in the kernel space. At this time, the source IP of the message is CIP, and the destination IP is VIP.
2. PREROUTING checks and finds that the destination IP of the data packet is the local machine, and sends the data packet to the INPUT chain.
3. IPVS compares whether the service requested by the data packet is a cluster service. If so, modify the destination IP address of the data packet to the back-end server IP, and then send the data packet to the POTROUTING chain. At this time, the source IP of the message is CIP, and the destination IP is RIP.
4. The POSTROUTING chain sends data packets to the Real Server through routing.
5. Real Server compares and finds that the target is its own IP, and starts to construct a response message and send it back to Director Server. At this time, the source IP of the message is RIP, and the destination IP is CIP.
6. Before the Director Server responds to the client, it will modify the source IP address to its own VIP address, and then respond to the client. At this time, the source IP of the message is VIP, and the destination IP is CIP.

Features of the LVS-NAT model

characteristic:

• RS should use private address, RS gateway must point to DIP
• DIP and RIP must be in the same network segment
• Support port mapping
• RS can use any operating system
• Save IP address

defect:

• The efficiency is low, the pressure on the Director Server will be relatively large, and the request and response must go through the director server

Principles and characteristics of DR mode

1. When a user request reaches the Director Server, the requested data message will first arrive at the PREROUTING chain in the kernel space. At this time, the source IP of the message is CIP, and the destination IP is VIP.
2. PREROUTING checks and finds that the destination IP of the data packet is the local machine, and sends the data packet to the INPUT chain.
3. IPVS compares whether the service requested by the data packet is a cluster service. If so, modify the source MAC address in the request message to the MAC address of DIP, modify the destination MAC address to the MAC address of RIP, and then send the data packet to the POSTROUTING chain. At this time, the source IP and destination IP are not modified, only the source MAC address is the MAC address of DIP, and the destination MAC address is the MAC address of RIP.
4. Since DS and RS are in the same network, they are transmitted through Layer 2. The POSTROUTING chain checks that the target MAC address is the MAC address of RIP, then the data packet will be sent to the Real Server at this time.
5. RS finds that the MAC address of the request message is its own MAC address, and receives this message. After the processing is completed, the response message is sent to the eth0 network card through the lo interface and then sent out. At this time, the source IP address is VIP and the destination IP is CIP.
6. The response message is finally delivered to the client.

Features of the LVS-DR model

• Feature 1: Ensure that the front-end routing sends all VIP packets with the destination address to Director Server instead of RS.
• RS can use a private address; it can also be a public network address. If you use a public network address, you can directly access RIP through the Internet.
• RS and Director Server must be in the same physical network
• All request messages go through Director Server, but response messages must not pass through Director Server
• Does not support address translation, nor port mapping
• RS can be most common operating systems
• The RS gateway is never allowed to point to DIP (because we do not allow him to pass through the director)
• Configure the IP address of the VIP on the lo interface on the RS
• Defect: RS and DS must be in the same computer room

Feature 1: Implementation plan:

arptables: On the arp level, implement firewall rules during ARP resolution, filtering RS to respond to ARP requests. This is provided by iptables. Modify the kernel parameters (arp_ignore and arp_announce) on the RS to configure the VIP on the RS on the alias of the lo interface, and restrict it from not responding to VIP address resolution requests.

Principle and characteristics of Tun mode

1. When a user request reaches the Director Server, the requested data message will first arrive at the PREROUTING chain in the kernel space. At this time, the source IP of the message is CIP, and the destination IP is VIP.
2. PREROUTING checks and finds that the destination IP of the data packet is the local machine, and sends the data packet to the INPUT chain.
3. IPVS compares whether the service requested by the data packet is a cluster service. If so, encapsulate a layer of IP packet again in the header of the request packet. The source IP is DIP and the destination IP is RIP. Then send it to the POSTROUTING chain. At this time, the source IP is DIP and the destination IP is RIP.
4. The POSTROUTING chain sends the data packet to the RS according to the latest encapsulated IP message (because there is an extra layer of IP header in the outer encapsulation, it can be understood as tunnel transmission at this time). At this time, the source IP is DIP and the destination IP is RIP.
5. After RS ​​receives the message and finds that it is its own IP address, it will receive the message. After removing the outermost IP, it will find that there is a layer of IP header inside, and the target is its own lo interface VIP, then at this time RS starts to process this request, and after the processing is completed, it is sent to the eth0 network card through the lo interface, and then passed out. At this time, the source IP address is VIP and the destination IP is CIP.
6. The response message is finally delivered to the client.

LVS-Tun model characteristics

• RIP, VIP, DIP are all public network addresses
• RS gateway will not and cannot point to DIP
• All request messages go through Director Server, but response messages must not pass through Director Server
• Does not support port mapping
• The RS system must support tunnels,

Principles and characteristics of full-nat mode

Fullnat model features:

• RIP, DIP can use private addresses;
• RIP and DIP can no longer be in the same network, and the RIP gateway does not necessarily need to point to DIP;
• Support port mapping;
• RS OS can use any type;
• Request messages go through Director, and response messages go through Director

Eight scheduling algorithms of LVS

1. Round-robin scheduling rr
   is the simplest algorithm, which is to schedule requests to different servers in a round-robin manner. The biggest feature of this algorithm is simplicity. The polling algorithm assumes that all servers have the same ability to process requests. The scheduler will evenly distribute all requests to each real server, regardless of the back-end RS configuration and processing capabilities, and distribute them in a very balanced manner.

2. The weighted round is called wrr.
   This algorithm has one more weight concept than the rr algorithm. You can set a weight for RS. The higher the weight, the more requests are distributed. The weight range is 0-100. It is mainly an optimization and supplement to the rr algorithm. LVS will consider the performance of each server and add a weight to each server. If the weight of server A is 1, and the weight of server B is 2, then The request dispatched to server B will be twice that of server A. The server with the higher the weight, the more requests it processes.

3. The least link lc
   algorithm will determine to whom the request is distributed based on the number of connections of the backend RS. For example, if the number of RS1 connections is less than the number of RS2 connections, then the request will be sent to RS1 first

4. The weighted least link wlc
   algorithm has a more weighted concept than lc.

5. The least connection scheduling algorithm based on locality, lblc,
   is a scheduling algorithm for requesting the destination IP address of the data packet. The algorithm first searches for the nearest server used by the destination IP address according to the requested destination IP address. If this server Still available and capable of processing the request, the scheduler will try to choose the same server, otherwise it will continue to choose other feasible servers

6. The complex connection algorithm based on the least locality, lblcr
   , does not record the connection record between the target IP and a server. It maintains the mapping relationship between a target IP and a group of servers to prevent a single point of server from being overloaded. .

7. Target address hash scheduling algorithm dh
   This algorithm is based on the target IP address to establish a mapping relationship between the target IP and the server through a hash function. In the event that the server is unavailable or the load is too high, the request sent to the target IP will be sent to The server.

8. The source address hash scheduling algorithm sh is
   similar to the destination address hash scheduling algorithm, but it statically allocates fixed server resources based on the source address hash algorithm.