只在虚拟机局域网下进行过测试,在服务器上我个人理解应该是把VIP设置成调度器的公网IP这样才能解析,就是不知道对不对,也没几台服务器供我测试一下。。
VS/NAT: 网络地址转换模式, 进站/出站的数据流量经过分发器(调度器)
1、由于NAT模式下,进出数据都在调度器进行,因此支持后端真实服务器数量较少
2、调度(Dip)和Vip需要工作在不同的网络中
3、所有的真实服务器的网关地址必须指向Dip
4、调度器需要双网卡,启用路由转发功能
下面是虚拟机实验步骤:
调度器:192.168.26.130
nginx1:192.168.26.129
nginx2:192.168.26.128
首先是调度器操作:
1.在网卡上添加一个IP
# ip addr add dev ens33 192.168.1.100/24(或添加一张物理网卡为桥接模式)
2.开启路由转发
# vim /etc/sysctl.conf
net.ipv4.ip_forward = 1
# sysctl -p
临时开启
# echo 1 > /proc/sys/net/ipv4/ip_forward
3.安装ipvsadm并定义分发策略
# yum -y install ipvsadm
# ipvsadm -C //清除所有规则
# ipvsadm -A -t 192.168.1.100:80 -s rr
-A 添加一个调度器
-s 指定调度算法 (rr是轮叫调度,调度算法的笔记在最后)
-a 向某个调度器添加一个真实服务器
-t TCP协议传输
-m 使用LVS-NAT模式
-r 真实服务器
# ipvsadm -a -t 192.168.1.100:80 -r 192.168.26.128 -m
# ipvsadm -a -t 192.168.1.100:80 -r 192.168.26.129 -m
然后是后方真实web服务器的配置,必须指定网关为调度器的IP
1.安装nginx
.....
2.添加网关
# route add default gw 192.168.26.130
如果没有route命令就安装一下
# yum install net-tools
做负载均衡两台配置肯定是一样的了,我这里随便区分了下,然后使用和调度器VIP同一网段的客户端访问
# ipvsadm -L -n --stats
1. Conns (connections scheduled) 已经转发过的连接数
2. InPkts (incoming packets) 入包个数
3. OutPkts (outgoing packets) 出包个数
4. InBytes (incoming bytes) 入流量(字节)
5. OutBytes (outgoing bytes) 出流量(字节)
以上为LVS的NAT模式简单测试。
VS/NAT模式的原理是:当调度器收到Client请求时,调度器将数据包的目标IP由VIP转换为选中的Real Server的RIP来实现分发,要求RS将网关指 向调度器的DIP。
特点是:配置简单,所有的入站、出站数据包都经过分发器。当数据量比较大时,分发器可能会出现网络瓶颈!因而支持的RS数量少。
VS/DR: 直接路由模式,只有进站的数据流量经过分发器
调度器和真实服务器必须在同一网段
VS/DR模式的原理是: 当一个client发送一个请求到VIP,调度器根据VIP,在后端真实服务器中选择一台Real-server,然后将client的请求包发给选择的Real-server,最后选择的Real-server把应答包直接传给client。
特点:解决了lvs-NAT模式下调度器瓶颈问题。
以下为实验操作步骤:
调度器:192.168.26.130
nginx1:192.168.26.129
nginx2:192.168.26.128
两台RS服务器:
# ip addr add dev lo 192.168.26.123/32
//在lo接口上绑定VIP
# echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore
//non-arp:避免出现IP冲突
# echo 2 > /proc/sys/net/ipv4/conf/all/arp_announce
//RS以适当IP传输数据(让RS用VIP回复数据)
因为LVS和real server都配置了VIP,client或者网关设备都可能arp学到LVS和real server的mac,也就会发生IP冲突,且无法实现负载均衡功能。为了避免这种情况发生,可通过内核参数arp_ignore和arp_announce的配置,只允许LVS应答VIP的arp请求,抑制real server应答VIP的arp请求和发送免费arp。(抑制ARP还可使用arptables)
nginx的配置过程就略过了,随便改点加以区分就行
调度器操作:
# ip addr add dev lo 192.168.26.123/32
# yum -y install ipvsadm
# ipvsadm -C
# ipvsadm -A -t 192.168.26.123:80 -s rr
# ipvsadm -a -t 192.168.26.123:80 -r 192.168.26.129 -g
# ipvsadm -a -t 192.168.26.123:80 -r 192.168.26.128 -g
# ipvsadm -Ln
LVS调度算法:
调度算法用于决定LVS如何选择后端的RealServer
1. 轮叫调度(Round Robin)(简称rr)
调度器通过“轮叫”调度算法将外部请求按顺序轮流分配到集群中的真实服务器上,它均等地对待每一台服务器,而不管服务器上实际的连接数和系统负载。
2. 加权轮叫(Weighted Round Robin)(简称wrr)
调度器通过“加权轮叫”调度算法根据真实服务器的不同处理能力来调度访问请求。这样可以保证处理能力强的服务器能处理更多的访问流量。调度器可以自动问询真实服务器的负载情况,并动态地调整其权值。
3. 最少链接(Least Connections)(LC)
调度器通过“最少连接”调度算法动态地将网络请求调度到已建立的链接数最少的服务器上。如果集群系统的真实服务器具有相近的系统性能,采用 “最小连接” 调度算法可以较好地均衡负载。
4.加权最少链接(Weighted Least Connections)(WLC)
在集群系统中的服务器性能差异较大的情况下,调度器采用“加权最少链接”调度算法优化负载均衡性能,具有较高权值的服务器将承受较大比例的活动连接负
载。调度器可以自动问询真实服务器的负载情况,并动态地调整其权值。
LVS的默认调度算法。
5. 基于局部性的最少链接(Locality-Based Least Connections)(LBLC)
“基于局部性的最少链接”调度算法是针对目标IP地址的负载均衡,目前主要用于Cache集群系统。该算法根据请求的目标IP地址找出该目标IP地址最近使用的
服务器,若该服务器是可用的且没有超载,将请求发送到该服务器;若服务器不存在,或者该服务器超载且有服务器处于一半的工作负载,则用“最少链接”
的原则选出一个可用的服务器,将请求发送到该服务器。
6. 带复制的基于局部性最少链接(Locality-Based Least Connections with Replication)(LBLCR)
“带复制的基于局部性最少链接”调度算法也是针对目标IP地址的负载均衡,目前主要用于Cache集群系统。它与LBLC算法的不同之处是它要维护从一个目标
IP地址到一组服务器的映射,而LBLC算法维护从一个目标IP地址到一台服务器的映射。该算法根据请求的目标IP地址找出该目标IP地址对应的服务器组,按
“最小连接”原则从服务器组中选出一台服务器,若服务器没有超载,将请求发送到该服务器;若服务器超载,则按“最小连接”原则从这个集群中选出一台
服务器,将该服务器加入到服务器组中,将请求发送到该服务器。同时,当该服务器组有一段时间没有被修改,将最忙的服务器从服务器组中删除,以降低复
制的程度。
7. 目标地址散列(Destination Hashing)(DH)
“目标地址散列”调度算法根据请求的目标IP地址,作为散列键(Hash Key)从静态分配的散列表找出对应的服务器,若该服务器是可用的且未超载,将请求发送到该服务器,否则返回空。
8. 源地址散列(Source Hashing)(SH)
“源地址散列”调度算法根据请求的源IP地址,作为散列键(Hash Key)从静态分配的散列表找出对应的服务器,若该服务器是可用的且未超载,将请求发送到该服务器,否则返回空。
9. 最短的期望的延迟(Shortest Expected Delay Scheduling SED)(SED)
基于wlc算法。这个必须举例来说了
ABC三台机器分别权重123 ,连接数也分别是123。那么如果使用WLC算法的话一个新请求进入时它可能会分给ABC中的任意一个。使用sed算法后会进行这样一个运算
A(1+1)/1
B(1+2)/2
C(1+3)/3
根据运算结果,把连接交给C。
10.最少队列调度(Never Queue Scheduling NQ)(NQ)
无需队列。如果有台 realserver的连接数=0就直接分配过去,不需要在进行sed运算