LVS（Linux virual server）

什么是集群

**集群（Cluster）** 指将多台独立的计算设备（服务器、计算机等）通过网络连接，协同工作形成一个统一整体，对外提供比单台设备更强大的计算能力、存储能力或高可用性的技术架构。简单来说，就是"多台机器一起干活"，目标是解决单机性能不足、单点故障等问题。

集群的特点

高性能：通过多机并行处理任务（比如分布式计算），突破单机算力上限。
高可用：某台机器故障时，其他机器自动接管任务，避免服务中断（无单点故障）。
可扩展：需要更强能力时，直接加机器即可（横向扩展），无需替换单机硬件。

集群分类

负载均衡集群：将用户请求分摊到多台机器（如Nginx集群），避免单机过载，提升响应速度（典型场景：网站高并发访问）。
高可用集群（HA集群）：重点保障服务不中断，比如数据库主从集群，主节点挂了从节点立刻顶上（典型：MySQL MHA、Redis哨兵）。
高性能计算集群（HPC）：用于科学计算、大数据处理等需要海量算力的场景（如气象模拟、基因测序），通过并行计算加速任务（典型：Hadoop、Spark集群）。

lvs的作用

LVS:Linux Virtual Server，负载调度器，内核集成，章文嵩，阿里的四层SLB(Server LoadBalance)是基于LVS+keepalived实现。

核心作用是：把大量客户端请求按规则分发到后端多台真实服务器（Real Server），让多台机器像"一台超级服务器"一样对外提供服务。

LVS概念

VS：Virtual Server（调度器）

RS：Real Server （真实业务主机）

CIP：Client IP （客户端主机的ip）

VIP: Virtual serve IP VS外网的IP （对外开放的让客户访问的ip）

DIP: Director IP VS内网的IP （调度器负责访问内网的ip）

RIP: Real server IP （真实业务主机IP）

访问流程：CIP VIP == DIP RIP

lvs的4种模式及原理

lvs-nat：修改请求报文的目标IP,多目标IP的DNAT

lvs-dr：操纵封装新的MAC地址

lvs-tun：在原请求IP报文之外新加一个IP首部

lvs-fullnat：修改请求报文的源和目标IP

NAT 模式

原理

客户端访问VIP
LVS 收到包，改写目标 IP（VIP → RIP），转发给某台 RS
RS 处理完，回包给 LVS（因为 RS 网关指向 DIP）
LVS 再把回包的源 IP 改回 VIP，发给客户端

DR 模式

原理

客户端访问VIP
LVS 不改 IP，只改 MAC 地址（目标 MAC → RS 的 MAC）
包送到 RS，RS 发现目标 IP 是 VIP（本机 lo 上配了 VIP 子接口），正常处理
RS 直接把响应包以 VIP 为源 IP 发给客户端（不经过 LVS）

TUN 模式

原理

LVS 收到 CIP→VIP 的包
LVS 在原 IP 包外再套一层 IP 头：DIP→VIP
RS 收到后解隧道，拿到原始 CIP→VIP 包，处理
RS 直接用 VIP 作源 IP 回包给 CIP（走公网/独立网络）

FullNAT 模式

原理

请求进来：LVS 同时改目标 IP（VIP→RIP）和源 IP（CIP→DIP）
RS 看到的是 DIP→RIP，回包给 DIP
LVS 再反改：源 IP 改回 VIP，目标 IP 改回 CIP

lvs的13种算法

静态调度算法

RR：roundrobin 轮询 RS分别被调度，当RS配置有差别时不推荐
WRR：Weighted RR，加权轮询根据RS的配置进行加权调度，性能差的RS被调度的次数少
SH：Source Hashing，实现session sticky，源IP地址hash；将来自于同一个IP地址的请求始终发往第一次挑中的RS，从而实现会话绑定
DH：Destination Hashing；目标地址哈希，第一次轮询调度至RS，后续将发往同一个目标地址的请求始终转发至第一次挑中的RS，典型使用场景是正向代理缓存场景中的负载均衡，如：宽带运营商
MH：Maglev Hashing；磁悬浮哈希，基于一致性哈希思想为每个 RS 生成固定长度的排列表并合成全局查找表，首次按 CIP 哈希结果选定 RS 后，后续来自同一源 IP 的请求始终转发至该 RS。

动态调度算法

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

