高可用负载均衡集群 - lvs的介绍和DR模式

1. lvs的定义

LVS（Linux Virtual Server）即Linux虚拟服务器。它是一个虚拟的服务器集群系统，可以实现负载均衡集群功能【UNIX/LINUX平台】
lvs基本工作原理：
lvs ——> kernel space ——> IP ——> INPUT(ipvs) ——> change ——> POSTROUTING ——> rs

该项目在Linux内核中实现了基于IP的数据请求负载均衡调度方案，其体系结构如图1所示，终端互联网用户从外部访问公司的外部负载均衡服务器，终端用户的Web请求会发送给LVS调度器，调度器根据自己预设的算法决定将该请求发送给后端的某台Web服务器
比如，轮询算法可以将外部的请求平均分发给后端的所有服务器，终端用户访问LVS调度器虽然会被转发到后端真实的服务器，但如果真实服务器连接的是相同的存储，提供的服务也是相同的服务，
最终用户不管是访问哪台真实服务器，得到的服务内容都是一样的，整个集群对用户而言都是透明的。
最后根据LVS工作模式的不同，真实服务器会选择不同的方式将用户需要的数据发送到终端用户，LVS工作模式分为NAT模式、TUN模式、以及DR模式

LVSLin	ux 虚拟服务	工作在四层的负载调度器，用于四层转发数据
组件	ipvs	内核态，工作在内核空间，LVS 核心代码
ipvsadm	用户态	工作在用户空间，是用户管理LVS的唯一手段

命名约定表

名称			简写				说明
虚拟IP			VIP			LB用于向客户端计算机提供服务的IP地址
真实IP			RIP			在集群下面节点上使用的IP地址，真实提供服务的IP地址
Dirctor的IP		DIP			连接内外网络的IP地址，负载均衡器上的IP
客户端IP			CIP			客户端请求集群服务器的IP地址，源IP

LVS集群的工作模式

NAT		（Network Address Translation）
TUN		（Tunneling）
DR		（Direct Routing）
FULLNAT （Full Network Address Translation）

2. 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就简单多了。

3. lvs三种工作模式的原理与区别

3.1 基于NAT的LVS负载均衡（lvs的NAT模式）

NAT（Network Address Translation）即网络地址转换，其作用是通过数据报头的修改，使得位于企业内部的私有IP地址可以访问外网，以及外部用户可以访问位于公司内部的私有IP主机
LVS负载调度器可以使用两块网卡配置不同的IP地址
eth0设置为私钥IP与内部网络通过交换设备相互连接，eth1设备为外网IP与外部网络联通

整个工作流程如下：

第一步：用户通过互联网DNS服务器解析到公司负载均衡设备上面的外网地址，相对于真实服务器而言，LVS外网IP又称VIP（Virtual IP Address），
用户通过访问VIP，即可连接后端的真实服务器（Real Server），而这一切对用户而言都是透明的，用户以为自己访问的就是真实服务器，
但访问的VIP仅仅是一个调度器，也不知道后端的真实服务器到底在哪里、有多少真实服务器。

第二步，用户将请求发送至调度器（124.126.147.168），此时LVS将根据预设的算法选择后端的一台真实服务器（192.168.0.1~192.168.0.3），
将数据请求包转发给真实服务器，并且在转发之前LVS会修改数据包中的目标地址以及目标端口，
目标地址与目标端口将被修改为选出的真实服务器IP地址以及相应的端口。

第三步，真实的服务器将响应数据包返回给LVS调度器，调度器在得到响应的数据包后会将源地址和源端口修改为VIP及调度器相应的端口，
修改完成后，由调度器将响应数据包发送回终端用户，另外，由于LVS调度器有一个连接Hash表，该表中会记录连接请求及转发信息，
当同一个连接的下一个数据包发送给调度器时，从该Hash表中可以直接找到之前的连接记录，并根据记录信息选出相同的真实服务器及端口信息。

3.2 基于TUN的LVS负载均衡（lvs的TUN模式、隧道模式）

在LVS（NAT）模式的集群环境中，由于所有的数据请求及响应的数据包都需要经过LVS调度器转发
也就是客户端通过调度器请求资源，最终资源也是调度器返回给客户端的，有回送的数据包
如果后端服务器的数量大于10台，则调度器就会成为整个集群环境的瓶颈

数据请求包往往远小于响应数据包的大小 因为响应数据包中包含有客户需要的具体数据
LVS（TUN）的思路就是将请求与响应数据分离让调度器仅处理数据请求，而让真实服务器将响应数据包直接返回给客户端，不再由调度器往返资源 IP隧道（IP tunning）是一种数据包封装技术
它可以将原始数据包封装并添加新的包头（内容包括新的源地址及端口、目标地址及端口），从而实现将一个目标为调度器的VIP地址的数据包封装，通过隧道转发给后端的真实服务器（RealServer）
通过将客户端发往调度器的原始数据包封装，并在其基础上添加新的数据包头（修改目标地址为调度器选择出来的真实服务器的IP地址及对应口）
LVS（TUN）模式要求真实服务器可以直接与外部网络连接，真实服务器在收到请求数据包后直接给客户端主机响应数据。

