1200字范文 > 企业级负载均衡集群（4层）——lvs的DR模式和TUN模式（一）

企业级负载均衡集群（4层）——lvs的DR模式和TUN模式（一）

时间：2024-02-18 23:35:14

文章目录

1.什么是lvs？1.1 lvs的特点1.1.1 lvs的优点1.1.2 lvs的缺点2 LVS工作模式2.1 LVS工作模式分类2.2 lvs三种工作模式的原理与区别2.2.1 基于NAT的LVS负载均衡（lvs的NAT模式）2.2.2 基于TUN的LVS负载均衡（lvs的TUN模式、隧道模式）2.2.3 基于DR的LVS负载均衡（DR模式）3 DR模式的原理3.1 LVS（Linux Virtual Server）Linux虚拟服务器的介绍4. 搭建实验环境5 实现lvs调度器的DR模式5.1 在server1上面搭建lvs服务5.2 ipvsadm -l列出策略（查看调度策略）5.3 配置服务5.4 设置DR模式的访问策略5.5 解决DR模式不轮询的问题5.5.1 yum install -y arptables安装针对MAC地址的防火墙管理工具5.5.2 在真机上面进行测试6 隧道模式6.1 TUN模式的工作原理6.2 .实现lvs调度器的TUN模式6.3 增加隧道所用的模块6.4 在web1和web2上面进行添加隧道模块6.5 关闭反向过滤规则6.7 测试

1.什么是lvs？

LVS（Linux Virtual Server）即Linux虚拟服务器。

用户从外部访问公司的外部负载均衡服务器，把终端用户的Web请求发送给LVS调度器，

调度器根据自己预设的算法决定将该请求发送给后端的某台Web服务器。

比如，轮询算法可以将外部的请求平均（或加权）分发给后端的所有服务器，终端用户访问LVS调度器虽然会被转发到后端真实的服务器

但如果真实服务器连接的是相同的存储，提供的服务也是相同的服务，最终用户不管是访问哪台真实服务器

得到的服务内容都是一样的，整个集群对用户而言都是透明的

互联网用户访问web资源的时候先去访问lvs负载均衡调度器，再由lvs将用户的请求转给web服务器

这样可以均衡一下后端服务器的压力，防止同一时间某台后端web服务器的访问量过大，导致服务器瘫痪

既有利于公司服务的稳定运行，也有利于客户的使用

最后根据LVS工作模式的不同，真实服务器会选择不同的方式将用户需要的数据发送到终端用户

1.1 lvs的特点

在互联网企业当中，通过LVS提供的负载均衡技术和Linux操作系统实现一个高性能、高可用的服务器群集

它具有良好可靠性、可扩展性和可操作性，从而以低廉的成本实现最优的服务性能

1.1.1 lvs的优点

1.1.2 lvs的缺点

工作在4层，不支持7层规则修改，机制过于庞大，不适合小规模应用

2 LVS工作模式

2.1 LVS工作模式分类

（1）NAT模式（转换一个ip地址，效率低）

（2）TUN模式（ip隧道）

（3）DR模式(调度器跟真正的服务器在同一网段，强行修改mac地址，并不改变ip地址)

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

2.2.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表中可以直接找到之前的连接记录，并根据记录信息选出相同的真实服务器及端口信息。

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

在LVS（NAT）模式的集群环境中，由于所有的数据请求及响应的数据包都需要经过LVS调度器转发

也就是客户端通过调度器请求资源，最终资源也是调度器返回给客户端的，有回送的数据包

如果后端服务器的数量大于10台，则调度器就会成为整个集群环境的瓶颈

数据请求包往往远小于响应数据包的大小

因为响应数据包中包含有客户需要的具体数据，所以LVS（TUN）的思路就是将请求与响应数据分离

让调度器仅处理数据请求，而让真实服务器将响应数据包直接返回给客户端，不再由调度器往返资源

IP隧道（IP tunning）是一种数据包封装技术，它可以将原始数据包封装并添加新的包头（内容包括新的源地址及端口、目标地址及端口），从而实现将一个目标为调度器的VIP地址的数据包封装，通过隧道转发给后端的真实服务器（Real Server），通过将客户端发往调度器的原始数据包封装，并在其基础上添加新的数据包头（修改目标地址为调度器选择出来的真实服务器的IP地址及对应口），LVS（TUN）模式要求真实服务器可以直接与外部网络连接，真实服务器在收到请求数据包后直接给客户端主机响应数据。

2.2.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不需要对外界可见

3 DR模式的原理

在一台主机上面搭建lvs服务器，设置lvs的工作模式是DR模式，lvs仅仅是一个调度器，它会把客户端的请求转发给后备服务器

DR模式直接由后备服务器把数据返回给客户端，不需要逆向发送数据包，此时lvs只做调度就可，效率很高

lvs调度器叫做DS调度器(director server)，RS是真正的后端web服务器(real server)

