LVS的详情讲解

1.何为LVS

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

运行原理图:

.LVS的优点

高性能:LVS具有很高的吞吐量,可以处理大量的并发连接,非常适合高访问量的网站或应用。

可扩展性:LVS可以轻松扩展后端服务器的数量,以满足不断增长的业务需求。

可靠性:LVS支持多种负载均衡算法,包括轮询(RR)、最少连接(LC)、源地址哈希(SH)等,可以根据实际情况选择最合适的算法。同时,LVS还支持健康检查功能,能够自动将故障服务器从负载均衡池中剔除,保证服务的持续性和可靠性。

 低成本:LVS是开源软件,可以免费使用,并且可以在大多数Linux发行版上运行,降低了部署和运维的成本。

三.集群和分布式简介

3.1.系统性能扩展方式

Scale UP:向上扩展,增强
Scale Out:向外扩展,增加设备,调度分配问题,Cluster

3.2.集群Cluster

Cluster: 集群是为了解决某个特定问题将堕胎计算机组合起来形成的单个系统
Cluster常见的三种类型:
LBLoadBalancing(负载均衡)由多个主机组成,每个主机只承担一部分访问
HAHigh Availiablity(高可用)SPOFsingle Point Of failure
MTBF:Mean Time Between Failure 平均无故障时间,正常时间
MTTR:Mean Time To Restoration repair)平均恢复前时间,故障时间
A=MTBF/MTBF+MTTR (0,1)99%, 99.5%, 99.9%, 99.99%, 99.999%
SLAService level agreement(服务等级协议)是在一定开销下为保障服务的性能和可用性,服
务提供商与用户间定义的一种双方认可的协定。通常这个开销是驱动提供服务质量的主要因素。在
常规的领域中,总是设定所谓的三个9,四个9来进行表示,当没有达到这种水平的时候,就会有一
些列的惩罚措施,而运维,最主要的目标就是达成这种服务水平。
停机时间又分为两种,一种是计划内停机时间,一种是计划外停机时间,而运维则主要关注计划外
停机时间
HPCHigh-performance computing(高性能计算,国家战略资源,不在课程范围内)

3.3.分布式

分布式存储:CephGlusterFsFastDFSMogileFs
分布式计算:hadoopSpark
分布式常见应用
分布式应用-服务按照功能拆分,使用微服务
分布式静态资源--静态资源放在不同的存储集群上分布式数据和存储--使用key-value缓存系统
分布式计算--对特殊业务使用分布式计算,比如Hadoop集群

3.4.集群和分布式

集群:同一个业务系统,部署在多台服务器上,集群中,每一台服务器实现的功能没有差别,数据
和代码都是一样的
分布式:一个业务被拆成多个子业务,或者本身就是不同的业务,部署在多台服务器上。分布式
中,每一台服务器实现的功能是有差别的,数据和代码也是不一样的,分布式每台服务器功能加起
来,才是完整的业务
分布式是以缩短单个任务的执行时间来提升效率的,而集群则是通过提高单位时间内执行的任务数
来提升效率 ,
对于大型网站,访问用户很多,实现一个群集,在前面部署一个负载均衡服务器,后面几台服务器
完成同一业务。如果有用户进行相应业务访问时,负载均衡器根据后端哪台服务器的负载情况,决
定由给哪一台去完成响应,并且台服务器垮了,其它的服务器可以顶上来。分布式的每一个节点,
都完成不同的业务,如果一个节点垮了,那这个业务可能就会失败

4.LVS三种模式

4.1概念

VSVirtual Server
RSReal Server
CIPClient IP
VIP: Virtual serve IP VS外网的IP
DIP: Director IP VS内网的IP
RIP: Real server IP
访问流程:CIP <--> VIP == DIP <--> RIP

4.2集群类型

lvs-nat
修改请求报文的目标IP,多目标IPDNAT
lvs-dr 操纵封装新的MAC地址
lvs-tun
在原请求IP报文之外新加一个IP首部
lvs-fullnat 修改请求报文的源和目标IP

4.3三种模式

4.3.1 nat模式

