LVS知识点总结

一、集群（Cluster）的概念

集群（Cluster）：是为了解决某个特定问题将多台计算机组合起来形成的单个系统

二、集群的分类

LB：LoadBalancing(负载均衡)由多个主机组成，每个主机只承担一部分访问

核心：分发用户请求，分摊压力，提升并发

代表：LVS、Nginx、HAProxy

场景：Web网站、接口服务、网关

特点：多节点对外统一入口，节点对等，故障自动剔除

HA：High Availability（高可用）

核心：防止单点故障，服务永不中断

模式：主备，双主，多主

代表：Keepalived、Redis主从、MySQL双主

场景：数据库、核心中间件、网关

指标：故障转移切换时间，通常秒级

HPC：High Performance Computing(高性能计算)

核心：并行海量计算，提升运算速度

代表：Slurm、MPI

场景：大数据建模，气象模拟，AI训练，仿真计算

特点：节点协同拆分大任务，侧重算力

分布式存储：

核心：海量数据分布式存放，扩容+多副本放丢失

代表：Ceph、GlusterFS、HDFS

场景:文件存储、对象存储、大数据离线存储

集群和分布式存储的区别

**集群：**同一个业务系统部署在多台服务器上，在集群中，每一台服务器实现的功能没有差别，数据和代码都是一样的

**分布式：**一个业务被拆成多个子业务，或者本身就是不同的业务，部署在多台服务器上。分布式中，每一台服务器实现的功能是有差别的，数据和代码也是不一样的，分布式每台服务器功能加起来才是完整的业务

三、lvs的作用

LVS（linux virtual server),Linux虚拟服务器，负载调度器，四层负载均衡，工作在内核态，基于IP+端口转发请求

核心作用：

1.流量负载分发

将大量客户端请求均衡转发到后端多台真实服务器上，分摊业务压力，提升并发承载能力

2.实现服务集群统一入口

对外只暴露一个虚拟VIP，用户只访问VIP，感知不到后端多台服务器

3.后端节点健康检测

自动检测真实服务器状态，故障节点自动剔除，不再分发流量，保证业务可用

4.高可用配合

可以搭配Keepalived实现LVS自身主备，消除负载均衡器单点故障

5.高性能四层转发

工作在内核，不处理应用层数据，转发速度远高于nginx（七层），适合大流量，高并发的场景

四、lvs的4种模式及原理

• nat模式

  

  用户请求：客户端IP-->LVS VIP

  LVS修改目标IP为后端真实主机的RS IP，转发给真实的服务器

  RS返回数据包，源IP为内网RS IP，目标IP为LVS内网IP

  LVS修改源IP为VIP，回包给客户端

  **优缺点：**简单易部署，并发上限低，适合小规模集群

• DR模式

  

  客户端请求：客户端IP+客户端MAC、VIP+VIP MAC

  LVS-->RS:客户端IP+客户端MAC、VIP+RS MAC

  RS本机配置VIP回环网卡lo0,接收目标VIP数据包

  RS响应（绕过LVS，直接给客户端）：VIP+RS MAC、客户端IP+客户端MAC

  **关键点：**入流量走LVS，出流量不走LVS，性能极强

  LVS和RS必须同一网段

  RS绑定VIP在lo环回，抑制ARP广播

  **优缺点：**性能最大，大流量首选；同网段限制，配置ARP参数

• TUN模式

  

  客户端发送请求包：CIP-->VIP

  LVS在原有的IP包外层再加一层新的IP头，源IP是DIP，目标RS公网IP,将报文发送给目标RS

  RS拆隧道外层包头，读取原始请求包

  RS直接回给客户端，不经过LVS（源IP是VIP,目标IP是CIP）

  特点：

  DIP, VIP, RIP都应该是公网地址

  RS的网关一般不能指向DIP

  请求报文要经由Director（LVS），但响应不能经由Director

  不支持端口映射

  RS的OS（操作系统）须支持隧道功能

• fullnet模式

客户端 CIP→VIP：LVS 改目标 IP 为 RS 内网 IP，改源 IP 为 LVS 本地内网 IP

RS 回包：源 RS 内网 IP，目标 LVS 内网 IP

LVS 再转换源 VIP、目标 CIP 返回用户

五、lvs的13种算法

LVS调度算法类型

根据其调度时是否考虑各 RS当前的负载状态被分为两种 ：静态方法和动态方法

静态方法：仅根据算法本身进行调度，不考虑RS的负载情况

动态方法：主要根据每RS当前的负载状态及调度算法进行调度，Overhead=value较小的RS将被调度

静态调度算法：

1. RR 轮询（Round Robin）

轮流分发请求，一台接一个，循环分配。 适用：所有后端服务器硬件性能完全一致场景。

2. WRR 加权轮询（Weight Round Robin）

给 RS 设置权重，权重越高分到的请求越多。 例：A 权重 3、B 权重 1，则顺序 A A A B 循环。 适用：后端机器配置性能不一致。

3. DH 目标地址哈希（Destination Hashing）

根据**客户端访问的目标 IP（VIP）**做哈希计算，同一目标 IP 固定转发到同一 RS。 场景：多 VIP 业务、会话保持、缓存业务。

4. SH 源地址哈希（Source Hashing）

根据客户端源 IP哈希，同一个用户 IP 永远调度到同一台后端 RS。 作用：简单会话保持，无需额外会话存储。

动态调度算法：

主要根据RS当前的负载状态及调度算法进行调度Overhead=value较小的RS会被调度

1. LC 最小连接（Least Connections）

