lvs知识点

目录

1. 什么是集群
2. 集群分类
3. lvs的作用
4. lvs四种模式及原理
5. lvs的13种算法
6. lvs的多端口轮询问题解决方案
7. lvs的会话粘滞解决方案

一、什么是集群

1.1集群的核心定义

集群是一组通过高速网络互联的独立计算机，以单一系统的模式对外提供服务，客户端访问时感知不到后端多台服务器的存在，就像在和一台超级服务器交互。
它的核心优势有三点：

高可用性：单台服务器故障时，其他节点可接管服务，避免业务中断
负载均衡：将用户请求均匀分配给多台服务器，避免单台设备过载
可扩展性：通过新增服务器节点，线性提升系统的处理能力和吞吐量

1.2 lvs与集群的关系

LVS（Linux Virtual Server，Linux虚拟服务器）是Linux内核实现的高性能负载均衡集群技术，是企业中最常用的集群类型（属于负载均衡集群），由章文嵩博士在1998年开发，现在已经成为Linux内核的标准模块。

二、集群的分类

集群是为了解决某个特定问题将堕胎计算机组合起来形成的单个系统
常见的三种类型：

• LB：LoadBalancing（负载均衡）由多个主机组成，每个主机只承担一部分访问
• HA：：High Availiablity（高可用）主节点宕机后备机自动接管
• HPC：High-performance computing高性能计算，国家战略资源、多台机器并行计算

三、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四种模式及原理

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

4.1 nat模式

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

4.1.1nat模式的数据传输过程

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

4.2 DR模式

在DR模式中，RS接收到访问请求后不需要回传给VS调度器，直接把回传数据发送给client，所以RS和vs
上都要有vip
1.客户端发送数据帧给vs调度主机帧中内容为客户端IP+客户端的MAC+VIP+VIP的MAC
2.VS调度主机接收到数据帧后把帧中的VIP的MAC该为RS1的MAC，此时帧中的数据为客户端IP+客户端
的MAC+VIP+RS1的MAC
3.RS1得到2中的数据包做出响应回传数据包，数据包中的内容为VIP+RS1的MAC+客户端IP+客户端IP的
MAC

4.2.1DR模式特点

1.Director和各RS都配置有VIP
2.确保前端路由器将目标IP为VIP的请求报文发往Director
3.在前端网关做静态绑定VIP和Director的MAC地址

• 在RS上使用arptables工具
• 在RS上修改内核参数以限制arp通告及应答级别

arptables -A OUT -s $VIP -j mangle --mangle-ip-s $RIP
/proc/sys/net/ipv4/conf/all/arp_ignore
/proc/sys/net/ipv4/conf/all/arp_announce

4.RS的RIP可以使用私网地址，也可以是公网地址；RIP与DIP在同一IP网络；
5.RIP的网关不能指向DIP，以确保响应报文不会经由Director
6.RS和Director要在同一个物理网络
7.请求报文要经由Director，但响应报文不经由Director，而由RS直接发往Client
8.不支持端口映射（端口不能修败）
9.RS可使用大多数OS系统

4.3TUN模式

转发方式：不修改请求报文的IP首部（源IP为CIP，目标IP为VIP），而在原IP报文之外再封装一个IP首部
（源IP是DIP，目标IP是RIP），将报文发往挑选出的目标RS；RS直接响应给客户端（源IP是VIP，目标IP
是CIP）

4.3.1TUN模式数据传输过程

1.客户端发送请求数据包，包内有源IP+vip+dport
2.到达vs调度器后对客户端发送过来的数据包重新封装添加IP报文头，新添加的IP报文头中包含
TUNSRCIP(DIP)+TUNDESTIP(RSIP1)并发送到RS1
3.RS收到VS调度器发送过来的数据包做出响应，生成的响应报文中包含SRCIP(VIP)+DSTIP（CIP）
+port，响应数据包通过网络直接回传给client

4.3.2TUN模式特点

1.DIP, VIP, RIP都应该是公网地址
2.RS的网关一般不能指向DIP
3.请求报文要经由Director，但响应不能经由Director
4.不支持端口映射
5.RS的OS须支持隧道功能

4.4 fullnet模式

