部署LVS DR集群

共计 4498 个字符，预计需要花费 12 分钟才能阅读完成。

一、DR 模式集群

在 TUN 模式下, 由于需要在 LVS 与真实服务器之间创建隧道连接，这样会增加服务器的负担。与 TUN 模式类似, 在 DR 模式中 LVS 依然只承担数据的入站请求，并且根据算法选择出合适的真实服务器，最终有后端真实服务器负责将响应数据包发送给客户端。但是与隧道模式不同的是，DR 模式中要求调度器与后端服务器必须在同一个局域网内，VIP 地址也需要在调度器与后端所有的服务器间共享，因为最终的真实服务器给客户端回应数据包时需要设置源地址为 VIP 的地址, 目标地址为为客户端的 IP 地址，这样客户端访问的是 LVS 调度器的 VIP 地址，回应的源地址也依然是 VIP 地址，客户端是感觉不到后端服务器的存在的，由于多台计算机都设置了同样一个 VIP 地址，所以在 DR 模式中要求调度器的 VIP 地址对外是可见的，客户端需要讲请求数据包发送到调度器主机，也就是 LVS，而所有的真实服务器的 VIP 地址必须配置在 Non-ARP 的网络设备上，也就是该网络设备并不会向外广播自己的 MAC 及对应的 IP 地址，真实服务器的 VIP 对外是不可见的，但是真实服务器却可以接受目标地址为 VIP 的网络请求，并在回应数据包时将源地址设置为该 VIP 地址，LVS 根据算法选出真实服务器后，在不修改数据报文的情况下，将数据帧的 MAC 地址修改为选择出的真实服务器的 MAC 地址，通过交换机将该数据帧发给真实服务器。整个过程中，真实服务器的 VIP 不需要对外可见

工作原理

基于直接路由来实现。当用户请求到达 director 之后，director 将请求报文的目标地址（即 VIP）改成选定的 realserver 地址，还要改写请求报文的 mac 地址，将请求发送到指定 mac 的 realserver，而 realserver 将响应直接返回给客户端，不经过 director。这个方式是三种调度中性能最好的，也是我们生产环境中使用最多的。

特点：

1、集群节点和 director 必须在一个物理网络内
2、RIP 可以使用公网地址或私有地址
3、director 仅处理入站请求
4、集群节点网关不指向 director，故出站不经过 director
5、不支持端口映射
6、大多数操作系统可以作为 realserver，要支持隔离 arp 广播
7、director 服务器的压力比较小

优点： VS/DR 跟 VS/TUN 方法相同，负载调度器中只负责调度请求，而服务器直接将响应返回给客户，可以极大地提高整个集群系统的吞吐量。

缺点： 要求负载均衡器的网卡必须与 RS 物理网卡在一个物理段上

二、实战案例

案例需求

部署基于 LVS DR 模式的 web 集群

实验环境

五台安装 CentOS8 的虚拟机一台测试机，一台 LVS 分发器，一台路由器，两台 web 服务器

注意事项

• 关闭 selinux
• 关闭防火墙
• 停止 libvirtd.service 服务

实验拓扑图

实验机器

实验步骤

a、配置路由，开启转发

ens33=192.168.1.1
ens160=192.168.2.1

[root@route ~]# echo 1 > /proc/sys/net/ipv4/ip_forward

c、配置客户端

ens33=192.168.1.200
[root@client ~]# route add default gw 192.168.1.1

c、LVS 负载均衡器设置

ens33=192.168.2.200
ens37=192.168.2.100(VIP)
[root@lvs ~]# route add default gw 192.168.2.1
[root@lvs ~]# ipvsadm -A -t 192.168.2.100:80 -s rr
[root@lvs ~]# ipvsadm -a -t 192.168.2.100:80 -r 192.168.2.220:80 -g
[root@lvs ~]# ipvsadm -a -t 192.168.2.100:80 -r 192.168.2.210:80 -g

d、RS1&RS2 设置

RS1=192.168.2.220
RS2=192.168.2.210

添加 VIP 并设置网关，调整内核参数

RS1
[root@rs1 ~]# route add default gw 192.168.2.1
[root@rs1 ~]# ifconfig lo:0 192.168.2.100 netmask 255.255.255.255 up
[root@rs1 ~]# echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore 
[root@rs1 ~]# echo 2 > /proc/sys/net/ipv4/conf/all/arp_announce 

RS2
[root@rs2 ~]# route add default gw 192.168.2.1
[root@rs2 ~]# ifconfig lo:0 192.168.2.100 netmask 255.255.255.255 up
[root@rs2 ~]# echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore 
[root@rs2 ~]# echo 2 > /proc/sys/net/ipv4/conf/all/arp_announce 

安装 web 服务，生成测试页面
RS1
[root@rs1 ~]# dnf install httpd -y
[root@rs1 ~]# echo "rs1" > /var/www/html/index.html
[root@rs1 ~]# systemctl start httpd.service
RS2
[root@rs2 ~]# dnf install httpd -y
[root@rs2 ~]# echo "rs2" > /var/www/html/index.html
[root@rs2 ~]# systemctl start httpd.service

e、客户端测试

