linux运维——LVS（DR模式）

原理

====LVS：负载均衡软件，可达到硬件f5效果。写入linux内核。
DR模式：
当客户发送请求，代理服务器收到之后，进行服务器集群的询问，此时服务机谁先抢占到这个包就由谁响应，但是这样就达不到负载均衡的效果。所以在策略上当代理服务器接受到包，询问谁接受包，接受到包的服务机将这个包抛弃，不响应，由代理服务机策略起分配效果，以达到轮询（在这个过程中其实都是在四层服务以内，使用的不是IP地址，而使用的是MAC地址在同一局域网内进行寻址）。但是处理之后会将已经处理过的服务包发还给客户端，由于客户访问的是VIP，那么如果服务器端没有这个VIP，发还给客户的包肯定不被信任，那么就给这个服务器集群都加VIP，然后让后端服务器使用VIP将包发还给客户。
当用户请求到达Director Server，此时请求的数据报文会先到内核空间的PREROUTING链。 此时报文的源IP为CIP，目标IP为VIP
(b) PREROUTING检查发现数据包的目标IP是本机，将数据包送至INPUT链
IPVS比对数据包请求的服务是否为集群服务，若是，将请求报文中的源MAC地址修改为DIP的MAC地址，将目标MAC地址修改RIP的MAC地址，然后将数据包发至POSTROUTING链。 此时的源IP和目的IP均未修改，仅修改了源MAC地址为DIP的MAC地址，目标MAC地址为RIP的MAC地址
由于DS和RS在同一个网络中，所以是通过二层来传输。POSTROUTING链检查目标MAC地址为RIP的MAC地址，那么此时数据包将会发至Real Server。
RS发现请求报文的MAC地址是自己的MAC地址，就接收此报文。处理完成之后，将响应报文通过lo接口传送给eth0网卡然后向外发出。 此时的源IP地址为VIP，目标IP为CIP
响应报文最终送达至客户端

LVS-DR模型的特性

特点1：保证前端路由将目标地址为VIP报文统统发给Director Server，而不是RS

RS可以使用私有地址；也可以是公网地址，如果使用公网地址，此时可以通过互联网对RIP进行直接访问
RS跟Director Server必须在同一个物理网络中
所有的请求报文经由Director Server，但响应报文必须不能进过Director Server
不支持地址转换，也不支持端口映射
RS可以是大多数常见的操作系统
RS的网关绝不允许指向DIP(因为我们不允许他经过director)
RS上的lo接口配置VIP的IP地址
缺陷：RS和DS必须在同一机房中

特点1的解决方案：

在前端路由器做静态地址路由绑定，将对于VIP的地址仅路由到Director Server。
存在问题：用户未必有路由操作权限，因为有可能是运营商提供的，所以这个方法未必实用
arptables：在arp的层次上实现在ARP解析时做防火墙规则，过滤RS响应ARP请求。这是由iptables提供的
修改RS上内核参数（arp_ignore和arp_announce）将RS上的VIP配置在lo接口的别名上，并限制其不能响应对VIP地址解析请求。

以下实验在rhel7.3主机上进行，真实主机使用arptable策略解决将用户所有针对VIP的请求发送到DS 而不是RS

代理端：

[root@lucky2 ~]# yum install ipvsadm -y
在策略设置完毕之后。可以使用 ipvsadm -l 查看的
[root@lucky2 ~]# ipvsadm -A -t 172.25.35.100:80 -s rr
[root@lucky2 ~]# ipvsadm -a -t 172.25.35.100:80 -r 172.25.35.3:80 -g
[root@lucky2 ~]# ipvsadm -a -t 172.25.35.100:80 -r 172.25.35.4:80 -g
[root@lucky2 ~]# ipvsadm -l
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
  -> RemoteAddress:Port           Forward Weight ActiveConn InActConn
TCP  172.25.35.100:http rr
  -> lucky3:http                  Route   1      0          0         
  -> lucky4:http                  Route   1      0          0 