Ivs-nat:
本质是多目标IPDNAT,通过将请求报文中的目标地址和目标端口修改为某挑出的RSRIP
PORT实现转发
RIPDIP应在同一个IP网络,且应使用私网地址;RS的网关要指向DIP
请求报文和响应报文都必须经由Director转发,Director易于成为系统瓶颈
支持端口映射,可修改请求报文的目标PORT
VS必须是Linux系统,RS可以是任意OS系统
逻辑图:

1.客户端发送访问请求,请求数据包中含有请求来源(cip),访问目标地址(VIP)访问目标端口
9000port
2.VS服务器接收到访问请求做DNAT把请求数据包中的目的地由VIP换成RSRIP和相应端口
3.RS1相应请求,发送响应数据包,包中的相应保温为数据来源(RIP1)响应目标(CIP)相应端口
9000port
4.VS服务器接收到响应数据包,改变包中的数据来源(RIP1-->VIP,响应目标端口(9000-->80
5.VS服务器把修改过报文的响应数据包回传给客户端
6.lvsNAT模式接收和返回客户端数据包时都要经过lvs的调度机,所以lvs的调度机容易阻塞

 

nat模式特点:

  1. 负载均衡器与真实服务器之间的网络连接:‌在LVS/NAT模式下,‌负载均衡器(‌Director Server)‌与真实服务器(‌Real Server)‌通过Switch/HUB相连接,‌提供相同的网络服务。‌这种连接方式使得负载均衡器能够根据调度算法将客户端的请求转发给真实服务器1。‌

  2.  

    请求和响应的处理:‌当计算机发出请求的数据包到达负载均衡器后,‌负载均衡器会对请求数据包进行源地址转换(‌SNAT)‌和目标地址转换(‌DNAT)‌。‌通过这些转换,‌请求被转发到某个真实服务器的IP地址和端口号,‌同时使用真实服务器的MAC地址。‌真实服务器收到请求后,‌返回响应的数据包,‌负载均衡器再次进行源地址转换和目标地址转换,‌将响应数据包返回给客户端。‌这种处理方式使得客户端认为其直接与负载均衡器进行通信,‌而实际上请求和响应都是在负载均衡器和真实服务器之间进行的2。‌

  3.  

    会话共享:‌为了实现会话共享,‌真实服务器需要将会话数据存储在共享存储服务器上,‌通常使用NFS(‌Network File System)‌来实现。‌这种共享存储机制确保了即使多个真实服务器处理同一个会话请求,‌也能保持会话信息的一致性,‌从而提供一致的服务体验3。‌

      综上所述,‌LVS/NAT模式通过负载均衡器和真实服务器之间的网络连接、‌请求和响应的处理机制以及共享存储的实现,‌提供了一种高性能、‌高可用的负载均衡解决方案

4.3.2 DR模式

LVS的DR模式是一种负载均衡模式,‌其中DR代表直接路由(‌Direct Routing)‌。‌在这种模式下,‌负载均衡器将请求发送到客户端,‌而真实的服务器将响应直接发送给客户端,‌避免了负载均衡器成为单点故障。‌DR模式利用了ARP抑制技术,‌确保真实服务器的MAC地址被注册到ARP表中,‌而负载均衡器的MAC地址则不被注册或者被设置为不存在的值,‌从而避免了数据包被发送到负载均衡器。‌这种模式适用于需要高可用性和可扩展性的应用场景,‌因为它可以有效地分散负载并提高系统的整体性能和可靠性。‌

在配置LVS的DR模式时,‌需要遵循一系列步骤来确保负载均衡和故障转移的机制能够正确运作。‌这包括配置负载均衡器、‌设置虚拟IP地址(‌VIP)‌、‌配置网络参数以确保数据包能够正确地路由到真实服务器,‌以及设置适当的负载均衡算法和故障检测机制。‌此外,‌还需要确保网络中的路由器和交换机配置正确,‌以便数据包能够直接从客户端发送到真实服务器,‌而不需要经过负载均衡器。‌

LVS的DR模式特别适用于需要高性能、‌高可用性和可扩展性的场景,‌如企业级应用、‌大型网站等。‌通过这种模式,‌可以显著提高系统的整体性能和可靠性,‌同时降低单点故障的风险。‌在实际应用中,‌需要根据具体的网络环境和需求来精细调整配置,‌以确保负载均衡和故障转移机制能够有效地工作

逻辑及数据传输图:

特点:

LVS的DR模式具有以下特点:‌

  1.  

    请求和响应分离:‌在DR模式下,‌负载均衡器(‌Director Server)‌负责接收客户端的请求,‌并根据调度算法将请求分发到后端真实服务器(‌Real Server)‌。‌真实服务器处理完请求后,‌直接将响应发送回客户端,‌无需经过负载均衡器。‌这种机制减少了负载均衡器的大量数据流动,‌使得负载均衡器不再是系统的瓶颈,‌能够处理巨大的请求量。‌

  2.  

    网络要求:‌DR模式要求负载均衡器和真实服务器必须在同一个物理网络中,‌且真实服务器的网关不允许指向负载均衡器的IP地址,‌即数据包不能经过负载均衡器。‌这是为了确保响应报文能够直接从真实服务器发送回客户端,‌而不经过负载均衡器。‌

  3.  

    地址配置:‌真实服务器需要在其通道接口上配置虚拟IP地址(‌VIP)‌,‌以便接收来自负载均衡器转发过来的数据包,‌并以此作为响应报文的源IP地址。‌这种配置方式支持真实服务器的IP地址为公网地址或私有地址,‌如果使用公网地址,‌可以通过互联网直接访问。‌

  4.  

    不支持端口映射:‌DR模式不支持端口映射功能,‌这意味着如果需要端口映射,‌则不能使用DR模式。‌

  5.  

    隧道功能要求:‌真实服务器的操作系统需要支持隧道功能,‌这是因为DR模式下,‌请求报文虽然经过负载均衡器,‌但响应报文直接从真实服务器发送回客户端,‌这要求真实服务器能够正确处理隧道内的IP报文。‌

  6.  

    ARP问题:‌在配置DR模式时,‌需要注意ARP问题,‌确保ARP缓存的一致性,‌避免因为ARP问题导致的通信故障。‌

  7. 综上所述,‌LVS的DR模式通过优化数据流动和配置要求,‌实现了高效的数据处理和传输,‌特别适合需要高并发连接和低延迟的应用场景

4.3.3 tun模式(了解,不常用)

LVS的TUN模式是一种负载均衡技术,‌其特点在于不改变请求数据包,‌而是在请求数据包上新增一层IP首部信息。‌这种模式允许负载均衡器与真实服务器不在同一局域网内,‌并且真实服务器需要支持能够解析两层IP首部信息,‌即需要支持“IP Tunneling”或“IP Encapsulation”协议。‌在TUN模式下,‌负载均衡器只转发了请求数据包,‌响应数据包不经过负载均衡器,‌而是直接返回给客户端。‌

在配置LVS的TUN模式时,‌需要在负载均衡器上配置虚拟服务器,‌包括虚拟IP和轮询方式。‌真实服务器上需要配置虚拟接口(‌tunl0)‌,‌并且需要配置内核参数如rp_filter和arp_filter来控制ARP响应。‌此外,‌还需要确保真实服务器上的VIP只能被自己“看见”,‌其他设备不可知,‌因此VIP必须绑定在真实服务器的lo网卡上,‌并且不允许将此网卡信息经过ARP协议对外通告。‌

TUN模式的优势在于负载均衡器与真实服务器可以不在同一局域网内,‌提供了更大的灵活性。‌然而,‌这种模式对网络设备和配置有一定的要求,‌包括对IP Tunneling或IP Encapsulation协议的支持,‌以及正确的内核参数配置。‌通过正确的配置和使用,‌TUN模式可以实现高效的负载均衡和容错,‌提高系统的可用性和性能

逻辑图:

特点:

  • 负载均衡器只负责将请求包分发给后端节点服务器,‌而RS将应答包直接发给用户,‌减少了负载均衡器的大量数据流动。‌
  • 这种模式允许负载均衡器处理巨大的请求量,‌使得一台负载均衡器能够为多个RS进行分发。‌
  • LVS-TUN模式支持不同地域的分发,‌即使跑在公网上也能进行有效率的负载均衡。‌

然而,‌LVS-TUN模式也存在一些缺点:‌

  • RS节点需要合法IP,‌且所有服务器必须支持"IP Tunneling"(‌IP Encapsulation)‌协议,‌这可能限制了服务器的使用范围。‌
  • 这种方式可能需要特定的操作系统配置和内核支持,‌可能只在部分Linux系统上可用。‌

总结来说,‌LVS-TUN模式通过减少负载均衡器的数据流动和处理量,‌提高了系统的整体性能和可扩展性,‌但同时也对服务器和网络配置有一定的要求

5.LVS的调度算法

5.1.lvs 调度算法类型
ipvs scheduler :根据其调度时是否考虑各 RS 当前的负载状态被分为两种:静态方法和动态方法
静态方法:仅根据算法本身进行调度,不考虑 RS 的负载情况
动态方法:主要根据每 RS 当前的负载状态及调度算法进行调度 Overhead=value 较小的 RS 将被调度
5.2.lvs 静态调度算法
1 RR roundrobin 轮询 RS 分别被调度,当 RS 配置有差别时不推荐
2 WRR Weighted RR ,加权轮询根据 RS 的配置进行加权调度,性能差的 RS 被调度的次数少
3 SH Source Hashing ,实现 session sticky ,源 IP 地址 hash ;将来自于同一个 IP 地址的请求始终发往
第一次挑中的 RS ,从而实现会话绑定
4 DH Destination Hashing ;目标地址哈希,第一次轮询调度至 RS ,后续将发往同一个目标地址的请
求始终转发至第一次挑中的 RS ,典型使用场景是正向代理缓存场景中的负载均衡,如:宽带运营商
5.2.lvs 动态调度算法
主要根据 RS 当前的负载状态及调度算法进行调度 Overhead=value 较小的 RS 会被调度
1 LC least connections (最少链接发)
适用于长连接应用 Overhead (负载值) =activeconns (活动链接数) x 256+inactiveconns (非活
动链接数)
2 WLC Weighted LC (权重最少链接)
默认调度方法 Overhead=(activeconns x 256+inactiveconns)/weight
3 SED Shortest Expection Delay,
初始连接高权重优先 Overhead=(activeconns+1+inactiveconns) x 256/weight
但是,当 node1 的权重为 1 node2 的权重为 10 ,经过运算前几次的调度都会被 node2 承接
4 NQ Never Queue ,第一轮均匀分配,后续 SED
5 LBLC Locality-Based LC ,动态的 DH 算法,使用场景:根据负载状态实现正向代理
6 LBLCR LBLC with Replication ,带复制功能的 LBLC ,解决 LBLC 负载不均衡问题,从负载重的复制 到负载轻的RS

6.IPVSADM命令

1.管理集群服务中的增删改
ipvsadm -A|E -t|u|f service-address [-s scheduler] [-p [timeout]]
-A  # 添加
-E  # 修改
-t
#tcp 服务
-u #udp 服务
-s # 指定调度算法,默认为 WLC
-p # 设置持久连接超时,持久连接可以理解为在同一个时间段同一个来源的请求调度到同一 Realserver
-f #firewall mask 火墙标记,是一个数字
2.管理集群中RealServer的增删改
ipvsadm -a|e -t|u|f service-address -r realserver-address [-g|i|m] [-w weight]
ipvsadm -Z [-t|u|f service-address] 清楚计数器
# 增加
[root@DR-server ~]# ipvsadm -A -t 172.25.250.130:80 -s rr
[root@DR-server ~]# ipvsadm -A -f 66 -p 3000
# 修改
[root@DR-server ~]# ipvsadm -E -t 172.25.250.130:80 -s wrr -p 3000
# 删除
[root@DR-server ~]# ipvsadm -D -t 172.25.250.130:80
[root@DR-server ~]# ipvsadm -D -f 66
-a # 添加 realserver
-e # 更改 realserver
-t #tcp 协议
-u #udp 协议
-f # 火墙 标签
-r #realserver 地址
-g # 直连路由模式
-i #ipip 隧道模式
-m #nat 模式
-w # 设定权重
-Z # 清空计数器
-C # 清空 lvs 策略
-L # 查看 lvs 策略
-n # 不做解析
--rate :输出速率信息
#添加
[root@DR-server ~]# ipvsadm -a -t 172.25.250.130:80 -r 192.168.186.10 -m
[root@DR-server ~]# ipvsadm -a -t 172.25.250.130:80 -r 192.168.186.20 -m -w 2
# 更改
[root@DR-server ~]# ipvsadm -e -t 172.25.250.130:80 -r 192.168.186.10 -m -w 1
[root@DR-server ~]# ipvsadm -e -t 172.25.250.130:80 -r 192.168.186.20 -i -w 1
# 删除
[root@DR-server ~]# ipvsadm -d -t 172.25.250.130:80 -r 192.168.186.20
[root@DR-server ~]# ipvsadm -Ln
[root@DR-server ~]# ipvsadm -Ln --rate
IP Virtual Server version 1.2.1 (size=5113)
Prot LocalAddress:Port CPS InPPS OutPPS InBPS OutBPS
-> RemoteAddress:Port
TCP 172.25.250.130:80 0 0 0 0 0
-> 192.168.186.10:80 0 0 0 0 0
-> 192.168.186.20:80 0 0 0 0 0
[root@DR-server ~]# ipvsadm -C
[root@DR-server ~]# ipvsadm -Z -t 172.25.250.20:80
[root@DR-server ~]# ipvsadm -Ln --rate
IP Virtual Server version 1.2.1 (size=5113)
Prot LocalAddress:Port CPS InPPS OutPPS InBPS OutBPS
-> RemoteAddress:Port
TCP 172.25.250.130:80 0 0 0 0 0
-> 192.168.186.10:80 0 0 0 0 0
-> 192.168.186.20:80 0 0 0 0 0

7.LVS实战案例

DR模式较复杂所以DR实战会做就会nat模式,所以我们部署一下DR模式实验

部署DR模式:

1.配置实验环境

1.1每台主机都关闭防火墙和SELINUX

systemctl stop firewalld

setenforce 0

每台主机配置IP配置如下

lvs:

web1:

web2:

client:

router:

配置好网卡IP和网关IP,然后重启网卡

nmcli connection reload

nmcli connection up eth0

 二、解决vip响应问题

DR模型中各主机上均需要配置VIP,解决地址冲突的方式有三种:

(1)在前端网关做静态绑定

(2)在各RS使用arptables

(3)在各RS修改内核参数,来限制arp响应和通告的级别

限制响应级别:arp_ignore

0:默认值,表示可使用本地任意接口上配置的任意地址进行响应
1:仅在请求的目标IP配置在本地主机的接收到请求报文的接口上时,才给予响应
限制通告级别:arp_announce

0:默认值,把本机所有接口的所有信息向每个接口的网络进行通告
1:尽量避免将接口信息向非直接连接网络进行通告 2:必须避免将接口信息向非本网络进行通告
webserver1:

[root@webserver1 ~]# echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore

[root@webserver1 ~]# echo 1 > /proc/sys/net/ipv4/conf/lo/arp_ignore

[root@webserver1 ~]# echo 2 > /proc/sys/net/ipv4/conf/lo/arp_announce

[root@webserver1 ~]# echo 2 > /proc/sys/net/ipv4/conf/all/arp_announce

webserver2进行相同配置

LVS:

[root@lvs ~]# ipvsadm -A -t 192.168.186.200:80 -s wrr

[root@lvs ~]# ipvsadm -a -t 192.168.186.200:80 -r 192.168.186.10:80 -g -w 1

[root@lvs ~]# ipvsadm -a -t 192.168.186.200:80 -r 192.168.186.20:80 -g -w 2
               

 路由器启用IP转发功能

net.ipv4.ip_forward = 1启用IP转发功能,当设置为 1 时,表示允许系统在不同的网络接口之间转发 IP 数据包。

net.ipv4.ip_forward_update_priority = 1这个配置项用于设置 IP 转发更新的优先级。当系统进行 IP 转发相关的更新操作时,这个优先级值会影响更新的顺序和处理方式。

net.ipv4.ip_forward_use_pmtu = 0这个配置项控制着在 IP 转发过程中是否使用路径最大传输单元(PMTU)发现机制。当设置为 0 时,表示在 IP 转发中不使用 PMTU 发现。

[root@route ~]# sysctl -a | grep ip_forward
net.ipv4.ip_forward = 1       
net.ipv4.ip_forward_update_priority = 1        
net.ipv4.ip_forward_use_pmtu = 0


在 /etc/sysctl.conf配置文件中添加net.ipv4.ip_forward = 1

测试

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值