Realization of LVS-NAT and LVS-DR Mode

Realization of LVS-NAT and LVS-DR Mode

Implementation of LVS in Linux

To use LVS in linux kernels earlier than 2.4.23, you need to re-compile the kernel and install patches, later, LVS directly entered the kernel and used grep-I-C 5 ipvs/boot/config-'uname-R' to check whether ipvsadm works in the user space/ipvs works in the kernel space, the ipvsadm function defines a cluster service and REALSERVER, view cluster services-t tcp-based cluster services-u udp-based cluster services-f firewall-based cluster services-A Add A service-E modify A service-s Scheduling Algorithm default WLC-g LVS-DR direct routing model-I LVS-TUN tunnel model-m LVS-NAT model-C clear rules-R recover rules from a file-S save to file-L/l -n: View and define cluster services to add or modify cluster services: ipvsadm-A | E-t | u | f VIP: port-s scheduling algorithm deletes A cluster service: ipvsadm-D-t | u | f VIP: portrealserver add or modify REALSERVER: ipvsadm-a | e-t | u | f VIP: port-r REALSERVER [: port]-g |-I |-m [-w weight] delete a REALSERVER: ipvsadm-d-t | u | f VIP: port-r REALSERVER [: port] ####################################### ####################################
Configure LVS-NAT

Here, the HTTP service is used as an example. The front-end server configures the VIP to respond to requests from the customer. the backend two realservers run the WEB service and configure the same webpage on the two backend web servers, set the DIP that the gateway directs to the front-end server.
Configuration on director
Echo 1> proc/sys/net/ipv4/ip_forward enable route forwarding
Ipvsadm-A-t 192.168.0.1: 80-s rr defines A cluster service. This VIP address should be an Internet address in actual applications.
Ipvsadm-a-t 192.168.0.1: 80-r 192.168.1.2-m
Ipvsadm-a-t 192.168.0.1: 80-r 192.168.1.3-m add two realservers
View ipvsadm-L-n
Ipvsadm-E-t 192.168.0.1: 80-s wlc Setting Algorithm to wlc
Ipvsadm-e-t 192.168.0.1: 80-r 192.168.1.2-m-w 4 set the weight to 4, that is, 1.2 server performance is 4 times that of 1.3 Server
AB-c-n 10000 http: // 192.168.0.1/index.html use the AB command for testing.
Watch-n 1 'wait SADM-L-n' refresh every second to view the status change. We can see that 1.2 of the server's Response count is basically 4 times that of 1.3 servers.

######################################## ##################################
Configure LVS-DR

In a model such as VS/DR or VS/TUN application (all machines are on the same physical network), all machines (including Director and RealServer) all use an additional IP address, that is, VIP.

When a client sends a connection request to the VIP, the request must be connected to the Director VIP, not the RealServer. The main goal of LVS is to assign Director to schedule these connection requests to the RealServer. Therefore, after the Client sends a connection request to the VIP, Director can only send its MAC address to the Client (or it may be a routing device directly connected to Director ), director updates ipvsadm table to track the connection and forwards it to one of the backend realservers.

If a RealServer responds to a Client request when a connection is established to the VIP, the Client establishes a peer relationship between the VIP and the RealServer in its MAC table, and even conduct subsequent communications. In this case, the Client seems to have only one RealServer and cannot realize the existence of other servers.

To solve this problem, you can do it by setting its forwarding rules on the router (static MAC-IP binding ). Of course, if you do not have the permission to access the vro and make relevant settings, you can only solve this problem through the traditional local method.
These methods include:
1. Prohibit the RealServer from responding to ARP requests to the VIP;
2. Hide the VIP addresses on the RealServer so that they cannot obtain ARP requests on the network;
3. Based on "Transparent Proxy" or "fwmark (firewall mark )";
4. Disable ARP requests from RealServers;

Traditionally, the solution to ARP problems can be implemented based on network interfaces or hosts. Linux uses a host-based approach, because it can work well in most scenarios, but LVS does not belong to one of these scenarios, so it was quite troublesome to implement this function in the past. Now you can set arp_ignore and arp_announce, which is much simpler.
Linux 2.2 and 2.4 (versions earlier than 2.4.26) have different methods to solve the "ARP problem" and are troublesome. Fortunately, the 2.4.26 and 2.6 kernels introduce two new signs for adjusting the ARP stack.
(Device flags): arp_announce and arp_ignore. In the DR/TUN environment, arp_announce = 2 and arp_ignore = 1/2/3 can be used for all IPVS-related settings to solve the "ARP problem. The following is an official description:
Arp_annouce: Define different restriction levels for announcing the local source IP address from IP packets in ARP requests sent on interface;
0-(default) Use any local address, configured on any interface.
1-Try to avoid local addresses that are not in the target's subnet for this interface.
2-Always use the best local address for this target.

