1.什么是集群LVS全称Linux Virtual Server,是Linux内核层实现的高性能高可用的负载均衡集群技术。它的核心作用是将前端的请求流量分到后端多台真实服务器上从而提升服务的并发处理能力和可用性。2.集群分类Cluster常见的三种类型LBLoadBalancing负载均衡由多个主机组成每个主机只承担一部分访问HAHigh Availiablity高可用SPOFsingle Point Of failureMTBF:Mean Time Between Failure平均无故障时间正常时间MTTR:Mean Time To Restorationrepair平均恢复前时间故障时间AMTBF/MTBFMTTR(0,1)99%, 99.5%, 99.9%, 99.99%, 99.999%SLAService level agreement服务等级协议是在一定开销下为保障服务的性能和可用性服务提供商与用户间定义的一种双方认可的协定。通常这个开销是驱动提供服务质量的主要因素。在常规的领域中总是设定所谓的三个9四个9来进行表示当没有达到这种水平的时候就会有一些列的惩罚措施而运维最主要的目标就是达成这种服务水平。停机时间又分为两种一种是计划内停机时间一种是计划外停机时间而运维则主要关注计划外停机时间HPCHigh-performance computing高性能计算国家战略资源不在课程范围内3.lvs的作用核心作用把海量客户端请求分发到后端多台真实业务服务器实现集群负载均衡、高可用。1. 流量负载均衡最核心接收用户所有访问请求按照调度算法分发给后端 RS真实服务器 Real Server。避免单台服务器压力过载分摊 CPU、内存、网络流量提升集群整体并发承载能力。支持百万级并发连接性能极高内核态转发无应用层损耗。2. 统一虚拟 IP 对外服务集群只暴露一个VIP 虚拟 IP给客户端用户只访问 VIP感知不到后端多台机器 后端服务扩容 / 缩容对前端完全透明不用改客户端配置。3. 故障自动剔除保障高可用健康检查后端服务器某台 RS 宕机、服务崩溃时LVS 自动把它从集群摘除不再转发流量故障恢复后自动重新加入集群业务无感知减少中断时间。4. 屏蔽后端服务细节、便于扩容业务增长时直接新增后端服务器接入 LVS无需改动前端、域名 支持横向无限扩展适合网站、数据库、中间件集群。5. 高性能四层转发低消耗运行在 Linux 内核不拆解 HTTP 等七层报文只处理 IP 端口CPU 占用极低 对比 Nginx 七层负载大流量场景吞吐量、并发能力远超七层代理。4.lvs的4种模式及原理lvs集群的类型lvs-nat 修改请求报文的目标IP,多目标IP的DNATlvs-dr操纵封装新的MAC地址lvs-tun 在原请求IP报文之外新加一个IP首部lvs-fullnat修改请求报文的源和目标IP1.nat模式1lvs-nat:本质是多目标IP的DNAT通过将请求报文中的目标地址和目标端口修改为某挑出的RS的RIP和PORT实现转发RIP和DIP应在同一个IP网络且应使用私网地址;RS的网关要指向DIP请求报文和响应报文都必须经由Director转发Director易于成为系统瓶颈支持端口映射可修改请求报文的目标PORTVS必须是Linux系统RS可以是任意OS系统2nat模式原理1.客户端发送访问请求请求数据包中含有请求来源cip访问目标地址VIP访问目标端口9000port2.VS服务器接收到访问请求做DNAT把请求数据包中的目的地由VIP换成RS的RIP和相应端口3.RS1相应请求发送响应数据包包中的相应保温为数据来源RIP1响应目标CIP相应端口9000port4.VS服务器接收到响应数据包改变包中的数据来源RIP1--VIP,响应目标端口9000--805.VS服务器把修改过报文的响应数据包回传给客户端6.lvs的NAT模式接收和返回客户端数据包时都要经过lvs的调度机所以lvs的调度机容易阻塞2.DR模式1DRDRDirect Routing直接路由LVS默认模式,应用最广泛,通过为请求报文重新封装一个MAC首部进行转发源MAC是DIP所在的接口的MAC目标MAC是某挑选出的RS的RIP所在接口的MAC地址源IP/PORT以及目标IP/PORT均保持不变2DR模式的原理1.客户端发送数据帧给vs调度主机帧中内容为客户端IP客户端的MACVIPVIP的MAC2.VS调度主机接收到数据帧后把帧中的VIP的MAC该为RS1的MAC此时帧中的数据为客户端IP客户端的MACVIPRS1的MAC3.RS1得到2中的数据包做出响应回传数据包数据包中的内容为VIPRS1的MAC客户端IP客户端IP的 MAC3DR模式的特点1.Director和各RS都配置有VIP2.确保前端路由器将目标IP为VIP的请求报文发往Director3.在前端网关做静态绑定VIP和Director的MAC地址在RS上使用arptables工具arptables -A IN -d $VIP -j DROP arptables -A OUT -s $VIP -j mangle --mangle-ip-s $RIP在RS上修改内核参数以限制arp通告及应答级别/proc/sys/net/ipv4/conf/all/arp_ignore /proc/sys/net/ipv4/conf/all/arp_announce4.RS的RIP可以使用私网地址也可以是公网地址RIP与DIP在同一IP网络5.RIP的网关不能指向DIP以确保响应报文不会经由Director6.RS和Director要在同一个物理网络7.请求报文要经由Director但响应报文不经由Director而由RS直接发往Client8.不支持端口映射端口不能修败9.RS可使用大多数OS系统3.TUN模式了解转发方式不修改请求报文的IP首部源IP为CIP目标IP为VIP而在原IP报文之外再封装一个IP首部源IP是DIP目标IP是RIP将报文发往挑选出的目标RSRS直接响应给客户端源IP是VIP目标IP 是CIP1TUN模式的原理1.客户端发送请求数据包包内有源IPvipdport2.到达vs调度器后对客户端发送过来的数据包重新封装添加IP报文头新添加的IP报文头中包含TUNSRCIP(DIP)TUNDESTIP(RSIP1)并发送到RS13.RS收到VS调度器发送过来的数据包做出响应生成的响应报文中包含SRCIP(VIP)DSTIPCIP port响应数据包通过网络直接回传给client2TUN模式特点1.DIP, VIP, RIP都应该是公网地址2.RS的网关一般不能指向DIP3.请求报文要经由Director但响应不能经由Director4.不支持端口映射5.RS的OS须支持隧道功能4.fullnet模式了解fullnat通过同时修改请求报文的源IP地址和目标IP地址进行转发CIP -- DIPVIP -- RIP1.VIP是公网地址RIP和DIP是私网地址且通常不在同一IP网络因此RIP的网关一般不会指向DIP2.RS收到的请求报文源地址是DIP因此只需响应给DIP但Director还要将其发往Client3.请求和响应报文都经由Director4.支持端口映射注意此类型kernel默认不支持5.lvs的13种算法LVS 调度器分为静态算法4 种、动态算法9 种合计 13 种。 静态不看后端服务器实时负载只按固定规则分发 动态根据 RS 当前连接数、负载权重实时调整分发。一、静态调度算法4 个1. rr 轮询 Round Robin原理请求依次轮流分给每台 RS权重全部均等。 适用所有后端服务器硬件性能完全一致。2. wrr 加权轮询 Weighted RR原理给 RS 配置权重权重越大分到的请求越多。 例A 权重 3、B 权重 1顺序A A A B 循环分发。 适用服务器配置高低不齐。3. dh 目标地址哈希 Destination Hashing原理对客户端访问的目标 IPVIP 端口做哈希固定映射一台 RS。 适用缓存集群同一后端缓存同一资源。4. sh 源地址哈希 Source Hashing原理对客户端源 IP哈希同一用户永远分配到同一 RS。 作用简易会话保持无额外会话存储。二、动态调度算法9 个5. lc 最小连接 Least Connections原理实时统计每台 RS 活跃连接数新请求分给当前连接最少的服务器。 适用长连接业务数据库、ssh。6. wlc 加权最小连接 Weighted LC线上默认最常用公式活跃连接数 / 权重比值越小越优先分配。 兼顾连接数与硬件性能生产环境主流算法。7. lblc 基于本地的最小连接 Locality-Based LC原理结合源 IP 哈希 最小连接。先对客户端 IP 哈希绑定固定 RS若该 RS 负载过高则重新选连接最少的空闲 RS。 适用缓存服务集群。8. lblcr 带复制的本地最小连接 Locality-Based LC with Replication在 lblc 基础上增加缓存复制 同一源 IP 的请求允许分发至多台 RS 缓存副本缓解单台缓存压力。9. sed 最短预期延迟 Shortest Expected Delay计算公式(活跃连接数 1) / 权重对比 wlc会优先给低连接机器分配新请求延迟更低。10. nq 永不排队 Never Queue基于 sed 优化存在 RS 活跃连接 0直接分配空闲机器无空闲机器再使用 sed 算法计算分配。 减少排队等待短连接业务性能更好。11. lbcs 基于连接数的本地最小连接 Locality-Based Connection Scheduling源 IP 哈希绑定 RS同时对比多候选 RS 的连接数均衡度优于 lblc。12. mh 多目标哈希 Multiple Destination Hashing支持对多个目标 IP / 端口做哈希调度适配多 VIP、多后端服务场景。13. fo 加权容差 Weighted Fair Overflow带过载阈值机制 当 RS 连接数超过设定阈值自动溢出分流到其他后端防止单台打满。6.lvs的多端口轮询问题解决方案利用火墙标记解决轮询错误1.在rs主机中同时开始http和https两种协议#在RS1和RS2中开启https [rootRS1RS2 ~]# dnf install mod_ssl -y [rootRS1RS2 ~]# systemctl restart httpd [rootRS1RS2 ~]# systemctl restart httpd2.在vsnode中添加https的轮询策略rootvsnode boot]# ip^Cadm -A -t 192.168.0.200:80 -s rr [rootvsnode boot]# ipvsadm -a -t 192.168.0.200:80 -r 192.168.0.20 -g [rootvsnode boot]# ipvsadm -a -t 192.168.0.200:80 -r 192.168.0.10 -g [rootvsnode boot]# ipvsadm -A -t 192.168.0.200:443 -s rr [rootvsnode boot]# ipvsadm -a -t 192.168.0.200:443 -r 192.168.0.10:443 -g [rootvsnode boot]# ipvsadm -a -t 192.168.0.200:443 -r 192.168.0.20:443 -g [rootvsnode boot]# ipvsadm -Ln IP Virtual Server version 1.2.1 (size4096) 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:4433.轮询错误展示[rootclient ~]# curl 192.168.0.200;curl -k https://192.168.0.200 RS2 - 192.168.0.20 RS2 - 192.168.0.20 #当上述设定完成后http和https是独立的service轮询会出现重复问题解决方案使用火墙标记访问vip的80和443的所有数据包设定标记为6666然后对此标记进行负载[rootvsnode boot]# iptables -t mangle -A PREROUTING -d 192.168.0.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.0.10 -g [rootvsnode boot]# ipvsadm -a -f 6666 -r 192.168.0.20 -g #测试在客户端 [rootclient ~]# curl 192.168.0.200;curl -k https://192.168.0.200 RS2 - 192.168.0.20 RS1 - 192.168.0.107.lvs的会话粘滞解决方案在我们客户上网过程中有很多情况下需要和服务器进行交互客户需要提交响应信息给服务器如果单 纯的进行调度会导致客户填写的表单丢失为了解决这个问题我们可以用sh算法但是sh算法比较简单 粗暴可能会导致调度失衡1解决方案在进行调度时不管用什么算法只要相同源过来的数据包我们就把他的访问记录在内存中也就是把 这个源的主机调度到了那个RS上如果在短期默认360S内同源再来访问我仍然按照内存中记录的调度信息把这个源的访问还调度到同一台RS上。如果过了比较长的时间默认最长时间360s同源访问再次来访那么就会被调度到其他的RS上ipvsadm -AlE -tlulf service-address [-s scheduler] [-p [timeout]]默认360秒 在lvs调度器中设定 [rootlvs ~]# ipvsadm -E -f 6666 -s rr -p [3000] [rootlvs ~]# ipvsadm -LnC2利用持久连接实现会话粘滞1.设定ipvs调度策略[rootvsnode ~]# ipvsadm -A -f 6666 -s rr -p 1 [rootvsnode ~]# ipvsadm -Ln IP Virtual Server version 1.2.1 (size4096) 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:02.测试[rootclient ~]# curl 192.168.0.200 RS1 - 192.168.0.10 [rootclient ~]# curl 192.168.0.200 RS1 - 192.168.0.103.观察[rootvsnode ~]# 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