[root@client ~]# elinks http://192.168.2.100 --dump
   rs2
[root@client ~]# elinks http://192.168.2.100 --dump
   rs1
[root@client ~]# elinks http://192.168.2.100 --dump
   rs2
[root@client ~]# elinks http://192.168.2.100 --dump
   rs1

三、部署中的问题

我们知道，每台主机都有一个 arp 表，这个 arp 表记录了已知主机的 IP 地址和对应的 mac 地址，计算机在进行数据包封装的时候，会读取这个表当中的内容，做为封装数据包的依据，比如说我要给 192.168.1.100 这台主机发送一个数据包，现在我知道这台主机的 IP 地址了, 但是它的 mac 地址是多少呢? 这就需要查看 arp 表当中的记录, 如果查看到了就直接使用 192.168.1.100 以及对应的 mac 地址做为数据包的目的地, 但是如果查看不到, 计算机就会发送 arp 广播, 在网络上去询问“192.168.1.100 你的 mac 地址是多少？我是 xxx，这是我的 mac 地址”, 一旦对方主机给予回应了, 双方就会将对应的信息记录到自己的 arp 表中，以便于下次使用，而我们知道不管是在 DR 模式还是在 tun 模式当中所有的主机都配置了一个叫 VIP 的东西, 那么以我们下面的这个架构图为例

当路由器 (192.168.2.1) 发送 arp 广播询问谁是 192.168.2.100 的时候就会出现一个问题, 我们期望的是 RIP=192.168.2.2 的这台分发器去响应这个 arp 广播，这样路由器才能把客户端的请求包正确的发送给分发器，分发器再去根据自己的算法将请求分配给 RS，也就是 RIP 为 2.3 和 2.4 的主机，但是如果是 RS 去响应这个 arp 的话，那么数据包就不能按照我们预想的去传递，所以在 DR 模式和 TUN 模式中我们要抑制 RS 主机针对于 VIP 的 arp 响应，同时我们还要告诉 RS 主机在发送 arp 广播时，不允许使用 VIP 去声明自己，这就需要我们通过调整内核参数来实现

arp_ignore 控制系统在收到外部的 arp 请求时，如何响应。常用的取值主要有 0，1，2，3~8 较少用到：

0：响应任意网卡上接收到的对本机 IP 地址的 arp 请求（包括环回网卡上的地址），而不管该目的 IP 是否在接收网卡上。

1：只响应目的 IP 地址为接收网卡上的本地地址的 arp 请求。

2：只响应目的 IP 地址为接收网卡上的本地地址的 arp 请求，并且 arp 请求的源 IP 必须和接收网卡同网段。

由于在 DR$TUN 模式中我们 RS 的 VIP 都不是绑定在实体网卡上，所以我们要使用 1 这个值来抑制 RS 主机的 arp 响应

arp_announce 控制系统在对外发送 arp 请求时，如何选择 arp 请求数据包的源 IP 地址。常用的取值有 0，1，2。

0：允许使用任意网卡上的 IP 地址作为 arp 请求的源 IP

1：尽量避免使用不属于该发送网卡子网的本地地址作为发送 arp 请求的源 IP 地址。也就是说，比如我的主机有两个 IP 地址，一个是 1.100，一个是 2.100，但是我发现我需要给 2.200 这台主机发送一个数据包，那此时如果需要发送 arp 请求的话呢我就要尽量使用 2.100 去声明我自己，而尽量去避免使用 1.100 去声明自己；但是如果我需要给 3.200 这台主机发送数据包呢？那就会使用 2 这个级别

2：忽略 IP 数据包的源 IP 地址，选择该发送网卡上最合适的本地地址作为 arp 请求的源 IP 地址。同样使用上面的例子如果给 3.200 发送数据包的话，你的主机发现自己用哪个 IP 地址去声明自己都不合适，你的主机就会查看一下路由记录，如果路由记录告诉你的主机发往 3 网段的数据包都要交给 1.1 这个网关，那你的主机就会使用 1.100 去声明自己，如果是交给 2.1 这个网关的话，你的主机就会使用 2.100 去声明自己。这就是所谓的最合适的

由于在 DR$TUN 模式中我们 RS 的 VIP 都不是绑定在实体网卡上，而实体网卡以及响应的设置信息, 才是最合适的, 我们就要使用 2 这个值来控制 RS 主机如何发送 arp 请求

同样由于 CentOS8 默认开启了反向路由校验功能，会影响 TUN 模式的运行，所以我们还要关闭这个功能，所谓反向路由校验，就是在一个网卡收到数据包后，把源地址和目标地址对调后查找路由出口，从而得到反转后路由出口。然后根据反向路由出口进行过滤，简单来说就是开了这个功能数据包就只能从进入的接口出去。而这个功能我们需要调整另外一个内核参数来实现

rp_filter

0：关闭反向路由校验

1：开启严格的反向路由校验。对每个进来的数据包，校验其反向路由是否是最佳路由。如果反向路由不是最佳路由，则直接丢弃该数据包。

2：开启松散的反向路由校验。对每个进来的数据包，校验其源地址是否可达，即反向路由是否能通（通过任意网口），如果反向路径不通，则直接丢弃该数据包。