LVS 介绍
LVS 是Linux Virtual Server 的简写，即linux虚拟服务器，是一个虚拟的服务器集群系统，可以在UNIX/LINUX平台下实现的负载均衡集群功能，该项目在1998年5月由章文嵩博士组织成立，是中国国内最早出现的自然软件之一。
官网：http://www.linuxvirtualserver.org/zh/
Linux虚拟服务器，我们使用该软件配置lvs时候，不能直接配置内核中的ipvs，而是需要使用ipvs的管理工具进行管理，当然，也可以通过keepalived等软件直接管理ipvs，而不是通过ipvsadm来管理ipvs
ipvs的管理工具ipvsadm管理ipvs
LVS：
1.实现调度的工具IPVS
2.管理工具ipvsadm
3.keepalived实现管理及高可用
名称解析
虚拟IP地址VIP VIP为Director用于向客户端计算机提供服务的IP地址（向外提供服务的IP）
Virtual ip Address
真实IP地址 RIP 在集群下面节点使用的IP地址，物理服务器IP地址。
Real Server Ip Address
Director的IP地址 DIP Director用于连接外网的IP地址，物理网卡地址，是负载均衡服务器上的IP
Director IP Address
客户端主机IP地址客户端计算机请求集群服务器的IP地址，用做发送集群的请求的源IP地址
Client IP Address
LVS集群内部的节点称为只是服务器RS，也叫集群节点。
#######################################################
IP虚拟服务器软件IPVS
在调度器的实现技术中，IP负载均衡技术是效率最高的。在已有的IP负载均衡技术中有通过网络地址转换（Network Address Translation）将一组服务器构成一个高性能的、高可用的虚拟服务器，我们称之为VS/NAT技术（Virtual Server via Network Address Translation），大多数商品化的IP负载均衡调度器产品都是使用此方法，如Cisco的LocalDirector、F5的Big/IP和 Alteon的ACEDirector。在分析VS/NAT的缺点和网络服务的非对称性的基础上，我们提出通过IP隧道实现虚拟服务器的方法VS/TUN （Virtual Server via IP Tunneling），和通过直接路由实现虚拟服务器的方法VS/DR（Virtual Server via Direct Routing），它们可以极大地提高系统的伸缩性。所以，IPVS软件实现了这三种IP负载均衡技术，它们的大致原理如下，
###################################################
Virtual Server via Network Address Translation（VS/NAT）
通过网络地址转换，调度器重写请求报文的目标地址，根据预设的调度算法，将请求分派给后端的真实服务器；真实服务器的响应报文通过调度器时，报文的源地址被重写，再返回给客户，完成整个负载调度过程。
Virtual Server via IP Tunneling（VS/TUN）
采用NAT技术时，由于请求和响应报文都必须经过调度器地址重写，当客户请求越来越多时，调度器的处理能力将成为瓶颈。为了解决这个问题，调度器把请求报 文通过IP隧道转发至真实服务器，而真实服务器将响应直接返回给客户，所以调度器只处理请求报文。由于一般网络服务应答比请求报文大许多，采用 VS/TUN技术后，集群系统的最大吞吐量可以提高10倍。
Virtual Server via Direct Routing（VS/DR）
VS/DR通过改写请求报文的MAC地址，将请求发送到真实服务器，而真实服务器将响应直接返回给客户。同VS/TUN技术一样，VS/DR技术可极大地 提高集群系统的伸缩性。这种方法没有IP隧道的开销，对集群中的真实服务器也没有必须支持IP隧道协议的要求，但是要求调度器与真实服务器都有一块网卡连 在同一物理网段上
##################################################################################
##################################################################################
NAT 模式
1、NAT技术将请求的报文DNAT和响应报文SNAT，通过调度器地址重写然后转发给内部的服务器，报文返回时再改写成原来的用户请求地址。
2、只需要在调度器LB上配置WAN公网IP即可，调度器也要有私有LAN IP和内部RS节点通信
3、每台内部RS节点的网关地址，必须要配置成调度器LB的私有LAN内物理网卡地址LDIP,这样才能确保数据报文返回时仍旧经过调度器LB 重点
4、由于请求与响应的数据报文必须经过调度器LB，因此网站访问量大时，调度器LB有较大的瓶颈，一般要求最多10-20台RS节点
5、NAT模式支持对IP及端口的转换，即用户请求10.0.0.1:80,可以通过调度器转换到RS节点的172.16.0.1:8080(DR和TUN模式不具备这样的功能)
6、所以的NAT内部RS节点只需要配置使用LAN IP即可
7、由于数据包来回都需要经过调度器，因此，要开启内核转发net.ipv4.ip.forward=1,当然也包括iptables防火墙的forward功能，（DR和TUN模式不需要）
##################################################################################
FULLNAT 模式
1、请求到调度器的时候，不仅仅把目标的ip修改，还把源的ip也修改。端口是否发生改变根据实质情况，如果需要改端口，它也可以修改
##################################################################################
##################################################################################
DR模式
1、通过在调度器LB上修改数据包的目的MAC地址实现转发，注意，源IP地址仍是CIP,目的IP仍是VIP
2、请求的报文经过调度器，而RS响应处理后的报文无需经过调度器LB，因此，并发访问量大时使用效率很高（和NAT模式对比）
3、因为DR模式是通过MAC地址的改写机制实现的转发，因此，所以的RS节点和调度器LB只能在一个局域网中（小缺点）
4、需要注意RS节点的VIP是绑定在lo接口上（lo：vip、lo1：vip）。以及ARP抑制问题，
5、强调：RS节点的默认网关不需要是调度器LB的DIP，而直接是IDC机房分配的上级路由IP（这是RS带有外网IP地址情况），理论上讲，只要RS可以出网即可，不是必须要配置外网IP
6、由于DR模式的调度器仅仅进行了目的MAC地址的改写，因此调度器LB无法改变请求报文的目的端口（和NAT模式的区别）
7、当前，调度器LB支持几乎所有UNIX.LINUX系统，但是目前不支持window系统，但是真实服务器RS可以是windows系统。
8、总的来说DR模式效率很高，但是配置也比较麻烦，因此，并发量不是特别大的公司，可以用haproxy/nginx取代，这符合运维的原则，简单、易用、高效，在日PV在2千万一些并发在1万一下都可以考虑用haproxy、nginx或者LVS的NAT 模式
9、直接对外的访问业务，例如：Web服务节点RS节点。RS最好有公网IP地址，如果不直接对外服务，例如：MySQL，存储系统的RS节点，最好只用内部IP地址
##################################################################################
##################################################################################
TUN模式
1、负载均衡器通过该把请求报文通过IP隧道（ipip隧道）的方式（请求的报文不经过源目的地址的修改（包括MAC），而是直接封装成另外一个报文）
转发到真实的服务器，而真实的服务器将响应处理后直接返回给客户端用户
2、由于真实服务器将响应后的报文直接返回转发给客户端用户，因此最好RS有一个外网IP地址，这样效率才能更高，理论上，只要能出网即可，无需外网IP地址也可以
3、由于调度器LB只处理如站请求的报文，因此，此集群系统的吞吐量可以提供10倍以上，但是隧道模式也会带来一定的系统开销，TUN模式适合LAN/WAM.
4、TUN模式的LAN环境转发不如DR模式效率高，而且还要考虑系统对IP隧道的支持问题，
5、所有的RS服务器要绑定VIP，抑制ARP转发，配置复制
6、LAN环境一般采用DR模式，WAN环境可以用TUN模式，但是当前在WAN环境下，请求转发更多的被haproxy、nginx、DNS调度等代理取代，要么DNS调度，底层数据还可以同步
7、直接对外的访问业务，例如：web服务做RS节点，最好用公网IP地址。不直接对外的业务.例如MySQL，存储系统RS节点，最好用内部IP地址
##################################################################################
##################################################################################
调度算法：
针对不同的网络服务需求和服 务器配置，IPVS调度器实现了如下八种负载调度算法：
轮叫（Round Robin）
调度器通过"轮叫"调度算法将外部请求按顺序轮流分配到集群中的真实服务器上，它均等地对待每一台服务器，而不管服务器上实际的连接数和系统负载。
加权轮叫（Weighted Round Robin）
调度器通过"加权轮叫"调度算法根据真实服务器的不同处理能力来调度访问请求。这样可以保证处理能力强的服务器处理更多的访问流量。调度器可以自动问询真实服务器的负载情况，并动态地调整其权值。
最少链接（Least Connections）
调度器通过"最少连接"调度算法动态地将网络请求调度到已建立的链接数最少的服务器上。如果集群系统的真实服务器具有相近的系统性能，采用"最小连接"调度算法可以较好地均衡负载。
加权最少链接（Weighted Least Connections）
在集群系统中的服务器性能差异较大的情况下，调度器采用"加权最少链接"调度算法优化负载均衡性能，具有较高权值的服务器将承受较大比例的活动连接负载。调度器可以自动问询真实服务器的负载情况，并动态地调整其权值。
基于局部性的最少链接（Locality-Based Least Connections）
"基于局部性的最少链接" 调度算法是针对目标IP地址的负载均衡，目前主要用于Cache集群系统。该算法根据请求的目标IP地址找出该目标IP地址最近使用的服务器，若该服务器 是可用的且没有超载，将请求发送到该服务器；若服务器不存在，或者该服务器超载且有服务器处于一半的工作负载，则用"最少链接"的原则选出一个可用的服务 器，将请求发送到该服务器。
带复制的基于局部性最少链接（Locality-Based Least Connections with Replication）
"带复制的基于局部性最少链接"调度算法也是针对目标IP地址的负载均衡，目前主要用于Cache集群系统。它与LBLC算法的不同之处是它要维护从一个 目标IP地址到一组服务器的映射，而LBLC算法维护从一个目标IP地址到一台服务器的映射。该算法根据请求的目标IP地址找出该目标IP地址对应的服务 器组，按"最小连接"原则从服务器组中选出一台服务器，若服务器没有超载，将请求发送到该服务器，若服务器超载；则按"最小连接"原则从这个集群中选出一 台服务器，将该服务器加入到服务器组中，将请求发送到该服务器。同时，当该服务器组有一段时间没有被修改，将最忙的服务器从服务器组中删除，以降低复制的 程度。
目标地址散列（Destination Hashing）
"目标地址散列"调度算法根据请求的目标IP地址，作为散列键（Hash Key）从静态分配的散列表找出对应的服务器，若该服务器是可用的且未超载，将请求发送到该服务器，否则返回空。
源地址散列（Source Hashing）
"源地址散列"调度算法根据请求的源IP地址，作为散列键（Hash Key）从静态分配的散列表找出对应的服务器，若该服务器是可用的且未超载，将请求发送到该服务器，否则返回空。
##################################################################################
##################################################################################