Servers provide services to the outside, when a server too much pressure to bear, then the service could generate case service is not available, so we should let the pressure on one server within reasonable limits, if a server can not meet demand , you can scale multiple servers share these pressures, these servers when a whole to provide services, and assessed as pressure, then we can call these servers as "load balancing cluster."
LVS is referred to as the Linux Virtual Server, which is the Linux Virtual Server. Now LVS is already part of the standard Linux kernel, the kernel Linux2.4 later, LVS has been completely built of various functional modules, without having to make any kernel patch, you can directly use the various functions provided by LVS. LVS in the kernel name is ipvs, as the netfilter module is present, ipvs management tool for ipvsadm.
LVS load balancing is four, that is built on the fourth layer of the OSI model - above the transport layer, there is the familiar TCP / UDP, LVS supports TCP / UDP load balancing on the transport layer. Because LVS load balancing is four, so it is relative to other high-level load balancing solutions, such as alternate DNS domain name resolution, application layer load scheduling, client scheduling, its efficiency is very high.
To facilitate follow-up to explore, where the first explain a few terms under
VS: Virtual Server, the scheduler is responsible for scheduling
RS: Real Server, responsible for providing real services, back-end servers
VIP: LVS public IP on the server, namely Virtual IP
DIP: LVS IP network on the server, namely Director IP
RIP: IP network on the Real Server
CIP: client IP
working principle:
The VS request packet destination IP and destination port and protocol which was forwarded to a dispatch RS, RS according to the scheduling algorithm to select.
LVS operating modes:
NAT :
SNAT: modifying the source address
DNAT: modify the destination address
DR: modify the destination MAC
TUN: In addition to the original request IP packets plus a new IP header
FULLNAT: modification request packets based on source and destination IP
LVS working position
LVS-NAT mode:
LVS-NAT IP packet conversion process
As shown in the figure:
1. The request will be sent to the client host LVS this case, the client's request to the CIP source IP, destination IP of the VIP LVS
2. When LVS receiving the request of the client, the request will target IP packet is modified to a RealServer of the back-end RIP, the RIP which RealServer specifically, depending on the specific algorithm used by LVS
3. When responding RealServer corresponding request packet is received, the packet will find that his destination IP RIP, then it will be received and processed. Response packets based on source IP, compared with RIP, compared with the target IP CIP
4. When the LVS receives a corresponding response packet, the response packet LVS will modify the source IP VIP, unchanged destination IP CIP, thus the response packet is sent to the client.
5. The client will receive the response packet, the source IP of the VIP, port 80, and the LVS with respect to clients, the conversion process is transparent.
Advantages: a cluster of physical servers can use any support TCP / IP operating system, physical server can be assigned a reserved private Internet addresses, only the load balancer need a valid IP address.
Cons: Limited scalability. When the server node (ordinary PC server) increase the number to 20 or more, the load balancer will become the bottleneck of the whole system, because all the request packets and response packets need to go through the load balancer regeneration.
LVS-NAT recommendations:
(1) RIP and DIP recommendations on the same IP network, and private network addresses should be used; the RS gateway to point DIP (no other intermediate devices)
(2) request messages and response messages must be forwarded via the LVS, LVS easily become a system bottleneck. But also to meet the general needs
(3) support port mapping, you can modify the target PORT request packet
(4) VS must be a Linux system, RS may be any OS system
LVS-DR Mode:
LVS default mode. Direct route, the most widely used, is forwarded through a re-encapsulated request packet MAC header.
RS needs LVS and bound to the same cluster VIP DR mode (RS VIP binding by the loopback implementation),
请求报文由 LVS 接受，响应报文不经过 LVS，由RealServer(RS）直接返回给用户。因此，DR 模式具有较好的性能，也是目前大型网站使用最广泛的一种负载均衡手段。
源MAC是DIP所在的接口的MAC，
目标MAC是调度算法选出的RS的RIP所在接口的MAC地址；
源IP/端口，以及目标IP/端口均保持不变
LVS和各RS都配置有VIP
LVS-DR报文中IP和MAC转换过程
上图所示：
1.客户端的请求会发往LVS主机，此时，客户端请求报文的源IP为CIP，目标IP为LVS的VIP
2.当LVS收到客户端的请求报文时，会将请求报文中的源MAC修改为本机的DIP所在网卡的MAC,把目标MAC修改为后端某个RealServer的RIP的MAC，具体为哪个RealServer的RIP，取决于LVS使用的具体算法。其他不作修改。
3.当RealServer收到对应的请求报文时，因为RealServer会在本机的LO上绑定了VIP的地址，并且会因为在内核中修改了ARP相关参数从而在同一网络中同时拥有了与LVS同样的IP地址，因此在接收到请求报文时会发现报文的目标IP就是自己的VIP，于是就会接收报文并处理后不经过LVS进行响应。响应报文的源IP则为VIP，目标IP则为CIP，源MAC地址则为RS发送数据包的MAC，目标MAC则为最近的路由MAC。
4.客户端则会收到响应报文，源IP为VIP，端口为80。而LVS相对于客户端而言，转换过程是透明的。
优点：负载均衡器也只是分发请求，应答包通过单独的路由方法返回给客户端。与LVS-TUN相比，LVS-DR这种实现方式不需要隧道结构，因此可以使用大多数操作系统做为物理服务器。
缺点：要求负载均衡器的网卡必须与物理网卡在一个物理段上。
因为VIP在同一网络中同时存在，必须改变RealServer 对APR报文响应规则
方法1：在RS上使用arptables工具
# arptables -A IN -d $VIP -j DROP
# arptables -A OUT -s $VIP -j mangle --mangle-ip-s $RIP
方法2：在RS上修改内核参数以限制arp通告及应答级别 (推荐)
arp_announce = 2
arp_ignore = 1
LVS-DR的建议：
(1) RealServer的RIP建议使用私网地址。RIP与DIP在同一IP网络；RIP的网关不能指向DIP，以确保响应报文 不会经过VS
(2) LVS和RS要在同一个物理网络。不能跨地域物理网络调度。
(3) 请求报文要经由VS，但响应报文不经由VS，而由RealServer直接发往Client
(4) 不支持端口映射（端口不能修改）
(5) RealServer可使用大多数OS系统
(6) VS可以只要一块网卡，同时配置VIP和DIP，注意路由走向。
LVS-TUN模式：
转发方式工作，不修改请求报文的IP首部，而在原IP报文之外再封装一个IP首部（源IP是DIP，目标IP是RIP），将报文发往挑选出的目标RealServer；RealServer直接响应给客户端（源IP是VIP，目标IP是CIP）
LVS-TUN报文中IP包头转换过程
上图所示：
1.客户端的请求会发往LVS主机，此时，客户端请求报文的源IP为CIP，目标IP为LVS的VIP
2.当LVS收到客户端的请求报文时，会在原请求报文基础上再封装一个新的IP包头，源IP为本机的DIP，目标IP为后端某个RealServer的RIP，具体为哪个RealServer的RIP，取决于LVS使用的具体算法。其他不作修改。
3.当RealServer收到对应的请求报文时，在接收到请求报文时会发现报文的目标IP就是自己的RIP，于是就会接收报文并处理后不经过LVS进行响应。响应报文的源IP则为VIP，目标IP则为CIP。
4.客户端则会收到响应报文，源IP为VIP，端口为80。而LVS相对于客户端而言，转换过程是透明的。
优点：负载均衡器只负责将请求包分发给物理服务器，而物理服务器将应答包直接发给用户。所以，负载均衡器能处理很巨大的请求量，这种方式，一台负载均衡能为超过100台的物理服务器服务，负载均衡器不再是系统的瓶颈。
缺点：这种方式需要所有的服务器支持"IP Tunneling"(IP Encapsulation)协议。
LVS-TUN的建议：
(1) DIP, VIP, RIP都应该是公网地址(或具备跨网络通讯支持)
(2) RS的网关不能指向DIP
(3) 请求报文要经由VS，但响应不能经由VS
(4) 不支持端口映射
(5) RealServer的OS须支持隧道功能。相对DR模式来讲，具备跨地域物理网络调度。
LVS-FULLNAT模式：
转发工作。通过同时修改请求报文的源IP地址和目标IP地址进行转发。
LVS-FULLNAT报文中IP包头转换过程
上图所示：
1.客户端的请求会发往LVS主机，此时，客户端请求报文的源IP为CIP，目标IP为LVS的VIP
2.当LVS收到客户端的请求报文时，会将源IP修改为本机的DIP，同时将请求报文中的目标IP修改为后端某个RealServer的RIP，具体为哪个RealServer的RIP，取决于LVS使用的具体算法
3.当RealServer收到对应的请求报文时，会发现报文的目标IP就是自己的RIP，于是就会接收报文并 处理后进行响应。响应报文的源IP则为RIP，目标IP则为DIP
4.当LVS收到对应的响应报文时，LVS会将响应报文的源IP修改为VIP，目标IP修改为CIP，于是响应报文被发往客户端。
5.客户端则会收到响应报文，源IP为VIP，端口为80，而LVS相对于客户端而言，转换过程是透明的。
LVS-FULLNAT的建议：
(1) VIP是公网地址，RIP和DIP是私网地址，且通常不在同一IP网络；因此，RIP的网关一般不会 指向DIP
(2) RS收到的请求报文源地址是DIP，因此，只需响应给DIP；但VS还要将其发往Client
(3) 请求和响应报文都经由VS，LVS易于成为系统瓶颈。但是也能满足一般需求
(4) 支持端口映射
注意：此类型kernel默认不支持