LVS——DR模式（负载均衡）

1. DR模式（直接路由模式:Virtual Server via Direct Routing）　

　　DR模式是通过改写请求报文的目标MAC地址，将请求发给真实服务器的，而真实服务器响应后的处理结果直接返回给客户端用户。同TUN模式一样，DR模式可以极大的提高集群系统的伸缩性。而且DR模式没有IP隧道的开销，对集群中的真实服务器也没有必要必须支持IP隧道协议的要求。但是要求调度器LB与真实服务器RS都有一块网卡连接到同一物理网段上，必须在同一个局域网环境。DR模式是互联网使用比较多的一种模式。

DR模式原理图：

DR模式原理过程简述：

　　　　如下图：当客户端请求VIP时，会将请求先发给Director（调度器），调度器发现请求的是一组集群服务，根据调度算法将这一请求转发给RealServer，注意在转发的过程中，仅仅是修改了数据报文中的MAC地址，所以这也是为什么我们要求DR和RS必须在同一个物理网络内，就是为了保证可以通过修改MAC地址而进行数据报文的转发。当RealServer处理请求，响应数据，发送响应数据给客户端，按理说此时的数据包的源IP为RIP,目标IP为CIP,虽然能找到客户端，但是客户端是不收该数据包的，因为并没有请求该RIP ，现在的做法就是进行IP欺骗，即就是修改源 IP 为 VIP，但是不可以将VIP设置在出口网卡上,否则会响应客户端的arp request,造成client/gateway arp table紊乱，以至于整个load balance都不能正常工作。要在lo接口上配置VIP，并将此 VIP 屏蔽，但是出去时候的数据包被路由转换，转换后的 IP不再是 VIP，所以要重新设置路由。

　　另外关于各服务器网络的配置，首先每个服务有一个独立网卡即可。在DR上将DIP配置eth0上，将VIP配置在网络别名上，这样是为了以后调度器做高可用方便VIP做IP地址飘移。在各RS上同样需要配置好VIP，这样个RS就可以直接响应Client，而不需要再经过DR，但是一个物理网络之内是不允许有多个同名IP的，所以需要修改RS的内核参数，并且将VIP配置在LO上，让其保留VIP但是不允许对外进行广播，这样从RS出去的报文源地址就是VIP，当然这需要从真实的物理网卡出去，所以必须加一条路由，让访问VIP的数据包请求，对其响应的是配置了VIP的网卡，这样响应出去的报文源地址就是VIP，可以被Client接受。

2. LVS-DR的配置参数

在如上图的VS/DR应用模型中（所有机器都在同一个物理网络），所有机器（包括Director和RealServer）都使用了一个额外的IP地址，即VIP。

　　当一个客户端向VIP发出一个连接请求时，此请求必须要连接至Director的VIP，而不能是RealServer的，因为LVS的主要目标就是要Director负责调度这些连接请求至RealServer的。因此，在Client发出至VIP的连接请求后，只能由Director将其MAC地址响应给客户端（也可能是直接与Director连接的路由设备），而Director则会相应的更新其ipvsadm table以追踪此连接，而后将其转发至后端的RealServer之一。

3. 配置一台LVS负载均衡服务器

实验环境：

实验步骤：

server1主机上：

1、搜索并下载ipvsadm

yum search ipvsadm     ###搜索包，企业6需要去配置，但企业7直接有，可以用
yum install ipvsadm.x86_64 -y    ####安装

注意：企业七版本可以直接下载，但企业六会发现报错，原因是因为yum源中没有ipvs的包，会出现No package ipvsadm available错误，这时需要安装去策略的编辑工具，这个工具不用在官网下载，他是linux系统自带的只是没有在内核中，但在镜像中可以找到，将他写进yum仓库中直接下载即可，可以在镜像挂载点找到安装包，并且要写enabled=1，否则之后的安装可能会有问题

2、查看策略和服务状态，并开启服务，如下所示：

   ipvsadm -l           ###查看策略systemctl status ipvsadm.service   ###查看ipvsadm的状态，此时应该是关着的systemctl start ipvsadm.service        ###开启服务，发现报错

通过查看文件的相关设定和日志，我们可以知道这是因为缺少文件/etc/sysconfig/ipvsadm，创建此文件，在次重启发现可以重启，如下所示：

  vim /usr/lib/systemd/system/ipvsadm.service  ###查看此文件，便于知道一些设置vim /var/log/messages        ###查看重启不原因touch /etc/sysconfig/ipvsadm    ##建文件systemctl start ipvsadm.service    ##开启服务systemctl status ipvsadm.service    ###查看状态，此时状态是开着的

3、进入文件下修改18行为yes，如下所示：

vim /etc/sysconfig/ipvsadm-config     ##进入此文件修改,将18行改为yes

4、添加后端实际服务器并保存策略，如下所示：

  ipvsadm -A -t 172.25.10.100:80 -s rr    ##添加100ip作为ipvsadm -a -t 172.25.10.100:80 -r 172.25.10.2:80 -gipvsadm -a -t 172.25.10.100:80 -r 172.25.10.3:80 -gcat /etc/sysconfig/ipvsadmsystemctl restart ipvsadm.servicecat /etc/sysconfig/ipvsadmipvsadm -lipvsadm -ln

注意：

-l：列出当前的策略

