LVS working mode and working principle

about LVS

The LVS is a Linux virtual server, a virtual servers for Linux, and a "multiple machine LB IP" for a virtualized server cluster . The LVS cluster is divided into three tiers: Load Scheduler (balancer): It is the entire LVS cluster external front-end machine, responsible for sending client requests to a set of servers [multiple lb IP] execution, while the client side is considered to return to a single IP "usually this IP Called Virtual IP/VIP server pool: A set of servers that really perform client requests, typically our web servers, and Ftp,mail,dns shared storage (GKFX stored) In addition to the Web: it is a server Pool provides a shared storage area, which makes it easy for the server pool to have the same content and provide the same service [not very understanding]

LVS has 4 commonly used patterns, respectively speaking about the difference between the 4 mode:
LVS DR Mode the network structure of the DR (Direct Routing) mode:

2. Basic principles of work:

(1). Client sends a PV request to VIP;VIP receive this request will be with the LVS set LB algorithm to choose a lb reasonable realserver, and then the request of the package's MAC address modified to Realserver MAC address The following is the basic format of our communications package:

The package in this communication has six main fields :src mac, dst mac, src IP, src prot, DST IP, DST IP; now the DST Mac in this packet is LVS VIP Nic Mac [only known DSP IP and DSP mac when the TCP three handshake is complete]
The DR mode changes the DST Mac in the packet to the MAC address of the Realserver, and then the VIP broadcasts the packet to the current LAN, so make sure the VIP and all realserver are in the same network segment in advance, Over the LAN.

The same network segment: With the subnet mask to achieve, we know that our network has a LAN, a LAN has a lot of machines, these LAN all the machines are common an external network IP; How do we define this LAN? Use is the network segment number, IP is only a 32-bit binary number, the 32 bits are divided into: network bit + host bit, the expression in the subnet mask is: Network bit is 1, the host bit is 0; so the network bit = IP bitwise AND subnet mask ; So, we're putting realserver on the LVS. , the DR Mode needs to be confirmed and the IP is within the same network segment.
The ARP protocol will send this packet to the real Realserver "find machine based on Mac" to create a hash table for this src IP----->realserver MAC address; This connection is not disconnected before The request sent by the same client is sent to this realserver by querying the hash table; Realserver receive this Pachet, first determine whether the DST IP is its own IP address; if not, drop the packet. If it is, dispose of the package. Therefore, the DR mode must also bind the VIP IP address on all realserver machines:

      /sbin/ifconfig lo:0 inet VIP netmask 255.255.255.255   -----> This should be noted.

This realserver found that the package DST itself can identify "Bound 2 IP", will handle this packet, after processing the packages of the Src Mac dst mac src IP DST IP is modified and then sent to the VIP via ARP, through the VIP   Sent to the client. Realserver the package format sent to the VIP:

Realserver after processing this package, it will be sent to client IP directly with DST for client IP, without LVS, this is more efficient, but there are security vulnerabilities.

The fundamentals of the LVS DR work package details: http://os.51cto.com/art/201105/264303.htm 3. LVS Dr Mode Note: LVS VIP and Realserver must be in the same network segment , or all the packages will be discarded after the broadcast: in advance to confirm lvs/hardware lb is what mode, whether the need to be in the same network segment all the Realse   RVer must be bound to the VIP IP address , otherwise realserver received the package found that DST is not their own I fear, all packages will be discarded. Realserver after processing the package directly sent to the client through the DST IP, not through the lvs/to meet the IP of such a LVS/VIP efficiency will be a little higher. "It's not very safe to leak the Realserver IP to the outside world."
LVS NAT Mode the network structure of the LVS NAT mode:

2. The basic principle of NAT mode: simulation diagram of how NAT mode works:

client:202.100.1.2
vip:202.103.106.5

realserver:172.16.0.2 172.16.0.3 provides HTTP and FTP services respectively

(1). First the client sends the request [package] to the VIP;

       Package #client sent to VIP:
       SOURCE 202.100.1.2:3478  edst   202.103.106.5:80

(2). After receiving the package, the VIP selects a suitable realserver based on the LB algorithm set by LVS and modifies the package's DST IP to Realserver:

       # VIP sent to Realserver package:
        SOURCE   202.100.1.2:3478  edst   172.16.0.3:8000

(3). Realserver received this package after judging the DST IP is their own, on the processing of the packages, after processing the packet sent to the LVS VIP:

       # Realserver Package:
        SOURCE   172.16.0.3:8000  edst     202.100.1.2:3478    # LVS sent to VIP after processing completed When you receive this package, you find that DST IP is not your own and will not be lost. I feel a mistake.

(4). LVS After receiving this package, change the Sorce IP to VIP IP,DST IP to client IP and send it to client:

       Modify the package Sourceip sent to the client after #VIP收到package:
       SOURCE   202.103.106.5.80:80  edst   202.100.1.2:3478