fullnat：通过同时修改请求报文的源IP地址和目标IP地址进行转发
CIP --> DIP
VIP --> RIP
1.VIP是公网地址，RIP和DIP是私网地址，且通常不在同一IP网络；因此，RIP的网关一般不会指向DIP
2.RS收到的请求报文源地址是DIP，因此，只需响应给DIP；但Director还要将其发往Client
3.请求和响应报文都经由Director
4.支持端口映射

4.5 LVS工作模式总结

4.6 关于LVS-NAT 模式和LVS-DR 模式实验

LVS 实验环境概览

实验一：LVS-NAT 模式部署

NAT 模式通过修改数据包的 IP 地址和端口进行转发，所有流量（请求和响应）都需经过调度器。

1. 网络规划

核心要点：

• VS (node1): 需要双网卡，一个连接外网（VIP），一个连接内网（DIP）。
• RS (node2, node3): 网关必须指向 VS 的内网 IP (DIP)，即 192.168.0.100。
  以RS1为例：

#设定网络
[root@RS1 ~]# vmset.sh eth0 192.168.0.10 RS1 noroute
[root@RS1 ~]# nmcli connection modify eth0 ipv4.gateway 192.168.0.100
[root@RS1 ~]# nmcli connection reload
[root@RS1 ~]# nmcli connection up eth0
[root@RS1 ~]# route  -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.0.100   0.0.0.0         UG    100    0        0 eth0
192.168.0.0     0.0.0.0         255.255.255.0   U     100    0        0 eth0

2. 配置步骤

基础环境准备（所有节点）
关闭防火墙和 SELinux，确保网络连通性。

systemctl stop firewalld
setenforce 0

第一步：在RS1、RS2设定访问业务真实数据

#RS1
[root@RS1 ~]# dnf install httpd -y
[root@RS1 ~]# systemctl enable --now httpd
[root@RS1 ~]# echo RS1 - 192.168.0.10 > /var/www/html/index.html
#RS2
[root@RS1 ~]# dnf install httpd -y
[root@RS1 ~]# systemctl enable --now httpd
[root@RS1 ~]# echo RS2 - 192.168.0.20 > /var/www/html/index.html

第二步：在调度器上启用 IP 转发
LVS-NAT 的核心是 DNAT，因此必须开启系统的路由转发功能。

# 创建配置文件
echo "net.ipv4.ip_forward=1" > /etc/sysctl.d/ip_forward.conf
# 使配置立即生效
sysctl --p

第三步：在调度器 上安装并配置 ipvsadm 规则
注意：NAT 模式使用 -m 参数。VIP 是客户端访问的地址，即 VS 的外网 IP。

# 1. 清除旧规则
ipvsadm -C

# 2. 添加虚拟服务 (VIP)
# -t: TCP协议, VIP地址(外网IP):端口
# -s: 调度算法 (rr=轮询, wrr=加权轮询, lc=最少连接)
ipvsadm -A -t 172.25.254.100:80 -s rr

# 3. 添加真实服务器 (RS)
# -r: 后端真实服务器 IP (RIP):端口
# -m: 代表 NAT 模式 (masquerading)
ipvsadm -a -t 172.25.254.100:80 -r 192.168.0.10:80 -m
ipvsadm -a -t 172.25.254.100:80 -r 192.168.0.20:80 -m

# 4. 查看规则
ipvsadm -Ln

预期输出：

IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
  -> RemoteAddress:Port           Forward Weight ActiveConn InActConn
TCP  172.25.254.100:80 rr
  -> 192.168.0.10:80             Masq    1      0          0
  -> 192.168.0.20:80             Masq    1      0          0

3. 测试与验证

在测试机 (node4) 上执行循环请求，观察请求是否被轮流分发到两台 RS 上。

# 在 client 上执行
curl http://172.25.254.100

预期现象： 输出结果会交替显示来自 192.168.0.10 和 192.168.0.20 的响应内容，证明轮询调度生效。

实验二：LVS-DR 模式部署

DR 模式通过修改数据包的 MAC 地址进行转发，响应数据由 RS 直接返回给客户端.

1. 网络规划

核心要点：

