1.DR模式的原理
其实就是在一台主机上面搭建lvs服务器,设置lvs的工作模式是DR模式,lvs仅仅是一个调度器,它会把客户端的请求转发给后备服务器
DR模式直接由后备服务器把数据返回给客户端,不需要逆向发送数据包,此时lvs专注做调度就可,效率很高
此时lvs调度器叫做DS调度器(director server),RS是真正的后端web服务器(real server)
Client发送请求 --> DS(调度器) -->prerouting --> INPUT -->postrouting -->RS(真正的服务器)–>lo回环接口 --> 网卡eth0 -->Client
整个过程的数据流向如下
用户(client)发送请求给调度器(DS),DS调度器先把请求发往prerouting链(内核空间kernal space),确定请求的是不是VIP
到了INPUT链之后,如果请求的是集群服务,会在这里修改MAC地址,把源MAC地址改为DS的MAC地址
把目的MAC地址改为RS的MAC地址,此时IP仍然不变,处理完成后把请求发往postrouting链
检测请求的是否为RS(会检测请求的MAC地址),如果是,接受请求,把请求通过回环接口发给出口的网卡,再发回给客户端
数据在系统内的交流用的是回环接口,与外部的交流用的是网卡eth0
DR模式高效的原因就是RS服务器会直接响应客户端的请求,发送的请求一直往前发送数据包,不会再返回数据包给调度器
注意:这里的prerouting,input,postrouting都是iptables防火墙里面的链,如果不懂先回去复习iptables
2.DR模式中的名词解释
DS | 调度器,lvs的前端设备 |
---|---|
RS | 真正提供服务的后端服务器 |
RIP | 后端服务器的ip地址 |
DIP | 调度器和后端服务器通信的ip |
源IP | CIP(客户端的IP) |
目的IP | VIP(设置的统一入口),对外公布的ip,客户请求进来的ip |
源MAC地址 | DS调度器的MAC地址 |
目的MAC地址 | RS真正服务器的MAC地址 |
3.DR模式的特点
所有的请求报文都是由调度器(DS)进行调度的
DR模式不支持端口映射
RS和DS必须在同一网络,可以不在同一网段,使用交换机即可
MAC地址在第二层,数据链路层,还没有到IP所在的网络层
realserver的RIP和Director的DIP必须处于同一网段中,以便使用MAC地址进行通信
realserver上必须配置VIP地址,以便接收director转发过来的数据包,以及作为响应报文的源IP
realserver响应给客户端的数据包的源和目的IP为VIP—>CIP
director只处理入站请求,响应请求由realserver完成
七层调度(负载均衡),4层分摊流量
LVS(Linux Virtual Server)Linux虚拟服务器
附着在netfilter上,有5个内置的钩子函数处理内置的请求,工作在4层模型上,会强行改变数据的流向
它不接受请求,只是一个调度器,把请求发给后端真正的服务器(RS)
LVS包括两个东西:
(1)IPVS:工作在INPUT链,依附于5个内置钩子函数,其实就是一段代码,已经集成在LInux的源码中
(2)IPVSADM:具体编写策略的工具
DR模式改变的是MAC地址
DR模式可能会有人恶意连接,一直发送数据包给一台后端服务器,不轮询,导致后端服务器瘫痪,可以解决
4.搭建实验环境
一共需要3台rhel7.5版本的虚拟机
主机信息 | 主机的功能(服务) |
---|---|
真机172.25.58.250 | 客户端client |
server1(172.25.58.1) | lvs调度器(DS) |
server2(172.25.58.2) | 后端的web服务器1(RS) |
server3(172.25.58.3) | 后端的web服务器2(RS) |
在真机中开启三台虚拟机
1台做lvs调度器,两台做后端轮询的web服务器,用真机分别连接三台虚拟机,真机本身是客户端
5.实现lvs调度器的DR模式
注意:虽然lvs的调度算法很多,为了实验效果明显起见,我们使用轮询算法
实验步骤如下:
(1)在server1上面搭建lvs服务
yum search ipvsadm寻找这个服务(工具)
yum install ipvsadm.x86_64 -y安装服务
此时的虚拟机版本是7.3的,7.3版本的yum源的packages安装包中有LoadBalancer负载均衡模块,因此不再需要搭建负载均衡的yum源
如果是6.5版本的yum源,需要搭建负载均衡的yum源才可以安装这个服务
(2)ipvsadm -l列出策略(查看调度策略),此时还没有布置u策略
(3)查看ipvsadm服务的基本信息
systemctl status ipvsadm.service可以看出这个服务的启动脚本
vim /usr/lib/systemd/system/ipvsadm.service查看开启这个服务的时候都干了一些什么
(4)systemctl start ipvsadm.service开启服务,此时会出错,于是不慌乱,先看日志,然后排错即可。
解决方法:
cat /var/log/messages在日志里面查看服务启动错误的原因
出来原因了,就是配置文件里没有ipvsadm这个文件。
解决:touch /etc/sysconfig/ipvsadm 即可
重启服务,成功
(5)配置服务
vim /etc/sysconfig/ipvsadm-config
修改lvs服务的配置文件:no->yes,重启服务的时候保存策略
(6)设置DR模式的访问策略
ipvsadm -A -t 172.25.12.100:80 -s rr 设置客户端进入lvs调度器的入口地址,调度算法是轮询
ipvsadm -a -t 172.25.12.100:80 -r 172.25.12.2:80 -g设置lvs的策略:入口的第一台后端服务器的信息
ipvsadm -a -t 172.25.12.100:80 -r 172.25.12.3:80 -g设置lvs的策略:入口的第二台后端服务器的信息
-s表示调度算法,rr表示轮询,-g表示lvs调度器工作在DR模式
- 配置完策略,记得重启服务,然后cat /etc/sysconfig/ipvsadm 即可查看设置的策略
(7)设置两台后端服务器(server2和server3)的apache服务,搭建web服务。
server2的默认发布目录写:www.westos.org
server3的默认发布目录写:bbs.westos.org
(8)在lvs服务器上面查看刚才设置的调度策略(DR模式的轮询)
ipvsadm -l做解析,慢
ipvsadm -Ln不做解析,快
(9)测试前的准备,在客户端的主机上,写本地解析
172.25.58.1 www.westos.org bbs.westos.org
(10)再server1上设置用户访问的入口地址
在lvs(server1)上面设置用户访问的入口地址:ip addr add 172.25.58.100/24 dev eth0
ip a查看
(11)在后端服务器1(server2和server3)上面设置用户访问的入口地址:ip addr add 172.25.58.100/24 dev eth0
ip a查看
注意:在两个web服务器上设置用户访问的入口地址是为了web服务器可以直接给客户端发送资源,不需要再返回给调度器,因为客户端访问的是入口地址,如果不用入口地址给客户发送资源,客户可能不会接收这个数据包
如果直接在客户端curl 172.25.8.100发现客户端要不到资源
因为DR工作模式是:client->vs->rs->client,由后备服务器端直接送回资源给客户端
但是客户端问172.25.8.100要的资源,后端服务器直接把资源给客户端,客户端不会识别
因此要在两个后端服务器上面设置入口地址
(12)在真机上面测试
注意:此时客户端访问资源有时候轮询,有时候不轮询,出现这样的现象是为什么呢?
因为DR模式是通过修改MAC地址进行访问的,调度器和两台web服务器上都有172.25.8.100这个入口地址ip
所以客户端在请求的时候,三台虚拟机都有可能回复请求,客户端会记录回复他的那台虚拟机的mac地址
所以下次在访问的时候他会找记录过的mac地址对应的虚拟机(有可能是真实的服务器)直接访问
这在现实中是不允许的,因为如果请求全部发往后端某一台真正的服务器的话,这台服务器会因为压力过大而宕机
而且,直接访问后端的真正的服务器,我们的server1(LVS调度器)也就没有起到作用
并没有实现真正意义上的负载均衡,这也是DR模式的一个缺点
这就类似于DDOS攻击,有可能会导致后端服务器瘫痪,造成用户不能正常访问资源
(13)进一步验证:
在客户端查看它访问的入口地址的主机的MAC地址是多少
(14)在客户端删除刚才记录的MAC地址,再次访问
6.现在解决DR模式不轮询的问题,由于DR模式使用的是MAC地址
会造成DDOS(就相当于造成高速公路拥堵)攻击,导致后端服务器瘫痪
因为客户端第一次访问172.25.58.100的时候server1,server2,server3均可以接收客户端的请求,这个是随机的
有可能不会经过lvs调度器,客户端直接问web服务器要资源
在两个web后端上进行设置,使的不会接受;来自客户端的请求,防止ddos攻击
在server2(第一个后端服务器)上进行设置
- (1)yum install -y arptables_jf安装针对MAC地址的防火墙管理工具
为什么使用arptables?
因为arptables专门用来处理arp协议有关的包。而DR的模式就是:通过修改请求报文的目标MAC地址,来访问RS。
- (2)man arptable可以查看设置规则,进行设置
- (3)设置规则
创建一个存放规则的文件:
touch /etc/sysconfig/arptables
设置策略:
arptables -A IN -d 172.25.8.100 -j DROP丢弃客户端的直接访问
arptables -A OUT -s 172.25.8.100 -j mangle --mangle-ip-s 172.25.8.2使自己以172.25.8.100的身份发送资源给客户端
cat /etc/sysconfig/arptables查看规则,此时查看不到,没有进行保存
arptables-save > /etc/sysconfig/arptables保存策略
cat /etc/sysconfig/arptables再次查看
由于时rhel6.5版本,所以下载的的是arptables_jf版本的
重启防火墙:
service arptables_jf restart
查看状态~~
[root@server1 sysconfig]# cat /etc/sysconfig/arptables
# Generated by arptables-save v0.0.8 on Fri Apr 17 00:39:07 2020
*filter
:IN ACCEPT [28:784]
:OUT ACCEPT [4:112]
:FORWARD ACCEPT [0:0]
-A IN -d 172.25.58.100 -j DROP
-A IN -d 172.25.58.100 -j DROP
-A OUT -s 172.25.58.100 -j mangle --mangle-ip-s 172.25.58.1
COMMIT
# Completed on Fri Apr 17 00:39:07 2020
[root@server1 sysconfig]# service arptables_jf restart
Flushing all current rules and user defined chains: [ OK ]
Clearing all current rules and user defined chains: [ OK ]
Applying arptables firewall rules: [ OK ]
[root@server1 sysconfig]# service arptables_jf status
Table: filter
Chain IN (policy ACCEPT)
target source-ip destination-ip source-hw destination-hw hlen op hrd pro
DROP anywhere 172.25.58.100 anywhere anywhere any any any any
DROP anywhere 172.25.58.100 anywhere anywhere any any any any
DROP anywhere 172.25.58.100 anywhere anywhere any any any any
DROP anywhere 172.25.58.100 anywhere anywhere any any any any
Chain OUT (policy ACCEPT)
target source-ip destination-ip source-hw destination-hw hlen op hrd pro
mangle 172.25.58.100 anywhere anywhere anywhere any any any any --mangle-ip-s 172.25.58.1
mangle 172.25.58.100 anywhere anywhere anywhere any any any any --mangle-ip-s 172.25.58.1
mangle 172.25.58.100 anywhere anywhere anywhere any any any any --mangle-ip-s 172.25.58.1
Chain FORWARD (policy ACCEPT)
target source-ip destination-ip source-hw destination-hw hlen op hrd pro
- (4)arptables -nL可以查看设置的访问规则
设置完毕后重启arptables服务即可,在另一个后端服务器server3进行同样的设置即可。
测试:
在真机上面进行测试
此时做完这个:就可以实现调度了
web2和web3就不会接受客户端的请求了,每次客户端的访问只能由调度器接受
只有调度器才会接收这个请求,因此也就是通过lvs调度器的mac地址,因此可以实现正常访问
通过调度器访问时,因为调度器里面设置了调度规则,因此可以实现正常访问.
出现问题了:客户端进行访问的时候,显示:
curl: (7) Failed connect to 172.25.58.100:80; No route to host
啊啊啊,太水了吧这emmmmmm
清除缓存,发现轮询了
![在这里插入图片描述](https://i-blog.csdnimg.cn/blog_migrate/07c87ee0bc1fdc0569f94d209f8f007b.png)
![在这里插入图片描述](https://i-blog.csdnimg.cn/blog_migrate/d69fee10bbeda86bdd4c52b7baedf520.png)
可以看到客户端此时访问的MAC地址是lvs调度器的MAC地址
7.lvs调度器工作在DR模式的总结(个人理解以及总结)
因为lvs、web1、web2均有172.25.58.100这个ip地址
当客户端第一次找lvs调度器这个入口地址的时候
他可能直接找到web1或者web2,因此就不能实现调度了
现在在web1和web2上面进行设置拒绝客户端请求172.25.8.100这个ip
因此只有lvs调度器入口地址才会接受客户端的请求
因此客户端访问就是一直是使用调度器的MAC地址
每次客户端只能通过lvs调度器去找web1和web2服务
这样就实现了调度,轮询工作
当客户端发送数据包给172.25.58.100(lvs)的时候(源地址172.25.58.250–>目的地址172.25.58.100)
此时lvs会将源mac地址变为lvs服务器的mac地址,将目的mac地址变为web服务器的mac地址,然后就实现调度了
直接去找目标mac地址,然后找web服务器,web服务器直接将数据返回给客户端(IP地址全程不变)
DR模式的特点:
不支持端口映射
RS和DS必须在同一网络(不是同一网段)
DR工作在数据链路层使用的是MAC地址,还没有牵扯到IP地址
IP地址始终不变,变的是MAC地址
lo是回环接口(和自己进行交流的时候用,使用起来快),系统里服务和服务之间使用的回环接口,效率高,快
etho是网卡(和外界进行交流的时候用)