一、什么是集群（Cluster）
集群 是为了解决某个特定问题，将多台计算机组合起来形成的单个系统。对用户来说，集群看起来就像一个整体， 但它背后是由多台主机协同工作来分担任务、提升能力。
系统性能扩展的两种思路：
• Scale UP（向上扩展） ：增强单台机器的硬件（加 CPU、内存），但有物理上限、成本非线性增长。
• Scale Out（向外扩展） ：增加设备、横向堆机器，通过调度分配把任务分摊------这就是**集群（Cluster）**的思路。
集群 vs 分布式（易混点）：
• 集群 ：同一业务部署在多台服务器上，每台功能、代码、数据都一样；靠"单位时间内处理的任务数"提升效率。
• 分布式 ：一个业务被拆成多个子业务（或不同业务）部署在多台服务器，每台功能/数据不同，合起来才是完整业务；靠"缩短单个任务执行时间"提升效率。
→ 大型网站常是：前端一个负载均衡器 + 后面几台做同一业务的集群；某台挂了其他顶上。分布式某个节点挂了，该业务就可能失败。
二、集群分类
常见集群按目标分为三类：LB（负载均衡） 、HA（高可用） 、HPC（高性能计算）。
HA 关键指标速记：
• MTBF ：Mean Time Between Failures，平均无故障时间（越长越好）。
• MTTR ：Mean Time To Restoration，平均恢复时间（越短越好）。
• A = MTBF / (MTBF + MTTR) ，取值 (0,1)，常见 99% / 99.5% / 99.9% / 99.99% / 99.999%。
• SLA ：服务等级协议，约定达不到水平会有惩罚；运维核心目标就是达成 SLA（重点关注计划外停机）。
三、LVS 的作用
LVS（Linux Virtual Server） 是负载调度器 ，自内核集成 ，由章文嵩博士发起，阿里四层 SLB（Server Load Balance）即基于 LVS + keepalived 实现。官网：The Linux Virtual Server Project - Linux Server Cluster for Load Balancing
http://www.linuxvirtualserver.org/
它的核心作用：作为 LB 集群的调度器（Director / VS） ，接收客户端请求，按调度算法挑选一台真实服务器（RS）并转发，使多台 RS 协同承担同一业务，从而提升并发能力、实现横向扩展。
3.1 LVS 核心术语（必背）
| 术语 | 英文 / 含义 | 说明 |
|---|---|---|
| VS | Virtual Server（调度器） | 负责调度，即 Director |
| RS | Real Server（真实服务器） | 真正提供业务服务的主机 |
| CIP | Client IP | 客户端主机的 IP |
| VIP | Virtual Server IP | VS 对外暴露、让客户端访问的 IP |
| DIP | Director IP | VS 内网 IP，负责访问后端 RS |
| RIP | Real Server IP | 真实业务主机的 IP |
访问流程：CIP <--> VIP == DIP <--> RIP
工作原理： VS 根据请求报文的目标 IP、目标协议及端口，将其调度转发至某台 RS，具体挑哪台由调度算法 决定。 注意：IPVS 的作用点位于 PREROUTING 与 INPUT 链之间，因此做 LVS 时应把 iptables 的防火墙策略清空，避免干扰。
四、LVS 的四种工作模式及原理
LVS 集群类型（4 种）：lvs-nat lvs-dr lvs-tun lvs-fullnat
4.1 NAT 模式（Network Address Translation）
本质： 多目标 IP 的 DNAT。把请求报文中的目标地址和目标端口修改为挑出的 RS 的 RIP 和 PORT 后转发。
- RIP 与 DIP 应在同一 IP 网络，且用私网地址；RS 的网关必须指向 DIP。
- 请求报文和响应报文都必须经 Director 转发，Director 易成瓶颈。
- 支持端口映射（可改目标 PORT）。
- VS 必须是 Linux，RS 可以是任意 OS。
NAT 模式数据逻辑（6 步）：
① 客户端发包，源 CIP、目标 VIP:端口（如 9000）。
② VS 做 DNAT，把目标由 VIP 换成 RS 的 RIP 及相应端口。
③ RS1 响应，源 RIP1、目标 CIP。
④ VS 收到响应，把源 RIP1 改回 VIP、端口 9000→80。
⑤ VS 把改写后的响应回传客户端。
⑥ 收/发都过 VS，故 VS 易阻塞。
4.2 DR 模式（Direct Routing，直接路由）
默认模式、应用最广。 通过为请求报文重新封装一个 MAC 首部 进行转发：源 MAC 是 DIP 所在接口 MAC，目标 MAC 是挑出的 RS 的 RIP 所在接口 MAC；源/目标 IP、PORT 均保持不变。
- Director 与各 RS 都配置有 VIP。
- 需解决 VIP 地址冲突（前端网关静态绑定 / arptables / 改内核参数限制 arp）。
- 请求经 Director，响应由 RS 直接发往 Client（RS 与 VS 上都有 VIP）。
- 不支持端口映射。
- RS 与 Director 须在同一物理网络；RIP 网关不能指向 DIP。
- RS 可使用大多数 OS。
DR 模式数据传输过程：
① 客户端发数据帧给 VS：客户端IP + 客户端MAC + VIP + VIP的MAC。
② VS 把帧中"VIP 的 MAC"改成 RS1 的 MAC：客户端IP + 客户端MAC + VIP + RS1的MAC。
③ RS1 收到后响应，回传：VIP + RS1的MAC + 客户端IP + 客户端MAC，直接发给客户端。
4.3 TUN 模式（IP Tunneling，隧道）
了解级。 不修改原请求报文 IP 首部（源 CIP、目标 VIP），而是在原 IP 报文外再封装一个 IP 首部（源 DIP、目标 RIP）发往 RS；RS 直接响应客户端（源 VIP、目标 CIP）。
- DIP、VIP、RIP 都应是公网地址；RS 网关一般不能指向 DIP。
- 请求经 Director，响应不经 Director。
- 不支持端口映射；RS 的 OS 须支持隧道功能。
4.4 FullNAT 模式（全地址转换）
了解级。 同时修改请求报文的源 IP 和目标 IP 进行转发：CIP→DIP，VIP→RIP。
- VIP 公网、RIP/DIP 私网且通常不在同一网络；RIP 网关一般不指向 DIP。
- RS 收到的请求源地址是 DIP，只需响应给 DIP，Director 再发往 Client。
- 请求和响应都经 Director；支持端口映射。
- ⚠️ 此类型内核默认不支持，需打补丁或专用版本。
4.5 四种模式对比总结
| 对比项 | NAT | DR（默认/最常用） | TUN | FullNAT |
|---|---|---|---|---|
| RS 操作系统 | 不限 | 禁用 arp（需配置） | 支持隧道 | 不限 |
| 调度器与服务器网络 | 可跨网络 | 不可跨网络（同物理网） | 可跨网络 | 可跨网络 |
| 可承载 RS 数量 | 少 | 多 | 多 | 多 |
| RS 网关 | 指向 DIP | 指向路由（非 DIP） | 指向路由 | 一般不指向 DIP |
| 端口映射 | ✅ 支持 | ❌ 不支持 | ❌ 不支持 | ✅ 支持 |
| 响应是否经 Director | ✅ 是 | ❌ 否（RS 直回） | ❌ 否 | ✅ 是 |
**一句话记忆：**NAT / FullNAT ------ 请求和响应都经 Director；DR / TUN ------ 请求经 Director，响应由 RS 直回 Client。DR 靠封装新 MAC，TUN 靠外层套新 IP 头（支持远距离）。
五、LVS 的十三种调度算法
LVS 调度算法（ipvs scheduler）按调度时是否考虑 RS 当前负载 分为两类：静态方法 （只看算法本身）与动态方法 （看 RS 负载，Overhead 值较小者被调度）。
5.1 静态调度算法（4 种）
| 算法 | 全称 / 中文 | 说明 |
|---|---|---|
| RR | Round Robin 轮询 | RS 轮流被调度；当 RS 配置有差别时不推荐 |
| WRR | Weighted RR 加权轮询 | 按 RS 配置加权调度，性能差的 RS 被调度次数少 |
| SH | Source Hashing 源地址哈希 | 实现 session sticky：同一 IP 请求始终发往第一次挑中的 RS（会话绑定） |
| DH | Destination Hashing 目标地址哈希 | 第一次轮询调度至 RS，后续发往同一目标地址的请求始终转发至该 RS；典型场景：正向代理缓存负载均衡 |
5.2 动态调度算法（6 种）
| 算法 | 全称 / 中文 | Overhead 计算 / 说明 |
|---|---|---|
| LC | Least Connections 最少链接 | Overhead = activeconns×256 + inactiveconns；适用长连接 |
| WLC | Weighted LC 权重最少链接 | 默认调度方法；Overhead = (activeconns×256 + inactiveconns) / weight |
| SED | Shortest Expectation Delay 最短期望延迟 | Overhead = (activeconns+1+inactiveconns)×256 / weight；初始连接高权重优先 |
| NQ | Never Queue 永不排队 | 第一轮均匀分配，后续按 SED |
| LBLC | Locality-Based LC 基于局部性最少链接 | 动态的 DH 算法；用于按负载实现正向代理 |
| LBLCR | LBLC with Replication 带复制的 LBLC | 解决 LBLC 负载不均：从负载重的 RS 复制到负载轻的 RS |
5.3 内核 4.15+ 新增算法（2 种）
| 算法 | 全称 / 中文 | 说明 |
|---|---|---|
| FO | Weighted Fail Over 加权故障转移 | 常用作灰度发布；遍历 RS 链表，找未过载（未置 IP_VS_DEST_F_OVERLOAD）且权重最高的 RS 调度。过载标记后不再被调度 |
| OVF | Overflow-connection 溢出连接 | 基于活动连接数与权重：新连接调度到权重最高 RS，直到其活动连接数超过权重值，再调度下一台；要求未过载、活动连接数<权重、权重≠0 |
5.4 内核 4.18+ 补充算法（第 13 种）
| 算法 | 全称 / 中文 | 说明 |
|---|---|---|
| MH | Maglev Hashing 一致性哈希 | 内核 4.18 引入，基于 Google Maglev 的一致性哈希，使 RS 扩缩容时最少连接被重新映射，常用于需要一致性哈希的场景（如 LVS 后端节点变动频繁时） |
小计： 静态 4（RR/WRR/SH/DH）+ 动态 6（LC/WLC/SED/NQ/LBLC/LBLCR）+ 4.15 新增 2（FO/OVF）+ 4.18 补充 1（MH）= 共 13 种。本课程讲义 PDF 列出前 12 种，MH 为较新内核补充，使总数恰为 13。
六、LVS 多端口轮询问题解决方案（火墙标记 FWM）
问题： 以 http(80) 与 https(443) 为例，若在 RS 同时开放 80 和 443，默认控制是分开轮询 的：第一次访问 80 被轮询到 RS1，下次访问 443 仍可能被轮询到 RS1 ------ 出现轮询错乱/重复，同一客户的两个端口被调度到不同 RS，导致会话/证书异常。
错误现象示例： curl http://VIP ; curl -k https://VIP 两次都落到同一台 RS（如都到 RS1），本应分别到 RS1/RS2 才合理。
6.1 解决思路：防火墙标记（FWM）
用 MARK 给访问 VIP 的 80 和 443 数据包打上同一个标记 （如 6666），然后基于该标记定义集群服务，把多个端口当作"同一个服务"统一调度。
6.2 操作步骤（DR 模式环境，VIP=192.168.0.200）
1**RS 上开启 https：**在 RS1、RS2 安装 mod_ssl 并重启 httpd，使 80 与 443 同时可用。
[RS1+RS2]# dnf install mod_ssl -y
[RS1+RS2]# systemctl restart httpd2**（错误示范）分开定义 80 和 443 两个服务：**此时两者独立轮询，会出现轮询错乱。
[vsnode]# ipvsadm -A -t 192.168.0.200:80 -s rr
[vsnode]# ipvsadm -a -t 192.168.0.200:80 -r 192.168.0.10 -g
[vsnode]# ipvsadm -a -t 192.168.0.200:80 -r 192.168.0.20 -g
[vsnode]# ipvsadm -A -t 192.168.0.200:443 -s rr
[vsnode]# ipvsadm -a -t 192.168.0.200:443 -r 192.168.0.10:443 -g
[vsnode]# ipvsadm -a -t 192.168.0.200:443 -r 192.168.0.20:443 -g测试：curl 192.168.0.200; curl -k https://192.168.0.200 → 两次都到 RS2（错乱）。
3**打火墙标记：**在 Director 用 iptables mangle 表给目标 VIP 的 80、443 数据包打标记 6666。
[vsnode]# iptables -t mangle -A PREROUTING -d 192.168.0.200 \
-p tcp -m multiport --dports 80,443 -j MARK --set-mark 66664基于标记定义集群服务（替代分开的两个服务）：
[vsnode]# ipvsadm -A -f 6666 -s rr
[vsnode]# ipvsadm -a -f 6666 -r 192.168.0.10 -g
[vsnode]# ipvsadm -a -f 6666 -r 192.168.0.20 -g5**验证：**客户端访问 80 与 443 被统一调度到不同 RS。
[client]# curl 192.168.0.200; curl -k https://192.168.0.200
RS2 - 192.168.0.20
RS1 - 192.168.0.10 # 80→RS2, 443→RS1，错乱解决七、LVS 会话粘滞解决方案（持久连接 Persistent）
问题： 客户上网常与服务器交互、提交表单。若每次调度都换 RS，会导致已填表单丢失。用 SH 算法虽能粘滞，但简单粗暴、易造成调度失衡。
**解决方案：持久连接（Persistent）。**无论用哪种调度算法，VS 把"某来源被调度到哪台 RS"记录在内存中；在短期（默认 360s）内同源再来，仍按记录调度到同一台 RS；超时后同源再访才会被调度到其他 RS。
核心命令： ipvsadm -A|-E -t|u|f 服务地址 [-s 算法] -p [timeout]
其中 -p 即设置持久连接超时（默认 360 秒）。配合防火墙标记 -f 时，可把 80 与 443 视为一个整体实现粘滞。
7.1 操作步骤（结合火墙标记，VIP=192.168.0.200）
1**先打标记（同第六节）：**把 80/443 合并为 FWM 6666。
[vsnode]# iptables -t mangle -A PREROUTING -d 192.168.0.200 \
-p tcp -m multiport --dports 80,443 -j MARK --set-mark 66662定义带持久连接的集群服务： 用 -f 6666 -s rr -p 1（此处 -p 1 表示 1 秒超时做演示；生产可按需设 3000 等）。
[vsnode]# ipvsadm -A -f 6666 -s rr -p 1
[vsnode]# ipvsadm -Ln
FWM 6666 rr persistent 1
-> 192.168.0.10:0 Route 1
-> 192.168.0.20:0Flags 中出现 persistent 即表示持久连接已生效。
3**验证粘滞：**客户端连续访问，同源在超时内始终落到同一 RS。
[client]# curl 192.168.0.200
RS1 - 192.168.0.10
[client]# curl 192.168.0.200
RS1 - 192.168.0.10 # 同一源被粘滞到 RS14观察持久连接条目：
[vsnode]# watch -n 1 ipvsadm -Lnc
IPVS connection entries
TCP 01:56 FIN_WAIT 172.25.254.99:42420 192.168.0.200:80 192.168.0.20:80
IP 00:57 ASSURED 172.25.254.99:0 0.0.26.10:0 192.168.0.20:0其中 IP ... ASSURED 行即持久连接模板，保证同源后续请求继续发往 192.168.0.20。
**持久连接 + 火墙标记组合的价值：**把"多端口（80/443）"与"会话粘滞"两个问题一并解决------既避免轮询错乱，又保证同一客户的 http/https 都落在同一 RS，表单不丢、证书一致。
附：实战项目 ------ 用 LVS 对数据库读动作做负载均衡
思路：用 DR 模式把对 MySQL/MariaDB 3306 的读请求均衡到多台 RS。关键步骤（精简）：
1部署 RS1/RS2 数据库： 安装 mariadb-server，配置不同 server-id（10 / 20），启动服务。
[rs1+2]# dnf install mariadb-server -y
[rs1+2]# vim /etc/my.cnf.d/mariadb-server.cnf # server-id=10 / 20
[rs1]# systemctl enable --now mariadb2建立可远程登录授权用户（用于客户端经 LVS 连接）。
[rs1+2]# mysql
MariaDB> create user root@'%' identified by 'lee';3按 DR 模式完成网络设定：客户端设网关到路由器 NAT IP；路由器开内核路由 + SNAT；RS 的 lo 配 VIP、禁 arp 响应、网关指向路由。
4设定 LVS 调度策略（DR 模式，VIP=192.168.0.100:3306）：
[lvs]# ipvsadm -A -t 192.168.0.100:3306 -s rr
[lvs]# ipvsadm -a -t 192.168.0.100:3306 -r 192.168.0.10 -g
[lvs]# ipvsadm -a -t 192.168.0.100:3306 -r 192.168.0.20 -g5客户端验证： 连 VIP 查询 @@server_id，可见读请求在 RS1/RS2 间轮询。
[client]# mysql -uroot -p -h 192.168.0.100
MariaDB> select @@server_id;
+-------------+
| 20 | # 第一次落到 RS2
MariaDB> exit
[client]# mysql -uroot -p -h 192.168.0.100
MariaDB> select @@server_id;
+-------------+
| 10 | # 第二次落到 RS1，读负载均衡生效