企业级负载均衡集群---LVS(二)---DR模式

企业级负载均衡集群—LVS(二)—DR模式

1.DR模式

DR（Direct Routing）直接路由模式

原理：

• 在一台主机上面搭建lvs服务器，设置LVS的工作模式是DR模式，LVS仅仅是一个调度器，它会把客户端的请求转发给后端服务器
• DR（直接路由）模式直接由后端服务器把数据返回给客户端，不需要逆向发送数据包，此时lvs调度器叫做DS调度器(Director Server)，RS是真正的后端web服务器(Real Server)，LVS专注做调度时效率很高
• DR模式改变的是MAC地址

Client发送请求 --> DS(调度器) -->prerouting --> INPUT -->postrouting -->RS(Real Server)–>lo --> 网卡eth0 -->Client
具体过程：

用户（client）发送请求给调度器(DS)，DS调度器先把请求发往prerouting链（内核空间kernal
space），确定请求的是不是VIP

到了INPUT链之后，如果请求的是集群服务，会在这里修改MAC地址，把源MAC地址改为DS的MAC地址，把目的MAC地址改为RS的MAC地址，此时IP仍然不变，处理完成后把请求发往postrouting链

postrouting链检测请求的是否为RS（会检测请求的MAC地址），如果是，接受请求，把请求通过回环接口发给出口的网卡，再发回给客户端

LVS（ipvs ipvsadm）–>IPVS改变数据包的ip和端口–>POSTROUTING–>后端服务器

注意：
1.数据在系统内的交流用的是回环接口，与外部的交流用的是网卡eth0
2.DR模式高效的原因就是RS服务器会直接响应客户端的请求，发送的请求一直往前发送数据包，不会再返回数据包给调度器

DR模式的特性：

• DR模式下调度器和服务器组都必须在物理上有一个网卡通过不分段的局域网相连，即通过交换机或者高速的HUB相连，中间没有隔有路由器。
• VIP地址为调度器和服务器组共享，调度器配置的VIP地址是对外可见的，用于接收虚拟服务的请求报文
• 所有的服务器把VIP地址配置在各自的Non-ARP网络设备上，它对外面是不可见的，只是用于处理目标地址为VIP的网络请求。
• 所有的请求报文经由Director Server，但响应报文必须不能经过Director Server
• 不支持地址转换，也不支持端口映射
• RS的网关绝不允许指向DIP
• 所有的请求报文都是由调度器（DS）进行调度的
• MAC地址在第二层，属于数据链路层，还没有到IP所在的网络层
• RIP和DIP必须处于同一网段中，以便使用MAC地址进行通信
• 后端服务器（Real Server）上必须配置VIP地址，以便接收LVS调度器（Director）转发过来的数据包，以及作为响应报文的源IP
• 后端服务器（Real Server）响应给客户端的数据包的源和目的IP为VIP—>CIP

2.部署实验环境

在这个实验中我们需要3台虚拟机：sever1 sever2 sever3
server1作为lvs调度器，而server2和server3作为后端服务器

在server2和server3中安装apache，并且写好测试页，以方便查看实验效果：

yum install httpd -y
cd /var/www/html/
vim index.html
systemctl start httpd

3.配置ipvsadm

在server1中：

yum install ipvsadm -y
ipvsadm -l		#查看策略（解析ip与域名的对应关系，查看速度较慢）
ipvsadm -ln		#-n不解析（速度快）
ipvsadm -A -t 172.25.254.100:80 -s rr	#添加策略：tcp，通过80端口访问172.25.254.100，以轮询的调度算法
ipvsadm -a -t 172.25.254.100:80 -r 172.25.254.2:80 -g	#添加策略：tcp，通过80端口访问172.25.254.100，以轮询的调度算法，使用DR（直接路由）模式，转发到172.25.254.2的80端口
ipvsadm -a -t 172.25.254.100:80 -r 172.25.254.3:80 -g	##添加策略：tcp，通过80端口访问172.25.254.100，以轮询的调度算法，使用DR（直接路由）模式，转发到172.25.254.3的80端口
ipvsadm -ln

4.添加VIP

在server1 server2 server3中分别添加VIP地址：

ip addr add 172.25.254.100/32 dev eth0	#添加VIP地址到eth0上
ip addr show

注意：此处的/32即掩码设置为32，表示对外不可见

5.测试

在客户端（真机）中：

curl 172.25.254.100

注意：用上面的方法配置lvs，server1、2、3都有可能被访问到：

• 如果绑定的MAC地址是server1，则在server2和3中轮询
• 如果绑定的MAC地址是sever2或sever3的，那么我们会发现，在测试端根本不会形成轮叫，而是直接去了MAC绑定的后端服务器 （显然这样在企业中是不允许的）

- 绑定的MAC地址是server1

- 绑定的MAC地址是server2

- 绑定的MAC地址是server3

6.解决方法

要避免这种情况：要求只能绑定server1（调度器）的MAC地址
配置server2和server3的arp路由策略：为arptables网络的用户控制过滤的守护进程

在server2中：

yum whatprovides arptables/*
yum install arptables-0.0.4-8.el7.x86_64 -y

arptables -A INPUT -d 172.25.254.100 -j DROP	#当网内广播需要172.25.254.100这个ip时，它丢弃所有网内的请求
arptables -A OUTPUT -s 172.25.254.100 -j mangle --mangle-ip-s 172.25.254.2	#当它自身需要在网内发包时，伪装为自己原本的ip172.25.254.2

在server3中：

yum whatprovides arptables/*
yum install arptables-0.0.4-8.el7.x86_64 -y
arptables -A INPUT -d 172.25.254.100 -j DROP	#当网内广播需要172.25.254.100这个ip时，它丢弃所有网内的请求
arptables -A OUTPUT -s 172.25.254.100 -j mangle --mangle-ip-s 172.25.254.3	#当它自身需要在网内发包时，伪装为自己原本的ip172.25.254.3

7.测试

arp -d 172.25.254.100		#先删除现有绑定MAC地址
curl 172.25.254.100