Linux Load Balancer--lvs (IPVS)

I. Introduction of LVS

LVS is a short name for Linux virtual server, the Linux web, is a free software project initiated by Dr. Zhangwensong and is now part of the Linux standard kernel. LVS is a TCP/IP-based load balancing technology that has high forwarding efficiency and the ability to process millions of concurrent connection requests.

The IP load balancing technology of LVS is realized by Ipvs module. Ipvs module is the core software module of LVS cluster, it is installed in the LVS cluster as the main node of load balancing, virtual out an IP address and port to provide services externally. The user accesses this virtual service (VS) and then the access request is dispatched by the load balancer (LB) to the back-end Real Server (RS), which is actually processed by RS to respond to the user's request.

Ii. three modes of forwarding for Ipvs

Depending on the load Balancer forwarding client requests and RS return response mechanism, the Ipvs forwarding mode is divided into three types: Nat,dr,fullnat. (There is also an IP tunnel mode, IP channel technology, less contact)

1. Dr Mode (Direct Routing)

In Dr Mode, after the client's request packet reaches the virtual service IP port of the load balancer, the load balancer does not overwrite the IP and port of the request packet, but overwrites the MAC address of the back-end RS with the request packet's MAC address, then forwards the packet, and the response packet is returned directly to the client after the real server processes the request. The load balancer is no longer being passed. Therefore, the DR mode is the highest forwarding efficiency, especially for large downstream traffic scenarios, such as the request for video and other big files.

Features of Dr Mode:

• The source/destination IP port does not change during the LB forwarding process of the packet

LB simply overwrites the MAC address of the packet with the MAC address of RS and forwards it to the corresponding Rs.

• The LB virtual service IP must be bound to the loopback adapter on each RS

Because LB forwards does not overwrite the destination IP of the packet, the destination IP of the packet received by RS is still the virtual service IP of lb. To ensure that the RS is able to handle the packet correctly instead of discarding it, the LB virtual service IP must be bound on the RS loopback network card. This allows RS to assume that the virtual service IP is its own IP and is capable of handling this packet. Otherwise RS will discard the packet directly!

• The business process on the RS must be listening on the virtual service IP of the loopback adapter, and the port must be consistent with the virtual service port on LB

Because LB does not overwrite the destination port of the packet, the monitoring port of the RS service must be the same as the virtual service port, otherwise the RS will reject the packet directly.

• When the RS finishes processing the request, the response is returned directly to the client, no longer passing lb

Since the source IP of the request packet received by RS is the IP of the client, it is natural that the RS response will be returned directly to the client without going through lb. This time the network between the RS and the client is required to be accessible.

• LB and Rs must be on the same subnet

Since LB needs to overwrite the MAC address of the packet during the forwarding process, it should be able to query the Mac of the Rs. To get to the Mac of RS, you need to ensure that both are on a subnet, otherwise lb can only get the MAC address of the RS gateway.

2. Nat Mode (Network Address translation)

In NAT mode, both the request packet and the response packet need to be processed by lb. When the client's request arrives at the virtual service, LB makes the destination address translation (DNAT) for the request packet, overwriting the destination IP of the request packet with the IP of Rs. When the response from RS is received, LB makes source address translation (SNAT) of the response packet, overwriting the source IP of the response packet to the IP of lb.

Features of NAT mode:

• LB modifies the address of the packet

Dnat is performed for the request package, and Snat is performed for the response package.

• LB will pass through the client IP to RS (DR Mode will also pass through)

Although LB does a NAT conversion during forwarding, it is able to see the client IP in the request packet that RS receives because it only makes part of the address forwarding.

• You need to configure the default gateway address of RS as a floating IP address for LB

Because the RS received the request package IP is the client's IP, in order to ensure that the response packet can go to lb on return, it is necessary to configure the default gateway address of RS as the virtual service IP address of LB. Of course, if the client's IP is fixed, you can also add a detail route to the virtual service IP on the RS to the LB, without changing the default gateway.

• LB and Rs must be on the same subnet, and clients cannot be on the same subnets as Lb/rs

Because you need to configure the default gateway of RS as the virtual service IP address of LB, you need to ensure that lb and Rs are on the same subnet.

And because it is necessary to ensure that the RS response packet can go back to lb, the client cannot be on the same subnet as Rs. Otherwise RS directly can get to the client's Mac, the response packet directly back to the client, will not go to the gateway, will not go to lb above. At this time because there is no lb do snat, the client receives the response package IP is RS IP, and the client's request packet destination IP is LB virtual service IP, this time the client cannot recognize the response packet, will be discarded directly.

　　

Linux Load Balancer--lvs (IPVS)