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种算法

静态调度算法

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. MH：Maglev Hashing；磁悬浮哈希，基于一致性哈希思想为每个 RS 生成固定长度的排列表并合成全局查找表，首次按 CIP 哈希结果选定 RS 后，后续来自同一源 IP 的请求始终转发至该 RS。

动态调度算法

主要根据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
7. FO(Weighted Fai Over)调度算法：常用作灰度发布 在此FO算法中，遍历虚拟服务所关联的真实服务器链表，找到还未过载(未设置IP_VS_DEST_F OVERLOAD标志)的且权重最高的真实服务器，进行调度 当服务器承接大量链接，我们可以对此服务器进行过载标记（IP_VS_DEST_F OVERLOAD），那么vs调度 器就不会把链接调度到有过载标记的主机中。
8. OVF(Overflow-connection)调度算法：基于真实服务器的活动连接数量和权重值实现。将新连接调度到权重值最高的真实服务器，直到其活动 连接数量超过权重值，之后调度到下一个权重值最高的真实服务器,在此OVF算法中，遍历虚拟服务相关 联的真实服务器链表，找到权重值最高的可用真实服务器。一个可用的真实服务器需要同时满足以下条件:1、未过载(未设置IP_VS_DEST_F OVERLOAD标志) 2、真实服务器当前的活动连接数量小于其权重值 3、其权重值不为零

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

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

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

架构图

未配置前

[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，然后对此标记进行负载

[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    

结果

[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上

[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         

测试

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

观察

到此这篇关于LVS（Linux virual server）详解的文章就介绍到这了,更多相关Linux virual server内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！

最新评论