LVS 项目知识点总结作业一、什么是集群Cluster1. 描述集群是指一组相互独立的计算机服务器通过高速网络连接作为一个整体对外提供服务。对于客户端来说访问集群就像访问一台高性能的服务器一样。集群系统通过多台服务器的协同工作提供了高可用性、高并发处理能力和可扩展性。2.步骤集群工作流程步骤 1客户端向集群的虚拟IPVIP发起服务请求。步骤 2调度器负载均衡器接收到请求。步骤 3调度器根据预设的算法将请求分发到后端的某一台真实服务器Real Server上。步骤 4后端服务器处理请求并将结果返回给客户端。二、集群分类1. 描述根据主要目的不同计算机集群通常分为三类高可用性集群High Availability Cluster, HA作用保证服务的连续性。当主节点宕机时备用节点能立即接管服务避免业务中断如双机热备。负载均衡集群Load Balancing Cluster, LBC作用将大量的用户访问请求分摊给多台服务器处理提高系统的整体响应速度和并发处理能力LVS 属于此类。高性能计算集群High Performance Computing Cluster, HPC作用利用多台服务器的计算能力进行复杂的科学计算、数据分析等任务如大数据处理、天气预报模拟。三、LVS 的作用1. 描述LVSLinux Virtual ServerLinux 虚拟服务器是 Linux 内核自带的负载均衡软件。它的核心作用是在 Linux 操作系统上构建一个高性能、高可用的负载均衡集群。负载均衡将客户端的请求分发到后端多台真实服务器RS。高可用性当后端某台服务器宕机时LVS 能够自动检测并将其剔除出集群不影响整体服务。性能提升利用多台服务器分担请求极大地提高了业务的并发处理能力。四、LVS 的4种模式及原理1. 描述LVS 主要有四种工作模式NAT、DR、TUN、FULLNAT。其中 DR 模式最常用。1LVS-NAT网络地址转换模式原理客户端请求到达 LVS调度器LVS 修改请求报文的目标 IP 地址VIP 改为 RIP转发给后端 RS。RS 处理完毕后将响应报文返回给 LVSLVS 再将源 IP 改为 VIP 返回给客户端。特点请求和响应都必须经过 LVSLVS 容易成为瓶颈。2LVS-DR直接路由模式原理LVS 只修改请求报文的目标 MAC 地址将请求直接转发给后端的 RS。RS 处理完毕后直接将响应报文返回给客户端不回传给 LVS。特点响应流量不经过 LVS性能极高是生产环境最常用的模式。要求 LVS 和 RS 必须在同一个物理网段。3LVS-TUN隧道模式原理LVS 将请求报文通过 IP 隧道IPIP封装转发给后端的 RS。RS 收到后解封装处理请求并直接返回响应给客户端。特点LVS 和 RS 可以不在同一个网段支持跨网段调度但开销较大。4LVS-FULLNAT完全 NAT 模式原理在 NAT 基础上不仅修改目标 IP还修改源 IPCIP 改为 LVS 的 IP。这样确保了请求和响应都能正常返回 LVS再转发给客户端。特点后端 RS 不需要配置网关指向 LVS部署更灵活但性能损耗较大。2.步骤DR 模式配置简要步骤步骤 1在 LVS 调度器上配置 VIP绑定在 lo 口或物理网卡上。步骤 2在 LVS 上配置 ipvsadm 规则设置 VIP 和调度算法。步骤 3在 RS 服务器上配置 VIP 绑定到 lo 口抑制 ARP 响应防止 VIP 冲突。步骤 4在 RS 服务器上配置内核参数arp_ignore和arp_announce禁止响应 VIP 的 ARP 请求。步骤 5验证访问测试负载均衡效果。五、LVS 的13种算法1. 描述LVS 的调度算法决定了调度器如何将新请求分配给后端的真实服务器RS。分为静态算法和动态算法两大类共 13 种。静态调度算法4种不考虑后端服务器的当前负载情况。RR轮询按顺序轮流分配。WRR加权轮询根据权重比例分配权重高的服务器获得更多请求。DH目标地址哈希根据请求的目标 IP 地址进行哈希分配相同目标 IP 始终发给同一台 RS。SH源地址哈希根据请求的源 IP 地址进行哈希分配相同客户端 IP 始终发给同一台 RS实现会话保持。动态调度算法9种根据后端服务器的实时负载情况动态分配。LC最小连接数分配当前连接数最少的 RS。WLC加权最小连接数在 LC 基础上加入权重计算(当前连接数 / 权重)最小的 RS 优先分配LVS 默认算法。SED最短期望延迟计算(当前连接数 1) / 权重选取值最小的 RS。NQ永不排队如果有空闲的 RS直接分配否则使用 SED 算法。LBLC基于本地的最少连接针对目标 IP 的调度尽量将相同目标 IP 的请求发给同一台 RS但如果该 RS 过载则找其他 RS。LBLCR带复制的本地最少连接在 LBLC 基础上如果某台 RS 负载过高可以将其承载的部分目标 IP 复制到其他 RS。DH目标地址哈希也属动态注意不同版本的归类有些将其归为基于目标地址的动态哈希。SH源地址哈希也属动态类似。MQ最低队列LVS 内核较少直接使用。(注实际常说的 RR、WRR、LC、WLC、SH、DH 等是核心算法13 种是统称)六、LVS 的多端口轮询问题解决方案1. 描述问题LVS 默认配置下ipvsadm 只能针对单一端口进行调度。如果后端服务器同时运行了多个服务如 Web 的 80 端口 和 HTTPS 的 443 端口我们需要分别配置两条规则。如果服务端口数量非常多例如几十个手动配置会非常繁琐且不容易维护。解决方案与步骤FWMARK 防火墙标记法步骤 1使用 iptables 的multiport模块将多个需要调度的目标端口如 80, 443打上一个相同的防火墙标记例如--set-mark 10。步骤 2在 ipvsadm 中不绑定具体的端口而是使用-f参数绑定这个防火墙标记号例如ipvsadm -A -f 10。步骤 3添加后端真实服务器时端口指定为0表示由标记决定。效果一个规则管理了所有端口的流量实现了多端口统一轮询。七、LVS 的会话粘滞解决方案1. 描述问题用户在访问网站时通常会产生会话状态Session例如登录状态、购物车信息等。如果使用轮询RR等算法用户第一次请求到了服务器 A第二次请求被分发到了服务器 B由于服务器 B 没有该用户的 Session用户会被迫重新登录导致体验极差。这就是“会话粘滞Session Sticky”问题。2.解决方案与步骤方案一使用 LVS 的源地址哈希算法SH步骤 1在 LVS 配置中将调度算法设置为shSource Hashing。步骤 2配置好后同一个客户端 IP 的所有请求都会被哈希算法固定分发到同一台真实服务器上从而保证 Session 不丢失。缺点如果该服务器宕机用户的 Session 还是会丢失虽然此时会切换到其他服务器。方案二统一会话存储Redis/Session 共享更推荐步骤 1在后端所有的 Web 服务器如 Tomcat、PHP中不将 Session 存放在本地内存。步骤 2搭建一个独立的 Redis 或 Memcached 缓存集群。步骤 3将所有服务器的 Session 存储全部指向这个统一的 Redis 集群如修改 Tomcat 的context.xml配置。步骤 4这样无论 LVS 将请求分配给哪一台 Web 服务器服务器都能从同一个 Redis 中读取到用户的 Session 数据。优点彻底解决了 LVS 调度带来的会话问题即使某一台服务器坏掉用户的登录状态依然不受影响。