Client发送请求 --> DS(调度器) -->prerouting --> INPUT -->postrouting -->RS（真正的服务器）–>lo回环接口 --> 网卡eth0 -->Client

整个过程的数据流向如下用户（client）发送请求给调度器(DS)，DS调度器先把请求发往prerouting链（内核空间kernal space），确定请求的是不是VIP。到了INPUT链之后，如果请求的是集群服务，会在这里修改MAC地址，把源MAC地址改为DS的MAC地址
把目的MAC地址改为RS的MAC地址，此时IP仍然不变，处理完成后把请求发往postrouting链
检测请求的是否为RS（会检测请求的MAC地址），如果是，接受请求，把请求通过回环接口发给出口的网卡，再发回给客户端
数据在系统内的交流用的是回环接口，与外部的交流用的是网卡eth0
DR模式高效的原因就是RS服务器会直接响应客户端的请求，发送的请求一直往前发送数据包，不会再返回数据包给调度器
注意：这里的prerouting，input，postrouting其实就是iptables防火墙里面的链
其中：

特点：

所有的请求报文都是由调度器（DS）进行调度的 DR模式不支持端口映射 RS和DS必须在同一网络，可以不在同一网段，使用交换机即可
MAC地址在第二层，数据链路层，还没有到IP所在的网络层
realserver的RIP和Director的DIP必须处于同一网段中，以便使用MAC地址进行通信
realserver上必须配置VIP地址，以便接收director转发过来的数据包，以及作为响应报文的源IP
realserver响应给客户端的数据包的源和目的IP为VIP—>CIP director只处理入站请求，响应请求由realserver完成
七层调度（负载均衡），4层分摊流量

3.1 LVS（Linux Virtual Server）Linux虚拟服务器的介绍

LVS包括两个东西：

（1）IPVS：工作在INPUT链，依附于5个内置钩子函数，其实就是一段代码，已经集成在LInux的源码中

（2）IPVSADM：具体编写策略的工具

DR模式改变的是MAC地址

DR模式可能会有人恶意连接，一直发送数据包给一台后端服务器，不轮询，导致后端服务器瘫痪，但可以解决

4. 搭建实验环境

在真机中开启三台虚拟机

1台做lvs调度器，两台做后端轮询的web服务器，用真机分别连接三台虚拟机，真机本身是客户端

5 实现lvs调度器的DR模式

注意：虽然lvs的调度算法很多，这里使用轮询算法

5.1 在server1上面搭建lvs服务

yum search ipvsadm寻找这个服务（工具）yum install ipvsadm.x86_64 -y安装服务

5.2 ipvsadm -l列出策略（查看调度策略）

5.3 配置服务

vim /etc/sysconfig/ipvsadm-config

修改lvs服务的配置文件:no->yes,重启服务的时候保存策略

重启服务：

5.4 设置DR模式的访问策略

ipvsadm -A -t 192.168.0.100:80 -s rr 设置客户端进入lvs调度器的入口地址，调度算法是轮询
ipvsadm -a -t 192.168.0.100:80 -r 192.168.0.12:80
-g设置lvs的策略：入口的第一台后端服务器的信息 ipvsadm -a -t 192.168.0.100:80 -r 192.168.0.13:80 -g设置lvs的策略：入口的第二台后端服务器的信息
-s表示调度算法，rr表示轮询，-g表示lvs调度器工作在DR模式

虚拟ip解决不了问题（入口）

增加实用ip可以解决问题的ip：

cat /etc/sysconfig/ipvsadm 查看策略文件，发现没有策略 systemctl restart
ipvsadm.service重启服务的时候保存策略
cat /etc/sysconfig/ipvsadm 查看策略文件，发现有策略

增加100的ip

设置两台后端服务器（server2和server3）的apache服务，也就是web服务yum install httpd -y安装httpdvim /var/www/html/index.html编写共享页面systemctl restart httpd重启

在真机里面测试，先做解析

192.168.0.11

测试无结果，但是由权重可以得出调度是对的：

总结：dr模式的走向：客户端到虚拟主机（vs）再到真实主机后端（rs）再直接返回给客户端。访问的100结果是12或13返回的数据，所以客户端不接收数据，因此没有数据。

100是公网ip，要让12或13也变为100，这样别人就能接收数据了：

在后端服务器1(server2、3)上面设置用户访问的入口地址:ip addr add 192.168.0.100/24 dev eth33
ip a查看

注意：在两个web服务器上设置用户访问的入口地址是为了web服务器可以直接给客户端发送资源，不需要再返回给调度器

因为客户端访问的是入口地址，如果不用入口地址给客户发送资源，客户可能不会接收这个数据包

如果直接在客户端curl 192.168.0.100发现客户端要不到资源

因为DR工作模式是：client->vs->rs->client，由后备服务器端直接送回资源给客户端

但是客户端问100要的资源，后端服务器12、13直接把资源给客户端，客户端不会识别

因此要在两个后端服务器上面设置入口地址

开启80端口：

这个是访问的调度器的：