[root@lucky2 ~]# ip addr add 172.25.35.100/24 dev eth0         这个的意思为加一个虚拟的vip 因为在客户访问的时候，企业是不会将自己real server的ip暴露的，所以使用vip 并且给所有的vip加上 客户端--->代理端---->后端服务器集群real server---->客户端 这样会比NAT模式更方便

加上虚拟的vip，而DR模式就是当 代理端接受的数据包通过vip ，而代理就会询问后台服务器，给其中一台服务器，而这台服务器就会传输给客户数据，但是出来的数据不是vip 的 ，显然这个的是不被信任的，所以就给服务器集群加上vip，通过 用户 ----> 代理-----> 服务器集群-----> 用户 这样的方式更加的快速。代理往后的都是在四层服务以内，使用的不是ip，而是MAC地址在统一局域网内寻址，

后端服务器：

• 需要注意的是后端服务器集群所进行的操作都是相同的，所以在此不过多叙述，以一个为模版即可。
• 两台服务下载httpd服务，并且分别书写index.html文件（在这里需要注意的是，我们为了实验效果明显，我们将index文件书写的不一样，但是在真正的后台服务器在负载均衡的情况下，index.htmnl文件里边的内容都是一样的）

[root@lucky3 ~]# yum install httpd -y
[root@lucky3 ~]# cd /var/www/html/
[root@lucky3 html]# vim index.html
[root@lucky3 html]# cat index.html 
lucky3
[root@lucky3 html]# systemctl start httpd
[root@lucky3 html]#  systemctl enable  httpd
Created symlink from /etc/systemd/system/multi-user.target.wants/httpd.service to /usr/lib/systemd/system/httpd.service.
[root@lucky3 html]# ip addr add 172.25.35.100/24 dev eth0            这句话的就是给后端的服务器也加上vip  而其他的服务器也需要这样进行操作

用户端：

在刚开始测试的时候，会出现某一个后台服务器抢占，而就达不到轮询的目的,所以是需要进行清理的。

[kiosk@foundation35 images]$ curl 172.25.35.100
lucky4
[kiosk@foundation35 images]$ curl 172.25.35.100
lucky4
[kiosk@foundation35 images]$ curl 172.25.35.100
lucky4
[kiosk@foundation35 images]$ curl 172.25.35.100
lucky4
[kiosk@foundation35 images]$ arp -an | grep 172.25.35.100 
? (172.25.35.100) at 52:54:00:74:24:f1 [ether] on br0              这个时候可以查看这个的mac地址是台服务器在占用。

查看到有一台服务器在一直抢占响应，达不到负载均衡的目的，会导致系统崩溃。所以是要将其尽快处理

[root@foundation35 images]# arp -d 172.25.35.100 可以使用这种方式通过轮询达到负载均衡的目的，但是这种不稳定性，所以一般不推荐

使用第二种方式进行解决

• 后端服务器集群同时操作

[root@lucky3 html]# yum install arptables -y
[root@lucky3 html]# arptables -A INPUT -d 172.25.35.100 -j DROP    后台服务器集群同时丢弃，让进来的客户端无法访问	
[root@lucky3 html]# arptables -A OUTPUT -s 172.25.35.100 -j mangle --mangle-ip-s 172.25.35.3 
# 在丢弃以后，还是需要这台服务器需要将数据传输出去的，但是后台服务器是不可能接触到用户的所以还是要代理端的vip 传输出去的。
在调试完毕可以在代理端查看策略 arptables -L 查看协议策略

检测：

[root@foundation35 images]# arp -d 172.25.35.100               可以先将之前的缓存清理，效果会更加明显
[root@foundation35 images]# curl 172.25.35.100
lucky4
[root@foundation35 images]# curl 172.25.35.100
lucky3
[root@foundation35 images]# curl 172.25.35.100
lucky4
[root@foundation35 images]# curl 172.25.35.100
lucky3
[root@foundation35 images]# curl 172.25.35.100
lucky4