一、什么是集群

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

二、集群分类

负载均衡集群 LB（Load Balancing） 多台服务器共同处理业务请求，调度器分发流量每个主机只承担一部分访问。代表：LVS、Nginx、HAProxy。

高可用集群 HA（High Availability） 解决单点故障，主备切换。代表：Keepalived、Pacemaker。

高性能集群 HPC（高性能计算） 多节点协同完成复杂计算任务，多用于科学运算。

三、lvs的作用

作为调度器，接收客户端请求，将请求分发到后端真实服务器（RealServer，RS）

基于内核 ipvs 模块，性能极高，支持几十万并发连接

不处理应用层数据，只转发数据包 ，无应用层瓶颈

实现后端服务器集群对外统一提供服务

四、lvs的4种模式及原理

echo 1 > /proc/sys/net/ipv4/ip_forward​ ipvsadm -A -t 172.25.254.100:80 -s rr ipvsadm -a -t 172.25.254.100:80 -r 172.25.254.10:80 -m ipvsadm -a -t 172.25.254.100:80 -r 172.25.254.11:80 -m

1.lvs-nat

修改请求报文的目标IP，多目标IP的DNAT

原理：四层 DNAT，入站、出站流量全部经过 VS

a.客户端：CIP → VIP 请求到达 VS

b.VS 修改目标 IP：CIP → RIP，转发给 RS

c.RS 处理，回包：RIP → CIP（RS 网关必须指向 VS 的 DIP！）

d,VS 修改源 IP：VIP → CIP，发回客户端

2.lvs-dr

操纵封装新的MAC地址

原理：只修改二层 MAC 地址，三层 IP 完全不变；响应报文不经过 VS

a.客户端请求：CIP → VIP 到达 VS

b.VS不改 IP，只改写目标 MAC，把包转发给选中 RS

c.RS 收到数据包：IP 依然是CIP→VIP； RS 本地lo 回环网卡绑定 VIP，并抑制 ARP 广播，防止 VIP 冲突

d.RS 直接回复客户端：VIP → CIP，不再经过 VS

3.lvs-tum

在原请求IP报文之外新加一个IP首部

原理:IPIP 隧道封装，跨网段版本的 DR

a.客户端 CIP→VIP 到达 VS

b.VS在外层新增一层 IP 包头：外层DIP→RIP，内层保留原始CIP→VIP报文

c.通过 IP 隧道发给 RS

d.RS 解封装，读取内层CIP→VIP报文处理

e.RS 直接回复客户端VIP→CIP，不经过 VS

4.lvs-fullnat

原理:同时修改源 IP + 目标 IP

a.请求包：CIP → VIP VS 修改：源 IP 改为 DIP，目标 IP 改为 RIP → DIP → RIP

b.RS 回包：RIP → DIP（网关不需要指向 VS）

c.VS 再次转换：源 IP 改 VIP，目标 IP 改 CIP → VIP → CIP

五、lvs的13种算法

分为静态算法（不考虑 RS 负载）、动态算法（感知连接数）

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

RR 轮询：roundrobin 轮询 RS 分别被调度，当 RS 配置有差别时不推荐

WRR 加权轮询：Weighted RR，加权轮询根据 RS 的配置进行加权调度，性能差的 RS 被调度的次数少

DH 目标地址哈希：Destination Hashing；目标地址哈希，第一次轮询调度至 RS，后续将发往同一个目标地址的请求始终转发至第一次挑中的 RS，典型使用场景是正向代理缓存场景中的负载均衡，如：宽带运营商

SH 源地址哈希：Source Hashing，实现 session sticky，源 IP 地址 hash；将来自于同一个 IP 地址的请求始终发往第一次挑中的 RS，从而实现会话绑定

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

1.LC 最小连接：适用于长连接应用 Overhead（负载值）=activeconns（活动链接数）×256 + inactiveconns（非活动链接数）

2.WLC 加权最小连接【默认算法】：默认调度方法 Overhead=(activeconns × 256+inactiveconns)/weight

3。LBLC 基于本地的最小连接：Locality-Based LC，动态的 DH 算法，使用场景：根据负载状态实现正向代理