• 所有机器 (VS, RS1, RS2): 必须在同一个物理网络（二层可达）。
• VIP 配置： VS 和所有 RS 都需要配置 VIP。RS 上的 VIP 通常配置在 lo (回环) 接口上，子网掩码为 255.255.255.255 (/32)。
• 以RS1为例：

#在lo上设定vip
[root@RS1 ~]# cd /etc/NetworkManager/system-connections/
[root@RS1 system-connections]# cp -p eth0.nmconnection lo.nmconnection
[root@RS1 system-connections]# vim lo.nmconnection
[connection]
id=lo
type=loopback
interface-name=lo

[ethernet]

[ipv4]
address1=127.0.0.1/8
address2=192.168.0.200/32
method=manual

[root@RS1 system-connections]# nmcli connection reload
[root@RS1 system-connections]# nmcli connection up lo

• RS 网关： RS 的网关指向路由器 (192.168.0.100)，绝不能指向 VS 的 DIP。

[root@RS1 ~]# vmset.sh eth0 192.168.0.10 RS1 noroute
[root@RS1 ~]# nmcli connection modify eth0 ipv4.gateway 192.168.0.100
[root@RS1 ~]# nmcli connection reload
[root@RS1 ~]# nmcli connection up eth0
[root@RS1 ~]# route  -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.0.100   0.0.0.0         UG    100    0        0 eth0
192.168.0.0     0.0.0.0         255.255.255.0   U     100    0        0 eth0

2. 配置步骤

基础环境准备（所有节点）
关闭防火墙和 SELinux，确保网络连通性。

systemctl stop firewalld
setenforce 0

第一步：部署路由器
路由器（router）在 LVS-DR 模式中扮演着网络网关和流量转发的核心角色。它的主要任务是为整个实验环境提供网络连通性，确保客户端的请求能够到达 LVS 调度器（vsnode）。

1. 清理与准备

首先，确保路由器上没有运行任何可能干扰实验的 ipvsadm 服务，并清空其规则。

# 停止并禁用 ipvsadm 服务
systemctl disable --now ipvsadm.service

# 清空所有 ipvsadm 规则
ipvsadm -C

2. 配置网络接口

为路由器的两个网卡配置 IP 地址，使其成为连接内外两个网段的网关。

• 外网接口 (eth0): 配置为 172.25.254.100，作为客户端（client）的网关。
• 内网接口 (eth1): 配置为 192.168.0.100，作为 LVS 调度器（vsnode）和真实服务器（RS）的网关。

# 配置外网接口 IP
vmset.sh eth0 172.25.254.100 vsnode

# 配置内网接口 IP
vmset.sh eth1 192.168.0.100 vsnode noroute

3. 开启内核路由转发

为了让数据包能够在不同网段（172.25.254.0/24 和 192.168.0.0/24）之间转发，必须开启 Linux 内核的 IP 转发功能。

# 将配置写入 sysctl.conf 文件以永久生效
echo net.ipv4.ip_forward=1 >> /etc/sysctl.conf

# 立即加载配置，使设置生效
sysctl -p

执行后，系统会输出 net.ipv4.ip_forward = 1，表示已成功开启。

4. 配置数据转发策略 (SNAT)

配置 iptables 的 SNAT（源地址转换）规则。当内网（192.168.0.0/24）的数据包通过路由器的 eth1 接口发出时，将其源 IP 地址伪装成路由器的内网 IP（192.168.0.100）。这确保了返回的数据包能正确地回到路由器，再由路由器转发给内网的原始请求者。

# 添加 SNAT 规则
iptables -t nat -A POSTROUTING -o eth1 -j SNAT --to-source 192.168.0.100

核心作用总结：
路由器本身不参与 LVS 的负载均衡逻辑（不配置 VIP，不安装 ipvsadm）。它的核心作用是作为一个标准的网络网关，通过配置 IP 转发和 SNAT，打通了客户端与 LVS 集群之间的网络路径，是整个实验环境能够通信的基础。

第二步：解决 ARP 冲突 (在 RS1 和 RS2 上操作)
由于 VS 和 RS 都配置了相同的 VIP，必须抑制 RS 对 VIP 的 ARP 响应，确保客户端的 ARP 请求只由 VS 响应。