Arp_ignore: Define different modes for sending replies in response to specified ed ARP requests that resolve local target IP address.
0-(default): reply for any local target IP address, configured on any interface.
1-reply only if the target IP address is local address configured on the incoming interface.
2-reply only if the target IP address is local address configured on the incoming interface and both with the sender's IP address are part from same subnet on this interface.
3-do not reply for local address configured with scope host, only resolutions for golbal and link addresses are replied.
4-7-reserved
8-do not reply for all local addresses
Arp_announce: defines the limit level when the network card declares its MAC-IP outward
There are three values:
0: the default value. No matter which network adapter receives the ARP request, the system responds as long as it finds that the local host has this MAC.
1: Try to avoid responding to ARP requests where the MAC is not the local Nic. One host has multiple NICs, and one Nic receives the ARP request, it is found that the requested MAC is another network card of the local machine. In this case, the network card that receives the ARP request tries its best to avoid responding.
2: always use the most suitable Nic to respond. One host has multiple NICs, one of which receives the ARP request and finds that the requested MAC is another Nic of the local host, at this time, the NIC that receives the ARP request will not respond. Only when the requested MAC is found to be its own
Arp_ignore: defines the response level of the NIC when responding to an external ARP request.
There are 8 values, but we only use 2
0: the default value. No matter which network adapter receives the ARP request, the system responds as long as it finds that the local host has this MAC.
1: always use the most suitable Nic to respond. One host has multiple NICs, one of which receives the ARP request and finds that the requested MAC is another Nic of the local host, at this time, the NIC that receives the ARP request will not respond. Only when the requested MAC is found to be its own

On RealServers, the VIP is configured on the local loopback interface lo. If the packet that is returned to the Client is routed to the eth0 interface, arp notice or use eth0. Therefore, you need to define the following configuration in the sysctl. conf file:
Vim/etc/sysctl. conf
Net. ipv4.conf. eth0.arp _ ignore = 1
Net. ipv4.conf. eth0.arp _ announce = 2
Net. ipv4.conf. all. arp_ignore = 1
Net. ipv4.conf. all. arp_announce = 2
The preceding options must be performed before VIP is enabled. Otherwise, you must clear the arp table on Drector to use LVS normally.

The data packet that arrives at ctor first passes through PREROUTING, and then the route finds that its target address is the address of a local interface. Therefore, the data packet is sent to the INPUT (LOCAL_IN HOOK ). Running
The ipvs (always monitoring LOCAL_IN HOOK) process in the row kernel will find that this packet requests a cluster service because its target address is VIP. Therefore, the original route of this packet to the Local Machine (Director) is changed to be sent to the RealServer through the postrouting hook. This process of changing the normal route of a data packet is implemented according to the IPVS table (defined by the Administrator through ipvsadm.

If multiple realservers exist, in some application scenarios, Director also needs to send requests from the same client to the Realserver that is allocated for the first time based on Connection Tracing, to ensure the integrity of the request. The Connection Tracing function is implemented by Hash table. For details about attributes such as the Hash table size, run the following command:
# Ipvsadm-lcn
To ensure its timeliness, the "Connection Tracing" Information in Hash table is defined as "survival time ". LVS defines three timers for recording "connection timeout:
1. Idle TCP session;
2. the TCP session after the client is normally disconnected;
3. connectionless UDP data packets (record the interval between the two sent data packets );
The default values of the above three timers can be modified by commands similar to the following, and the values following them correspond to the preceding three timers in sequence:
# Ipvsadm -- set 28800 30 600

When a packet is sent from Direcotr to the Realserver, only the target MAC address (changed to the MAC address of the Realserver) is changed ). After the Realserver receives the data packet, it routes the data packet to the local loopback device according to the local route table. Then, it listens to the service on the local loopback device VIP to process the incoming database accordingly, then, the processing result is returned to RIP, but the original address of the packet is still VIP.

Configure the topology as follows:

1. DIP needs to be configured on the interface, VIP needs to be configured on the Interface alias on the front-end server (configure VIP) ifconfig eth0: 0 $192.168.0.1 broadcast $192.168.0.1 netmask 255.255.255.255 uproute add-host $192.168.0.1 dev eth0: 0 route add-host $192.168.1.1 dev eth0echo 1>/proc/sys/net/ipv4/ip_forward2. the configuration RIP on the REALSERVER must be configured on the interface, and the VIP must be configured on the lo alias to define the kernel parameters, disable response to ARP broadcast requests to VIP 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 configure VIPifconfig lo: 0 $192.168.0.1 broadcast $192.168.0.1 netmask 255.255.255.255 uproute add-host 192.168.0.1 dev lo: 0 make sure that if the requested target IP address is $ VIP, the source address of the outgoing packet is also displayed as $ VIP3. configure and start the service ipvsadm-A-t 192.168.0.1: 80-s wlc ipvsadm-a-t 192.168.0.1 on the front-end server: 80-r 192.168.1.2-g-w 4 ipvsadm-a-t 192.168.0.1: 80-r 192.168.1.3-g-w 2 ipvsadm-L-nab-c-n 10000 http: // 192.168.0.1/index.html watch-n 1 'ipvsadm-L-n' this article permanently updates the link address: