负载均衡集群——lvs的介绍+DR模式详细介绍

一、lvs的定义
LVS（Linux Virtual Server）即Linux虚拟服务器，是由章文嵩博士主导的开源负载均衡项目，目前LVS已经被集成到Linux内核模块中。该项目在Linux内核中实现了基于IP的数据请求负载均衡调度方案，其体系结构如图1所示，终端互联网用户从外部访问公司的外部负载均衡服务器，终端用户的Web请求会发送给LVS调度器，调度器根据自己预设的算法决定将该请求发送给后端的某台Web服务器，比如，轮询算法可以将外部的请求平均分发给后端的所有服务器，终端用户访问LVS调度器虽然会被转发到后端真实的服务器，但如果真实服务器连接的是相同的存储，提供的服务也是相同的服务，最终用户不管是访问哪台真实服务器，得到的服务内容都是一样的，整个集群对用户而言都是透明的。最后根据LVS工作模式的不同，真实服务器会选择不同的方式将用户需要的数据发送到终端用户，LVS工作模式分为NAT模式、TUN模式、以及DR模式。
LVS：Linux 虚拟服务,工作在四层的负载调度器，用于四层转发数据
组件：ipvs：内核态，工作在内核空间，LVS 核心代码
ipvsadm：用户态，工作在用户空间，是用户管理LVS的唯一手段

LVS的优点是：
1、抗负载能力强、是工作在网络4层之上仅作分发之用，没有流量的产生，这个特点也决定了它在负载均衡软件里的性能最强的，对内存和cpu资源消耗比较低。
2、配置性比较低，这是一个缺点也是一个优点，因为没有可太多配置的东西，所以并不需要太多接触，大大减少了人为出错的几率。
3、工作稳定，因为其本身抗负载能力很强，自身有完整的双机热备方案，如LVS+Keepalived，不过我们在项目实施中用得最多的还是LVS/DR+Keepalived。
4、无流量，LVS只分发请求，而流量并不从它本身出去，这点保证了均衡器IO的性能不会受到大流量的影响。
5、应用范围比较广，因为LVS工作在4层，所以它几乎可以对所有应用做负载均衡，包括http、数据库、在线聊天室等等。
LVS的缺点是：
1、软件本身不支持正则表达式处理，不能做动静分离；而现在许多网站在这方面都有较强的需求，这个是Nginx/HAProxy+Keepalived的优势所在。
2、如果是网站应用比较庞大的话，LVS/DR+Keepalived实施起来就比较复杂了，特别后面有Windows Server的机器的话，如果实施及配置还有维护过程就比较复杂了，相对而言，Nginx/HAProxy+Keepalived就简单多了。

DR模式中的名词解释
DS	调度器，lvs的前端设备
RS	真正提供服务的后端服务器
RIP	后端服务器的ip地址
DIP	调度器和后端服务器通信的ip
源IP	CIP（客户端的IP）
目的IP	VIP（设置的统一入口），对外公布的ip，客户请求进来的ip
源MAC地址	DS调度器的MAC地址
目的MAC地址	RS真正服务器的MAC地址

三、搭建实验环境
1.实验环境
三台虚拟机+一台真实主机

主机名称　　           ip                  功能
server1            192.168.1.11          lvs调度器 DS       
server2            192.168.1.22          [apache]后端web服务器1 RS
server3            192.168.1.33          [apache]后端web服务器2 RS
主机localhost      192.168.1.55          客户端（client）

四、lvs的安装与启用
安装策略编写工具

[root@server1 ~]# yum install -y ipvsadm.x86_64 

[root@server1 ~]# rpm -qa | grep ipvsadm
ipvsadm-1.27-7.el7.x86_64
[root@server1 ~]# rpm -qc ipvsadm-1.27-7.el7.x86_64
/etc/sysconfig/ipvsadm-config
[root@server1 ~]# vim /etc/sysconfig/ipvsadm-config
[root@server1 ~]# systemctl restart ipvsadm.service  重启服务会报错

查看日志缺少文件

[root@server1 ~]# touch /etc/sysconfig/ipvsadm  创建编写策略的文件
[root@server1 ~]# systemctl restart ipvsadm.service   重启服务

编写策略

[root@server1 ~]# ipvsadm -h  帮助文档

rr轮询

-A添加  -t：指定虚拟ip  -s：指定轮询
[root@server1 ~]# ipvsadm -A -t 192.168.1.100:80 -s rr
[root@server1 ~]# ipvsadm -l  查看策略ipvsadm -ln不解析
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
  -> RemoteAddress:Port           Forward Weight ActiveConn InActConn
TCP  192.168.1.100:http rr
-a:添加真实ip  -r:主机ip  -g：DR模式
[root@server1 ~]#ipvsadm -a -t 192.168.1.100:80 -r 192.168.1.22:80 -g
[root@server1 ~]#ipvsadm -a -t 192.168.1.100:80 -r 192.168.1.33:80 -g
[root@server1 ~]# systemctl restart ipvsadm.service重启服务

注意
此时使用192.168.1.100作为公网传递信息
访问原理：客户端——>接收中心——>服务器
反馈原理：服务器——>客户端

[root@server2 ~]# ip addr add 192.168.1.100/24 dev ens33
[root@server3 ~]# ip addr add 192.168.1.100/24 dev ens33

真机里面测试：

vim /etc/hosts先做解析
arp -d 192.168.1.100在清除缓存

结果1：

结果2：
客户端没有使用调度器去访问（DR模式改变的是MAC地址）

[root@localhost ~]# arp -d 192.168.1.100  清除此ip的Mac地址
[root@localhost ~]# arp -an | grep 100 查看100的mac地址，此地址不是lvs调度器的地址

这种情况的原因是因为DR模式是通过修改MAC地址进行访问的，调度器和两台web服务器上都有192.168.1…100这个入口地址ip
所以客户端在请求的时候，三台虚拟机都有可能回复请求，客户端会记录回复他的那台虚拟机的mac地址
所以下次在访问的时候他会找记录过的mac地址对应的虚拟机（有可能是真实的服务器）直接访问
这在现实中是不允许的，因为如果请求全部发往后端某一台真正的服务器的话，这台服务器会因为压力过大而宕机
而且，直接访问后端的真正的服务器，我们的server1（LVS调度器）也就没有起到作用
并没有实现真正意义上的负载均衡，这也是DR模式的一个缺点（）
五、解决在DR模式下不轮询的问题
DR模式改变的是MAC地址
DR模式可能会有人恶意连接，一直发送数据包给一台后端服务器，不轮询，导致后端服务器瘫痪，可以解决。
解决方法：
原理：在后端服务器上面设置拒绝客户端直接访问192.168.1.100这个IP地址，那么就只有lvs调度器服务的主机可以接受客户端的请求，并且要设置后端服务器可以通过192.168.1.100的ip身份反馈资源信息。

在后端服务器server2和server3分别设置以下操作

yum install -y arptables 

测试结果

客户端访问的MAC地址为lvs服务主机的地址

六、LVS——>DR模式的工作原理

在一台主机上面搭建lvs服务器，设置lvs的工作模式是DR模式，lvs仅仅是一个调度器，它会把客户端的请求转发给后备服务器
DR模式直接由后备服务器把数据返回给客户端，不需要逆向发送数据包，此时lvs只有一个职责就是专注做调度，效率很高，此时lvs调度器叫做DS调度器(director server)，RS是真正的后端web服务(realserver)
流程：Client发送请求 --> DS(调度器) -->prerouting --> INPUT -->postrouting -->RS（真正的服务器）–>lo回环接口 --> 网卡eth0 -->Client
整个过程的数据流向如下：
客户端（client）发送请求给lvs调度器(DS)，DS调度器先把请求发往prerouting链（内核空间kernal space），确定请求的是不是VIP（虚拟ip），到了INPUT链之后，如果请求的是集群服务，会在这里修改MAC地址，把源MAC地址改为DS的MAC地址，把目的MAC地址改为RS的MAC地址，此时IP仍然不变，处理完成后把请求发往postrouting链，检测请求的是否为RS（会检测请求的MAC地址），如果是，接受请求，把请求通过回环接口发送到出口的网卡，再发回给客户端，数据在系统内的交流用的是回环接口，与外部的交流用的是网卡ens33
DR模式高效的原因就是RS服务器会直接响应客户端的请求，发送的请求一直往前发送数据包，不会再返回数据包给调度器
prerouting，input，postrouting都是iptables防火墙里面的链