# 在 RS1 和 RS2 上分别执行以下命令
# 1. 限制 ARP 响应级别：只在请求的目标IP配置在接收接口上时才响应
echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore
echo 1 > /proc/sys/net/ipv4/conf/lo/arp_ignore

# 2. 限制 ARP 通告级别：避免向非直连网络通告接口信息
echo 2 > /proc/sys/net/ipv4/conf/all/arp_announce
echo 2 > /proc/sys/net/ipv4/conf/lo/arp_announce

第三步：配置调度器 (lvs) 的 ipvsadm 规则

# 1. 添加虚拟服务 (VIP)
# -t: 指定 TCP 协议及 VIP 地址(192.168.0.200)和端口(80)
# -s: 指定调度算法，这里使用加权轮询 (wrr)
ipvsadm -A -t 192.168.0.200:80 -s wrr

# 2. 添加真实服务器 (RS)
# -r: 指定后端 RS 的真实 IP (RIP)
# -g: 代表 DR 模式 (Gatewaying/直接路由)，这是最关键参数
# -w: 设置权重，配合 wrr 算法使用（图中未标明权重差异，默认设为 1）
ipvsadm -a -t 192.168.0.200:80 -r 192.168.0.10:80 -g -w 1
ipvsadm -a -t 192.168.0.200:80 -r 192.168.0.20:80 -g -w 1

# 3. 保存规则并查看配置结果
service ipvsadm save  # (可选) 保存规则防止重启丢失
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 wrr
  -> 192.168.0.10:80             Route   1      0          0
  -> 192.168.0.20:80             Route   1      0          0

注意这里的 Forward 列显示为 Route，代表 DR 模式。

3. 测试与验证

在任意能访问 VIP 的客户端

# 在客户端执行
for N in {1..6}; do curl 192.168.0.200; done

预期现象： 输出结果会交替显示来自 192.168.0.101 和 192.168.0.102 的响应内容，证明 DR 模式下的负载均衡生效。

五、LVS的算法

5.1 LVS 调度算法体系详解

LVS 调度器（IPVS Scheduler）的核心职责是决定如何将客户端的请求分发到后端的真实服务器（RS）。根据调度时是否感知后端服务器的实时负载状态，LVS 的调度算法被划分为三大体系：静态调度算法、动态调度算法，以及 Linux 4.15 内核之后引入的新型专用算法。

5.2 调度算法分类概述

• 静态调度方法：仅依赖算法自身的预设规则进行流量分发，完全不考虑后端 RS 当前的负载情况（如连接数、CPU 使用率等）。适用于集群内 RS 硬件配置相近且业务负载相对平稳的场景。
• 动态调度方法：实时感知并评估每台 RS 的当前负载状态。系统会为每台 RS 计算一个负载值（Overhead），并将新请求优先分配给 Overhead 值最小的 RS，从而实现真正的动态负载均衡。

5.3 静态调度算法

静态算法通过固定的映射或轮询规则分配请求，主要包含以下四种：

1. RR（Round Robin，轮询调度）

   • 工作原理：将接收到的请求按顺序依次、循环地分配给集群中的每台 RS。
   • 适用场景：所有 RS 硬件配置完全一致，且请求处理时间均匀的场景。
   • 局限性：若 RS 配置存在差异，性能较差的节点容易因被频繁调度而过载。

2. WRR（Weighted Round Robin，加权轮询）

   • 工作原理：在 RR 的基础上引入权重（Weight）机制。管理员根据 RS 的实际处理能力分配不同的权重，权重越高的 RS 被调度的次数越多。
   • 适用场景：集群内 RS 性能不均等，需根据硬件差异合理分配流量的场景。

3. SH（Source Hashing，源地址哈希）

   • 工作原理：根据客户端请求的源 IP 地址进行哈希运算，将来自同一源 IP 的请求始终映射到同一台 RS。
   • 适用场景：需要实现会话保持（Session Sticky）的业务，如用户登录状态维持。
   • 局限性：若某一客户端请求量过大，会导致对应 RS 负载过高。

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

   • 工作原理：根据请求的目标 IP 地址进行哈希运算，将发往同一目标 IP 的请求固定转发至同一台 RS。
   • 适用场景：正向代理缓存场景（如宽带运营商的缓存集群），可显著提高缓存命中率。

