Linux cluster (i)-lvs-four types of work models

Servers to provide services externally, when a server under too much pressure, then the service may be caused by the service is not available, so we should let a server under the pressure of reasonable scope, if a server can not meet the requirements, then scale out using multiple servers to apportion these pressures, These servers serve as a whole and distribute the pressure, then we can call these servers "load Balancer cluster".

LVS is the abbreviation for Linux virtual server, which is the Linux virtualization server. LVS is now a part of the Linux standard kernel, from the Linux2.4 kernel, has fully built-in LVS of the various functional modules, no need to patch the kernel, you can directly use the various features of LVS. LVS in the kernel name is Ipvs, as the NetFilter module exists, the Management Ipvs tool for Ipvsadm.

LVS is a four-layer load balancer, that is, based on the fourth layer of the OSI model-the transport layer, where our familiar Tcp/udp,lvs support tcp/udp load balancing. Since LVS is a four-layer load balancer, it is very efficient compared to other high-level load balancing solutions, such as DNS domain name rotation resolution, application layer load scheduling, and client scheduling.

For the convenience of follow-up discussion, here first explain the next few nouns

VS: Virtual Server, Scheduler, responsible for scheduling

RS: Real server, which is responsible for truly providing services to back-end servers

VIP: The public IP on the LVS server, which is virtual IP

DIP: The intranet IP on the LVS server, which is the director IP

RIP: Intranet IP on Real server

CIP: IP for client

Working principle:

VS, according to the target IP and target protocol and Port of the request message, forwards its dispatch to a certain RS, and selects Rs according to the scheduling algorithm.

working mode of LVS :

NAT :

SNAT: Modify Source Address

DNAT: Modify Destination Address

DR: Modifying the target MAC

TUN: Add a new IP header outside the original request IP message

Fullnat: Modify the source and destination IP of the request message

Working position of LVS

Incoming packets

Lvs-nat mode:

IP conversion process in Lvs-nat messages

As shown:

1. the client request will be sent to the LVS host, at this time, the client request message source IP is CIP, the target IP is LVS VIP

2. when the LVS receives the client's request message, the target IP in the request message is modified to the back end of a realserver rip, specifically which realserver rip, depending on the specific algorithm used by LVS

3. when Realserver receives the corresponding request message, it will find that the target IP of the message is its own rip, so it will receive the message and respond after processing. The source IP of the response message is RIP, and the target IP is the CIP

4. when the LVS receives the corresponding response message, LVS will change the source IP of the response message to VIP, the target IP will not become CIP, so the response message is sent to the client.

5. the client receives a response message, the source IP is the VIP, the port is 80, and the LVS is transparent relative to the client.

Lvs-nat's advice:

(1) Rip and dip recommendations in the same IP network, and should use the private network address;RS gateway to dip(no other devices in the middle)

(2) The request message and the response message must be forwarded via LVS, andLVs is easy to become a system bottleneck. But also to meet the general requirements

(3) support port mapping , can modify the request message destination port

(4)vs must be a Linux system , RS can be any OS system

LVS-DR mode:

LVS default mode. Direct routing, the most widely used, is forwarded by re-encapsulating a Mac header for the request message.

In DR mode, the LVS and RS clusters are required to bind to the same VIP(RS is implemented by binding the VIP to the loopback),

The request message is accepted by LVS, and the response message is returned to the user directly by Realserver (RS) without the LVS. Therefore,DR mode has better performance and is also the most widely used load balancing method in large-scale websites.

The source Mac is the Mac of the interface where the dip is located,

The Target Mac is the MAC address of the interface where the rip of RS is chosen by the scheduling algorithm;

Source ip/port, and destination ip/port remain unchanged

LVS and each RS are equipped with VIP

IP and Mac conversion process in LVS-DR messages

As shown:

1. the client request will be sent to the LVS host, at this time, the client request message source IP is CIP, the target IP is LVS VIP

2. when the LVS receives the request message from the client, it modifies the source Mac in the request message to the Mac of the network card where the local dip is located, and modifies the target Mac to be the Mac of the back end of a realserver rip, specifically which realserver rip, Depends on the specific algorithm used by LVS. Other modifications are not made.