4.LBLCR 带复制的 LBLC：LBLC with Replication，带复制功能的 LBLC，解决 LBLC 负载不均衡问题，从负载重的复制到负载轻的 RS

5.SED 最短期望延迟：初始连接高权重优先 Overhead=(activeconns+1+inactiveconns) × 256/weight 但是，当 node1 的权重为 1，node2 的权重为 10，经过运算前几次的调度都会被 node2 承接

6.NQ 永不排队：Never Queue，第一轮均匀分配，后续 SED

在 4.15 版本内核以后新增调度算法

1.FO (Weighted Fair Over) 调度算法：常用作灰度发布 在此 FO 算法中，遍历虚拟服务所关联的真实服务器链表，找到还未过载 (未设置 IP_VS_DEST_F_OVERLOAD 标志) 的且权重最高的真实服务器，进行调度

当服务器承接大量链接，我们可以对此服务器进行过载标记（IP_VS_DEST_F_OVERLOAD），那么 vs 调度器就不会把链接调度到有过载标记的主机中。

2.OVF (Overflow-connection) 调度算法 基于真实服务器的活动连接数量和权重值实现。将新连接调度到权重值最高的真实服务器，直到其活动连接数量超过权重值，之后调度到下一个权重值最高的真实服务器，在此 OVF 算法中，遍历虚拟服务相关联的真实服务器链表，找到权重值最高的可用真实服务器。一个可用的真实服务器需要同时满足以下条件：

1.未过载 (未设置 IP_VS_DEST_F_OVERLOAD 标志)
2.真实服务器当前的活动连接数量小于其权重值
3.其权重值不为零
3.MH

对客户端源 IP 进行哈希计算，选出哈希值最小的、可用、未过载的 RS 分发请求。

六、LVS 多端口轮询问题 + 解决方案
1. 在rs主机中同时开始http和https两种协议

2.如果完成设定后http和https都是独立的service，会出现重复问题

3.当同时开启http和https服务，利用防火墙对于80端口和443端口的访问流量做标记，设定标记为6666，随后标记进行负载

[root@vsnode boot]# ipvsadm -A -t 192.168.188.200:80 -s rr [root@vsnode boot]# ipvsadm -a -t 192.168.188.200:80 -r 192.168.188.20 -g [root@vsnode boot]# ipvsadm -a -t 192.168.188.200:80 -r 192.168.188.10 -g [root@vsnode boot]# ipvsadm -A -t 192.168.188.200:443 -s rr [root@vsnode boot]# ipvsadm -a -t 192.168.188.200:443 -r 192.168.188.10:443 -g [root@vsnode boot]# ipvsadm -a -t 192.168.188.200:443 -r 192.168.188.20:443 -g [root@vsnode boot]# iptables -t mangle -A PREROUTING -d 192.168.188.200 -p tcp -m multiport --dports 80,443 -j MARK --set-mark 6666 [root@vsnode boot]# ipvsadm -A -f 6666 -s rr [root@vsnode boot]# ipvsadm -a -f 6666 -r 192.168.188.10 -g [root@vsnode boot]# ipvsadm -a -f 6666 -r 192.168.188.20 -g

4.验证

[root@client ~]# curl 192.168.0.200;curl -k https://192.168.0.200 RS2 - 192.168.0.20 RS1 - 192.168.0.10

七、LVS会话粘滞（会话保持）解决方案
什么场景需要会话保持？

传统Web业务session保存在本机，用户连续多次请求必须访问同一台RS，否则登录状态丢失。

方案1：LVS SH源地址哈希（四层原生方案）

调度算法修改为SH，同一个客户端IP始终调度至同一台Real Server。

弊端：局域网大量用户出口同一个公网IP，流量分配不均。

方案2：持久连接模板 ipvs persistence（LVS持久化）

设置persistence_timeout超时时间。指定时间内，同一客户端IP持续调度到同一RS。

ipvsadm -A -f 6666 -s rr -p 1

方案3：七层层实现会话保持（Nginx）

LVS只做四层转发，上层Nginx依靠Cookie、ip实现会话绑定。灵活性最高。

方案4：业务架构改造

业务无状态化，session统一放入Redis/共享存储。

不再依赖会话粘滞，集群扩容、故障转移更加平滑，大型互联网标准方案。