5.4 动态调度算法

动态算法通过计算 Overhead 值来评估 RS 的繁忙程度，Overhead 值越小，被调度的优先级越高。

1. LC（Least Connections，最少连接）

   • 工作原理：将新请求分配给当前连接数最少的 RS。
   • Overhead 公式：Overhead = ActiveConns × 256 + InactiveConns
   • 适用场景：请求处理时间长短不一的长连接应用（如数据库连接、SSH）。

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

   • 工作原理：在 LC 的基础上引入权重，兼顾 RS 的硬件性能与实时连接数。这是 LVS 的默认调度算法。
   • Overhead 公式：Overhead = (ActiveConns × 256 + InactiveConns) / Weight
   • 适用场景：绝大多数生产环境，尤其适合 RS 性能不均且请求处理时间不一的场景。

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

   • 工作原理：WLC 的改进版，旨在最小化新连接的预期延迟。
   • Overhead 公式：Overhead = (ActiveConns + 1 + InactiveConns) × 256 / Weight
   • 特性：初始阶段会优先将请求分配给高权重的 RS。例如，若 Node1 权重为 1，Node2 权重为 10，前几次调度都会被 Node2 承接。

4. NQ（Never Queue，永不排队）

   • 工作原理：SED 的优化版。如果存在活动连接数为 0 的 RS，则直接将请求分配给它，无需进行 SED 运算；否则按 SED 算法调度。
   • 适用场景：希望完全避免新请求排队等待，确保即时响应的场景。

5. LBLC（Locality-Based Least Connections，基于局部性的最少连接）

   • 工作原理：一种动态的 DH 算法。为同一目标 IP 维护一个服务器子集，优先从子集中按 LC 算法选择；若子集内服务器均过载，则重新选择集群中负载最低的 RS。
   • 适用场景：Web 缓存、正向代理缓存集群，兼顾缓存命中率与负载均衡。

6. LBLCR（LBLC with Replication，带复制的 LBLC）

   • 工作原理：解决 LBLC 可能导致的负载不均问题。当某台 RS 负载过重时，会将其负责的部分目标 IP “复制”（转移）到其他负载较轻的 RS。
   • 适用场景：大规模正向代理集群，需动态再平衡负载。

5.5 Linux 4.15+ 内核新增调度算法

随着内核的升级，LVS 引入了针对特定运维场景的专用算法，支持通过 IP_VS_DEST_F_OVERLOAD 标志对 RS 进行过载标记。

1. FO（Weighted Failover，加权故障转移）

   • 工作原理：遍历虚拟服务关联的 RS 链表，优先选择未过载且权重最高的 RS 进行调度。
   • 适用场景：灰度发布、服务容灾。当某台 RS 承接大量连接或需要维护时，管理员可手动为其打上过载标记，调度器将自动跳过该节点，实现无损的流量切换。

2. OVF（Overflow Connections，溢出连接）

   • 工作原理：基于 RS 的活动连接数和权重值进行调度。调度器会寻找权重最高且当前活动连接数小于其权重值的可用 RS。当高权重 RS 的连接数达到上限后，再调度至下一个权重最高的 RS。
   • 可用 RS 判定条件：① 未设置过载标记；② 当前活动连接数 < 自身权重值；③ 权重值不为零。
   • 适用场景：高并发场景下需要严格限制每台 RS 最大连接数，确保负载均匀分配。

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

针对 LVS 在多端口（如 HTTP 的 80 端口和 HTTPS 的 443 端口）场景下可能出现的轮询错乱问题，其核心解决方案是使用防火墙标记

问题根源：独立调度导致会话不一致

默认情况下，LVS 会为每个监听的端口（VIP:Port）创建独立的虚拟服务。例如，为 80 端口和 443 端口分别配置一套调度规则。

当用户的一个会话同时包含 HTTP 和 HTTPS 请求时，LVS 会独立地对这两个端口的请求进行调度。这可能导致来自同一个客户端的请求被分发到不同的后端真实服务器（RS）上，从而引发会话状态丢失、登录信息不一致等问题。