-n：不解析
-A：增加一台虚拟设备
-a：增加真实服务器的操作
-t：tcp服务地址
-s：调度算法（调度算法分别有10种，为rr/wrr/lc/wlc/lblc/lblcr/dh/sh/sed/nq）
-r：对应的真实ip
-g：rh（路由）
rr：调度算法，轮循

5、添加VIP地址，将VIP地址配置在各自的NonARP网络设备中，如下所示：

 ip aip addr add 172.25.10.100/24 dev eth0ip aipvsadm -ln

server2主机上：

1、安装httpd服务，如下所示：

yum install httpd -y

2、在默认发布目录下编写一个测试页，开启apache服务，并添加VIP，如下所示：

 vim /var/www/html/index.htmlcat /var/www/html/index.htmlsystemctl start httpdip addr add 172.25.10.100/24 dev eth0ip a

server3主机上：

1、安装httpd服务，如下所示：

yum install httpd -y

2、在默认发布目录下编写一个测试页，开启apache服务，并添加VIP，如下所示：

 vim /var/www/html/index.htmlcat /var/www/html/index.htmlsystemctl start httpdip addr add 172.25.10.100/24 dev eth0ip a

物理机测试：

1、在物理机尝试访问172.25.66.100，会发现其一直返回的是server3中的测试页

curl 172.25.10.100
curl 172.25.10.100
curl 172.25.10.100
curl 172.25.10.100

2、我们通过查看物理机绑定的MAC地址后，会发现其MAC地址是server3的MAC地址，无法进行轮循，如下所示：

arp -an | grep 100

3、删除绑定的MAC地址并重新访问，发现此时的MAC地址是server1的MAC地址，如下所示：

 arp -d 172.25.10.100curl 172.25.10.100    ##此时会出现轮循

注意：
1.servrer1，server2，server3都有可能被访问到
2.如果绑定的MAC地址是server1，则访问的测试页会在server2和server3中循环显示
3.如果绑定的MAC地址是server2或server3中其中一个，访问时不会轮循，而是只显示绑定MAC地址的主机的测试页，所以，这样是不合理的

为了解决上面的不合理情况，只有一直绑定sever1的MAC地址，所以我门要配置server2和server3的arp路由策略，具体如下所示：

server2主机上：

1、安装arptables_jf工具（配置arp路由策略）

 yum search arptablesyum install arptables.x86_64 -y

2、为arptables网络的用户控制过滤的守护进程（防止在物理机中测试时直接访问server2，相当于编写防火墙策略）

[root@server2 ~]# iptables -nL  ##查看策略
[root@server2 ~]# arptables -A IN -d 172.25.12.100 -j DROP  #当网内广播需要172.25.12.100这个ip时，它将丢弃网内的所有请求
[root@server2 ~]# arptables -A OUT -s 172.25.12.100 -j mangle --mangle-ip-s 172.25.12.2 #当它自身需要在网内发包时，伪装为自己原本的ip172.25.12.2
[root@server2 ~]# arptables -nL
[root@server2 ~]#  cat /etc/sysconfig/arptables
[root@server2 ~]# arptables-save > /etc/sysconfig/arptables
[root@server2 ~]# cat /etc/sysconfig/arptables      ##此时有文件

3、查看状态，并开启arptables服务，如下所示

 systemctl status arptables.servicesystemctl start arptables.servicesystemctl status arptables.service

server3主机上：

1、安装arptables_jf工具（配置arp路由策略）

 yum search arptablesyum install arptables.x86_64 -y

2、为arptables网络的用户控制过滤的守护进程（防止在物理机中测试时直接访问server3，相当于编写防火墙策略）

[root@server3 ~]# iptables -nL  ##查看策略
[root@server3 ~]# arptables -A IN -d 172.25.12.100 -j DROP  #当网内广播需要172.25.12.100这个ip时，它将丢弃网内的所有请求
[root@server3 ~]# arptables -A OUT -s 172.25.12.100 -j mangle --mangle-ip-s 172.25.12.3 #当它自身需要在网内发包时，伪装为自己原本的ip172.25.12.3
[root@server3 ~]# arptables -nL
[root@server3 ~]# arptables-save > /etc/sysconfig/arptables
[root@server3 ~]# systemctl restart iptables  ##重启服务

物理机再次测试：

删除原来绑定的MAC地址，再次测试，此时发现可以轮循，且经过调度器，如下所示：

arp -d 172.25.10.100   ###清理缓存
curl 172.25.10.100
curl 172.25.10.100
curl 172.25.10.100
curl 172.25.10.100

DR模式小结：

　　1、通过在调度器LB上修改数据包的目的MAC地址实现转发，端口不改变。意味着发送到RS上时的端口还是原来的端口，如果在RS上安装了Tomcat，那么

Tomcat的端口也应该是和前面的端口一致，注意源地址仍然是CIP，目的地址仍然是VIP地址。

　　2、请求的报文经过调度器，而RS响应处理后的报文无需经过调度器LB，因此并发访问量大时使用效率很高（和NAT模式比）

　　3、因为DR模式是通过MAC地址改写机制实现转发，因此所有RS节点和调度器LB只能在一个局域网里面

　　4、RS主机需要绑定VIP地址在LO接口上，并且需要配置ARP抑制。

　　5、RS节点的默认网关不需要配置成LB，而是直接配置为上级路由的网关，能让RS直接出网就可以。

　　6、由于DR模式的调度器仅做MAC地址的改写，所以调度器LB就不能改写目标端口，那么RS服务器就得使用和VIP相同的端口提供服务。