LVS简单介绍
LVS （Linux Virtual Server）的缩写，其实就是Linux虚拟服务器。在1实际的生产场景，提供一个web服务应用的一般不会是一台web服务器，为了保证业务的可靠性，一般会为业务布置多台服务器来支撑业务，及时有其中的一台或者部分服务器挂掉也不至于导致整个业务无法访问。那么既然存在那么多台web服务器用来提供服务，难道需要用户记下来所有的地址么？当然不是，此时就需要一个前端的调度器，用户只需要记住这个前端的调度器的地址，每回访问的时候去访问调度器就可以了，调度器接收到用户的请求以后会根据自己的算法来判定当前的请求分发给下面的哪一台web服务器，来为用户提供服务。
假如有两台负责同样业务的web机器B和C，A来负责把客户发来的请求分发到B和C上，A就成为Director，或者又叫调度器。调度方案不止一种，也就是接下来呢要说的LVS的几种工作模式。
首先了解几个名词：
VIP：虚拟IP，首先来说每个web服务器肯定都有自己的管理地址，那么为用户提供访问的挂在调度器上的IP就是VIP
RIP：Real IP，即服务器的真实IP地址。
CIP：Client IP，客户端的IP地址。
RS：Real Server，真实服务器
LVS一共有四种负载均衡模式，分别为NAT模式，DR模式，TUN模式，以及FULLNAT模式
用户发送请求数据包，源IP为客户端的IP，目的IP为VIP
当数据包到达LVS的时候，NAT模式下的LVS会对数据包的目的地址进行改写，改为真实服务器的地址，把对应的请求分发下去，此时数据包的源IP依然为CIP，目的IP则改成了RIP。
真实服务器收到用户的请求，对请求进行处理和回复，同时真实服务器的网关地址写的就是LVS的VIP地址，因此它会把客户的请求回复再丢给LVS的调度器，此时数据包的源IP是RIP目的IP是CIP。
当数据转发到调度器以后，同样会对数据包进行一次地址转换，此次转换的地址为数据包的源IP，将源IP中的RIP替换为调度器的VIP，此时数据包中的源为VIP，目的为CIP。
客户收到回复数据包以后进行检查，check ok。
通过上面的过程，其实我们可以发现LVS在NAT模式下进行了两次的地址转换，在IN方向上进行一个DNAT（目的地址转换），在OUT方向上进行了一次SNAT（源地址转换），同时我们也发现，不管是来还是去都要经过调度器，可想而知，如果出现瓶颈的话那么这个调度器肯定是瓶颈之一。
总结：
在NAT模式下，内部web服务器完全可以是内网地址，仅需要在调度器上配置公网地址即可，同时调度器要有内网卡去访问内网web服务器，这个在一定程度上提高了系统的安全性。
内部web服务器的网关要指向LVS的调度器，这样才可以确保报文返回时仍然经过调度器
NAT模式支持IP以及端口的转换，比如我VIP对应的是12.1.1.1:80，可以通过调度器转到内部RS节点的10.0.0.1:8080，这个是DR和TUN模式做不到的。
当访问量很大的时候，调度器会成为瓶颈。
由于数据包来回都要经过调度器，因此要开启内核的net.ipv4.ip_forward=1当然也包括iptables防火墙的forward功能（DR和TUN模式不需要）
NAT模式的加强版本！一定程度上解决了NAT模式低并发的局限性。
如上图：
图片来源：http://blog.csdn.net/mumumuwudi/article/details/47064281
和NAT模式的区别：
和NAT模式不同的地方是，当LB接收到用户发来的请求数据包以后会对CIP和VIP同时进行更改。
当RS再处理完以后把数据返回给LB，LB会将源目IP再一次进行映射，映射成之前的源目IP，LB集群会共同维护地址的映射表，来维护映射关系。（参考淘宝的TOA模式）
构建基于LVS+OSPF+FULLNAT的前端负载均衡架构
LVS-ospf集群
LVS的DR模式是通过改写报文的目标mac地址，然后将请求报文发送给服务器的。真实服务器在响应完请求以后不会再把数据交给调度器而是走自己的路由出取直接将数据返还给客户端。因此DR模式可以极大的提高集群系统的伸缩性，而且没有TUN模式的隧道开销，对集群中的服务器也没有必须支持IP隧道协议的要求。但是有一点，要求LB与真实服务器有一块网卡要在一个局域网环境里。
数据包的处理过程：
客户端发送请求包，源地址为CIP，目的地址为VIP。
LVS收到客户端的请求包以后会把数据包的目标mac地址（VIP的MAC地址）改为要调度的真实服务器的MAC地址。此时源IP仍然为CIP，目的IP仍然为VIP，仅仅是把目标mac做了一个重新封装。
真实服务器收到数据包以后拆开包来一看，发现目标IP不是我的话那么他就会丢包，因此为了避免这个问题，我们把VIP的地址绑定在每一台真实服务器的loopback接口上，RS节点接收到这个请求后一看lo0口的地址匹配，于是对报文进行重新封装。
真实服务器处理完请求以后会直接返回给客户端数据而不再通过调度器。
客户收到回复的数据包，检查完毕，没有问题。
如图 DR模式改写MAC地址的过程
考虑两个个问题：
我客户端去访问你的VIP的时候，会发送ARP请求，那么位于一个局域网的LB和真实服务器是都可以收到ARP广播包的。那么真实服务器和LB上都有VIP地址，谁来回复这个ARP请求呢？按照要求来说肯定是LB去回复这个ARP请求，但是真实服务器也是可以听到这个广播包的，因此如果真实服务器进行了回复就会造成一系列的问题，为了避免这种情况要在真实服务器上一直ARP，我不让真实服务器回应你了，说白了不这么做的话就IP冲突了。
那么为什么这个VIP不绑定在RS的物理网口上，而是绑定在一个逻辑网口上呢？
首先看数据的接受，收到VIP转发数据帧的，不是lo，而是real server的物理网卡。物理网卡收到数据帧之后，拆开看到目的地址是VIP，查找路由表，自己的lo上绑着VIP，说明这个包是自己需要处理的，就把这个活接了，产生响应报文。real server返回给客户端的数据帧，源mac是real server物理网卡的mac，里面的源IP地址是VIP。客户端收到数据帧之后，看到目的mac和目的IP都是自己，就会接收，并不会去检查源mac。将VIP设置在出口网卡上是行不通的,否则会响应客户端的arp request,造成client/gateway arp table紊乱，以至于整个load balance都不能正常工作。
总结：
和NAT不同的是，DR模式的请求回包无需再经过调度器，因此在大并发的情况下，DR模式的使用效率是非常高的。
所有RS节点和调度器只能在一个局域网中，这是局限性。
RS节点的默认网关不需要是调度器LB的DIP，理论上来说，只要是RS能出公网就可以，不一定就非得要给RS配置公网地址。
DR模式仅仅是修改了目标mac，因此LB无法修改报文的目的端口。
针对访问量不大的可以使用haproxy/nginx代替，日2000W PV或并发请求1w以下都可以考虑用ha/nginx
TUN，tunnel mode，隧道模式。其实TUN和DR模式是类似的，只不过到达VIP后处理请求包的方式不一样。同DR模式，数据请求到达RS端以后，RS也是直接返回给客户端而不用再交给LB。
数据包的处理过程：
用户向服务端发起请求，源IP为CIP，目的IP为VIP
LB接收到客户的请求包，为客户的请求包增加一个IP头（RIP），然后直接发给调度的真实服务器，因为新的IP头指向的是RIP，所以RIP能够正确的接收到这个请求报文。
RS节点收到以后拆开包一看，源地址是CIP，目的地址是VIP，这找的还不是我啊，那么就会进行丢包，为了避免这种问题同样是把VIP绑定在lo0上，同时为了避免出现IP冲突的情况也要在RS端上抑制ARP（这一点完全可以参考DR模式的处理过程）。
RS端处理完数据以后，直接将数据返还给客户端，源IP：VIP；目的IP：CIP。
可以发现Tunnel模式其实是和DR模式很类似的，只不过是LB交给RS节点请求包的方式不一样罢了。
总结：
由于回包不必经过LB，因此TUN模式也有比较好执行效率，但是LAN模式下它的转发效率是比不上DR模式的，同时还要考虑到隧道的开销和IP隧道的支持问题
总体来说比NAT要强~
通过直接路由实现虚拟服务器（VS/DR）
http://zh.linuxvirtualserver.org/node/28
LVS/DR模式原理剖析
http://zh.linuxvirtualserver.org/node/2585
原文地址：http://vanjle.blog.51cto.com/9794584/1904646
