z0ukun 文章目录
1、DR模型（Director Routing–直接路由）
LVS的DR工作模式，是目前生产环境中最常用的一种工作模式、下图反映了DR模式的整个工作过程，同样为了简单起见，这里的Real Server也只画了一个。如果是多个Real Server的话，LVS会通过调度算法来决定发往哪台Real Server。LVS-DR工作模式的几个关键点在于：
1、被Real Server处理后形成的响应报文，不再回发到LVS节点，而是直接路由给中心交换机然后发送出去。省去了LVS-NAT方式中的LVS回发过程。
2、LVS节点只会改写链路层的报文封装，对网络层和传输层报文是不进行改写的。
3、有网帖说DR工作模式，不能跨子网，也就是说LVS节点和各个Real Server节点必须处于同一个网段中。这是为什么呢？事实又真的是这样吗？很多网络帖子没有回答这个问题，这篇文章马上回答一下（实际上章文嵩先生已经回答过这个问题）。
4、使用DR模式时，需要Real Server设置LVS上的VIP为自己的一个回环IP，不然包会被丢弃。
工作原理：
1、中心交换机采取的IP映射的方式。但是与LVS-NAT方式不一样，Real Server在机房的中心交换机上也需要绑定一个外网映射。这样保证Real Server回发的响应报文能够被发送到外网。
2、LVS节点接收到请求报文后，会改写报文的数据链路层格式。将Target Mac改写成Real Server的Mac，但是网络层和传输层报文不会改写，然后重新回发给交换机。这里就涉及一个问题，现在target Mac和Destination IP的对应关系的错误的，这个数据报文到了交换机后，由于这种错位的关系，是不能进行三层交换的，只能进行二层交换（一旦进行IP交换，数据报文的验证就会出错，被丢弃）。所以LVS-DR方式要求Real Server和LVS节点必须在同一个局域网内，或者这样说更确切：LVS节点需要找到一个二层链路，将改写了Mac地址的报文发送给Real Server，而不能进行三层交换的校验。这样来看，实际上LVS节点和Real Server界面不一定要在同一个子网，您用一个独立网卡独立组网，传送报文也是可行的。
3、通过二层交换，数据被发送到Real Server节点。那么Real Server节点怎么来判断这个包的正确性呢？首先当然是传输层TCP/IP报文校验没有问题，LVS-NAT没有改写TCP/IP，当然校验就没有问题（除非报文本身就存在问题）；然后是链路层的MAC地址能够被识别，这时就是回环IP的功劳了。对于Real Server节点来说，192.168.100.10这个VIP就是自己的回环IP，绑定的MAC也就是被LVS替换后的target mac。那么Real Server会认为这个包是在本机运行的某一个应用程序通过回环IP发给自己的，所以这个包不能被丢弃，必须处理。
4、被处理后的生成的响应报文，被直接发送给网管。只要保证Real server的默认路由设置成到核心交换机的192.168.100.1就可以了。另外，需要说明的是，由于LVS-DR模式并没有更改原有的IP报文和TCP报文，所以LVS-DR模式本身是不支持端口映射的，实际上在日常使用实践中，我们一般使用Nginx做端口映射。
DR的优点：
解决了LVS-NAT工作模式中的转发瓶颈问题，能够支撑规模更大的负载均衡场景。
比较耗费网外IP资源，机房的外网IP资源都是有限的，如果在正式生产环境中确实存在这个问题，可以采用LVS-NAT和LVS-DR混合使用的方式来缓解。
DR的缺点：
配置工作较LVS-NAT方式稍微麻烦一点，您至少需要了解LVS-DR模式的基本工作方式才能更好的指导自己进行LVS-DR模式的配置和运行过程中问题的解决。
由于LVS-DR模式的报文改写规则，导致LVS节点和Real Server节点必须在一个网段，因为二层交换是没法跨子网的。但是这个问题针对大多数系统架构方案来说，实际上并没有本质限制。
2、NAT模型（NetWork Address Translation – 网络地址转换）
NAT方式是一种由LVS Master服务节点收到数据报，然后转给下层的Real Server节点，当Real Server处理完成后回发给LVS Master节点然后又由LVS Master节点转发出去的工作方式。LVS的管理程序IPVSADMIN负责绑定转发规则，并完成IP数据报文和TCP数据报文中属性的重写。
工作原理：
1、在正式的机房环境中，一般有两种方式为一个机器分配外网地址：在核心交换机上直接绑定外网地址到主机网卡的，这样使用ifconfig命令看到的IP地址为外网地址；在核心交换机上使用映射规则，将一个外网地址映射到内网地址，这样使用ifconfig命令看到的IP地址为内网地址。上图中我们采用的是后一种映射规则。如果使用前一种外网IP的分配规则，也不会影响LVS NAT的工作方式，因为这个IP被限制在LVS NAT工作以外。只不过eth1的IP从192.168.100.10换成100.64.92.199而已。
2、我们用中文描述一下转换规则：凡是发送到“192.168.100.10:80”的数据报，目标地址全部改写为“192.168.220.121:8080”，所以来自于100.64.92.199:80的报文被改写了。被改写的属性包括：IP.header.destinationIP、IP.header.checksum、TCP.header.sourcePort、TCP.header.targetPort、TCP.header.checksum。注意IP报文的Source IP不会发生变化，还是“互联网某个IP”。
3、这个包最终被送到了192.168.220.121的8080端口进行处理，并由下层的Real Server生成了返回的数据报（至于这个Real Server是不是“真正的Real Server”，LVS不会关心）。你要问它是怎么被发送过去的，请参考ARP查询协议。
4、注意：因为LVS服务器和Real Server（可能有多个），组成了一个封闭的局域网。除了LVS节点以外，这个子网的任何节点都是无法访问外网的。所以要求192.168.220.121这个Real Server直接把数据报给“互联网某个IP”这个外网地址，显然是不行的，因为在局域网中根本就找不到这个IP。Real Server只能将数据报返给网关，再由网关去寻找这个外网地址。整个服务器中只有LVS节点能够找到这个外网地址，这就是为什么在LVS-NAT工作模式下，所有的Real Server节点必须设置自己的Gateway为LVS节点的原因。
5、收到来源于“192.168.220.121:8080”的数据报文后，IPVS又要进行数据报文的重写了。重写规则是：凡是来源于“192.168.220.121:8080”的数据报，源地址全部改写为“192.168.100.10:80”。于是数据报文的Source IP、Source Port被改写成“192.168.100.10:80”。在外层的核心交换机（或者是机房以外的请求方）看来，LVS接受了数据报，并进行了处理，返回了结果。它并不知道LVS节点的下层还有什么。
NAT的优点：
配置管理简单。LVS-NAT的工作方式是LVS三种工作模式中最容易理解、最容易配置、最容易管理的工作模式。
节省外网IP资源，一般机房分配给使用者的IP数量是有限的，特别是您购买的机架的数量不多时。LVS-NAT工作方式将您的系统架构封装在局域网中，只需要LVS有一个外网地址或外网地址映射就可以实现访问了。
系统架构相对封闭。在内网环境下我们对防火墙的设置要求不会很高，也相对容易进行物理服务器的运维。您可以设置来源于外网的请求需要进行防火墙过滤，而对内网请求开放访问。
另外改写后转给Real Server的数据报文，Real Server并不会关心它的真实性，只要TCP校验和IP校验都能通过，Real Server就可以进行处理。所以LVS-NAT工作模式下Real Server可以是任何操作系统，只要它支持TCP/IP协议即可。
当然作为Linux系统忠实拥护者，我并不建议使用Window服务器。但如果您的Real Server是.Net系统，又有业务场景需要用到LVS，那么LVS-NAT可能是一个不错的选择。
NAT的缺点：
转发点就是瓶颈点。您可以想象100台Real Server将处理结果全部转到一个LVS进行发送是一个怎么样的场景。事实上，LVS-NAT的极限负载是达不到100台Real Server的。
3、IP TUN模型(IP Tunneling – IP隧道)
DR模式和IP TUN模式的工作原理完全不一样，工作场景完全不一样。DR基于数据报文重写，TUN模式基于IP隧道，后者是对数据报文的重新封装。
IPIP隧道就是将一个完整的IP报文封装成另一个新的IP报文的数据部分，并通过路由器传送到指定的地点。在这个过程中路由器并不在意被封装的原始协议的内容。到达目的地点后，由目的地方依靠自己的计算能力和对IPIP隧道协议的支持，打开封装协议，取得原始协议。如下图：
可以说隧道协议就是为了解决跨子网传输准备的，在生产环境中由于业务需要、技术需要或者安全需要，可能使用交换机进行VLAN隔离（即形成若干个虚拟的独立的局域网），我们可能需要LVS节点在局域网A，而需要进行负载的多台Mysql读服务器可能在局域网B中。这个时候，我们就要配置LVS的隧道方式。
注意：目标节点要能够解开隧道协议，Linux支持IPIP隧道协议。
工作原理：
1、一旦LVS节点发现来目标为192.168.100.10VIP的请求，就会使用IPIP隧道协议对这个请求报文进行封装。而不是像LVS-DR模式重写数据报文的MAC信息。如果配置了多个Real Server，那么LVS会使用设置的调度算法确定一个Real Server。
2、重新封装后的IPIP隧道协议报文会重新被回发到路由器，路由器（或三层交换机）会根据设置的LVAN映射情况，找到目标服务器，并将这个IPIP隧道报文发送过去。
3、Real Server收到这个IPIP隧道报文后，会将这个报文进行解包。这里注意一下，一般情况下IPIP隧道报文会进行分片，就如同IP报文分片一样，只是为了讲解方便，我们假定这个报文不需要分片。解压后得到的数据报文就是原来发送给VIP的请求报文。
4、Real Server设置的回环IP，让Real Server认为原始的请求报文是从自己本地的某个应用程序发出的，完成原始报文的校验后，它会对这个报文进行处理。剩下的过程就和LVS-DR相同了，这里就不再进行复述了。
可以说LVS-TUN方式基本上具有LVS-DR的优点。在此基础上又支持跨子网间穿透。这样的敷在方案能够给我们架构师足够的系统设计场景。
4、补充：LVS调度方式
利用一致性Hash算法完成调度
目标地址Hash（DH）：调度算法根据请求的目标IP地址，作为散列键（Hash Key）从静态分配的散列表找出对应的服务器，若该服务器是可用的且未超载，将请求发送到该服务器，否则返回空。
原地址Hash（SH）：根据请求的源IP地址，作为散列键（Hash Key）从静态分配的散列表找出对应的服务器，若该服务器是可用的且未超载，将请求发送到该服务器，否则返回空。
轮询调度
最简轮询（RR）：调度算法将外部请求按顺序轮流分配到集群中的真实服务器上，它均等地对待每一台服务器，而不管服务器上实际的连接数和系统负载。
最少连接轮询（LC）：请注意“最少连接轮询”和“最少连接加权轮询”两种调度算法的区别。调度器通过“最少连接”调度算法动态地将网络请求调度到已建立的链接数最少的服务器上。注意请求肯定会被分配到这台目前连接数最少的Real Server上面，不会考虑几率问题
加权轮询调度：
性能加权轮询（WRR）：调度算法根据真实服务器的不同处理能力来调度访问请求。这样可以保证处理能力强的服务器能处理更多的访问流量。调度器可以自动问询真实服务器的负载情况，并动态地调整其权值。
最少连接数的加权轮询（WLC）：具有较高权值的服务器将承受较大比例的活动连接负载。调度器可以自动问询真实服务器的负载情况，并动态地调整其权值。注意，是按照一个比例，有较高的分配几率，而不是LC一样“肯定分配”。