• 示例：客户端的首个 HTTP 请求被调度到 RS1，而紧接着的 HTTPS 请求却被调度到了 RS2。

解决方案：防火墙标记（FWM）

防火墙标记的核心思想是将多个端口的流量“捆绑”在一起，视为同一个服务进行统一调度。

工作原理

1. 打标记 (Marking)：在 LVS 调度器上，使用 iptables 的 mangle 表，在数据包进入 PREROUTING 链时，根据预设规则（如目标 IP 和多个端口号）为数据包打上一个唯一的数字标记（Mark）。
2. 基于标记调度 (Scheduling by Mark)：在 ipvsadm 中，不再为每个端口单独创建虚拟服务，而是创建一个基于该标记（-f 参数）的虚拟服务。所有带有相同标记的数据包，无论其目标端口是 80 还是 443，都会被这套统一的调度规则处理，从而确保被转发到同一台后端服务器。

配置步骤

以下是解决 80 和 443 端口轮询错乱问题的具体配置流程：

1. 使用 iptables 为数据包打标记
   将发往虚拟 IP (VIP) 的 80 和 443 端口的 TCP 数据包统一标记为 6666。

   iptables -t mangle -A PREROUTING -d <VIP> -p tcp -m multiport --dports 80,443 -j MARK --set-mark 6666
   

2. 使用 ipvsadm 基于标记创建调度规则
   创建一个基于标记 6666 的虚拟服务，并添加后端真实服务器。

   # 添加基于标记的虚拟服务，并指定调度算法（如 rr）
   ipvsadm -A -f 6666 -s rr
   
   # 添加真实服务器，注意这里不需要指定端口
   ipvsadm -a -f 6666 -r <RS1_IP> -g
   ipvsadm -a -f 6666 -r <RS2_IP> -g
   

通过这种方式，来自同一客户端的 80 和 443 端口请求会被 LVS 识别为同一个“流”，并被始终调度到同一台真实服务器，从而彻底解决了多端口轮询错乱的问题。

以下述实验为例：

• 实验环境：

1. 在 RS 主机中同时开启 HTTP 和 HTTPS

首先需要在真实服务器（RS1 和 RS2）上安装 SSL 模块并重启服务，确保它们能同时处理两种协议的请求。

# 在 RS1 和 RS2 中执行
[root@RS1+RS2 ~]# dnf install mod_ssl -y
[root@RS1+RS2 ~]# systemctl restart httpd

2. 在调度器 (vsnode) 中添加独立的轮询策略（错误演示）

如果分别对 80 端口和 443 端口配置独立的轮询策略，会导致同一个用户的 HTTP 和 HTTPS 请求可能被分发到不同的服务器上。

配置命令：

# 配置 HTTP (80端口)
[root@vsnode boot]# ipvsadm -A -t 192.168.0.200:80 -s rr
[root@vsnode boot]# ipvsadm -a -t 192.168.0.200:80 -r 192.168.0.20 -g
[root@vsnode boot]# ipvsadm -a -t 192.168.0.200:80 -r 192.168.0.10 -g

# 配置 HTTPS (443端口)
[root@vsnode boot]# ipvsadm -A -t 192.168.0.200:443 -s rr
[root@vsnode boot]# ipvsadm -a -t 192.168.0.200:443 -r 192.168.0.10:443 -g
[root@vsnode boot]# ipvsadm -a -t 192.168.0.200:443 -r 192.168.0.20:443 -g

# 查看配置
[root@vsnode boot]# ipvsadm -Ln

出现的问题：
由于 80 和 443 是独立的服务，轮询是分开计算的。

• 测试命令： curl 192.168.0.200; curl -k https://192.168.0.200
• 结果： 可能会发现 HTTP 请求到了 RS2，而 HTTPS 请求到了 RS1（或者相反），导致会话不一致。

3. 解决方案：使用防火墙标记 (Firewall Mark)

为了解决上述问题，我们需要利用 iptables 给访问 VIP 的 80 和 443 端口的数据包打上相同的标记（例如 6666），然后让 LVS 针对这个标记进行统一的负载均衡。

操作步骤：

