CPU-BOUND,IO-BOUND(CPU密集,IO密集)
mysql既是CPU密集应用也是IO密集应用需考虑这个服务是有状态还是无状态 stateful stateless用户的身份识别是靠COOKIE的session是用于记录该用户的活动行为session的保持方式: session sticky 可以用ip hash实现 session replication session复制 session server 七层调度器转发时最大并发不超过4万 受限于端口数量 四层调度:百万级 在内核中实现 四层负载:lvs nginx(stream) haproxy(mode tcp) 七层负载:nginx haproxy, ATS ENVOY ,TRAFFIC 当检测到ip_port访问时(ipvs定义了那个端口加ip是集群,并且访问集群之后往后端转发) lvs 调度器模块(内置许多算法,根据用户配置的算法实现),将请求调度到后端服务器 基于ipvs框架实现 ipvsadmin 生成IPVS规则 ipvs规则附着在input链上,当ipvs发现某个请求是到,集群服务的,会强行拦截下来,及改变流向 ipvs支持十种调度算法 lsmod 列出本机的载入mokuai modinfo +模块名 查看模块详细信息 在/boot下配置文件中可以查看到ipvs执行的具体信息 静态算法:仅根据算法本身和 请求报文特征进行调度。 起点公平 rr roundrobin轮询 轮叫 轮调 轮训 将每个服务器权重作为数组的下标(这里权重是相等的) wrr 按照权重分配数组元素的个数 sh:source hash 源地址哈希 对源地址哈希之后对RS权重取模,然后按照数组下标来匹配 对5取模 0-4 6 0-5 缺点:多个内网共用一个公网IP dh:destination hash 目标地址哈希 对负载均衡地址哈希,对rs服务器权重 取模( 负载均衡后有正向代理,缓存机制) 动态算法:额外考虑后端的RS的当前负载状态(消耗资源多,速度慢 调度效果好) 结果公平 lc:最小链连数 默认权重相同 overhand(负载)=(活动链接数*256+非活动连接数)(为什么是256,因为默认活动连接数默认是非活动连接数的256倍平均值) wlc:加权最小连接 overhand(负 载)=(活动链接数*256+非活动连接数)/权重 sed 最短期望延迟 最短延迟调度 overhand= (活动连接+1)*256/权重 nq:永不排队/最少队列调度 先每个服务器分配一个,后面分配按照权重 lblc 基于本地的最少连接 基于dh+lc的复杂运算 LBLCR:带复制的基于本地的最少连接 lvs 的模式 dr 通过在ip报文外增加帧首部 源mac 与目标mac,是由调度算法挑选出的目标rs服务端的mac地址 (rs与负载均衡器必须在同一个二层网络中) rs的网关地址一定要只想负载均衡的dip地址 nat:多目标的DNAT 通常修改请求报文的源ip+port 经由调度算法转发至rs服务器端 fullnat :通过修改请求报文的源IP(cip - dip与目标ip完成调度(vip-rsip) tun 在原IP报文外再添加一个新的ip首部 IVS-NAT1 与DIP必须在同一个网络,且应使用私网地址,后端RS的网关必须指向DIP;2 请求报文与响应报文都必须经过Director转发;director易成为系统瓶颈;3 支持端口映射,可修改请求报文的目标IP;4 vs必须是Linux系统,rs可以是任意系统;IVS-DR1 通过请求报文重新封装一个MAc首部进行转发,源端口是dip所在的接口的mac',目标mac是挑选出的RIP所在接口的MAC地址,源ip/port,以及目标ip/port均保持不变。directors和各rs都得配置vip1 确保前端路由器将目标IP为vip的请求报文发往DIRECTORSa 在前端网关做静态绑定b 在rs上使用arpiptablesc在rs上修改内核参数以限制arp通告以及应答级别:arp_announcearp_ignore2 rs的rip可以是私网地址,也可以是公网地址,需要与dip在同一网段rip的网关不能指向dip3rs要与director要在同一个物理网络。4请求报文经由director,但相应不能经由director。而是由rs直接发往client5不支持端口映射 tun 异地容灾 就是在原有请求报文上增加一层新的ip(目标rip,源dip) 1 dip VIP rip 都应该是公网地址 vip可以是私网地址 2 rs 的网关不能,也不可能指向dip 3 请求报文经由directos,但响应报文不能经由director 4 不支持端口映射 5 rs的os需支持隧道功能ipvsadm ipvs规则: 实别集群服务: vip, port/tcp vip, port/udp FWMipvsamd -A追加 E修改 -D删除 -L查看 -C clear -R restore 重载 -S 保存 ipvsadm -A (-t|-u|-f) service-address -s(调度算法) -g gateway dr型号 -i ipip tun -m masquerade nat类型 启动脚本的存放地点;/usr/lib/systemd/system/ docker在启动之后,默认forward链的规则改为DROP,所以要开启转发就得 修改forward的默认规则 ExecStartPost=/usr/sbin/iptables -P FORWARD ACCEPT 在启动之后 ipvsadm -Ln 查看的参数,顺序不能乱 ipvsadm -A -t(tcp) 172.20.102.21:80(director) -s(调度算法) wrr 添加一个集群服务 pvsadm -L --rateipvsadm -a -t 172.20.102.21:80 -r 172.17.0.2:80 -m -w 1 将rs主机加入集群当中cps 每秒钟建立的连接数inPPS 每秒钟入栈的报文数outpps 出栈INbps 入栈字节数outbps 出栈字节数ipvsadm -Ln --stats 上面这些数据的总和ipvsadm -Z 是清楚这些数据ipvsadm -a -t 172.20.102.21:80 -r 172.17.0.2:80 -m -w 1 修改rs服务器的权重Cookie 是在 HTTP 协议下,服务器或脚本可以维护客户工作站上信息的一种方式。Cookie 是由 Web 服务器保存在用户浏览器(客户端)上的小文本文件,它可以包含有关用户的信息。无论何时用户链接到服务器,Web 站点都可以访问 Cookie 信息 [2] 。目前有些 Cookie 是临时的,有些则是持续的。临时的 Cookie 只在浏览器上保存一段规定的时间,一旦超过规定的时间,该 Cookie 就会被系统清除 [2] 。持续的 Cookie 则保存在用户的 Cookie 文件中,下一次用户返回时,仍然可以对它进行调用while true ; do curl 172.20.102.21 ;sleep .5 ;done 休眠0.5秒请求一次curl --connect-timeout 1 (允许超时时间为1s)dr 的详细过程:首先明白 数据包从哪块网卡出去,该包源地址为此网卡地址多网卡的主机ip与mac对应关系都会在路由上有相应记录,网卡都会通告和应答 目标地址vip 源地址cip的包通过路由器到达director,director修改此包的帧首部,将源mac改为本机的mac,目标mac为通过调度算法选择出来的其中之一rs的mac,这几台rs服务器 将回环地址绑定为vip通过三种方法阻止了此网卡的通告和应答,此rs解包之后,强制增加路由使其先经过lo地址在经由rip直接lvs可以当mysql读库的调度器调度器ssh会话卸载器 需支持七层将ipvs规则保存至/etc/sysconfig/ipvsadm 下次自动生效防火墙标记(端口亲缘性) :可以将多个服务捆绑成一个服务进行调度 用防火墙标记,意思 服务本来是轮询调度但是我将这两个ip+port绑定之后,本来是 访问80端口 轮询调度r1 r2 但是如果第二次是访问8080则相当于r2已经被调度过。总而言之,就是将服务捆绑在了一起。用sh哈希算法额能够实现会话保持的功能防火墙标记的作用::::::::::::::::::: iptables -t mangle -A PREROUTING -p tcp -m multiport --dports 80,8080 -j MARK --set-mark 7 标记 ipvsadm -A -f 7 -s sh 持久连接机制,是将请求的地址与所调度的地址记录成一张表,并附上过期时间,在此期间内只要是 此ip访问都会调度到同一rs服务端 ppc 用iptables规则绑定两个端口,再用持久连接实现。有限端口 pcc: ipvsadm -A -f 172.28.29.9:0(此处所有的端口在360秒内都会调度在同一rs ) -p (默认360)-s wrr选择后端服务器 所有端口modprobe -r +模块名 来拆除模块bash -n +脚本 检查语法错位实现会话保持 iptables + ipvs sh = iptables + ipvs -p wrr lvs无法对后端服务器做健康状态检测