Linux运维之LVS实现负载均衡的DR（直接路由）模式

最新推荐文章于 2024-07-15 16:07:59 发布

那人如此可好

最新推荐文章于 2024-07-15 16:07:59 发布

阅读量355

点赞数 2

CC 4.0 BY-SA版权

分类专栏：运维

本文链接：https://blog.youkuaiyun.com/qq_41830712/article/details/89331325

运维专栏收录该内容

48 篇文章

订阅专栏

本文详细介绍LVS（Linux Virtual Server）的DR模式负载均衡原理与搭建过程，涵盖硬件负载均衡器与软件负载均衡对比，LVS的工作原理，以及如何在多台服务器间实现高效、稳定的流量分配。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

前言：

我们在浏览器输入网址后，经过cdn的反向代理后缓解了一些访问压力，下面就来到了LB（负载均衡）集群！

硬件负载均衡器 HA、F5
软件实现负载均衡（LVS（工作在OSI网络模型的传输层）、Nginx、HAProxy）

硬件负载均衡器一般价格比较昂贵，我们今天主要说一下软件实现负载均衡的LVS软件！

LVS简介与工作原理

LVS是Linux Virtual Server的简写，意即Linux虚拟服务器，是一个虚拟的服务器集群系统。本项目在1998年5月由章文嵩博士成立，是中国国内最早出现的自由软件项目之一。目前有三种IP负载均衡技术（VS/NAT、VS/TUN和VS/DR），十种调度算法 (rrr|wrr|lc|wlc|lblc|lblcr|dh|sh|sed|nq）。

LVS主要用于服务器集群的负载均衡。它工作在网络层，可以实现高性能，高可用的服务器集群技术。它廉价，可把许多低性能的服务器组合在一起形成一个超级服务器。它易用，配置非常简单，且有多种负载均衡的方法。它稳定可靠，即使在集群的服务器中某台服务器无法正常工作，也不影响整体效果。另外可扩展性也非常好。

可以利用LVS技术实现高可伸缩的、高可用的网络服务，例如WWW服务、Cache服务、DNS服务、FTP服务、MAIL服务、视频/音频点播服务等等，有许多比较著名网站和组织都在使用LVS架设的集群系统，例如：Linux的门户网站（www.linux.com）、向RealPlayer提供音频视频服务而闻名的Real公司（www.real.com）、全球最大的开源网站（sourceforge.net）等。

（1）LVS是四层负载均衡，也就是说建立在OSI模型的第四层——传输层之上，传输层上有我们熟悉的TCP/UDP，LVS支持TCP/UDP的负载均衡。因为LVS是四层负载均衡，因此它相对于其它高层负载均衡的解决办法，比如DNS域名轮流解析、应用层负载的调度、客户端的调度等，它的效率是非常高的。

（2）LVS的转发主要通过修改IP地址（NAT模式，分为源地址修改SNAT和目标地址修改DNAT）、修改目标MAC（DR模式）来实现。

①NAT模式：网络地址转换
　NAT（Network Address Translation）是一种外网和内网地址映射的技术。NAT模式下，网络数据报的进出都要经过LVS的处理。LVS需要作为RS（真实服务器）的网关。当包到达LVS时，LVS做目标地址转换（DNAT），将目标IP改为RS的IP。RS接收到包以后，仿佛是客户端直接发给它的一样。RS处理完，返回响应时，源IP是RS IP，目标IP是客户端的IP。这时RS的包通过网关（LVS）中转，LVS会做源地址转换（SNAT），将包的源地址改为VIP，这样，这个包对客户端看起来就仿佛是LVS直接返回给它的。客户端无法感知到后端RS的存在。

②DR模式：直接路由
DR模式下需要LVS和RS集群绑定同一个VIP（RS通过将VIP绑定在loopback实现），但与NAT的不同点在于：请求由LVS接受，由真实提供服务的服务器（RealServer, RS）直接返回给用户，返回的时候不经过LVS。详细来看，一个请求过来时，LVS只需要将网络帧的MAC地址修改为某一台RS的MAC，该包就会被转发到相应的RS处理，注意此时的源IP和目标IP都没变，LVS只是做了一下移花接木。RS收到LVS转发来的包时，链路层发现MAC是自己的，到上面的网络层，发现IP也是自己的，于是这个包被合法地接受，RS感知不到前面有LVS的存在。而当RS返回响应时，只要直接向源IP（即用户的IP）返回即可，不再经过LVS。

（3）DR负载均衡模式数据分发过程中不修改IP地址，只修改mac地址，由于实际处理请求的真实物理IP地址和数据请求目的IP地址一致，所以不需要通过负载均衡服务器进行地址转换，可将响应数据包直接返回给用户浏览器，避免负载均衡服务器网卡带宽成为瓶颈。因此，DR模式具有较好的性能，也是目前大型网站使用最广泛的一种负载均衡手段。

lvs 负载均衡：

vanish：用作前端作反向代理，专业的负载均衡用lvs；
基于软件的负载均衡；（F5和bigip基于硬件的负载均衡）

四种工作模式：
	DR	直接路由模式
	NAT模式
	tun	隧道模式
	LVS-FULLNAT转发模式
	
	lvs附着于netfiler：
	五个内置的钩子函数

数据从外部进来先经过firewall

数据的流向：
	PREROUTING----> INPUT(流向内部)
	PREROUTING----> FORWARD----> POSTROUTING(转发)
	OUTPUT----> POSTROUTING(流向外部)

	lvs工作在INPUT链上：
	PREROUTING----> INPUT（lvs在此强行改变数据流向）----> POSTROUTING

lvs的组成：

##lvs是由两部分组成的：
ipvs（ip virrual server）:一段代码（工作在内核），是真正生效实现调度的代码
ipvsadm：（工作在用户空间）负责为ipvs内核编译规则

附：
lvs（四层）
haproxy（四层）
nginx（七层）
varnish（七层）
前三个是主流。

一、LVS实现负载均衡的DR模式的原理

有关的原理推荐给大家一篇博客：LVS | LVS 负载均衡之工作原理说明（DR模式）

二、lvs—DR模式的搭建

1、server1:

1、yum源的修改（因为一般的配置只能获得基础的包，不能获得ipvsadm）

vim /etc/yum.repos.d/rhel-source.repo

[rhel-source]
name=Red Hat Enterprise Linux $releasever - $basearch - Source
baseurl=http://172.25.75.250/rhel6.5
enabled=1
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release

[LoadBalancer]
name=LoadBalancer
baseurl=http://172.25.75.250/rhel6.5/LoadBalancer
enabled=1
gpgcheck=0
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release

在这里插入图片描述

2、用同样的方法更改server2与server3的yum源

scp /etc/yum.repos.d/rhel-source.repo server2:/etc/yum.repos.d/
scp /etc/yum.repos.d/rhel-source.repo server3:/etc/yum.repos.d/

在这里插入图片描述

3、安装ipvsadm调度器，查看调度规则

yum install ipvsadm -y
ipvsadm -l

在这里插入图片描述

4、查看

lsmod | grep ip_vs

在这里插入图片描述

5、添加外网ip地址（使客户端访问调度器外网）

ip addr add 172.25.75.100/24 dev eth0
ip addr show eth0

在这里插入图片描述

6、编写调度器规则（让客户端在访问172.25.75.100时采用轮循访问server2、server3）

ipvsadm -A -t 172.25.75.100:80 -s rr
ipvsadm -a -t 172.25.75.100:80 -r 172.25.75.2:80 -g
ipvsadm -a -t 172.25.75.100:80 -r 172.25.75.3:80 -g
/etc/init.d/ipvsadm save

在这里插入图片描述

2、server2:

1、安装apache服务，编写默认发布页

yum install httpd -y
vim /var/www/html/index.html
/etc/init.d/httpd start

在这里插入图片描述

2、添加IP

ip addr add 172.25.75.100/32 dev eth0
ip addr show eth0

在这里插入图片描述

3、server3:与server2操作相同

1、安装apache服务，编写默认发布页

yum install httpd -y
vim /var/www/html/index.html
/etc/init.d/httpd start

在这里插入图片描述

2、添加IP

ip addr add 172.25.75.100/32 dev eth0
ip addr show eth0

在这里插入图片描述

4、测试：在客户机（172.25.75.250）

curl 172.25.75.100
arp -an | grep 100		#查看此时mac地址是server1、2、3谁的
arp -d 172.25.8.100		#清除一次
curl 172.25.75.100

调度器server1的eth0网卡的mac地址： 52:54:00:6b?82
服务器server2的mac地址： 52:54:00:ed:5b:6d
服务器server3的mac地址： 52:54:00:8b:ca:1c

在这里插入图片描述
分析： 由图知第一次缓存的mac地址为服务器server2的，故访问到的内容为server2httpd的内容。清理了一次mac缓存后，重新访问缓存到的是调度器的mac地址，故可以成功轮循。
注意： 此时的客户端进行访问的时候，会随机选取，后端谁抢到就是谁的，（因为arpip广播）

5、解决步骤

server2：

1、在server2上安装arptables火墙策略，查看火墙策略

yum search arptables
yum install arptables_jf.x86_64 -y
arptables -L

在这里插入图片描述

2、编写arptables火墙策略

arptables -A IN -d 172.25.75.100 -j DROP	#将此IP的请求都丢弃了
arptables -A OUT -s 172.25.75.100 -j mangle --mangle-ip-s 172.25.75.2	#让访问172.25.75.2的IP出去的都是172.25.75.100
arptables -L		#查看arptables的火墙策略
/etc/init.d/arptables_jf save	#保存当前火墙策略

在这里插入图片描述

server3：

1、在server3上安装arptables火墙策略，查看火墙策略

yum search arptables
yum install arptables_jf.x86_64 -y
arptables -L

在这里插入图片描述

2、编写arptables火墙策略

arptables -A IN -d 172.25.75.100 -j DROP	#将此IP的请求都丢弃了
arptables -A OUT -s 172.25.75.100 -j mangle --mangle-ip-s 172.25.75.3	#让访问172.25.75.3的IP出去的都是172.25.75.100
arptables -L		#查看arptables的火墙策略
/etc/init.d/arptables_jf save	#保存当前火墙策略

在这里插入图片描述

测试：

arp -d 172.25.75.100
arp -an | grep 100
curl 172.25.75.100
arp -d 172.25.75.100
arp -an | grep 100
curl 172.25.75.100

在这里插入图片描述
分析： 访问：会发现实现调度器，不会出现随机情况