简介
LVS是Linux Virtual Server的简写，意即Linux虚拟服务器，是一个虚拟的服务器集群系统。本项目在1998年5月由章文嵩博士成立，是中国国内最早出现的自由软件项目之一。
LVS是四层负载均衡，也就是说建立在OSI模型的第四层——传输层之上，传输层上有我们熟悉的TCP/UDP，LVS支持TCP/UDP的负载均衡
一 什么是负载均衡?
当单台服务器性能不足时我们有两种对其进行扩展的方式, 分别是向上扩展和向外扩展
向上扩展:
向上扩展意思是提升服务器的硬件性能来应对性能不足的问题
向外扩展：
向外扩展意思是新增服务器和现有服务器组成集群来应对性能不足的问题
在这两种解决方案中, 我们一般情况下都选择向外扩展
因为向上扩展所付出的代价和得到性能的提升不成正比, 大多时候提升服务器一倍的性能需要花费三倍的价格
向外扩展也有很多问题, 例如：如何协调两台服务器提供一服务, 用户在两台服务器进行轮调时如何保存其的session信息….
我们可以将向外扩展数台服务器组成一个负载均衡集群, 前端通过负载均衡调度器来对用户请求通过调度算法合理分发到后端服务器中, 来达到负载均衡的目的.
负载均衡有软件和硬件的实现方式
硬件：F5 BIG IP, NetScaler
软件:
传输层: LVS
应用层: HAproxy, Nginx, Varnish, Perlbal….
二 LVS架构
为了更好地理解LVS, 先解释一下相应的术语:
Director: 负载均衡调度器, 负责在前端接受用户请求根据特定的算法转发到后端Real Server
Real Server: 后端提供服务的服务器
VIP: Director接受用户请求的IP地址
DIP: Director和Real Server联系的IP地址
RIP: Real Server的IP地址
CIP: Client IP, 客户端的IP地址
LVS其实由两个组件组成, 在用户空间的ipvsadm和内核空间的ipvs, ipvs工作在INPUT链上, 如果有请求报文被ipvs事先定义，就会将请求报文直接截取下根据其特定的模型修改请求报文, 再转发到POSTROUTING链上送出TCP/IP协议栈
1.当客户端的请求到达负载均衡器的内核空间时，首先会到达PREROUTING链。
2.当内核发现请求数据包的目的地址是本机时，将数据包送往INPUT链。
3.LVS由用户空间的ipvsadm和内核空间的IPVS组成，ipvsadm用来定义规则，IPVS利用ipvsadm定义的规则工作，IPVS工作在INPUT链上,当数据包到达INPUT链时，首先会被IPVS检查，如果数据包里面的目的地址及端口没有在规则里面，那么这条数据包将被放行至用户空间。
4.如果数据包里面的目的地址及端口在规则里面，那么这条数据报文将被修改目的地址为事先定义好的后端服务器，并送往POSTROUTING链。
5.最后经由POSTROUTING链发往后端服务器。
三 LVS 工作模型
LVS为了在不同场景中使用而提供了4种实现模型: 分别为NAT, DR, TUN, FULLNAT.
1. NAT模型实现原理
a) 客户端将请求发往前端的负载均衡器，请求报文源地址是CIP，目标地址为VIP(负载均衡器前端地址)。
b) 负载均衡器收到报文后，发现请求的是在规则里面存在的地址，那么它将客户端请求报文的目标地址改为了后端服务器的RIP地址并将报文根据算法发送出去。
c) 报文送到Real Server后，由于报文的目标地址是自己，所以会响应该请求，并将响应报文返还给LVS。
d) 然后lvs将此报文的源地址修改vip地址并发送给客户端。
实现NAT模型有几点需要注意的:
(1) RS应该和DIP应该使用私网地址，且RS的网关要指向DIP；
(2) 请求和响应报文都要经由director转发；极高负载的场景中，director可能会成为系统瓶颈；
(3) 支持端口映射；
(4) RS可以使用任意OS；
(5) RS的RIP和Director的DIP必须在同一IP网络；
2. DR模型实现原理
a) 客户端将请求发往前端的负载均衡器，请求报文源地址是CIP，目标地址为VIP。
b) 负载均衡器收到报文后，发现请求的是在规则里面存在的地址，那么它将客户端请求报文的源MAC地址改为自己DIP的MAC地址，目标MAC改为了RIP的MAC地址，并将此包发送给RS。
c) RS发现请求报文中的目的MAC是自己，就会将次报文接收下来，处理完请求报文后，将响应报文通过lo接口送给eth0网卡直接发送给客户端。注意：需要设置lo接口的VIP不能响应本地网络内的arp请求。
实现DR模型有一个最为关键的问题, 大家都知道Linux主机配置一个IP地址会向本网络进行广播来通告其他主机或网络设备IP地址对应的MAC地址, 那么VIP分别存在于Director和RS, IP不就冲突了么, 我们该如何解决这个问题？
事实上LVS并不能帮助我们解决这个麻烦的问题:
我们有多种方法可以解决上面的问题:
(1) 网络设备中设置VIP地址和DIrector的MAC地址进行绑定
(2) Linux系统中有一个软件可以实现对ARP广播进行过滤, arptables
(3) 可以修改内核参数来实现, arp_ignore, arp_announce
实现DR模型需要注意的:
(1) 保证前端路由器将目标IP为VIP的请求报文发送给director;
(2) RS的RIP可以使用私有地址；但也可以使用公网地址；
(3) RS跟Director必须在同一物理网络中；
(4) 请求报文经由Director调度，但响应报文一定不能经由Director；
(5) 不支持端口映射；
(6) RS可以大多数OS；
(7) RS的网关不能指向DIP；
3. TUN模型实现原理
TUN模型通过隧道的方式在公网中实现请求报文的转发, 客户端请求VIP(Director), Director不修改请求报文的源IP和目标IP, 而是在IP首部前附加DIP和对应RIP的地址并转发到RIP上, RS收到请求报文, 本地的接口上也有VIP, 遂直接响应报文给CIP
TUN的工作流程:
a) 客户端将请求发往前端的负载均衡器，请求报文源地址是CIP，目标地址为VIP。
b) 负载均衡器收到报文后，发现请求的是在规则里面存在的地址，那么它将在客户端请求报文的首部再封装一层IP报文,将源地址改为DIP，目标地址改为RIP,并将此包发送给RS。
c) RS收到请求报文后，会首先拆开第一层封装,然后发现里面还有一层IP首部的目标地址是自己lo接口上的VIP，所以会处理请求报文，并将响应报文通过lo接口送给eth0网卡直接发送给客户端。
实现TUN模型需要注意的:
(1) RIP, DIP, VIP全得是公网地址；
(2) RS的网关的不能指向DIP；
(3) 请求报文必须经由director调度，但响应报文必须不能经由director；
(4) 不支持端口映射；
(5) RS的OS必须支持隧道功能；
4. FULLNAT.模型实现原理
FULLNAT是近几年才出现的, 客户端请求VIP(Director), Director修改请求报文的源地址(DIP)和目标地址(RIP)并转发给RS, FULLNAT模型一般是Director和RS处在复杂的内网环境中的实现
FULLNAT工作流程:
a) 客户端请求VIP
b) Director接受到请求, 通过调度算法得出转发的RS, 将源地址修改为DIP, 目标地址修改为对应RIP, 转发给RS
c) RS接受到请求后, 响应请求给DIP, DIP将响应报文源地址改为VIP, 目标地址改为CIP, 响应给CIP
实现FULLNAT模型需要注意的:
(1) VIP是公网地址；RIP和DIP是私网地址，二者无须在同一网络中；
(2) RS接收到的请求报文的源地址为DIP，因此要响应给DIP；
(3) 请求报文和响应报文都必须经由Director;
(4) 支持端口映射机制；
(5) RS可以使用任意OS；
四 LVS的调度算法
1. 静态调度算法(4种)：
1) RR：Round Robin, 轮询 将用户请求轮询到各个RS上
2) WRR: Weighted Round Robin, 加权轮轮询, 根据每一台RS的权重将用户请求轮询分发到各个RS上
3) SH: Source Hash, 源地址哈希， 将同一客户端的请求转发到同一个RS上
4) DH: Destination Hash, 将同一类型的请求转发到同一个RS上
2. 动态调度算法(6种):
1) LC：least connections, 根据最少连接数调度. 公式: Active*256+Inactive
2) WLC：Weighted Least Connections, 加权最少连接数调度. 公式: (Active*256+Inactive)/Weighted
3) SED：Shortest Expection Delay, 最短延迟预期. 公式: (Active+1)*256/Weighted
4) NQ：Never Queue, 永不排队, 对SED算法的改进
5) LBLC：Locality-Based Least-Connections, 基于局部的最少链接, 即为动态的dh算法
6) LBLCR：locality-based least-connections replication, 带复制功能的lblc
原创文章，作者：liangkai，如若转载，请注明出处：http://www.178linux.com/62669
