lvs:Linux Virtual Server
l4:四层路由、四层交换
根据请求报文的目标IP和目标PORT将其调度转发至后端的某主机；
IPTABLES:
工作在用户空间中的iptables
工作在内核空间中的netfilter
PREROUTING–>INPUT
PREROUTING–>FORWORD–>POSTROUTING
OUTPUT–>POSTROUTING
LVS：
工作在用户空间中的ipvsadm
工作在内核空间中的ipvs
ipvsadm：用户空间的命令行工具，用于管理集群服务及集群服务的RS(real server)；
ipvsadm用于定义哪一个服务是集群服务，即TCP或UDP哪一个端口被定义为集群服务
ipvs:内核中的协议栈上实现
工作于内核上的netfilter的INPUT钩子之上的程序，可根据用户定义的集群实现请求转发；
ipvs在内核INPUT层面，监控目前集群服务的请求，强行修改报文的流程。将报告送往POSTROUTING，并离开本机；
POSTROUTING发送到后端服务器时，需要做相应的修改，使后端服务器能够接受报文
因此不建议一台LVS服务器上LVS与其他程序一同使用filter规则（尤其不同启用nat规则），否则将影响LVS服务器的并发连接能力
支持基于TCP、UDP、SCTP、AH、EST、AH_EST等协议进行调度；
一般基于TCP的某个端口进行调度
一个ipvs主机可以为多个集群提供服务，因为Lvs是通过请求的目标地址和目标端口来进行转发的。但是因为Director可能成为负载均衡的瓶颈，因此不建议一台Director为多个集群进行负载
一个ipvs服务至少应该有一个RS; #否则没有意义
LVS集群的专用术语：
vs:Virtual Server、Director、Dispatcher、Balancer
rs:Real Server
CIP:Client IP #客户端地址
VIP:Virtual Server IP #用于与客户端通信的地址
DIP:Director IP #用于与Real Server通信的地址
RIP:Real Server IP
lvs集群的类型:
1.lvs-nat：多目标的DNAT，通过将请求报文中的目标地址和目标端口修改为挑选出的某RS的RIP和PORT实现转发（并发能力有限）
请求报文：先根据算法选择一台合适的rs，并修改客户端请求的目标IP为REAL SERVER的IP实现的
客户端–>调度器 源IP：CIP 目标IP:VIP 调度器–>真实服务器 源IP：CIP 目标IP:RIP1
响应报文：要经过调度服务器发送回客户端
真实服务器–>调度器 源IP：RIP1 目标IP:CIP 调度器–>客户端 源IP：VIP 目标IP:CIP
使用规则：
（1）RIP和DIP必须在同一网段中，并建议使用私有地址，RS的网关必须指向DIP（保证响应报文必须经由Director）；
（2）请求报文和响应报文都经由Director转发，较高负载下，Director易于成为系统性能瓶颈；
（3）支持端口映射；
（4）Director必须是Linux,RS可以是任意OS；
2.lvs-dr：Direct Routing
lvs的默认类型
RS是接入在与Director相同层次的网络中，因此请求经Director调度给后端的RS后，RS直接响应客户端，而不经过Director。
这要求每个RS都配有VIP，为避免VIP地址冲突，每台RS中将RIP配置在物理接口上，将VIP配置在Loopback口的子接口中（lo:0），并调整内核参数，使其他主机对的VIP的ARP请求RS的物理接口不会响应。
工作原理：
请求报文：用户发送请求后应送达Director，由Director进行调度，因此后端RS的VIP地址不能直接响应客户端的请求，即RS需要做隔离广播ARP请求
由Director发送至调度的RS，变更请求报文中的源、目的MAC，RS的lo:0会响应请求，并将数据由外部网卡（如eth0）发出
客户端–>调度器 源IP：CIP 目标IP:VIP 源MAC：路由器MAC 目标MAC：Director VIP的MAC 调度器–>真实服务器 源IP：CIP 目标IP:VIP 源MAC：Director VIP的MAC 目标MAC：挑选出的RS 的RIP接口的MAC
响应报文：报文由RIP所在接口发出，因此下一跳必须是与RIP接口在同一网段的路由器。因报文是由RS服务器的外部接口发出，因此下一条路由器必须与RSIP在同一网段内
真实服务器–>客户端 源IP：VIP 目标IP:CIP
总结如下：
通过为请求报文重新封装一个MAC首部进行转发，源MAC是DIP所在的MAC，目标MAC是挑选出的某RS的RIP所在接口的MAC地址；IP首部不会发生变化
（1）确保前端路由器将目标IP为VIP的请求报文发往Director
解决方案：
在路由器上静态绑定VIP和Director的MAC地址；
禁止RS响应VIP的ARP请求，禁止RS的VIP进行通告
(a)使用系统自带的ARPtables
(b)修改RS的内核参数，并把VIP绑定lo的别名上
arp_ignore,arp_announce
（2）RS的RIP可以使用私有地址，也可以使用公网地址
（3）RS跟Director必须在同一物理网络；RS的网关必须不能指向DIP
（4）请求报文必须由Director调度，但响应报文必须不能经由Director
（5）不支持端口映射
（6）RS可以使用大多的OS
3.lvs-tun：tunnel
隧道模型：用于实现多地域的负载均衡
请求报文：用户发送请求后应送达Director，由Director进行调度，在IP首部外再加了一层IP首部，源地址DIP 目标地址是某个挑选的RIP
客户端–>调度器 源IP：CIP 目标IP:VIP 调度器–>真实服务器 内部IP首部如“客户端–>调度器”，外部隧道IP首部 源地址：DIP 目标地址：某个挑选的RIP
响应报文：响应报文通过RIP发送出去
真实服务器–>客户端 源IP：VIP 目标IP:CIP
转发方式：不修改请求报文的IP首部（源IP为CIP、目标IP为VIP），而是在源IP首部之外在封装一个首部（源IP为DIP、目标IP为挑选出RS的RIP）
（1）RIP、DIP、VIP全得是公网地址
（2）RS的网关不能指向也不可能指向DIP（否则负载均衡便没有意义）
（3）请求报文必须由Director调度，但响应报文必须不能经由Director
（4）不支持端口映射
（5）RS的OS必须支持隧道功能
4.lvs-fullnat（非标准模型）
通过同时修改报文的源IP和目标IP进行转发
请求报文：
客户端–>调度器 源IP：CIP 目标IP:VIP 调度器–>真实服务器 源IP：DIP 目标IP:RIP
响应报文：
真实服务器–>调度器 源IP：RIP 目标IP:DIP 调度器–>客户端 源IP：VIP 目标IP:CIP
（1）VIP是公网地址，RIP和DIP是私网地址，且通常不在同一个网络中，但需要经由路由器互通
（2）RS收到的请求报文源IP为DIP，因此响应报文将直接响应给DIP
（3）请求和响应报文都经由Director
（4）支持端口映射
原创文章，作者：oranix，如若转载，请注明出处：http://www.178linux.com/66282
