一、什么是集群集群是为了解决某个特定问题将多台计算机组合起来形成的单个系统二、集群分类负载均衡集群 LBLoad Balancing 多台服务器共同处理业务请求调度器分发流量每个主机只承担一部分访问。代表LVS、Nginx、HAProxy。高可用集群 HAHigh Availability 解决单点故障主备切换。代表Keepalived、Pacemaker。高性能集群 HPC高性能计算 多节点协同完成复杂计算任务多用于科学运算。三、lvs的作用作为调度器接收客户端请求将请求分发到后端真实服务器RealServerRS基于内核 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 -m1.lvs-nat修改请求报文的目标IP多目标IP的DNAT原理四层 DNAT入站、出站流量全部经过 VSa.客户端CIP → VIP 请求到达 VSb.VS 修改目标 IPCIP → RIP转发给 RSc.RS 处理回包RIP → CIPRS 网关必须指向 VS 的 DIPd,VS 修改源 IPVIP → CIP发回客户端2.lvs-dr操纵封装新的MAC地址原理只修改二层 MAC 地址三层 IP 完全不变响应报文不经过 VSa.客户端请求CIP → VIP 到达 VSb.VS不改 IP只改写目标 MAC把包转发给选中 RSc.RS 收到数据包IP 依然是CIP→VIP RS 本地lo 回环网卡绑定 VIP并抑制 ARP 广播防止 VIP 冲突d.RS 直接回复客户端VIP → CIP不再经过 VS3.lvs-tum在原请求IP报文之外新加一个IP首部原理:IPIP 隧道封装跨网段版本的 DRa.客户端 CIP→VIP 到达 VSb.VS在外层新增一层 IP 包头外层DIP→RIP内层保留原始CIP→VIP报文c.通过 IP 隧道发给 RSd.RS 解封装读取内层CIP→VIP报文处理e.RS 直接回复客户端VIP→CIP不经过 VS4.lvs-fullnat原理:同时修改源 IP 目标 IPa.请求包CIP → VIP VS 修改源 IP 改为 DIP目标 IP 改为 RIP → DIP → RIPb.RS 回包RIP → DIP网关不需要指向 VSc.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 当前的负载状态及调度算法进行调度 Overheadvalue 较小的 RS 将被调度1.LC 最小连接适用于长连接应用 Overhead负载值activeconns活动链接数×256 inactiveconns非活动链接数2.WLC 加权最小连接【默认算法】默认调度方法 Overhead(activeconns × 256inactiveconns)/weight3。LBLC 基于本地的最小连接Locality-Based LC动态的 DH 算法使用场景根据负载状态实现正向代理4.LBLCR 带复制的 LBLCLBLC with Replication带复制功能的 LBLC解决 LBLC 负载不均衡问题从负载重的复制到负载轻的 RS5.SED 最短期望延迟初始连接高权重优先 Overhead(activeconns1inactiveconns) × 256/weight 但是当 node1 的权重为 1node2 的权重为 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随后标记进行负载[rootvsnode boot]# ipvsadm -A -t 192.168.188.200:80 -s rr [rootvsnode boot]# ipvsadm -a -t 192.168.188.200:80 -r 192.168.188.20 -g [rootvsnode boot]# ipvsadm -a -t 192.168.188.200:80 -r 192.168.188.10 -g [rootvsnode boot]# ipvsadm -A -t 192.168.188.200:443 -s rr [rootvsnode boot]# ipvsadm -a -t 192.168.188.200:443 -r 192.168.188.10:443 -g [rootvsnode boot]# ipvsadm -a -t 192.168.188.200:443 -r 192.168.188.20:443 -g [rootvsnode boot]# iptables -t mangle -A PREROUTING -d 192.168.188.200 -p tcp -m multiport --dports 80,443 -j MARK --set-mark 6666 [rootvsnode boot]# ipvsadm -A -f 6666 -s rr [rootvsnode boot]# ipvsadm -a -f 6666 -r 192.168.188.10 -g [rootvsnode boot]# ipvsadm -a -f 6666 -r 192.168.188.20 -g4.验证[rootclient ~]# 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否则登录状态丢失。方案1LVS SH源地址哈希四层原生方案调度算法修改为SH同一个客户端IP始终调度至同一台Real Server。弊端局域网大量用户出口同一个公网IP流量分配不均。方案2持久连接模板 ipvs persistenceLVS持久化设置persistence_timeout超时时间。指定时间内同一客户端IP持续调度到同一RS。ipvsadm -A -f 6666 -s rr -p 1方案3七层层实现会话保持NginxLVS只做四层转发上层Nginx依靠Cookie、ip实现会话绑定。灵活性最高。方案4业务架构改造业务无状态化session统一放入Redis/共享存储。不再依赖会话粘滞集群扩容、故障转移更加平滑大型互联网标准方案。