3. Nat Mode considerations: NAT Mode is modified by the DST IP, go directly to switch or pub do not need to modify the Mac so, do not need VIP and Realserver in a network segment. The NAT mode for both the package and package out requires LVS, so LVS may become a system bottleneck. LVS full NAT mode the fundamentals of full natt:

Full NAT not only replaces the package's DST IP when the client requests the VIP, but also replaces the SRC IP of the package, but also replaces the SRC IP when the VIP returns to the client, or the graph for the working reason of the NAT mode above. How at works:

(1). First the client sends the request [package] to the VIP;

       Package #client sent to VIP:
       SOURCE 202.100.1.2:3478  edst   202.103.106.5:80

(2). After receiving the package, the VIP will select a suitable realserver based on the LB algorithm set by LVS, then change the package's DST IP to realserver; convert sorce IP to LVs cluster's lb IP

       # VIP sent to Realserver package:
        SOURCE   172.24.101.135[lb IP]  edst   172.16.0.3:8000

(3). Realserver received this package after judging the DST IP is their own, on the processing of the packages, after processing the packet sent to the LVS VIP:

       # Realserver The package that was sent to the VIP after processing was completed:
        SOURCE   172.16.0.3:8000  edst     172.24.101.135[This IP is a machine of the LVS VIP cluster]   

(4). LVS After receiving this package, change the Sorce IP to VIP IP,DST IP to client IP and send it to client:

       Modify the package Sourceip sent to the client after #VIP收到package:
       SOURCE   202.103.106.5.80:80  edst   202.100.1.2:3478

2. Considerations for full NAT mode:Full NAT mode also does not require LBIP and realserver IP in the same network segment;
The advantage of full NAT compared to NAT is that the RS return package must be able to return to LVS, because the source address is lvs--> indeterminate
Full NAT performance is 10% lower than NAT mode due to updating the Sorce IP
LVS IP tunnel mode network structure diagram for IP tunnel mode:

2. Fundamentals of IP tunnel mode:

or the basic framework of NAT mode to illustrate the fundamentals of tunnel mode:

(1). First the client sends the request [package] to the VIP;

       Package #client sent to VIP:
       SOURCE 202.100.1.2:3478  DST   202.103.106.5:80

(2). After receiving the package, the VIP selects a suitable realserver based on the LB algorithm set by LVS and wraps the package sent by the client into a new IP packet; DST for the new IP packet is realserver IP

       # VIP sent
        to Realserver package: Client sent packet  DST   172.16.0.3:8000

(3). Realserver received this package after judging the DST IP is itself, and then resolves out of the package DST is VIP, will detect our network card is to help the VIP IP address, if you help will deal with this packet, if not directly discarded. We usually lo:0 on the realserver. The IP address of the VIP is bound and can be processed

       # Realserver processing is completed and sent directly to the client response package:
        SOURCE   172.16.0.3:8000  DST      202.100.1.2:3478  "Client IP"

3. Note For IP tunnel mode:Tunnel mode must be on all realserver machines to bind VIP IP address tunnel mode VIP------>realserver packet communication through the tunnel mode, both the intranet and the external network can communicate, so do not need LVS VIP with Realserver in the same network segment tunnel mode Realserver will send packet directly to the client will not give LVs tunnel mode walk tunnel mode, so the operation is more difficult, so generally do not

the difference between LVS DR, Nat, full NAT, IP tunnel mode: whether to need LVS VIP with Realserver in the same network segment:

DR mode because only modify the package's MAC address through the situation of ARP broadcast to find Realserver, so require LVS VIP and realserver IP must be in the same network segment, that is, when the VIP is mounted to confirm the LVS working mode, If the DR Mode needs to confirm that the IP can only hang under this LVS.

Other modes because it modifies the IP address of the DST IP to Realserver, it does not need to be within the same network segment
2. Whether you need to bind the LVS VIP IP address in realserver:

Realserver receive the package will determine whether the DST IP is its own IP, if not directly lose the packet, because Dr Mode DST is not modified or LVS VIP, so need to bind Vip;ip tunnel above the Realserver   Mode just repack the package one layer, realserver resolution of the IP packet DST is still the VIP of LVS, also need to bind VIP on the Realserver, the others do not need 3. Performance comparisons for four modes:

Because the DR Mode TP Tunell mode is the LVS in the package in, the package out is directly returned to the client, so the performance of the two is higher than the NAT mode, but the IP tunnel is more complex than the tunnel mode and its performance is inferior to Dr mode; Full NAT mode because not only the DST IP is replaced but the SOURCE IP is replaced, so performance is 10% less than NAT

So, the performance of the 4 mode is as follows: DR--and IP tunnel--->nat-----The accumulation of >full NAT LVs in practice 1. LVS does not actively disconnect

For example, the client through the LVS VIP with long link to access the server, even if we have the LVS below the realserver status.html file deleted; The request through LVS and this realserver link will not be LVS

To wait until the client disconnects itself, "during the client's active disconnection, the client can communicate with the realserver normally"; there is a benefit when the network jitter; LVs does not frequent traffic truncation, to different RS above