1.什么是集群
将多台独立服务器通过网络组合成一个整体对外提供服务，对外表现为单一系统。集群中，每一台服务器实现的功能没有差别，数据和代码都是一样的。客户端访问集群时，感知不到后端多台真实服务器。
2.集群分类
-
负载均衡集群 LB（Load Balancing）
由多个主机组成，每个主机只承担一部分访问
作用：将用户流量分发至后端多台服务器，提高并发。
-
高可用集群 HA（High Availability）
作用：解决单点故障，主节点宕机自动切换至备节点。
MTBF: 平均无故障时间，正常时间
MTTR:平均恢复前时间，故障时间
A=MTBF/（MTBF+MTTR） (0,1)：99%, 99.5%, 99.9%, 99.99%, 99.999%
SLA：（服务等级协议）是在一定开销下为保障服务的性能和可用性，服务提供商与用户间定义的一种双方认可的协定。通常这个开销是驱动提供服务质量的主要因素。在常规的领域中，总是设定所谓的三个9，四个9来进行表示，当没有达到这种水平的时候，就会有一些列的惩罚措施，而运维，最主要的目标就是达成这种服务水平。
停机时间又分为两种，一种是计划内停机时间，一种是计划外停机时间，而运维则主要关注计划外
-
高性能集群 HPC（High Performance Computing）
作用：将大型计算任务拆分给多服务器并行运算，多用于科学计算。
3.lvs的作用
LVS:（Linux Virtual Server），负载调度器，内核集成，由章文嵩博士开发，工作在 Linux 内核层（IPVS 模块），是四层负载均衡。
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 核心作用
- 四层（传输层 TCP/UDP）负载均衡调度，性能极高；
- 将客户端请求分发至后端多台真实服务器（Real Server，RS）；
- 屏蔽后端服务器拓扑，客户端仅访问虚拟 IP（VIP）；
- 配合 Keepalived 实现调度器自身高可用，消除调度器单点故障。
4.lvs的4种模式及原理
VS-NAT 网络地址转换模式
lvs-nat:
- 本质是多目标IP的DNAT，通过将请求报文中的目标地址和目标端口修改为某挑出的RS的RIP和PORT实现转发
- RIP和DIP应在同一个IP网络，且应使用私网地址;RS的网关要指向DIP
- 请求报文和响应报文都必须经由Director转发，Director易于成为系统瓶颈
- 支持端口映射，可修改请求报文的目标PORT
- VS必须是Linux系统，RS可以是任意OS系统
nat模式数据逻辑:
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的调度机容易阻塞
VS-DR 直接路由模式（生产最常用）
DR：Direct Routing，直接路由，LVS默认模式,应用最广泛,通过为请求报文重新封装一个MAC首部进行转发，源MAC是DIP所在的接口的MAC，目标MAC是某挑选出的RS的RIP所在接口的MAC地址；源IP/PORT，以及目标IP/PORT均保持不变
DR模式数逻辑
在DR模式中，RS接收到访问请求后不需要回传给VS调度器，直接把回传数据发送给client，所以RS和vs
上都要有vip
DR模式数据传输过程
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
VS-TUN IP 隧道模式(了解)
转发方式：不修改请求报文的IP首部（源IP为CIP，目标IP为VIP），而在原IP报文之外再封装一个IP首部（源IP是DIP，目标IP是RIP），将报文发往挑选出的目标RS；RS直接响应给客户端（源IP是VIP，目标IP是CIP）
VS-FULLNAT 模式（了解）
fullnat：通过同时修改请求报文的源IP地址和目标IP地址进行转发
CIP --> DIP
VIP --> RIP
1.VIP是公网地址，RIP和DIP是私网地址，且通常不在同一IP网络；因此，RIP的网关一般不会指向DIP
2.RS收到的请求报文源地址是DIP，因此，只需响应给DIP；但Director还要将其发往Client
3.请求和响应报文都经由Director
4.支持端口映射
5.lvs的13种算法
静态调度算法
1、RR：（roundrobin)轮询 RS分别被调度，请求依次轮流分配给后端所有 RS，当RS配置有差别时不推荐
2、WRR：(Weighted RR) 加权轮询根据RS的配置进行加权调度，权重越高分到请求越多，性能差的RS被调度的次数少
3、SH：(Source Hashing) 实现session sticky，源IP地址hash；将来自于同一个IP地址的请求始终发往第一次挑中的RS，从而实现会话绑定，也就是对客户端源 IP 做 hash；同一客户端 IP 永远调度至同一 RS
4、DH：（Destination Hashing）目标地址哈希，第一次轮询调度至RS，后续将发往同一个目标地址的请
求始终转发至第一次挑中的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 加权故障转移 Faulty Overflow
遍历寻找未过载、权重最高的节点；灰度发布、故障隔离场景。
8、OVF 溢出调度 Overflow
高权重服务器连接数到达权重阈值后，新流量溢出分配至下一台 RS。
9、MH多目标哈希 Multicast Hashing
支持端口 + IP 组合哈希，多用于 UDP 会话调度。
6.lvs的多端口轮询问题解决方案
问题描述
业务同时开放多个端口（80、443），如果分别创建多条 VS 规则，LVS 会对每个端口独立轮询；造成同一用户访问不同端口被调度到不同 RS。
例：用户访问 80 分配 RS1，访问 443 分配 RS2，业务如果依赖会话会出错。
解决方案：防火墙标记
利用 iptables mangle 表对同一业务所有端口数据包打上相同标记，基于标记创建一条统一的虚拟服务，所有端口共享同一套调度规则。
1.在rs主机中同时开启http和https两种协议
#在RS1和RS2中开启https
[root@RS1+RS2 ~]# dnf install mod_ssl -y
[root@RS1+RS2 ~]# systemctl restart httpd
[root@RS1+RS2 ~]# systemctl restart httpd2.在vsnode中添加https的轮询策略
bash
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
[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
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP 192.168.0.200:80 rr
-> 192.168.0.10:80 Route 1 0 0
-> 192.168.0.20:80 Route 1 0 0
TCP 192.168.0.200:443 rr
-> 192.168.0.10:443 Route 1 0 0
-> 192.168.0.20:443 解决方案：使用火墙标记访问vip的80和443的所有数据包，设定标记为6666，然后对此标记进行负载
bash
[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
[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
#测试：在客户端
[root@client ~]# curl 192.168.0.200;curl -k https://192.168.0.200
RS2 - 192.168.0.20
RS1 - 192.168.0.107.lvs的会话粘滞解决方案
利用持久连接实现会话粘滞
1.设定ipvs调度策略
bash
[root@vsnode ~]# ipvsadm -A -f 6666 -s rr -p 1
[root@vsnode ~]# ipvsadm -Ln
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
FWM 6666 rr persistent 1
-> 192.168.0.10:0 Route 1 0 0
-> 192.168.0.20:0 2.测试：
bash
[root@client ~]# curl 192.168.0.200
RS1 - 192.168.0.10
[root@client ~]# curl 192.168.0.200
RS1 - 192.168.0.103.观察:
bash
[root@vsnode ~]# watch -n 1 ipvsadm -Lnc
IPVS connection entries
pro expire state source virtual destination
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
TCP 01:54 FIN_WAIT 172.25.254.99:46216 192.168.0.200:80 192.168.0.20:80
TCP 01:55 FIN_WAIT 172.25.254.99:46222 192.168.0.200:80 192.168.0.20:80