注意：此时客户端访问资源有时候轮询，有时候不轮询：

造成这种情况的原因是因为DR模式是通过修改MAC地址进行访问的，调度器和两台web服务器上都有100这个入口地址ip

所以客户端在请求的时候，三台虚拟机都有可能回复请求，客户端会记录回复他的那台虚拟机的mac地址

所以下次在访问的时候他会找记录过的mac地址对应的虚拟机（有可能是真实的服务器）直接访问

这样会有可能会直接访问到12、13后端服务器，容易崩溃。

比如打10086，但是知道了一个服务员的号码，所有人都只给他打电话就造成宕机了：

在客户端查看它访问的入口地址的主机的MAC地址是多少

5.5 解决DR模式不轮询的问题

因为DR模式使用的是MAC地址

会造成DDOS攻击，导致后端服务器瘫痪

因为客户端第一次访问192.168.0.100的时候server1,server2,server3均可以接收客户端的请求，这个是随机的

有可能不会经过lvs调度器，客户端直接问web服务器要资源

在两个web后端上进行设置，防止ddos攻击

直接让后端服务器不做响应：

server2和server3做同样事情

5.5.1 yum install -y arptables安装针对MAC地址的防火墙管理工具

5.5.2 在真机上面进行测试

此时做完这个：就可以实现调度了

web2和web3就不会接受客户端的请求了，每次客户端的访问只能由调度器接收这个请求，因此也就是通过lvs调度器的mac地址。

通过调度器访问时，因为调度器里面设置了调度规则，所以可以实现正常访问

访问的都是调度器上：

6 隧道模式

6.1 TUN模式的工作原理

TUN模式简称隧道模式，隧道模式就是修改请求报文的首部IP，再加一层IP报头

优点：DS和RS不需要在同一网段，可以实现不同网络之间的访问

数据流向如下

数据包从客户端发往DS服务器，DS服务器会根据调度策略确定要把请求给哪台RS，会在数据包外面再加一层IP报头

此时源IP从CIP（172.25.0.250）变为了VIP（DIP172.25.0.100）

目的IP从VIP（172.25.0.100）变为了RIP（172.25.0.2/172.25.0.3），数据包的请求来源就是DS调度器（172.25.0.100）

请求的目的地是RS（172.25.0.2/3），RS在接收到数据包之后，请求包的来源本来是CIP（172.25.0.250）

但是加了一层数据包之后变为了VIP（172.25.0.100），而RS服务器上也有172.25.0.100这个ip

所以RS会把IP包的报头拆开，拆开发现请求的数据包访问的还是自己的ip（172.25.0.2/3）

这时RS就会回复客户端的请求（跟DR模式类似，只不过多加了一层IP报头，封装IP守护）

Client --> DS(调度器) -->prerouting --> INPUT -->postrouting -->RS（真正的服务器）–>lo 回环接口–> 网卡eth0 -->Client

IP隧道技术又称为IP封装技术，它可以将带有源和目标IP地址的数据报文使用新的源和目标IP进行二次封装

这样这个报文就可以发送到一个指定的目标主机上

客户端发送到lvs调度器的数据包：源地址：CIP（客户端IP）目标地址：VIP（DS服务器）

加了数据包报头之后：源地址：DIP（VIP）（DS服务器）目标地址：RIP（RS真正的服务器）

清除原先的规则：

在lvs服务器上面进行（server1）ipvsadm -ln查看一下刚才的轮询调度访问策略ipvsadm -C清除DR模式的策略ipvsadm -ln再查看一下

6.2 .实现lvs调度器的TUN模式

DR模式：给web1和web2使用arptables规则来丢弃客户端的第一次访问，使客户端直接找lvs服务器实现调度轮询，不可以跨网络访问

隧道模式：给web1和web2用关闭反向过滤规则来丢弃客户端的第一次访问，使客户端直接找lvs服务器实现调度轮询，可跨网络访问

6.3 增加隧道所用的模块

lsmod查看模块（虚拟机上没有虚拟模块），准备加入隧道模块lsmod | grep kvm在虚拟机上查看没有虚拟模块，在真机上查看有虚拟机模块modprobe ipip加入隧道模块ip a 可以看到多了一块网卡tunl0ip addr del 172.25.0.100/24 dev eth0 将172.25.0.100从原来的网卡上ip删除ip addr add 172.25.0.100/24 dev tunl0 放到隧道网卡上面ip a查看网卡的状态是downip link set up tunl0激活网卡ip a查看是unknow，只要不是down就行

在隧道模式里面添加策略：ipvsadm -A -t 172.25.0.100:80 -s rr 设置轮询调度ipvsadm -a -t 172.25.0.100:80 -r 172.25.0.2:80 -i 表示隧道模式，轮询web服务器1ipvsadm -a -t 172.25.0.100:80 -r 172.25.0.3:80 -i 表示隧道模式，轮询web服务器2systemctl restart ipvsadm.service重启服务使设置生效cat /etc/sysonfig/ipvsadm查看策略文件