3. when the realserver receives the corresponding request message, because the realserver will bind the address of the VIP on the lo of the machine, and will have the same IP address as the LVS in the same network because the ARP related parameters are modified in the kernel. Therefore, when the request message is received, the target IP of the message is the VIP, so the message is received and processed without the LVS response. The source IP of the response message is the VIP, the target IP is CIP, the source MAC address is the Mac that the RS sends the packet, the target Mac is the closest route Mac.

4. the client receives a response message, the source IP is the VIP and the port is 80. The conversion process is transparent relative to the client.

Because the VIP exists simultaneously in the same network, the Realserver response rules must be changed for the APR message.

Method 1: Use the Arptables tool on the RS

# arptables-a in-d $VIP-j DROP

# arptables-a out-s $VIP-j mangle--mangle-ip-s $RIP

Method 2: Modify the kernel parameters on the RS to limit the ARP notification and response level (recommended)

Arp_announce = 2

Arp_ignore = 1

LVS-DR's advice:

(1) Realserver's RIP is recommended to use a private network address. RIP and dip are in the same IP network;RIP gateways cannot point to dipsto ensure that response messages do not go through vs

(2) LVs and RS are to be in the same physical network. You cannot schedule a physical network across geographies.

(3) The request message passes VS, but the response message does not pass VS, and the Realserver is sent directly to the client

(4) port mapping not supported (port cannot be modified)

(5) Realserver can use most OS systems

(6) vs can be as long as a network card, configure VIP and dip, pay attention to the routing trend.

Lvs-tun mode:

Forwarding mode of work, do not modify the IP header of the request message, and in addition to the original IP packet to encapsulate an IP header (the source IP is a dip, the target IP is RIP), send the message to the selected target Realserver;realserver direct response to the client (the source IP is the VIP, Target IP is CIP)

IP header conversion process in Lvs-tun messages

As shown:

1. the client request will be sent to the LVS host, at this time, the client request message source IP is CIP, the target IP is LVS VIP

2. when the LVS receives the request message from the client, it encapsulates a new IP header based on the original request message, the dip of the source IP is native, the target IP is the rip of a realserver on the back end, and specifically which Realserver rip, Depends on the specific algorithm used by LVS. Other modifications are not made.

3. when the realserver receives the corresponding request message, when the request message is received, it will find that the target IP of the message is its own rip, so it will receive the message and processed without the LVS to respond. The source IP of the response message is the VIP and the target IP is CIP.

4. the client receives a response message, the source IP is the VIP and the port is 80. The conversion process is transparent relative to the client.

Lvs-tun's advice:

(1) DIP, VIP, RIP should be the public address (or have cross-network communication support)

(2) RS Gateway cannot point to dip

(3) The request message goes through VS, but the response is not via vs

(4) port mapping not supported

(5) The Realserver OS must support tunnel function. Relative to Dr Mode, there is a cross-regional physical network scheduling.

Lvs-fullnat mode:

Forwarding work. Forward by simultaneously modifying the source IP address and destination IP address of the request message.

IP header conversion process in Lvs-fullnat messages

As shown:

1. the client request will be sent to the LVS host, at this time, the client request message source IP is CIP, the target IP is LVS VIP

2. when the LVS receives the client's request message, the source IP is modified to the local dip, and the target IP in the request message is modified to the back end of a realserver rip, specifically which realserver rip, depending on the specific algorithm used by LVS

3. when Realserver receives the corresponding request message, it will find that the target IP of the message is its own rip, so it will receive the message and respond after processing. The source IP of the response message is RIP and the target IP is dip

4. when the LVS receives the corresponding response message, the LVS will change the source IP of the response message to the VIP, the target IP is modified to CIP, and the response message is sent to the client.

5. the client receives a response message, the source IP is the VIP, the port is 80, and the LVS is transparent relative to the client.

Lvs-fullnat's advice:

(1) VIP is the public address, RIP and dip is the private network address, and usually not the same IP network; therefore, RIP gateways generally do not point to dip

(2) The source address of the request message received by RS is a dip, so just respond to the dip, but vs also sends it to the client

(3) The request and response messages are through VS,LVs is easy to become a system bottleneck. But also to meet the general requirements

(4) Support port mapping

Note: This type of kernel is not supported by default

Linux cluster (i)-lvs-four types of work models