3.3 基于DR的LVS负载均衡（DR模式）

• 在LVS（TUN）模式下，由于需要在LVS调度器与真实服务器之间创建隧道连接，这同样会增加服务器的负担

• 与LVS（TUN）类似，DR模式也叫直接路由模式

• 该模式中LVS依然仅承担数据的入站请求以及根据算法选出合理的真实服务器
  最终由后端真实服务器负责将响应数据包发送返回给客户端

• 与隧道模式不同的是，直接路由模式（DR模式）要求调度器与后端服务器必须在同一个局域网内

- VIP地址需要在调度器与后端所有的服务器间共享，因为最终的真实服务器给客户端回应数据包时需要设置源IP为VIP地址
目标IP为客户端IP，这样客户端访问的是调度器的VIP地址，回应的源地址也依然是该VIP地址（真实服务器上的VIP）
客户端是感觉不到后端服务器存在的
- 由于多台计算机都设置了同样一个VIP地址，所以在直接路由模式中要求调度器的VIP地址是对外可见的
客户端需要将请求数据包发送到调度器主机，而所有的真实服务器的VIP地址必须配置在Non-ARP的网络设备上
也就是该网络设备并不会向外广播自己的MAC及对应的IP地址，真实服务器的VIP对外界是不可见的

- 但真实服务器却可以接受目标地址VIP的网络请求，并在回应数据包时将源地址设置为该VIP地址
调度器根据算法在选出真实服务器后，在不修改数据报文的情况下，将数据帧的MAC地址修改为选出的真实服务器的MAC地址
通过交换机将该数据帧发给真实服务器，整个过程中，真实服务器的VIP不需要对外界可见

4. 搭建实验环境

三台虚拟机+一台真实主机

主机名称　　           ip                  	功能 服务
server1            172.25.254.11           lvs调度器 DS
server2            172.25.254.12           apache 后端web服务器1 RS
server3            172.25.254.13           apache 后端web服务器2 RS
主机localhost      172.25.254.60           客户端（client）

5. lvs的安装与启用

5.1 安装策略编写工具

• vim /etc/sysconfig/ipvsadm-config
  

• systemctl restart ipvsadm.service
  重启服务会报错

• touch /etc/sysconfig/ipvsadm
  创建编写策略的文件
  systemctl restart ipvsadm.service
  重启服务

5.2 DR模式编写策略

• ipvsadm -h
  帮助文档

• rr轮询

# -A : 添加一个虚拟路由主机(LB)
# -t : 指定虚拟路由主机的VIP地址和监听端口
# -s : 指定负载均衡算法
# -p : 指定会话保持时间
 
# -a : 添加RS节点
# -r : 指定RS节点的RIP地址和监听端口
# -g : 指定DR模式
 
# rr : 这里使用的是rr轮循算法，所以没有使用-w参数，可以通过-w参数指定权值

[root@server1 ~]# ipvsadm -A -t 172.25.254.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  172.25.254.100:http rr
-a:添加真实ip  -r:主机ip  -g：DR模式
[root@server1 ~]#ipvsadm -a -t 172.25.254.100:80 -r 172.25.254.12:80 -g
[root@server1 ~]#ipvsadm -a -t 172.25.254.100:80 -r 172.25.254.13:80 -g
[root@server1 ~]# systemctl restart ipvsadm.service重启服务

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

• 测试1

• 测试二
  客户端没有使用调度器去访问（DR模式改变的是MAC地址）

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

这种情况的原因是因为DR模式是通过修改MAC地址进行访问的，调度器和两台web服务器上都有172.25.254.100这个入口地址ip
所以客户端在请求的时候，三台虚拟机都有可能回复请求，客户端会记录回复他的那台虚拟机的mac地址，下次在访问的时候他会找记录过的mac地址对应的虚拟机（有可能是真实的服务器）直接访问

这在现实中是不允许的，因为如果请求全部发往后端某一台真正的服务器的话，这台服务器会因为压力过大而宕机
而且，直接访问后端的真正的服务器，我们的server1（LVS调度器）也就没有起到作用，并没有实现真正意义上的负载均衡，这也是DR模式的一个缺点

6. 解决在DR模式下不轮询的问题

DR模式改变的是MAC地址
DR模式可能会有人恶意连接，一直发送数据包给一台后端服务器，不轮询，导致后端服务器瘫痪。

解决方法：
原理：在后端服务器上面设置拒绝客户端直接访问192.168.1.100这个IP地址，那么就只有lvs调度器服务的主机可以接受客户端的请求，并且要设置后端服务器可以通过192.168.1.100的ip身份反馈资源信息。

测试：