1. 添加防火墙标记规则：
   将目标地址为 192.168.0.200 且端口为 80 或 443 的 TCP 数据包标记为 6666。

   [root@vsnode boot]# iptables -t mangle -A PREROUTING -d 192.168.0.200 -p tcp -m multiport --dports 80,443 -j MARK --set-mark 6666
   

2. 配置基于标记的 LVS 规则：
   删除之前的独立端口规则，改为基于防火墙标记（-f 6666）配置。

   # 添加基于标记的虚拟服务
   [root@vsnode boot]# ipvsadm -A -f 6666 -s rr
   
   # 添加真实服务器（注意：这里不需要指定端口，因为标记已经包含了流量信息）
   [root@vsnode boot]# ipvsadm -a -f 6666 -r 192.168.0.10 -g
   [root@vsnode boot]# ipvsadm -a -f 6666 -r 192.168.0.20 -g
   

3. 测试结果：
   再次在客户端测试，LVS 会根据标记将同一来源的 HTTP 和 HTTPS 请求分发到同一台服务器。

   [root@client ~]# curl 192.168.0.200; curl -k https://192.168.0.200
   # 预期结果（示例）：
   # RS2 - 192.168.0.20
   # RS2 - 192.168.0.20  (或者两次都指向 RS1)
   

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

LVS 实现会话粘滞主要有两种方案，分别适用于不同的业务场景：一种是基于客户端 IP 的源地址哈希（SH）算法，另一种是更灵活的持久连接功能。

7.1 方案一：源地址哈希 (SH) 算法

• 工作原理：LVS 调度器使用一个哈希函数对客户端请求的源 IP 地址 (CIP) 进行计算。无论集群状态如何变化，来自同一个源 IP 的所有请求，其哈希值始终不变，因此会被始终定向到同一台后端真实服务器（RS）。
• 适用场景：适用于需要强制、永久将会话绑定到特定服务器的场景。
• 配置命令：在创建虚拟服务时，将调度算法指定为 sh。

  # 示例：为 TCP 80 端口的服务启用源地址哈希算法
  ipvsadm -A -t <VIP>:80 -s sh
  

• 优缺点：
  • 优点：实现简单，粘滞效果绝对，不受连接超时影响。
  • 缺点：可能导致负载不均。例如，当大量用户通过同一个 NAT 网关访问时，他们的请求源 IP 是相同的，这会导致所有流量都被分发到同一台 RS。

7.2 方案二：持久连接

这是一种更灵活、更常用的方案，它可以在使用任何调度算法（如轮询 rr、加权最少连接 wlc）的同时，实现临时性的会话粘滞。

• 工作原理：LVS 调度器会在内存中维护一个“持久连接模板”。当一个新的客户端请求到来时，调度器会按配置的算法（如 rr）选择一台 RS，并记录下 客户端IP -> RS 的映射关系。在设定的超时时间内，来自该客户端的所有后续请求，无论目标端口是什么，都会被直接转发到之前记录的那台 RS，而不再进行调度计算。
• 适用场景：适用于大多数 Web 应用，特别是需要维持登录状态、购物车信息等短期会话的场景。它能更好地兼顾负载均衡和会话保持。
• 配置命令：在使用 ipvsadm 添加或编辑虚拟服务时，使用 -p 参数指定超时时间（单位为秒）。

  # 示例1：为新服务启用持久连接，超时时间为 300 秒
  ipvsadm -A -t <VIP>:80 -s wlc -p 300
  
  # 示例2：为已存在的服务修改持久连接超时时间
  ipvsadm -E -t <VIP>:80 -p 600
  

• 优缺点：
  • 优点：非常灵活，可以与任何调度算法结合使用。超时后连接会重新调度，有助于在 RS 增减或负载变化时重新平衡流量。
  • 缺点：需要维护连接状态表，有轻微的内存开销。如果超时时间设置不当，可能导致会话意外中断或粘滞时间过长。

7.3 方案对比与选择

总结：

• 如果你的业务必须将同一个客户端的所有请求永远固定在一台服务器上，请选择 SH 算法。
• 如果你只是希望在一段时间内（如用户登录期间）保持会话，同时又不希望牺牲负载均衡的灵活性，那么 持久连接 (-p) 是更好的选择。

7.4 实验环境配置案例