LC：least connections（最少链接发）适用于长连接应用Overhead（负载值）=activeconns（活动链接数） x 256+inactiveconns（非活动链接数）
WLC：Weighted LC（权重最少链接）默认调度方法Overhead=(activeconns x 256+inactiveconns)/weight
SED：Shortest Expection Delay, 初始连接高权重优先Overhead=(activeconns+1+inactiveconns) x 256/weight 但是，当node1的权重为1，node2的权重为10，经过运算前几次的调度都会被node2承接
NQ：Never Queue，第一轮均匀分配，后续SED
LBLC：Locality-Based LC，动态的DH算法，使用场景：根据负载状态实现正向代理
LBLCR：LBLC with Replication，带复制功能的LBLC，解决LBLC负载不均衡问题，从负载重的复制到负载轻的RS
FO(Weighted Fai Over)调度算法：常用作灰度发布在此FO算法中，遍历虚拟服务所关联的真实服务器链表，找到还未过载(未设置IP_VS_DEST_F OVERLOAD标志)的且权重最高的真实服务器，进行调度当服务器承接大量链接，我们可以对此服务器进行过载标记（IP_VS_DEST_F OVERLOAD），那么vs调度器就不会把链接调度到有过载标记的主机中。
OVF(Overflow-connection)调度算法：基于真实服务器的活动连接数量和权重值实现。将新连接调度到权重值最高的真实服务器，直到其活动连接数量超过权重值，之后调度到下一个权重值最高的真实服务器,在此OVF算法中，遍历虚拟服务相关联的真实服务器链表，找到权重值最高的可用真实服务器。一个可用的真实服务器需要同时满足以下条件:1、未过载(未设置IP_VS_DEST_F OVERLOAD标志) 2、真实服务器当前的活动连接数量小于其权重值 3、其权重值不为零

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

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

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

架构图

未配置前

bash 复制代码

[root@client ~]#curl 192.168.182.100;curl -k https://192.168.182.100
rs1 192.168.238.10
rs1 192.168.238.10

解决方案：使用火墙标记访问vip的80和443的所有数据包，设定标记为6666，然后对此标记进行负载

bash 复制代码

[root@lvs ~]# ipvsadm -A -f 6666 -s rr
[root@lvs ~]# ipvsadm -a -f 6666 -r 192.168.238.10 -m
[root@lvs ~]# ipvsadm -a -f 6666 -r 192.168.238.20 -m     
[root@lvs ~]# systemctl restart ipvsadm.service         
[root@lvs ~]# ipvsadm-save  > /etc/sysconfig/ipvsadm
[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.182.100:80 rr persistent 1
  -> 192.168.238.10:80            Masq    1      0          0         
  -> 192.168.238.20:80            Masq    1      0          0         
TCP  192.168.182.100:443 rr
  -> 192.168.238.10:443           Masq    1      0          0         
  -> 192.168.238.20:443           Masq    1      0          0         
TCP  192.168.182.100:3306 rr
  -> 192.168.238.10:3306          Masq    1      0          0         
  -> 192.168.238.20:3306          Masq    1      0          0         
FWM  6666 rr
  -> 192.168.238.10:0             Masq    1      0          0         
  -> 192.168.238.20:0             Masq    1      0          0

结果

bash 复制代码

[root@client ~]#curl 192.168.182.100;curl -k https://192.168.182.100
rs2 - 192.168.238.20
rs1 192.168.238.10

lvs的会话粘滞解决方案

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

架构图同上

解决方案

在进行调度时，不管用什么算法，只要相同源过来的数据包我们就把他的访问记录在内存中，也就是把这个源的主机调度到了那个RS上如果在短期（默认360S）内同源再来访问我仍然按照内存中记录的调度信息，把这个源的访问还调度到同一台RS上。如果过了比较长的时间（默认最长时间360s）同源访问再次来访，那么就会被调度到其他的RS上

bash 复制代码

[root@lvs ~]# ipvsadm -E -f 6666 -s rr -p 1
[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.182.100:80 rr persistent 1
  -> 192.168.238.10:80            Masq    1      0          0         
  -> 192.168.238.20:80            Masq    1      0          0         
TCP  192.168.182.100:443 rr
  -> 192.168.238.10:443           Masq    1      0          0         
  -> 192.168.238.20:443           Masq    1      0          0         
TCP  192.168.182.100:3306 rr
  -> 192.168.238.10:3306          Masq    1      0          0         
  -> 192.168.238.20:3306          Masq    1      0          0         
FWM  6666 rr persistent 1
  -> 192.168.238.10:0             Masq    1      0          0         
  -> 192.168.238.20:0             Masq    1      0          0

测试

bash 复制代码

[root@client ~]#  curl  192.168.182.100
rs2 - 192.168.238.20

观察