适用于长连接应用Overhead（负载值）=activeconns（活动链接数） x 256+inactiveconns（非活

动链接数）

逻辑：新请求分给当前活跃连接最少的服务器。 缺陷：不区分服务器性能，高配低配同等权重，不公平。

2. WLC 加权最小连接（Weighted Least Connections）

生产最常用。 公式：Overhead=(activeconns x 256+inactiveconns)/weight，比值越小越优先分配。 兼顾连接数与服务器硬件权重，适配配置参差不齐集群。

3. SED 最短预期延迟（Shortest Expected Delay）

改进 WLC，公式：Overhead=(activeconns+1+inactiveconns) x 256/weight。 避免空闲权重高的机器一直等待，新请求优先给到空闲高性能节点。

4. NQ 永不排队（Never Queue）

SED 升级版。 如果存在 RS 活跃连接 = 0，直接分配给空节点；无空闲节点再走 SED 算法。

5.LBLC基于局部性最少连接(Locality-Based Least Connections)

动态的DH算法，使用场景：根据负载状态实现正向代理

根据请求目标 IP查询映射表，找到上次处理该 IP 的 RS；

如果该 RS 正常、负载不超载，直接转发（保证缓存命中）；

如果该机器宕机 / 连接过载，则按LC 最小连接规则，挑负载最轻的 RS，并更新映射记录。

6.LBLCR带复制的基于局部性最少连接（Locality-Based Least Connections with Replication）

解决LBLC负载不均衡问题，从负载重的复制到负载轻的RS

核心区别（对比 LBLC）

LBLC：一个目标 IP 只绑定单台 RS； LBLCR：一个目标 IP 绑定一组 RS，组内按最小连接调度，热点数据自动多机复制缓存。

六、lvs的多端口轮询问题解决方案

以http和https为例，当我们在RS中同时开放80和443端口，那么默认控制是分开轮询的，这样我们就出现了一个轮询错乱的问题

当我第一次访问80被轮询到RS1后下次访问443仍然可能会被轮询到RS1上

问题呈现

在RS1和RS2中安装mod_ssl并重启apache
yum install mod_ssl -y
systemctl restart httpd
#在lvs中设置调度，因为我们要调度80和443两个端口所以我们需要设定两组策略
ipvsadm -C

[root@lvs ~]# ipvsadm -A -t 192.168.0.100:80 -s rr
[root@lvs ~]# ipvsadm -A -t 192.168.0.100:443 -s rr
[root@lvs ~]# ipvsadm -a -t 192.168.0.100:80 -r 192.168.0.101:80 -g
[root@lvs ~]# ipvsadm -a -t 192.168.0.100:80 -r 192.168.0.102:80 -g
[root@lvs ~]# ipvsadm -a -t 192.168.0.100:443 -r 192.168.0.102:80 -g
[root@lvs ~]# ipvsadm -a -t 192.168.0.100:443 -r 192.168.0.101:80 -g
[root@lvs ~]# 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.0.100:80 rr
-> 192.168.0.101:80 Route 1 0 0
-> 192.168.0.102:80 Route 1 0 0
TCP 192.168.0.100:443 rr
-> 192.168.0.101:443 Route 1 0 0
-> 192.168.0.102:443 Route 1 0 0
测试问题
[root@node10 ~]# curl http://192.168.0.100;curl -k https://192.168.0.100
RS1 server - 192.168.0.101
RS1 server - 192.168.0.101
当访问vip时两次调度都到了101

使用防火墙标记解决轮询调度问题

原理

用iptables mangle给多个端口数据包打统一标记 ，LVS 基于标记（-f mark）创建单一虚拟服务，所有端口共用同一套调度、会话保持规则。 同一客户端 80/443 请求统一调度同一 RS，彻底解决多端口分离轮询问题。

示例：

#在vs调度器中设定端口标签，人为80和443是一个整体
[root@lvs ~]# iptables -t mangle -A PREROUTING -d 192.168.0.100 -p tcp -m multiport --dports 80,443 -j MARK --set-mark 6666

#设定调度规则
[root@lvs ~]# ipvsadm -A -f 6666 -s rr
[root@lvs ~]# ipvsadm -a -f 6666 -r 192.168.0.101 -g
[root@lvs ~]# ipvsadm -a -f 6666 -r 192.168.0.102 -g

#测试
[root@node10 ~]# curl -k https://192.168.0.100
RS2 server - 192.168.0.102
[root@node10 ~]# curl -k https://192.168.0.100;curl 192.168.0.100
RS1 server - 192.168.0.10
RS2 server - 192.168.0.20

七、lvs的会话粘滞解决方案

在我们客户上网过程中有很多情况下需要和服务器进行交互，客户需要提交响应信息给服务器，如果单纯的进行调度会导致客户填写的表单丢失，为了解决这个问题我们可以用sh算法，但是sh算法比较简单粗暴，可能会导致调度失衡

解决方案

在进行调度时，不管用什么算法，只要相同源过来的数据包我们就把他的访问记录在内存中，也就是把这个源的主机调度到了那个RS上

如果在短期（默认360S）内同源再来访问我仍然按照内存中记录的调度信息，把这个源的访问还调度到同一台RS上。

如果过了比较长的时间（默认最长时间360s）同源访问再次来访，那么就会被调度到其他的RS上

#语法
ipvsadm -AlE -tlulf service-address [-s scheduler] [-p [timeout]]默认360秒

#在lvs调度器中设定
[root@lvs ~]# ipvsadm -E -f 6666 -s rr -p [3000]
[root@lvs ~]# ipvsadm -LnC