结合我们当前的实验环境（调度器 VIP: 192.168.0.200，后端 RS: 192.168.0.10 和 192.168.0.20），以下是两种方案的具体配置演示：

案例一：配置源地址哈希 (SH) 算法

# 1. 清除旧的 LVS 规则（防止冲突）
[root@vsnode ~]# ipvsadm -C

# 2. 添加虚拟服务，指定 VIP 的 80 端口，调度算法为 sh
[root@vsnode ~]# ipvsadm -A -t 192.168.0.200:80 -s sh

# 3. 添加真实服务器，使用 DR 模式 (-g)
[root@vsnode ~]# ipvsadm -a -t 192.168.0.200:80 -r 192.168.0.10 -g
[root@vsnode ~]# ipvsadm -a -t 192.168.0.200:80 -r 192.168.0.20 -g

案例二：配置持久连接 (结合防火墙标记)

这是实际生产中最常用的方案。为了兼顾我们之前解决的“HTTP 和 HTTPS 会话粘滞”问题，这里演示持久连接 + 防火墙标记的组合方案。

# 1. 清除旧的 LVS 规则
[root@vsnode ~]# ipvsadm -C

# 2. 添加防火墙标记（将 80 和 443 端口的流量打上 6666 的标记）
[root@vsnode ~]# iptables -t mangle -A PREROUTING -d 192.168.0.200 -p tcp -m multiport --dports 80,443 -j MARK --set-mark 6666

# 3. 添加基于标记的虚拟服务，使用轮询算法 (rr)，并开启持久连接 (-p 300 表示 300 秒超时)
[root@vsnode ~]# ipvsadm -A -f 6666 -s rr -p 300

# 4. 添加真实服务器（注意：基于标记的服务不需要指定端口）
[root@vsnode ~]# ipvsadm -a -f 6666 -r 192.168.0.10 -g
[root@vsnode ~]# ipvsadm -a -f 6666 -r 192.168.0.20 -g

案例二效果说明：客户端首次访问 VIP 时，LVS 会按轮询算法选择一台 RS（例如 RS1）。在接下来的 300 秒内，该客户端发起的任何访问 VIP 的请求（无论是 HTTP 的 80 端口，还是 HTTPS 的 443 端口），都会被直接定向到 RS1，实现完美的跨协议会话粘滞。300 秒超时后，LVS 会重新进行调度计算。

7.5生产环境最佳实践：规则持久化

LVS 会话粘滞规则默认保存在内存中，一旦调度器服务器重启，配置将会丢失，导致用户的会话瞬间断裂。为确保会话粘滞策略长期有效，建议在配置完成后执行以下持久化操作。

方法一：利用自定义文件进行持久化（适合手动备份/恢复）

这种方法将当前的 LVS 规则导出为一个文本文件。如果不小心清空了规则，可以手动从文件中恢复。

# 1. 将当前的 LVS 规则以数字形式导出，并保存到自定义文件中
[root@vsnode ~]# ipvsadm-save -n > /mnt/ipvs.rule

# 2. （模拟误操作）清空当前系统中所有的 LVS 规则
[root@vsnode ~]# ipvsadm -C

# 3. 从刚才保存的文件中恢复 LVS 规则
[root@vsnode ~]# ipvsadm-restore < /mnt/ipvs.rule

方法二：利用守护进程进行规则持久化（推荐生产环境使用）

这种方法将规则保存到系统默认的配置文件 /etc/sysconfig/ipvsadm 中，并开启 ipvsadm 服务，实现开机自动加载规则。

# 1. 将当前的 LVS 规则导出，并保存到系统默认的配置文件
[root@vsnode ~]# ipvsadm-save -n > /etc/sysconfig/ipvsadm

# 2. （模拟误操作）清空当前系统中所有的 LVS 规则
[root@vsnode ~]# ipvsadm -C

# 3. 立即启动 ipvsadm 服务，并设置为开机自启
[root@vsnode ~]# systemctl enable --now ipvsadm.service

说明：会话粘滞负责把用户绑对服务器，而规则持久化负责保证这个绑定策略不会丢。两者在技术原理上无直接关系，但在实际部署中是一套必须组合使用的"组合拳"。

附录：核心命令速查表