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