集群
简介
如何提升服务器性能
-
增加服务器硬件如CPU、内存或换配置更高的服务器来提升单机的性能
- 很快会达到瓶颈, 而且成本和性能不成正比
-
应用分离，如主机A(Apache) + 主机B(MySQL)
- 依然会达到瓶颈
-
采用集群技术
-
LB
- Load Balancing负载均衡
- 即多个服务器同时提供相同的服务,并分担压力,至少三台服务器
-
HA
- High Availability高可用
- 又称双机Active/Standby,即一个提供服务,另一个保持等待状态,至少两台服务器
-
HPC
- High Performance Computing高性能计算
- 高性能集群上运行的应用程序一般使用并行算法,把一个大的普通问题根据一定的规则分为许多小的子问题,在集群内的不同节点上进行计算,而这些小问题的处理结果,经过处理可合并为原问题的最终结果
-
整个集群提供一个唯一的访问入口,对最终用户透明
-
HA集群
-
1.keepalived
- 基于vrrp协议,常用于实现前端调度器的高可用, 轻量级, 不需要共享存储
-
2.corosync+pacemaker
- 实现的是Service的高可用, 需要共享存储, 一般用于多个节点
-
3.Heartbeat
- 是基于主机或网络的服务的高可用方式, 不常用
LB集群
-
硬件
- F5 BIG-IP。性能好,成本高
-
软件
- LVS、Nginx、Haproxy、SLB
LB集群
LVS
- 抗负载能力强、性能高,能达到F5硬件的60%；对内存和cpu资源消耗比较低
- 工作在网络4层,通过vrrp协议转发(仅作分发之用),具体的流量由linux内核处理,因此没有流量的产生
- 稳定性、可靠性好,自身有完美的热备方案；(如：LVS+Keepalived)
- 应用范围比较广,可以对所有应用做负载均衡
- 不支持正则处理,不能做动静分离
- 支持负载均衡算法：rr(轮循)、wrr(带权轮循)、lc(最小连接)、wlc(权重最小连接)
- 配置复杂,对网络依赖比较大
Nginx
- 工作在网络的7层之上,可以针对http应用做一些分流的策略,比如针对域名、目录结构
- Nginx对网络的依赖比较小,理论上能ping通就就能进行负载功能
- Nginx安装和配置比较简单,测试起来比较方便
- 也可以承担高的负载压力且稳定,一般能支撑超过1万次的并发
- 对后端服务器的健康检查,只支持通过端口来检测,不支持通过url来检测
- Nginx对请求的异步处理可以帮助节点服务器减轻负载
- Nginx仅能支持http、https和Email协议,适用范围较小
- 不支持Session的直接保持,但能通过ip_hash来解决
- 支持负载均衡算法：Round-robin(轮循),Weight-round-robin(带权轮循),Ip-hash(Ip哈希)
- Nginx还能做Web服务器即Cache功能
Haproxy
- 支持两种代理模式：TCP(四层)和HTTP(七层),支持虚拟主机
- 能够补充Nginx的一些缺点比如Session的保持,Cookie的引导等工作
- 支持url检测,后端的服务器出问题的检测会有很好的帮助
- 更多的负载均衡策略：动态加权轮循(Dynamic Round Robin),加权源地址哈希(Weighted Source Hash),加权URL哈希和加权参数哈希(Weighted Parameter Hash)
- 单纯从效率上来讲HAProxy更会比Nginx有更出色的负载均衡速度
- HAProxy可以对Mysql进行负载均衡,对后端的DB节点进行检测和负载均衡
- 支持负载均衡算法：Round-robin(轮循)、Weight-round-robin(带权轮循)、source(原地址保持)、RI(请求URL)、rdp-cookie(根据cookie)
- 不能做Web服务器和Cache
LVS介绍
LVS概述
- Linux Virtual Server,也就是Linux虚拟服务器，简称LVS
- 是Linux内核的一部分,因此性能高
- 它不真正提供服务,但它接受客户的访问,为整个集群提供一个唯一的入口。虚拟服务器再和真实服务器通信
- 真实服务器(Real Server):它真正提供服务,集群中每个Real Server可以是一台物理主机,也可以是虚拟机
中文文档
- http://linuxvirtualserver.org/zh/index.html
LVS相关术语
-
DS
- Director Server。指的是前端负载均衡器节点
-
RS
- Real Server。后端真实的工作服务器
-
VIP
- 向外部直接面向用户请求,作为用户请求的目标的IP地址
-
DIP
- Director Server IP,DS和内部主机通讯的IP地址
-
RIP
- Real Server IP,后端服务器的IP地址
-
CIP
- Client IP,客户端的IP地址
LVS四种模式
-
VS-NAT
-
网络地址转换模式, 进站/出站的数据流量都经过DS
-
优点
- 集群中的物理服务器可以使用任何支持TCP/IP的操作系统,只有负载均衡器需要一个合法的IP地址
-
缺点
- 当服务器节点过多时,大量的数据包都交汇在负载均衡器那,速度就会变慢
-
-
VS-DR
-
直接路由模式，只有进站的数据流量经过DS，出站流量直接发送至客户端
-
优点
- 不需要隧道结构,因此可以使用大多数操作系统做为物理服务器
-
限制
- 要求负载均衡器的网卡必须与物理网卡在一个物理段上
-
-
VS-TUN
-
隧道模式,只有进站的数据流量经过分发器
-
原理
- 把客户端发来的数据包,封装一个新的IP头标记(仅目的IP)发给RS,RS收到后,先把数据包的头解开,还原数据包,处理后,直接返回给客户端,不需要再经过负载均衡器｡由于RS需要对负载均衡器发过来的数据包进行还原,所以说必须支持IPTUNNEL协议
-
优点
- 只有进站数据经过DS,减少了负载均衡器的大量数据流动,能处理很巨大的请求量,这种方式,一台负载均衡器能够为很多RS进行分发。而且跑在公网上就能进行不同地域地分发
-
缺点
- 隧道模式的RS节点需要合法IP,这种方式需要所有的服务器支持”IP Tunneling”(IP Encapsulation)协议,服务器可能只局限在部分Linux系统上
-
-
full-nat
- 完全的NAT，修改源IP和目标IP
模式特点对比
-
模式
-
VS-NAT
-
VS-TUN
- VS-DR
-
-
-
服务器操作系统
-
任意
-
支持隧道
- 多数(支持Non-arp)
-
-
-
服务器网络
-
私有网络
-
局域网/广域网
- 局域网
-
-
-
服务器数目(100M网络)
-
10-20
-
100
- 大于100
-
-
-
服务器网关
-
负载均衡器
-
自己的路由
- 自己的路由
-
-
-
效率
-
一般
-
高
- 最高
-
-
ipvsadm命令
安装
- yum -y install ipvsadm
作用
- 用于在Linux内核中设置、维护或检查虚拟服务器表
- 虚拟服务器定义了访问集群的数据包的匹配条件及调度策略
参数
-
虚拟服务器
-
-A
-
新增虚拟服务器记录
- ipvsadm -A -t 192.168.10.11:80 -s rr
-
-
-E
- 修改虚拟服务器记录
-
-D
- 删除虚拟服务器记录
-
-C
-
清除所有虚拟服务器记录
- ipvsadm -C
-
-
-S
-
保存虚拟服务器规则
- ipvsadm -Sn > /etc/sysconfig/ipvsadm
-
-
-R
-
恢复虚拟服务器规则
- ipvsadm -R < /etc/sysconfig/ipvsadm
-
-
-Z
-
虚拟服务表计数器清零
- ipvsadm -Z
-
-
-
真实服务器
-
-a
- 在虚拟服务器记录中新增集群真实服务器记录
- ipvsadm -a -t 192.168.10.11:80 -r 172.16.10.12:80 -m
-
-e
- 编辑真实服务器记录
-
-d
- 删除真实服务器记录
-
-r
- 真实服务器
-
-w
- 权值
-
-
查看
-
-c
-
显示LVS目前的连接
-
ipvsadm -ln -c
-
watch -n.5 ‘ipvsadm -Ln -c’
- 0.5秒刷新一次
-
-
-
-L|-l
-
显示内核虚拟服务器表
- ipvsadm -ln
-
-
-n
- 以数字形式输出IP地址和端口
-
–stats
-
显示统计信息
- ipvsadm -ln --stats
-
-
–rate
-
显示速率信息
- ipvsadm -Ln --rate
-
-
-h
- 帮助信息
-
-
虚拟服务器服务类型
-
-t
- tcp服务
-
-u
- udp服务
-
-f
- 经过iptables标记过的服务
-
-
LVS工作模式
-
-g
- 直接路由模式(默认)
-
-m
- NAT模式
-
-i
- 隧道模式
-
-
-s scheduler
-
指定调度算法，默认wlc
- rr|wrr|lc|wlc|lblc|lblcr|dh|sh|sed|nq
-
-
-p [timeout]
- 持久性连接，默认值为300s
IP负载均衡
介绍
- 在网络层通过修改请求目标地址进行负载均衡
- 请求包到达DS目标地址被改为RIP转发到RS，响应包到达DS源地址被改为VIP转发到用户
- IP负载均衡在内核进程完成数据分支,较反向代理负载均衡(在应用程序中分发数据)有更好的处理性能
- 所有请求响应都需要经过负载均衡服务器,集群的最大响应数据吞吐量受制于负载均衡服务器网卡带宽
LVS-NAT
-
原理
- 1). 用户请求发送给DS,先到内核空间的PREROUTING链。 此时报文源IP为CIP,目标IP为VIP
- 2). PREROUTING检查发现数据包的目标IP是本机,将数据包送至INPUT链
- 3). IPVS比对数据包请求的服务是否为集群服务,若是,修改其目标IP为RIP,然后发至POSTROUTING链。 此时报文的源IP为CIP,目标IP为RIP
- 4). POSTROUTING链通过选路,将数据包发送给Real Server
- 5). RS收到请求数据包,构建响应报文发回给DS。 此时报文的源IP为RIP,目标IP为CIP
- 6). DS将源IP修改为自己的VIP,然后响应给客户端。 此时报文的源IP为VIP,目标IP为CIP
-
特性
- RS应该使用私有地址,RS的网关必须指向DIP
- DIP和RIP必须在同一个网段内
- 请求和响应报文都需要经过Director Server,高负载场景中,DS易成为性能瓶颈
- 支持端口映射
- RS可以使用任意操作系统
- 缺陷：对Director Server压力会比较大,请求和响应都需经过director server
实验
-
规划
-
Client
- 192.168.10.10
-
Director
-
VIP
- 192.168.10.11
-
DIP
- 172.16.10.11
-
-
Real Server A
- 172.16.10.12
-
Real Server B
- 172.16.10 .13
-
-
配置
-
Real Server A
- yum install httpd
- echo web1 >/var/www/html/index.html;systemctl start httpd
- route add default gw 172.16.10.11
-
Real Server A
- yum install httpd
- echo web2 >/var/www/html/index.html;systemctl start httpd
- route add default gw 172.16.10.11
-
Director
- echo 1 > /proc/sys/net/ipv4/ip_forward
- yum install ipvsadm
- ipvsadm -A -t 192.168.10.11:80 -s rr
- ipvsadm -a -t 192.168.10.11:80 -r 172.16.10.12:80 -m
- ipvsadm -a -t 192.168.10.11:80 -r 172.16.10.13:80 -m
-
-
验证
-
Client
- for i in {1…100};do curl 192.168.10.11;done
-
数据链路层
负载均衡
介绍
- 指在通信协议的数据链路层修改mac地址进行负载均衡
- 数据传输方式又称作三角传输模式，通过配置RS虚拟IP与DS一致，实现不修改IP只修改MAC进行数据分发
- 负载均衡方式又称作直接路由方式(DR)，请求响应包不经过DS而直接返回给用户，避免DS瓶颈
- 是目前大型网站使用最广的一种负载均衡手段。在linux平台上最好的链路层负载均衡开源产品是LVS
LVS-DR
-
原理
- 1). 用户请求发送给DS,先到内核空间的PREROUTING链。 此时报文源IP为CIP,目标IP为VIP
- 2). PREROUTING检查发现数据包的目标IP是本机,将数据包送至INPUT链
- 3). IPVS比对数据包请求的服务是否为集群服务,若是,将请求报文中的源MAC修改为DIP的MAC地址,将目标MAC修改RIP的MAC地址,然后将数据包发至POSTROUTING链
- 4). 由于DS和RS在同一个网络中,所以是通过二层来传输。POSTROUTING链检查目标MAC地址为RIP的MAC地址,那么此时数据包将会发至Real Server
- 5). RS接收报文，处理完成之后,将响应报文通过lo接口传送给eth0网卡然后向外发出。 此时的源IP地址为VIP,目标IP为CIP
- 6). 响应报文最终送达至客户端
-
特性
- 保证前端路由将目标地址为VIP报文全都只发给Director Server,而不是RS
- RS可以使用私有地址；也可以是公网地址,如果使用公网地址,此时可以通过互联网对RIP进行直接访问
- RS跟Director Server必须在同一个物理网络中
- 所有的请求报文经过Director Server,响应报文直接由RS回给客户端
- 不支持地址转换,也不支持端口映射
- RS可以是大多数常见的操作系统
- RS的网关绝不允许指向DIP(因为我们不允许他经过director)
- RS上的lo接口配置VIP的IP地址
-
过程及
解决方案-
1). 客户端要找vip访问80端口,因为是在同一个网段,所以发arp广播找vip的mac地址通信
-
2). 因为RS上也有vip,不能让RS上的vip回应arp广播,所以设置内核参数arp_ignore的内容为1
- 1表示如果接收的网卡上没有这个ip就不做出响应
- 0表示任任意网卡上有这个ip就响应发送mac地址
-
3). 当DS的vip收到这个广播之后,回应mac地址,然后收到客户端发来的80端口请求,再通过lvs分发到一个RS
-
4). 那么DS如何分发到一个RS？
- dip发出arp广播询问RIP所对应的mac地址,然后发出一个目标ip为VIP,目标mac为RIP-MAC的包到RS
-
5).DS如何指定通过DIP发出？
- 确保DIP网卡的路由优先级比VIP高，或直接删除VIP网卡的路由
-
6). RS必须要使用vip把回应包发出去，那么怎样让RS使用lo的vip而不使用eth0?
- 设置arp_announce为2, 2表示使用本机最好的本地IP地址把回应包发出去
-
7). 怎么算是最好的本地IP地址？
- 同一个网段下,子网掩码最长的IP地址被认为是好IP(更精确)
-
实验
-
规划
-
Client
- 192.168.10.10/24
-
Director
-
VIP
- 192.168.10.100/24
-
DIP
- 192.168.10.13/24
-
-
Real Server A
-
RIP
- 192.168.10.11/24
-
VIP
- 192.168.10.100/32
-
-
Real Server B
-
RIP
- 192.168.10.12/24
-
VIP
- 192.168.10.100/32
-
-
-
配置
-
Real Server A & B
-
ifconfig lo:1 192.168.10.100 netmask 255.255.255.255
- 本地环回接口
-
echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore
-
echo 2 > /proc/sys/net/ipv4/conf/all/arp_announce
-
-
Director
- ipvsadm -A -t 192.168.10.100:80 -s rr
- ipvsadm -a -t 192.168.10.100:80 -r 192.168.10.11:80 -g
- ipvsadm -a -t 192.168.10.100:80 -r 192.168.10.12:80 -g
-
-
验证
-
Client
- for i in {1…100};do curl 192.168.10.100;done
-
LVS持久性连接
是什么
- 用来保证当来自同一个用户的请求时能够定位到同一台服务器
为啥要用
-
cookie/session机制
- HTTP是无状态协议,不能标识用户来源,当用户在一个网站浏览了A网页并跳转到B网页,此时服务器就认为B网页是一个新的用户请求,之前的登陆就失效了
- 为了记录用户的会话信息,当访问网站时,服务器端建立一个session会话区,并建立一个cookie与这个session绑定,将cookie信息发送给浏览器
- 这样,只要浏览器cookie存在,服务器端的session存在,那么当开新页面的时候,服务器依然能识别该浏览器
-
cookie/session由
负载均衡导致的问题- 负载均衡时不能确保将同一用户根据session发往同一个服务器,用户第一次被分配到了A服务器,第二次可能分到B,但B并没有A服务器用户的session记录
-
session保持方案
-
将来自于同一个用户的请求发往同一个服务器
- sh算法
- 持久连接
-
将session信息在服务器集群内共享,每个服务器都保存整个集群的session信息
-
建立一个session存储池,所有session信息都保存到存储池中
-
sh算法
- hash算法在内核中自动维护一个哈希表,表中用每一个请求的源IP地址作为键,把请求所到达的RS的地址作为值
- 在后面的请求中,每一个请求会先经过此哈希表,如果请求在此哈希表中有键值,那么直接定向至特定RS,如没有,则会新生成一个键值
- 但是此种方法在时间的记录上比较模糊(依据TCP的连接时长计算),而且其是算法本身,所以无法与算法分离
持久连接
- 实现了无论使用哪一种调度算法,持久连接功能都能保证在指定时间范围之内,来自于同一个IP的请求将始终被定向至同一个RS,还可以把多种服务绑定后统一进行调度
- 在director内有一个LVS持久连接模板,模板中记录了每一个请求的来源、调度至的RS、维护时长等
- 在新的请求进入时,首先在此模板中检查是否有记录，如果该记录未超时,则使用该记录所指向的RS
- 如果是超时记录或者是新请求,则会根据调度算法先调度至特定RS,再将调度的记录添加至此表中
持久连接方式
-
PCC
- 每客户端持久
- 将来自于同一个客户端的所有请求统统定向至此前选定的RS
- 也就是只要IP相同,分配的服务器始终相同
-
PPC
- 每端口持久
- 将来自于同一个客户端对同一个服务(端口)的请求,始终定向至此前选定的RS
- 如：来自同一个IP的用户第一次访问80端口分配到A,访问25号端口分配到B。当之后这个用户继续访问80端口仍然分配到A,25号端口仍然分配到B
-
PFMC
- 持久防火墙标记连接
- 将来自于同一客户端对指定防火墙标记的请求,始终定向至此选定的RS
- 如：使用iptables将80和443端口标记为同一值,使用该值创建虚拟服务器。当用户访问80端口分配到A,访问443端口仍分配到A
如何定义
-
PCC
- ipvsadm -A -t 192.168.1.200:0 -s rr -p 600
ipvsadm -a -t 192.168.1.200:0 -r 192.168.1.10
ipvsadm -a -t 192.168.1.200:0 -r 192.168.1.20 - 端口为0，表示所有端口
- ipvsadm -A -t 192.168.1.200:0 -s rr -p 600
-
PPC
- ipvsadm -A -t 192.168.10.100:80 -s rr -p 300
ipvsadm -a -t 192.168.1.100:80 -r 192.168.1.10
ipvsadm -a -t 192.168.1.100:80 -r 192.168.1.20
- ipvsadm -A -t 192.168.10.100:80 -s rr -p 300
-
PFMC
- iptables -t mangle -A PREROUTING -d 192.168.1.200 -p tcp -m multiport --dports 80,443 -j MARK --set-mark 80
- ipvsadm -A -f 80 -s rr -p 600
ipvsadm -a -f 80 -r 192.168.1.10
ipvsadm -a -f 80 -r 192.168.1.20
实验
-
目的
- 通过防火墙标记解决端口亲缘性问题
-
规划
-
client
- 1.1.1.14
-
director
-
VIP
- 1.1.1.55
-
DIP
- 1.1.1.11
-
-
RS A
-
VIP
- 1.1.1.55
-
RIP
- 1.1.1.12
-
-
RS B
-
VIP
- 1.1.1.55
-
RIP
- 1.1.1.13
-
-
-
配置
pasv_min_port=50000
pasv_max_port=60000
- systemctl start csftpd
- director
- iptables -t mangle -A PREROUTING -d 1.1.1.55 -p tcp -m multiport --dports 20,21,50000:60000 -j MARK --set-mark 21
- ipvsadm -A -f 21 -s rr -p 30
- ipvsadm -a -f 21 -r 1.1.1.12
- ipvsadm -a -f 21 -r 1.1.1.13
LVS调度算法
rr
- 轮叫调度(Round Robin)
- 将外部请求按顺序轮流分配到集群中的真实服务器上
- 均等地对待每一台服务器,而不管服务器上实际的连接数和系统负载
wrr
- 加权轮叫(Weighted Round Robin)
- 根据真实服务器的不同处理能力来调度访问请求
- 调度器可以自动问询真实服务器的负载情况,并动态地调整其权值
lc
- 最少链接(Least Connections)
- 动态地将网络请求调度到已建立的链接数最少的服务器上
- 如果集群系统的真实服务器性能相近,采用lc可以较好地均衡负载
wlc
- 加权最少链接(Weighted Least Connections)
- 服务器性能差异较大的情况下,采用wlc优化负载均衡性能
- 较高权值的服务器承受较大比例的活动连接负载
- 调度器可以自动问询真实服务器的负载情况,并动态地调整其权值
lblc
- 基于局部性的最少链接(Locality-Based Least Connections)
- 针对目标IP地址的负载均衡,目前主要用于Cache集群系统(目标ip是变化的)
- 根据请求的目标IP地址找出该目标IP地址最近使用的服务器，若该服务器是可用的且没有超载,将请求发送到该服务器
- 若服务器不 存在，或者该服务器超载且有服务器处于其一半的工作负载，则用“最少链接”的原则选出一个可用的服务器，将请求发送到该服务器
lblcr
- 带复制的基于局部性最少链接(Locality-Based Least Connections with Replication)
- 针对目标IP地址的负载均衡,目前主要用于Cache集群系统
- lblcr维护从一个目标IP地址到一组服务器的映射,而lblc维护从一个目标IP地址到一台服务器的映射
- 根据目标IP找出其对应的服务器组,按lc从中选出一台服务器,若未超载,将请求发送到该服务器
- 若服务器超载,则按lc从集群中选出一台服务器,将其加入到服务器组中,将请求发送到该服务器
- 当该服务器组有一段时间没有被修改,将最忙的服务器从服务器组中删除,以降低复制的程度
sed
-
最短的期望的延迟(Shortest Expected Delay Scheduling SED)
-
基于wlc算法，若wlc算法得出的各服务器载荷一致，将请求分配到权值最高的服务器
-
示例
- ABC三台机器分别权重123 ,连接数也分别是123
- 如果使用wlc，新请求可能会分给ABC中的任意一个
- 使用sed会进行一个运算：A(1+1)/1 B(2+1)/2 C(1+3)/3，根据结果分配给C
nq
- 最少队列调度(Never Queue Scheduling NQ)
- 无需队列。如果有台服务器的连接数为0就直接分配过去,不需要在进行sed运算
dh
- 目标地址散列(Destination Hashing)
- 根据请求的目标IP地址,作为散列键(Hash Key)从静态分配的散列表找出对应的服务器
- 该服务器是可用的且未超载,将请求发送到该服务器,否则返回空
- 特点：查找速度快
sh
- 源地址散列(Source Hashing)
- 根据请求的源IP地址,作为散列键(Hash Key)从静态分配的散列表找出对应的服务器
- 若该服务器是可用的且未超载,将请求发送到该服务器,否则返回空
HAProxy
介绍
-
是一款高性能TCP/HTTP反向代理负载均衡服务器
-
功能
- 根据静态分配的cookies完成HTTP请求转发
- 在多个服务器间实现负载均衡,并且根据HTTP cookies 实现会话粘性
- 主备服务器切换
- 接受访问特定端口实现服务监控
- 实现平滑关闭服务,不中断已建立连接的请求响应,拒绝新的请求
- 在请求或响应HTTP报文中添加,修改,或删除首部信息
- 根据正则规则阻断请求
- 提供带有用户认证机制的服务状态报告页面
-
haproxy请求报文头部默认已传递X-Forwarded-For真实ip，在真实服务器修改日志格式即可获取
-
安装
- yum -y install haproxy
配置文件
-
路径
- /etc/haproxy/haproxy.cfg
-
组件
-
global
- 参数是进程级的,通常和操作系统相关
-
defaults
-
配置默认参数的,这些参数可以被利用配置到frontend,backend,listen组件
-
mode http
- 默认的模式，tcp是4层，http是7层，health只会返回ok
-
-
frontend
- 接收请求的前端虚拟节点,Frontend可以根据规则直接指定具体使用后端的backend(可动态选择)
- frontend main *:5000 #服务监听端口
acl url_static path_beg -i /static /images #访问路径以这些开头的标记为url_static
acl url_static path_end -i .jpg .gif .png .css .js #访问路径以这些结尾的标记为url_static
use_backend static if url_static #符合url_static的使用static集群
default_backend app #定义默认backend为app集群-
backend
- 后端服务集群的配置,是真实的服务器,一个Backend对应一个或者多个实体服务器
- backend static #定义static集群
balance roundrobin #定义调度算法
server static1 1.1.1.14:80 check #集群中真实服务器
backend app #定义app集群
balance roundrobin
server app1 1.1.1.12:80 check #一定要写端口
server app2 1.1.1.13:80 check
-
listen
- Frontend和Backend的组合体
-
状态页
-
在defaults里设置
-
stats uri /status
- 访问状态页的路径
-
stats hide-version
- 隐藏软件版本号
-
stats auth tom:123
- 设置授权用户及密码
-
stats refresh 30s
- 状态页刷新时间
日志
$ModLoad imudp #打开注释
$UDPServerRun 514 #打开注释
local2.* /var/log/haproxy.log #添加记录
-
重启服务
- systemctl restart rsyslog haproxy
-
默认保存在message日志中
ACL访问控制
-
acl定义语法
- acl 名称 匹配类型 [选项] [参数]
-
匹配类型
-
dst
- 目标地址
-
dst_port
- 目标端口
-
src
-
源地址
- acl badguy src 1.1.1.16
-
-
src_port
- 源端口
-
XX_reg
-
正则匹配,根据正则表达式列表匹配文本(相比字符匹配慢很多)
-
hdr_reg(xx)
- 某个首部的值匹配什么正则表达式
- acl bbs hdr_reg(host) -i ^(bbs.test.com|shequ.test.com|forum)
- acl with_ip hdr_reg(host) -i [0-9]$
-
path_reg
- 访问路径匹配正则表达式
- acl url_static path_reg -i (.jpg$|^/static)
-
-
XX_beg
-
前缀匹配,检查文本是否以指定字符串开头
-
hdr_beg(xx)
- 某个首部以什么开头
- acl www hdr_beg(host) -i www.test.com
-
path_beg
- 路径以什么开头
- acl bbs_path path_beg -i /bbs
-
-
XX_end
-
后缀匹配,检查文本是否以指定字符串结尾
-
hdr_end(xx)
- 某个首部以什么结尾
- acl with_ip hdr_end(host) -i 1.1.1.15
-
path_end
- 路径以什么结尾
- acl static path_end -i .html .css .js
-
-
-
选项
-
-i
- 不区分大小写
-
-
使用acl的
控制指令-
block
-
block if badguy
- 禁止符合acl名称为badguy的用户访问
-
后续版本可能取消
-
-
use_backend
-
tcp-request
-
4层tcp连接控制
-
tcp-request connection accept if goodguys
- 如果是goodguys则允许连接
-
tcp-request connection reject
- 拒绝所有连接
-
-
http-request
-
7层访问控制
-
http-request allow if url_stats manager
- 同时满足url_stats和manager时允许
-
http-request deny if url_stats
- 只满足url_stats时禁止
-
-
redirect
-
-
说明
- 使用acl必须提前定义
- 同名的acl之间是或的关系
- 同一个acl中的多个参数之间是或的关系
- 同一个控制指令中的多个acl之间是与的关系
- 访问控制指定匹配按从上到下的顺序，匹配到即执行相应的指令
调度算法
-
balance
-
定义负载均衡调度算法，可用于defaults、listen、backend
-
算法
-
roundrobin
- 基于权重轮询，动态算法
-
static-rr
- 基于权重轮询，静态算法
-
leastconn
- 最少连接
-
source
- 源地址哈希，默认为静态调度
-
uri
- 对uri的左半部分或整个uri进行哈希运算，可使得对同一个uri的请求派发至同一服务器
-
url_param
- 可使得同一个用户ID的请求派发至同一个服务器
-
hdr()
- 对每个http请求通过name指定的头部进行检索，没有则使用轮叫调度
-
rdp-cookie()
- 根据cookie(name)来锁定并哈希每一次TCP请求
-
-
-
hash-type
-
定义将hash码映射到后端服务器的方法，不能用于frontend。大多数场景下推荐使用默认的map-based
-
方法
-
map-based
- hash表是一个包含了所有在线服务器的静态数组，挑选服务器是根据其在数组中的位置进行，不适用于缓存服务器的工作场景
-
consistent
- hash表是一个由各服务器填充而成的树状结构；基于hash键在hash树中查找相应的服务器时,最近的服务器将被选中。适用于后端服务器为cache的场景
-
-
HA集群
介绍
- 高可用集群(High Availability Cluster)
- 集群(cluster)就是一组计算机,它们作为一个整体向用户提供一组网络资源。每一个单个的计算机系统都叫集群节点(node)
- 计算机硬件和软件易错性不可避免,这样在节点上的服务会不可避免的中断
- 高可用集群在一组计算机中,采用主备模式,主节点提供服务,备节点等待；一旦主节点失效,备节点无需人工无缝取代主节点提供服务,这样保证了服务的不中断
- 高可用集群软件的主要作用就是实现故障检查和业务切换的自动化,以提供不中断的服务
衡量标准
-
平均无故障时间(MTTF)度量系统的可靠性(reliability)
平均维修时间(MTTR)度量系统的可维护性(maintainability) -
HA=MTTF/(MTTF+MTTR)*100%
-
99%
- 一年宕机时间不超过4天
-
99.9%
- 一年宕机时间不超过10小时
-
99.99%
- 一年宕机时间不超过1小时
-
99.999%
- 一年宕机时间不超过6分钟
-
层次结构
-
信息层
(Messaging)- 也叫底层基础架构层/心跳层，主要用于节点之间传递心跳信息，通过广播、组播、单播等方式
- 心跳信息：集群中每一台服务器都不停的将自己在线的信息通告给集群中的其他主机
- 心跳传递通过软件提供服务监听套接字,实现数据发送、请求。实现HA的基础：安装软件开启服务
-
成员层
(Membership)-
通过CCM服务由Messaging层提供的信息,来产生一个完整的成员关系
-
CCM组件
- (Cluster Consensus Menbership Service)：监听底层的心跳信息,当监听不到时候重新计算整个集群的票数和收敛状态信息,并将结果转递给上层
-
Messaging & Membership一般由同一软件实现
-
-
资源分配层
(Resource Allocation)-
真正实现集群服务的层。包含CRM,CIB,PE,TE, LRM
-
CRM组件
- 集群资源管理器cluster Resource Manager：核心组件,实现资源的分配和管理
- 主节点上的CRM被选举为DC(Designated Coordinator)，决策和管理集群中的所有资源，DC上运行PE和TE
-
PE
- 策略引擎Policy Engine：定义资源转移的一整套转移方式
-
TE
- 实施引擎Transition Engine：执行PE做出的策略
-
CIB组件
- 集群信息基库,Cluster Infonation Base
- XML格式的配置文件,工作时常驻内存,只有DC才能对CIB进行修改,其他节点复制DC上的CIB。集群的所有信息都会反馈在CIB中
-
LRM组件
- Local Resource Manager本地资源管理器：CRM管理资源的具体执行人
-
资源
- 在集群中构成一个完整服务的每一部分都叫资源
-
-
资源代理层
(Resource Agents)- 管理本节点上的集群资源启动,停止和状态信息的脚本
-
工作机制
- PE根据CIB获取资源的配置信息,而后做出决策,再进行资源的管理
- PE借助CCM通知其它节点CIB来实现资源管理信息的传递
- 比如通告其它CRM要启动某一资源,CRM收到后,转由LRM启动,而并发资源又借助于资源代理实现资源管理
高可用集群软件
-
Messaging and Membership Layer
- heartbeat (v1,v2,v3)
- corosync
- cman
- keepalived
- ultramokey
-
Cluster Resource Manager Layer
- haresource,crm (heartbeat v1/v2)
- pacemaker (heartbeat v3/corosync)
- rgmanager (cman)
-
常用组合
-
corosync+pacemaker
- 现在最常用的组合
-
cman + rgmanager
- 红帽集群套件中的组件,还包括gfs2,clvm
-
keepalived+lvs
- 常用于lvs的高可用
-
keepalived
介绍
-
作用
- 集群管理中保证集群高可用的一个服务软件,用来防止单点故障
-
原理
-
以VRRP协议为实现基础,VRRP全称Virtual Router Redundancy Protocol,即虚拟路由冗余协议
-
vrrp
- 将N台提供相同功能的路由器组成一个路由器组,这个组里面有一个master和多个backup
- master上面有一个对外提供服务的vip(该路由器所在局域网内其他机器的默认路由为该vip)
- master会持续发组播消息(地址224.0.0.18),当backup收不到vrrp包时就认为master宕掉了,此时根据vrrp的优先级选举一个backup当master并接管vip，由新的master提供服务
-
模块
-
core
- keepalived的核心,负责主进程的启动、维护以及全局配置文件的加载和解析
-
check
- 负责健康检查,包括常见的各种检查方式
-
vrrp
- 实现VRRP协议
-
-
-
keepalived+LVS
- 实现LVS服务高可用，用于避免LVS单点故障
keepalived+LVS/DR
-
规划
-
DS master
- 1.1.1.14
-
DS backup
- 1.1.1.15
-
VIP
- 1.1.1.111
-
RS 1
- 1.1.1.12
-
RS 2
- 1.1.1.13
-
-
配置
global_defs {
…
#vrrp_strict #注释掉,否则vip漂移后自动生成一条drop规则
}
vrrp_instance VI_1 {
…
state BACKUP #避免脑裂都设为BACKUP,实际生效取决于优先级
interface ens33
priority 100 #优先级，[1,254]
nopreempt #高优先级服务恢复后不抢占vip
advert_int 1 #检查间隔,单位秒
virtual_ipaddress {
1.1.1.111 #vip，默认掩码32位
}
}
virtual_server 1.1.1.111 { #LVS 配置
delay_loop 3 #服务轮询的时间间隔
lb_algo rr #LVS调度算法
lb_kind DR #LVS集群模式
#persistence_timeout 50 #持久连接超时时间，关闭
protocol TCP
real_server 1.1.1.12 80 { #RS配置
weight 1
TCP_CHECK { #RS健康检查
connect_timeout 3
}
}
real_server 1.1.1.13 80 {
weight 1
TCP_CHECK {
connect_timeout 3
}
}
}
- systemctl start keepalived
- DS backup
- yum install keepalived -y
- scp 1.1.1.12:/etc/keepalived/keepalived.conf /etc/keepalived/
- # vim /etc/keepalived/keepalived.conf
priority 90
- systemctl start keepalived
- RS 1 & 2
- ifconfig lo:0 1.1.1.55/32
- echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore
- echo 2 > /proc/sys/net/ipv4/conf/all/arp_announce
-
测试
-
client
- curl 1.1.1.111
- 关闭DC master上的keepalived，curl 1.1.1.111
-
DS
- tcpdump -i any -nnvvv vrrp
-
keepalived+script
实现nginx高可用
…
vrrp_script down { #down为自定义名字
script “/tmp/check.sh” #脚本路径
interval 3 #执行间隔时间
weight -20 #脚本返回非0,则降低优先级
fall 2 #连续检测2次失败才算真的失败
rise 1 #检测1次成功就算成功
}
vrrp_instance VI_1 {
…
nopreempt
track_script { #执行脚本
down #与vrrp_script一致
}
}
- 脚本
- # vim /tmp/check.sh
#!/bin/bash
pgrep nginx
- chmod +x /tmp/check.sh
- nginx A&B
- # vim /etc/nginx/nginx.conf
http {
…
upstream webs {
server 1.1.1.12;
server 1.1.1.13;
}
server {
…
location / {
proxy_pass http://webs;
}
}
}
-
script说明
- 脚本成功执行且weight为正值，则优先级增加
- 脚本失败执行且weight为负值，则优先级降低
- 其他情况优先级不变
- 优先级增加或降低只会执行一次
- VIP漂移会造成短时间的服务不可用, 应尽量减少(设置不抢占)
- selinux开启会影响脚本的执行结果, 进而影响优先级
3082
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
